ระบบบริหารการชำระเงิน Loco Payment Gateway Management

Loco Payment Gateway Management เป็นระบบบริหารการชำระเงินออนไลน์ของ LOCO ทำหน้าที่เป็น ศูนย์ควบคุมการรับชำระเงินจากทุกจุดรับเงิน ตั้งแต่ลูกค้าสแกน QR พร้อมเพย์ แตะบัตรเครดิต ผ่อนชำระ หรือจ่ายผ่านวอลเล็ต ไปจนถึงรอบโอนเงินเข้าบัญชีบริษัท โดยทำงานเชื่อมกับระบบของธนาคาร KBank และ SCB ทั้งการขอรายการชำระ การรับผลยืนยันอัตโนมัติ และการกระทบยอดรายวัน

ระบบถูกออกแบบให้ทีมปฏิบัติการและการเงินเห็นทุกอย่างจบในที่เดียว: ธุรกรรมทุกรายการตรวจย้อนได้ ค่าธรรมเนียมแยกตามช่องทาง รอบโอนและกระทบยอดชัดเจน และจัดการจุดรับเงินได้ทุกแห่งในเครือ ปัจจุบันระบบอยู่ในเวอร์ชันต้นแบบที่ทำงานครบทุกหน้าจอในโหมดสาธิต พร้อมการออกแบบการเชื่อมต่อจริงที่ระบุไว้ในบทที่ 6 และ 9

สิ่งที่ระบบทำได้ในภาพรวม

• ภาพรวมเรียลไทม์: ยอดรับชำระวันนี้ อัตราความสำเร็จ ยอดรอชำระบัญชี และยอดคืนเงิน พร้อมกราฟแยกรายธนาคารและสถานะการเชื่อมต่อ
• ธุรกรรมครบวงจร: ค้นหาและกรองทุกมิติ ดูรายละเอียดแบบไทม์ไลน์ คืนเงิน ส่ง Webhook ซ้ำ และส่งออกไฟล์ CSV
• ลิงก์ชำระเงิน: สร้าง QR และลิงก์เรียกเก็บเงินรายรายการ พร้อมวันหมดอายุและการติดตามสถานะ
• คืนเงิน: คืนแบบเต็มจำนวนหรือบางส่วน ส่งคำขอไปธนาคาร และติดตามผลจนจบขั้นตอน
• กระทบยอดและรอบโอน: รวมยอดรายวันเป็นรอบ T+1 หักค่าธรรมเนียม แสดงความถูกต้องของทุกรอบ และแจ้งเมื่อยอดไม่ตรง
• ช่องทางธนาคาร: เปิดและปิดบริการของ KBank และ SCB ต่อจุดรับเงิน จัดการคีย์เชื่อมต่อ Webhook และค่าธรรมเนียม
• จุดรับเงิน: บริหารสถานะและบริการของจุดรับเงินทุกแห่ง พร้อมยอดรับชำระล่าสุดของแต่ละจุด
• รายงาน: สรุปยอดรับชำระ ค่าธรรมเนียม และอัตราความสำเร็จ แยกตามวัน จุดรับเงิน และช่องทาง พร้อมส่งออก CSV
• ผู้ใช้และสิทธิ์: 4 บทบาท 10 สิทธิ์ กำหนดขอบเขตจุดรับเงินที่แต่ละคนรับผิดชอบได้
• บันทึกระบบ: ประวัติการเรียก API และการส่ง Webhook ทุกครั้ง พร้อมความหน่วงและผลตอบกลับสำหรับตรวจสอบ

ขอบเขตของเอกสารฉบับนี้

เอกสารนี้อธิบาย ระบบต้นแบบเวอร์ชัน V1 ตามที่สร้างจริง ณ วันที่ระบุ โดยแยกให้ชัดเจนระหว่าง (หนึ่ง) ส่วนที่ทำงานแล้วในโหมดสาธิต ซึ่งเปิดใช้ได้ทันทีจากไฟล์เว็บแอป และ (สอง) ส่วนการเชื่อมต่อธนาคารจริง ซึ่งออกแบบไว้พร้อมใช้งานและสรุปขั้นตอนดำเนินการไว้ในบทที่ 9 เอกสารนี้จึงใช้ได้ทั้งสำหรับทบทวนการออกแบบ ชี้แจงผู้มีส่วนได้ส่วนเสีย และเป็นคู่มือตั้งต้นของทีมที่ดูแลระบบต่อ

ระบบแบ่งการทำงานเป็นสามชั้นชัดเจน ได้แก่ ชั้นคอนโซลบริหารสำหรับทีมงาน ชั้นบริการชำระเงินที่สร้างรายการและรับผลจากธนาคาร และชั้นเชื่อมต่อธนาคารที่คุยกับ KBank และ SCB ในเวอร์ชันต้นแบบ ชั้นทั้งหมดรวมอยู่ในไฟล์เว็บแอปเดียวเพื่อสาธิตครบทุกฟังก์ชัน เมื่อใช้งานจริง แยกเป็นหน้าบ้าน ระบบบริการ และฐานข้อมูลกลางตามแนวทางที่ระบุในแผนภาพ โดยใช้แนวทางแบบเดียวกับระบบ LOCO24Park ที่ใช้งานอยู่แล้ว (Cloudflare Worker + D1)

องค์ประกอบหลัก

การไหลของคำขอ

ทุกการทำงานในระบบเดินตามเส้นทางเดียวกันเสมอ ทำให้ตรวจสอบและต่อระบบเพิ่มได้ง่าย:

1. เข้าสู่ระบบ: ผู้ใช้เปิดคอนโซลและยืนยันตัวตน ระบบตรวจสิทธิ์ตาม 4 บทบาทก่อนแสดงข้อมูล
2. สร้างรายการรับชำระ: จากจุดรับเงินหรือลิงก์ชำระเงิน ระบบส่งคำขอไปยังธนาคารของช่องทางนั้น
3. ลูกค้าชำระเงิน: ลูกค้าจ่ายในแอปธนาคารของตนเอง (QR บัตร หรือผ่อนชำระ) ไม่ผ่านหน้าจอของระบบ
4. รับผลยืนยัน: ธนาคารส่งผลกลับแบบ Webhook ระบบบันทึกธุรกรรมทันทีและแจ้งระบบปลายทาง
5. รวมรอบโอนและกระทบยอด: สิ้นวัน ระบบรวมยอดเป็นรอบ T+1 หักค่าธรรมเนียม และเทียบยอดกับธนาคารอัตโนมัติ
6. คืนเงินเมื่อจำเป็น: ทีมการเงินยืนยันคำขอ ระบบส่งไปธนาคารและติดตามผลจนบันทึกในรายงานครบถ้วน

ระบบแบ่งสิทธิ์ผู้ใช้เป็น 4 บทบาท ครอบคลุม 10 สิทธิ์ใน 4 กลุ่มงาน (ธุรกรรม การเงิน รายงาน และระบบ) โดยผู้ดูแลระบบกำหนดบทบาทของแต่ละคนได้ พร้อมกำหนดขอบเขตจุดรับเงินที่รับผิดชอบ (ทุกจุด หรือเลือกเฉพาะจุด) การแยกแบบนี้ทำให้ทีมปฏิบัติการสร้างรายการรับชำระได้ แต่แตะต้องงานเงินไม่ได้ และทีมการเงินคุมการคืนเงินกับกระทบยอดโดยไม่ต้องเห็นการตั้งค่าระบบ

คอนโซลประกอบด้วย 12 หน้าจอ เรียงตามการใช้งานจริงของทีมงาน ตั้งแต่เห็นภาพรวม ลงรายละเอียดธุรกรรม จนถึงการตั้งค่าและตรวจสอบย้อนหลัง ทุกหน้าจอใช้ข้อมูลชุดเดียวกัน การแก้ไขในหน้าหนึ่งจึงสะท้อนถึงหน้าอื่นทันที เช่น เมื่อคืนเงินจากหน้าธุรกรรม รายการจะปรากฏในหน้าคืนเงินและตัวเลขในภาพรวมพร้อมกัน

หลักการออกแบบหน้าจอ

• ตัวเลขที่เชื่อถือได้: ตัวเลขการเงินทุกตัวใช้ฟอนต์แบบตาราง (tabular) หลักตรงกันทุกแถว อ่านเทียบกันได้ทันที
• ทุกรายการตรวจย้อนได้: ทุกธุรกรรมมีไทม์ไลน์ ทุกการเรียก API มีบันทึก ทุกรอบโอนมีที่มาของยอด
• สองธนาคารเป็นพลเมืองชั้นหนึ่ง: สีและสัญลักษณ์ของ KBank และ SCB ปรากฏสม่ำเสมอทั้งระบบ ช่วยการกวาดสายตาแยกรายธนาคารได้ทันที
• ใช้ได้ทุกขนาดจอ: หน้าจอทำงานได้บนเดสก์ท็อป แท็บเล็ต และมือถือ โดยตารางข้อมูลเลื่อนในกรอบของตนเองไม่ทำหน้าเว็บแตก

การทำงานของระบบวนอยู่กับวงจรเดียวเสมอ: สร้างรายการ ลูกค้าจ่าย ธนาคารยืนยัน บันทึกและแจ้งผล รวมรอบโอน กระทบยอด แล้วเข้าบัญชี วงจรนี้ทำงานอัตโนมัติเกือบทั้งหมด ทีมงานเข้ามาแทรกเฉพาะกรณีคืนเงินหรือเมื่อยอดกระทบไม่ตรงเท่านั้น

5.1 การรับชำระเงินที่จุดรับเงิน

1. ทีมงานเปิดรับชำระที่จุดรับเงิน เลือกวิธีชำระ (QR พร้อมเพย์ บัตรเครดิต/เดบิต ผ่อนชำระ หรือวอลเล็ต) และช่องทางธนาคาร
2. ระบบสร้างรายการและส่งคำขอไปยังธนาคารของช่องทางนั้น ลูกค้าชำระเงินในแอปธนาคารของตนเอง
3. ธนาคารประมวลผลและส่งผลยืนยันกลับแบบ Webhook ระบบบันทึกธุรกรรมพร้อมค่าธรรมเนียมตามอัตราที่ตั้งไว้
4. ระบบแจ้งผลไปยังระบบปลายทางทันที (เช่น ระบบลานจอด หรือเว็บไซต์) เพื่อให้งานต่อเนื่อง
5. ผู้ใช้เห็นรายการใหม่ในหน้าธุรกรรมทันที พร้อมสถานะและไทม์ไลน์ครบทุกขั้น
6. สิ้นวัน รายการที่สำเร็จจะถูกนับเข้ารอบโอนของธนาคารนั้น

5.2 การสร้างลิงก์ชำระเงิน

1. ทีมงานสร้างลิงก์ใหม่ ระบุหัวข้อ ยอดเงิน จุดรับเงิน ช่องทางธนาคาร และอายุลิงก์ (3, 7 หรือ 30 วัน)
2. ระบบออกรหัสลิงก์พร้อม QR สำหรับส่งให้ลูกค้าทางช่องทางใดก็ได้
3. ลูกค้าเปิดลิงก์และชำระเงินผ่านแอปธนาคาร เมื่อสำเร็จ ลิงก์เปลี่ยนเป็นสถานะ "ชำระแล้ว" อัตโนมัติ
4. ลิงก์ที่เลยกำหนดเปลี่ยนเป็น "หมดอายุ" เอง และทีมงานยกเลิกลิงก์ที่ไม่ใช้ได้ตลอดเวลา

5.3 การคืนเงิน

1. ทีมการเงินเปิดคำขอคืนเงิน เลือกธุรกรรมต้นทาง และระบุเหตุผล (ลูกค้ายกเลิกบริการ ชำระซ้ำซ้อน สแกน QR ซ้ำ หรืออื่น ๆ)
2. เลือกระหว่างคืนเต็มจำนวนอัตโนมัติ หรือคืนบางส่วนโดยระบุยอดเอง ระบบตรวจเพดานยอดให้ทันที
3. ยืนยันผ่านกล่องยืนยันการเงิน ระบบส่งคำขอไปยังธนาคารและตั้งสถานะ "รอดำเนินการ"
4. ธนาคารคืนเงินเข้าช่องทางเดิมของลูกค้า (ใช้เวลาประมาณ 1 ถึง 3 วันทำการ) ระบบอัปเดตสถานะเป็นสำเร็จหรือไม่สำเร็จพร้อมเหตุผล
5. ยอดคืนเงินปรากฏในภาพรวม หน้าคืนเงิน และรายงานอัตโนมัติ

5.4 การกระทบยอดและรอบโอนเงิน

1. สิ้นวัน ระบบรวมยอดรับชำระที่สำเร็จของแต่ละธนาคารเป็นรอบโอน (T+1) หักค่าธรรมเนียมตามอัตราต่อช่องทาง
2. ระบบเทียบยอดของระบบกับยอดที่ธนาคารรายงานอัตโนมัติ ผลลัพธ์เป็น 4 สถานะ: กระทบยอดแล้ว รอตรวจสอบ ไม่ตรง หรือรอโอน
3. รอบที่ยอดไม่ตรงจะแสดงส่วนต่างชัดเจน พร้อมขั้นตอนให้ทีมการเงินเทียบกับรายงานธนาคารก่อนยืนยัน
4. เมื่อยืนยันแล้ว ระบบบันทึกผลและแสดงยอดโอนสุทธิเข้าบัญชีบริษัทตามรอบของแต่ละธนาคาร (KBank 17:00 น. และ SCB 16:30 น. ในค่าตั้งต้น)
5. ทุกอย่างพร้อมสำหรับรายงานประจำวันและการปิดงบ โดยไม่ต้องรวบรวมยอดมือ

5.5 การจัดการช่องทางธนาคาร

1. ทีมเทคนิคแก้ไข Merchant ID Terminal Webhook และคีย์ของแต่ละธนาคารได้จากหน้าช่องทางธนาคาร
2. เปิดหรือปิดบริการรายวิธีชำระได้ทันที (เช่น ปิดรับผ่อนชำระชั่วคราว) โดยมีผลกับรายการใหม่ทันที
3. ทดสอบการเชื่อมต่อได้จากปุ่มทดสอบ ระบบรายงานเวลาตอบกลับของธนาคาร
4. ทุกการเปลี่ยนแปลงถูกบันทึกในบันทึกระบบพร้อมผู้ดำเนินการและเวลา

การเชื่อมต่อออกแบบเป็นสองทางเสมอ: ระบบเป็นฝ่ายส่งคำขอ (สร้างรายการชำระ คืนเงิน ตรวจสอบสถานะ) และเป็นฝ่ายรับผลผ่าน Webhook ที่ธนาคารเรียกกลับมาที่ระบบ ทั้งสองทางยืนยันความถูกต้องด้วยคีย์ของแต่ละช่องทาง และทุกคำขอถูกบันทึกไว้ในบันทึกระบบเพื่อการตรวจสอบ ในโหมดสาธิตปัจจุบัน เส้นทางเหล่านี้จำลองการทำงานครบถ้วน โดยไม่เรียกบริการจริงของธนาคาร

ข้อมูลที่ต้องเตรียมจากธนาคาร

• Merchant ID และ Terminal ID สำหรับแต่ละจุดรับเงิน (แยกตามธนาคาร)
• คีย์สำหรับเรียกบริการ (Merchant Secret / API Key) ระบบเก็บแบบเข้ารหัสและแสดงเพียงบางส่วน
• บัญชีสำหรับรับโอน ของแต่ละธนาคาร พร้อมรอบโอนที่ตกลงไว้
• อัตราค่าธรรมเนียม (MDR) ตามสัญญา แยกตามวิธีรับชำระ เพื่อให้ระบบคำนวณยอดสุทธิได้ตรง
• Webhook URL ปลายทาง ของระบบ คือ https://api.loco.cloud/hooks/payments/<ช่องทาง> พร้อม Secret สำหรับตรวจลายเซ็น

รูปแบบการรับผลยืนยัน (Webhook)

เมื่อลูกค้าชำระเงินสำเร็จ ธนาคารจะเรียกกลับมาที่ระบบพร้อมข้อมูลยืนยัน ระบบตรวจลายเซ็นก่อนบันทึกทุกครั้ง ตัวอย่างข้อมูลที่ระบบออกแบบไว้:

{
  "event":     "payment.succeeded",
  "ref":       "PG-20261016-0042",
  "bank":      "kbank",
  "method":    "qr",
  "amount":    450,
  "fee":       4.05,
  "net":       445.95,
  "currency":  "THB",
  "paid_at":   "2026-10-16 09:33:12",
  "signature": "X-Loco-Signature: t=1760599992, v1=6f3a..."
}

ความน่าเชื่อถือของการรับส่งผล

• ตรวจลายเซ็นทุกครั้ง: ใช้ HMAC-SHA256 ในหัวข้อ X-Loco-Signature ป้องกันข้อมูลปลอม
• ส่งซ้ำอัตโนมัติ: ระบบปลายทางที่ยังไม่ตอบรับจะได้รับ Webhook ซ้ำสูงสุด 3 ครั้ง (เว้นช่วง 2, 4 และ 8 วินาที) ป้องกันเหตุการณ์ตกหล่นชั่วคราว
• บันทึกครบทุกคำขอ: ทั้งขาเข้าและขาออก พร้อมรหัสผลตอบกลับและความหน่วง แสดงในหน้าบันทึกระบบ
• กระทบยอดเป็นด่านสุดท้าย: ก่อนโอนเงินทุกครั้ง ระบบเทียบยอดกับธนาคารอีกชั้นหนึ่ง ไม่โอนยอดที่ไม่ตรงโดยไม่มีการยืนยัน

ข้อมูลของระบบยึด ธุรกรรมเป็นศูนย์กลาง ทุกกลุ่มข้อมูลอื่นอ้างอิงกลับมาที่ธุรกรรมเสมอ ทำให้การตรวจสอบทำได้จากจุดเดียว: เปิดธุรกรรมหนึ่งรายการ แล้วเห็นได้ทันทีว่ามาจากจุดรับเงินใด ชำระผ่านช่องทางใด ถูกรวมในรอบโอนไหน มีการคืนเงินหรือไม่ และเกิดบันทึกอะไรขึ้นบ้าง

กติกาความถูกต้องของข้อมูล

• หนึ่งเลขอ้างอิงต่อหนึ่งรายการ: ทุกธุรกรรมมีรหัสเฉพาะรูปแบบ PG-วันเดือนปี-ลำดับ ใช้อ้างอิงกับธนาคาร ระบบปลายทาง และเอกสารได้ตลอดสาย
• คืนเงินไม่เกินยอดจริง: ยอดคืนสะสมทุกรายการของธุรกรรมหนึ่งต้องไม่เกินยอดชำระ และระบบตรวจเพดานให้ก่อนยืนยันทุกครั้ง
• หนึ่งลิงก์ชำระได้ครั้งเดียว: เมื่อลิงก์ถูกชำระสำเร็จ จะผูกกับธุรกรรมนั้นและไม่เปิดรับซ้ำ
• หนึ่งรอบโอนต่อธนาคารต่อวัน: ป้องกันยอดโอนซ้ำหรือตกหล่น และทำให้กระทบยอดตรวจได้ตรงกับรายงานธนาคารเสมอ

ระบบชำระเงินกำหนดให้ความปลอดภัยเป็นข้อบังคับ ไม่ใช่ตัวเลือก นโยบายของระบบวางไว้สองหลัก: เก็บข้อมูลน้อยที่สุด และ เปิดเผยเท่าที่จำเป็นต่อบทบาทเท่านั้น ข้อมูลบัตรไม่เคยผ่านระบบ เนื่องจากลูกค้าชำระในหน้าแอปธนาคารหรือหน้าของธนาคารโดยตรง

การยืนยันตัวตนและการเข้าถึง

• เข้าสู่ระบบด้วยอีเมลและรหัสผ่าน เมื่อใช้งานจริงรหัสผ่านจัดเก็บแบบเข้ารหัสทางเดียว (hashed) ไม่สามารถอ่านค่าต้นฉบับได้
• ผู้ดูแลระบบสามารถเปิดการยืนยันสองขั้นตอน (2FA) บังคับสำหรับบัญชีระดับผู้ดูแลได้
• เซสชันหมดอายุอัตโนมัติเมื่อไม่มีการใช้งานนาน (ค่าตั้งต้น 8 ชั่วโมง) และบังคับออกจากระบบทุกอุปกรณ์เมื่อเปลี่ยนรหัสผ่าน
• ทุกหน้าจอและทุกการสั่งงานตรวจสิทธิ์ตามบทบาท 4 ระดับ ก่อนแสดงหรือแก้ไขข้อมูล

การเก็บและการแสดงข้อมูลสำคัญ

• คีย์เชื่อมต่อธนาคารและคีย์ API ของระบบภายนอกจัดเก็บแบบเข้ารหัส แสดงเพียงบางส่วน (ปิดอักขระกลาง) และไม่ส่งค่ากลับในรายการใด ๆ
• การหมุนคีย์ (Rotate) ทำได้จากหน้าตั้งค่า พร้อมแจ้งเตือนให้อัปเดตคีย์ที่ระบบปลายทางภายใน 24 ชั่วโมง
• ข้อมูลลูกค้าที่แสดงในธุรกรรมถูกปิดบางส่วน เช่น เบอร์โทรศัพท์ แสดงเท่าที่จำเป็นต่อการติดตามงาน

ความปลอดภัยของการรับส่งข้อมูล

• การรับส่งทุกเส้นทางผ่าน HTTPS ทั้งหมด ไม่มีเส้นทางไม่เข้ารหัส
• Webhook ทุกเส้นทางตรวจลายเซ็น HMAC-SHA256 ก่อนประมวลผล ป้องกันข้อมูลปลอมหรือการแก้ไขระหว่างทาง
• การตั้งค่าช่องทางธนาคารสามารถจำกัดเฉพาะ IP ที่กำหนดได้ (ตัวเลือกสำหรับการใช้งานจริง)
• ข้อมูลที่รับเข้าทุกคำขอถูกตรวจสอบความถูกต้องของรูปแบบก่อนบันทึกเสมอ

การตรวจสอบย้อนหลัง (Audit)

• ทุกการเรียก API และทุก Webhook ถูกบันทึกพร้อมเวลา ผู้ดำเนินการ ปลายทาง รหัสผลตอบกลับ และความหน่วง
• การคืนเงินทุกครั้งมีบันทึกว่าใครเป็นผู้ยืนยัน เวลาใด พร้อมเหตุผลประกอบ
• การเปลี่ยนแปลงการตั้งค่าช่องทางและคีย์ถูกบันทึกพร้อมผู้ดำเนินการ เพื่อตรวจสอบย้อนหลังได้ครบถ้วน

การเปลี่ยนจากโหมดสาธิตเป็นระบบใช้งานจริงใช้ขั้นตอนมาตรฐาน 5 ขั้น โดยไม่ต้องรื้อหน้าจอที่สร้างไว้เลย เนื่องจากทุกอย่างใน V1 ออกแบบตามเส้นทางเดียวกับของจริงอยู่แล้ว งานหลักที่เพิ่มคือการได้รับคีย์จากธนาคารและเปิดใช้ส่วนบริการหลังบ้าน

ลำดับขั้นตอนเปิดใช้งาน

1. เตรียมบัญชีร้านค้ากับธนาคาร: ยื่นเอกสารกับ KBank และ SCB เพื่อเปิดบัญชีร้านค้าสำหรับแต่ละจุดรับเงิน และรับชุดคีย์สำหรับทดสอบ
2. ทดสอบใน Sandbox: เชื่อมช่องทางทดสอบของธนาคาร ทดสอบให้ครบทุกเส้น: QR บัตร ผ่อนชำระ คืนเงิน Webhook และกระทบยอด โดยไม่ใช้เงินจริง
3. ตั้งค่าในระบบ: กรอก Merchant ID Terminal คีย์ Webhook และอัตราค่าธรรมเนียมตามสัญญา ทดสอบการเชื่อมต่อจากหน้าจอให้ผ่านทุกช่องทาง
4. เปิดใช้จริงแบบนำร่อง: ย้ายขึ้นระบบจริงและเปิดทีละ 2 ถึง 3 จุดรับเงินก่อน ตรวจกระทบยอดของรอบแรกให้ตรง ก่อนขยายผลทุกจุด
5. เปิดใช้เต็มรูปแบบ: ทดสอบคืนเงินจริงหนึ่งรายการ ทบทวนบันทึกระบบ อบรมทีมตามบทบาท แล้วเปิดใช้งานทุกจุดรับเงิน

ระบบต้นแบบผ่านการตรวจสอบคุณภาพครบทั้งการทำงาน การแสดงผล และเอกสาร ก่อนส่งมอบทุกครั้ง บทนี้อธิบายสิ่งที่ตรวจสอบแล้วในเวอร์ชันปัจจุบัน และเกณฑ์ตรวจรับที่จะใช้เมื่อเชื่อมต่อธนาคารจริง เพื่อให้ทุกฝ่ายเห็นตรงกันว่าอะไรคือความพร้อมใช้งาน

สิ่งที่ตรวจสอบแล้วในเวอร์ชันนี้

• การทำงานอัตโนมัติ 40 รายการ ครอบคลุมทั้ง 12 หน้าจอ ตั้งแต่เข้าสู่ระบบ กรองธุรกรรม เปิดรายละเอียดธุรกรรม ไปจนถึงยืนยันกระทบยอด ผ่านทั้งหมด ไม่พบข้อผิดพลาด
• การแสดงผลทุกขนาดจอ ตรวจที่ความกว้าง 1440 พิกเซลสำหรับเดสก์ท็อป 1024 พิกเซลสำหรับแท็บเล็ต และ 390 พิกเซลสำหรับมือถือ ไม่มีเนื้อหาล้นกรอบหรือถูกบดบัง และตารางข้อมูลเลื่อนในกรอบของตนเอง
• การส่งออกไฟล์ ตรวจไฟล์ CSV ทุกชุด เปิดได้ถูกต้องทั้ง Excel และ Google Sheets รวมถึงการส่งออกเฉพาะรายการที่กรองอยู่
• รูปแบบการพิมพ์ ตรวจการพิมพ์เอกสารและ PDF ขนาด A4 จัดหน้าเรียบร้อย ตารางและแผนภาพไม่ถูกตัดกลางหน้า
• เอกสารระบบ ตรวจความครบถ้วนของทั้ง 12 บทและภาคผนวก ความถูกต้องของทุกสถานะและคำศัพท์ และความสอดคล้องกับตัวระบบ

เกณฑ์ตรวจรับเมื่อเชื่อมต่อธนาคารจริง

เวอร์ชันต้นแบบจัดเก็บและเผยแพร่เป็นไฟล์เว็บแอปไฟล์เดียวบน Cloudflare Pages ทำให้เปิดใช้ได้ทุกที่โดยไม่ต้องติดตั้ง เมื่อเชื่อมต่อจริง ส่วนบริการและฐานข้อมูลจะเพิ่มเข้ามาในโครงเดียวกัน บทนี้อธิบายโครงสร้างการจัดเก็บ วิธีปรับปรุงระบบ และงานปฏิบัติการประจำที่ทีมควรทำอย่างสม่ำเสมอ

โครงสร้างการจัดเก็บ

• เวอร์ชันออนไลน์ เผยแพร่บน Cloudflare Pages ที่ loco-payment-gateway.pages.dev อัปเดตได้ทันทีเมื่อมีเวอร์ชันใหม่
• ไฟล์งานต้นทาง แยกเป็นโฟลเดอร์โปรเจ็กต์ พร้อมสคริปต์ประกอบไฟล์เดียว จึงสร้างเวอร์ชันใหม่ได้ทุกเมื่อด้วยคำสั่งเดียว
• การเก็บย้อนหลัง ทุกเวอร์ชันเดิมถูกเก็บครบสำหรับเทียบและย้อนกลับได้เสมอ
• เอกสารระบบ จัดเก็บเป็นชุดเดียวกันทั้งเวอร์ชันเว็บ ไฟล์ PDF และแผนภาพ อยู่คู่กับตัวระบบ

การปรับปรุงระบบ

1. แก้ไขที่ไฟล์ต้นทางเท่านั้น ไม่แก้ไฟล์ที่เผยแพร่แล้วโดยตรง เพื่อให้ทุกอย่างตรวจสอบย้อนกลับได้
2. สร้างเวอร์ชันใหม่โดยเพิ่มเลขรุ่นถัดไป ระบบจะเก็บรุ่นเดิมเข้ากรุให้อัตโนมัติ
3. ตรวจสอบตามรายการมาตรฐาน 40 ข้อ และตรวจการแสดงผลทุกขนาดจอก่อนเผยแพร่ทุกครั้ง
4. หลังเผยแพร่ แจ้งทีมงานพร้อมบันทึกสิ่งที่เปลี่ยนไว้คู่กับเอกสารฉบับนี้

งานปฏิบัติการประจำ

ข้อจำกัดที่ทราบ ณ เวอร์ชันนี้

• ข้อมูลในโหมดสาธิตเป็นข้อมูลตัวอย่างที่ฝังในตัว ไม่ผูกกับธุรกรรมจริง และจะถูกรีเซ็ตเมื่อเปิดไฟล์ใหม่
• การเรียกธนาคารเป็นการจำลองครบทุกเส้นทาง แต่ยังไม่มีการส่งคำขอจริงออกนอกระบบ
• การแจ้งเตือนภายนอก (อีเมล รายงานประจำวัน) เป็นการตั้งค่าเตรียมไว้ จะเริ่มทำงานเต็มรูปแบบเมื่อเชื่อมผู้ให้บริการ
• รายงานเน้นช่วง 7/14/30 วัน ยังไม่มีรายงานเปรียบเทียบรายปีหรือรายงานภาษีเฉพาะกิจ

แนวทางพัฒนาต่อไป

• เชื่อมธนาคารจริง: ดำเนินการตามแผนในบทที่ 9 เพื่อให้ระบบรับชำระและกระทบยอดด้วยข้อมูลจริง
• แจ้งเตือนเชิงรุก: เชื่อม LINE แจ้งทีมการเงินทันทีเมื่อมีธุรกรรมล้มเหลวหรือยอดกระทบไม่ตรง
• เอกสารอัตโนมัติ: ออกใบเสร็จรับเงินและใบกำกับภาษีอัตโนมัติจากรายการชำระ คู่กับชุดเลขหมายแยกตามกฎหมาย
• รายงานขั้นสูง: เปรียบเทียบช่วงเวลา วิเคราะห์ค่าธรรมเนียมย้อนหลัง และมุมมองสำหรับผู้บริหาร
• เชื่อมระบบในเครือครบวงจร: ขยาย Webhook ไปยังทุกผลิตภัณฑ์ LOCO เพื่อให้การรับชำระจบในระบบเดียวโดยไม่ต้องบันทึกซ้ำ

สถานะของรายการในระบบ

คำศัพท์ที่ใช้ในระบบ

• QR พร้อมเพย์ (PromptPay QR): การชำระเงินด้วยการสแกน QR ผ่านแอปธนาคาร เป็นวิธีที่ค่าธรรมเนียมต่ำและสำเร็จเร็วที่สุด
• MDR (Merchant Discount Rate): อัตราค่าธรรมเนียมที่ธนาคารหักจากยอดชำระ คิดเป็นเปอร์เซ็นต์ตามวิธีรับชำระ
• รอบโอน T+1: ธนาคารโอนยอดรับชำระของวันนี้เข้าบัญชีในวันถัดไป หลังหักค่าธรรมเนียม
• Webhook: การที่ธนาคารหรือระบบภายนอกเรียกกลับมาที่ระบบของเราโดยอัตโนมัติเมื่อมีเหตุการณ์เกิดขึ้น เช่น ชำระสำเร็จหรือคืนเงินสำเร็จ
• HMAC-SHA256: วิธีลงลายเซ็นดิจิทัลสำหรับ Webhook เพื่อยืนยันว่าข้อมูลมาจากแหล่งที่เชื่อถือได้และไม่ถูกแก้ไข
• Merchant ID / Terminal: รหัสบัญชีร้านค้าและรหัสเครื่องรับชำระที่ธนาคารออกให้ ใช้ระบุว่ายอดนี้เป็นของจุดรับเงินใด
• กระทบยอด (Reconciliation): การเทียบยอดในระบบกับยอดที่ธนาคารรายงาน ให้ตรงกันก่อนโอนเงินทุกครั้ง
• Sandbox: สภาพแวดล้อมทดสอบของธนาคาร ใช้ซ้อมทุกขั้นตอนโดยไม่ใช้เงินจริง
• PDPA: พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล ระบบออกแบบให้เก็บข้อมูลเท่าที่จำเป็นและเข้าถึงตามสิทธิ์