XGAMBET • PAYMENT TRANSACTION WORKFLOW GUIDE
ระบบฝากถอนอัตโนมัติทำงานอย่างไร ตั้งแต่ Transaction ถึง Wallet
ระบบฝากถอนอัตโนมัติไม่ได้ทำงานแบบ “รับคำขอแล้วโอนเงินทันที” แต่เป็น Transaction Workflow ที่เชื่อม Platform, Payment Provider, Transaction State, Wallet, Backoffice และ Reconciliation เข้าด้วยกัน
สิ่งสำคัญคือ Operator ต้องแยกให้ออกว่า Request ถูกสร้างแล้วหรือยัง, Provider รับรายการหรือยัง, Transaction อยู่ State ใด, Wallet ถูก Update แล้วหรือยัง และข้อมูลระหว่าง Platform, PSP และ Wallet ตรงกันจริงหรือไม่
ON THIS PAGEสารบัญ
ระบบฝากถอนอัตโนมัติไม่ใช่แค่ “API โอนเงิน”
Transaction จริงสามารถเดินผ่านหลายระบบ และหลาย State ก่อนจะถือว่า Workflow จบสมบูรณ์ ดังนั้นการเห็นคำว่า Success ที่จุดใดจุดหนึ่ง ไม่ได้แปลว่าระบบทุกส่วน อยู่ในสถานะเดียวกันแล้ว
การสร้าง Request ไม่ได้หมายความว่า External Payment จบแล้ว
Provider State กับ Financial State ภายใน Platform เป็นคนละบริบท
รับ Event แล้ว ยังต้องตรวจ Reference, State และ Financial Record
Approved หมายถึง Workflow ไปต่อได้ ไม่ได้ยืนยันว่าเงินถึงปลายทางแล้ว
Payment Transaction เดินผ่านระบบอะไรบ้าง
Architecture นี้ใช้เพื่ออธิบาย Industry Workflow ไม่ใช่ Internal Architecture ที่ยืนยันว่า XGAMBET ใช้อยู่จริง
Payment Module, PSP และ Wallet มีหน้าที่ต่างกัน
Transaction Workflow
สร้าง Request, Route Provider, Track State, รับ Status, Map State และส่งข้อมูลไปยังระบบที่เกี่ยวข้อง ตาม Architecture
External Processing
เชื่อม External Payment Method เช่น Bank, Card, Transfer Rail หรือระบบการชำระเงินภายนอก
Internal Financial State
ดูแล Balance, Hold, Debit, Credit, Adjustment และ Transaction Linkage ตาม Ledger Design
Deposit Workflow ทำงานอย่างไรตั้งแต่ User จน Wallet Credit
Platform อาจต้องตรวจ Transaction Reference, Amount, Currency, Current State, Duplicate และ Business Rule ก่อนสร้าง Financial Posting
ทำไมต้องมีทั้ง Platform Transaction ID และ PSP Reference
Platform ควรมี Identifier ของ Transaction ภายในระบบตัวเอง และสามารถ Mapping ไปยัง Provider Reference ที่เกี่ยวข้องได้
เมื่อลูกค้าแจ้งว่า “เงินออกจากธนาคารแล้ว แต่ยอดยังไม่เข้า” Operator ต้องสามารถค้น Platform Transaction และเชื่อมไปยัง External Provider Transaction เพื่อดูว่าแต่ละระบบอยู่ State ใด
Deposit Transaction มีหลาย State และ Pending ไม่เท่ากับ Failed
| State | ความหมายเชิง Concept | Operator ควรตรวจอะไร |
|---|---|---|
| Created | Platform สร้าง Transaction แล้ว | Reference ถูกสร้างหรือไม่ |
| Pending | ยังรอ Final Outcome | Provider State / Webhook / Timeout |
| Processing | External Workflow กำลังดำเนินการ | Current Provider State |
| Completed | Payment ผ่าน Final State ที่กำหนด | Wallet Posting และ Reconciliation |
| Failed | Transaction ไม่สำเร็จ | Failure Reason และ Retry Policy |
| Cancelled | Transaction ถูกยกเลิก หาก Flow รองรับ | ใครหรือระบบใดยกเลิก |
| Expired | หมดอายุตาม Provider/Flow หากมี | มี Financial Effect หรือไม่ |
ชื่อ State จริงแตกต่างกันตาม Platform และ PSP ตารางนี้เป็น Conceptual State Model ไม่ใช่ State ของ XGAMBET
Payment Success กับ Wallet Credit เป็นคนละ Action
External Transaction State
Provider ระบุว่า Payment ผ่าน State ที่กำหนดตาม Payment Flow
Internal Financial Posting
Platform บันทึก Financial Effect ลง Wallet/Ledger หลังผ่าน Validation ที่เกี่ยวข้อง
Webhook ทำหน้าที่แจ้งว่า Transaction State เปลี่ยน
ใน Payment Workflow แบบ Asynchronous API Response แรก อาจเพียงยืนยันว่า Provider รับ Request ไว้แล้ว ขณะที่ Final Outcome อาจมาภายหลัง ผ่าน Webhook, Callback หรือ Status Query
วิธี Verify Event ขึ้นอยู่กับ Provider Integration บางระบบอาจใช้ Signature Verification หรือ Mechanism อื่น จึงต้องอิง Documentation ของ PSP ที่ใช้จริง
Callback กับ Webhook ต่างกันอย่างไร
ในระดับ Concept คำสองคำนี้มักใช้เรียก Mechanism ที่ External System ส่ง Event หรือ Status กลับมายัง Platform หลังจาก Transaction เปลี่ยนสถานะ
Implementation จริงแตกต่างกันตาม PSP จึงไม่ควรสมมติว่า Callback, Webhook และ API Response มี Behaviour เดียวกันทุก Provider
Withdrawal Workflow มี Control มากกว่าแค่ส่ง Payout
Transaction สามารถผ่าน Validation, Review, Approval, Provider Processing, Pending หรือ Return State ก่อนเข้าสู่ Final Outcome
Approved, Submitted และ Completed เป็นคนละ State
| State | ความหมายเชิง Concept | สิ่งที่ยังต้องตรวจ |
|---|---|---|
| Requested | User สร้าง Withdrawal Request | Validation และ Eligibility |
| Review | อยู่ในขั้นตรวจสอบตาม Policy | ใครเป็น Owner ของ Case |
| Approved | Platform อนุญาตให้ Workflow ไปต่อ | ยังไม่แปลว่าเงินถึง Recipient |
| Submitted | ส่ง Payout ไปยัง Provider แล้ว | Provider รับและ Process หรือไม่ |
| Processing | External Movement ยังดำเนินการอยู่ | Final Provider State |
| Completed / Credited | ถึง Final State ที่ Flow กำหนด | Reconciliation |
| Failed | Payout ไม่สำเร็จ | Wallet State และ Recovery |
| Returned | เคย Process แต่ Funds ถูกส่งกลับภายหลัง | Financial Correction / Review |
| Cancelled | ยกเลิกตาม Flow หากรองรับ | Wallet และ Audit |
State Name แตกต่างกันตาม Platform และ PSP ไม่ควรสร้าง Universal Status Mapping สำหรับ Provider ทุกเจ้า
Withdrawal Approved ไม่ได้หมายความว่าเงินถึงผู้รับแล้ว
Wallet ตอน Withdrawal สามารถใช้หลาย Model
Platform แต่ละระบบ สามารถจัดการ Balance ระหว่าง Withdrawal ต่างกันได้ เช่น Hold/Reserve, Debit ตาม Stage ที่กำหนด หรือ Ledger Model รูปแบบอื่น
Hold / Reserve
กัน Balance ระหว่างรอ Outcome ตาม Design
Debit at Defined Stage
Debit Balance เมื่อถึง State ที่ Business Rule กำหนด
Other Ledger Models
ใช้ Financial Posting Model ตาม Architecture ของ Platform
จึงไม่ควรสมมติว่า XGAMBET ใช้ Hold, Reserve หรือ Direct Debit Model ใด หากยังไม่มี First-party Evidence
Payout Fail แล้วไม่ควร Credit กลับแบบ Blind
Wallet Correction ต้องพิจารณาจาก Current Financial State, Provider State, Transaction History และ Business Rule ไม่ควรกำหนดว่า Failed ทุกกรณีต้อง Auto Credit กลับ
Returned Withdrawal ต่างจาก Request ที่ Fail ตั้งแต่ต้น
Returned สามารถหมายถึง Provider เคย Process Financial Movement ไปแล้ว แต่ External Network หรือปลายทางส่ง Funds กลับภายหลัง
เงินออกจาก Wallet แล้วหรือยัง?
Provider อยู่ State ใด?
Funds กลับจริงแล้วหรือไม่?
ต้อง Adjustment หรือ Release หรือไม่?
ต้องมี Human Review หรือไม่?
Automation ช่วย Payment Workflow ตรงไหน
Automation สามารถช่วยจัด Workflow แต่ไม่ควรถูกมองเป็น Financial Source of Truth เพราะ Wallet และ Transaction System ยังคงเป็นเจ้าของ Financial State ตาม Architecture
อ่านหลัก Event/Rule Workflow เพิ่มได้ที่ ระบบ Automation เว็บพนัน
Auto Approval กับ Auto Processing ไม่ใช่สิ่งเดียวกัน
Rule Decision
Rule ตัดสินว่า Request ผ่านเงื่อนไขที่จะไปต่อหรือไม่
Execution
ระบบส่ง Request ไปยัง External Provider โดยอัตโนมัติ
ทั้งสอง Capability ไม่จำเป็นต้องเกิดพร้อมกัน และไม่ควร Claim ว่า XGAMBET มี Auto Approval หรือ Auto Payout หากยังไม่มีข้อมูลยืนยัน
Manual Review ยังเป็นส่วนหนึ่งของ Payment Workflow ได้
Transaction บางรายการ อาจต้อง Manual Review เมื่อข้อมูลไม่ครบ, Rule ไม่ผ่าน, เกิด Risk Signal, Provider มีปัญหา หรือมี Requirement ด้าน Compliance ตามตลาดที่เกี่ยวข้อง
Backoffice ต้องช่วย Operator Investigate Transaction ได้
Backoffice เป็น Control / Investigation Interface ส่วน Payment Engine เป็น Transaction Workflow Service ทั้งสองจึงทำงานร่วมกัน แต่ไม่ใช่ระบบเดียวกัน
ดูรายละเอียด Operator Control Layer เพิ่มได้ที่ Backoffice สำหรับตรวจธุรกรรม
State History มีค่ามากกว่าการเห็นสถานะล่าสุดอย่างเดียว
หาก Backoffice แสดงเพียง “Completed” Operator จะไม่รู้ว่า Transaction เคย Pending, Retry, Manual Review หรือเปลี่ยน State ผ่านเหตุการณ์ใดมาก่อน
ลำดับนี้เป็น Conceptual Example ไม่ใช่เวลาหรือ SLA จริงของ XGAMBET
Duplicate, Retry และ Idempotency ต้องแยกให้ออก
ข้อมูลเดิมเข้ามาซ้ำ
Event หรือ Request เดิม ถูกส่งเข้ามามากกว่าหนึ่งครั้ง
Platform ตั้งใจลองใหม่
Request เดิม ถูกส่งซ้ำเพราะครั้งก่อน ไม่ได้ Final Response
ป้องกัน Financial Operation ซ้ำ
Request เดิม ไม่ควรสร้าง Business Effect ใหม่ โดยไม่ตั้งใจ
Timeout ไม่ได้พิสูจน์ว่า Transaction Failed
Timeout หมายถึง Platform ไม่ได้รับ Response ภายในช่วงเวลาที่กำหนด แต่ Provider อาจ Process Transaction ไปแล้วก็ได้
ต้องตรวจ Existing Reference, Current State และ Provider Behaviour ก่อนส่ง Financial Operation ซ้ำ
Webhook ใหม่อาจมาถึงก่อน Event เก่า
Platform จึงต้องตรวจ Current State, Event Type, Reference และ Business Rule ก่อน Update Transaction เพื่อไม่ให้ State Regression เกิดจาก Event เก่าที่มาช้า
ก่อน Wallet Update ต้อง Match Transaction ให้ถูกตัว
การรับ Success Status ที่อ้างอิง Transaction ผิด, Amount ผิด หรือ Currency ผิด ไม่ควรถูกนำไปสร้าง Financial Posting โดยไม่ผ่าน Validation ตาม Integration Design
Payment Routing สามารถมีหลายเงื่อนไข แต่ Failover ต้องระวัง Duplicate
บาง Platform อาจเลือก Provider ตาม Market, Currency, Payment Method, Availability, Commercial Configuration หรือ Rule อื่น ตาม Architecture
แต่หาก Request ไป PSP A แล้วเกิด Timeout การส่ง Request เดิมไป PSP B ทันที สามารถสร้าง Duplicate Risk หาก PSP A Process รายการไปแล้ว
ไม่ควร Claim ว่า XGAMBET มี Smart Routing, Failover Routing หรือ Rule Engine หากยังไม่มี First-party Evidence
Reconciliation คือการพิสูจน์ว่า Records ระหว่างระบบตรงกัน
Transaction รายการนี้ อยู่ State อะไร?
Financial Records ระหว่างหลายระบบ ตรงกันหรือไม่?
รายการต่อรายการ
Match Reference และ Amount
ยอดรวมตามช่วงเวลา
เทียบ Aggregate Records
แยกตาม PSP
ตรวจแต่ละ Provider ตาม Operation
Settlement กับ Reconciliation ต่างกันอย่างไร
Financial Movement Process
การจัดการ Financial Amount ผ่าน Provider หรือ Payment Network ตาม Payment Process
Record Verification
ตรวจว่า Platform, Provider และ Wallet มีข้อมูลตรงกันหรือไม่
Failed Payment ไม่ควรแก้ด้วย Retry ทุกกรณี
Error ที่ดีควรช่วย Operator แยกได้ว่า User ต้อง Action, Operator ต้อง Action, Technical Team ควร Retry, ต้อง Escalate Provider หรือควรเข้า Manual Review
Monitoring ควรช่วยเห็นปัญหาที่กำลังเกิดขึ้น
Payment Integration ต้องตรวจ Security โดยไม่เปิดเผย Secret
Operational Log ควรช่วย Trace Transaction, Provider, Status, Error และเวลา แต่ไม่ควรเปิดเผย API Key, Signing Secret, Merchant Credential, Production Token หรือ Sensitive Financial Data โดยไม่จำเป็น
Withdrawal Workflow ต้องสัมพันธ์กับข้อกำหนดของตลาดที่เกี่ยวข้อง
ตาม Business Model และ Jurisdiction Workflow อาจต้องพิจารณา Account Verification, KYC, AML, Sanctions/Risk Requirement, Withdrawal Restriction หรือ Responsible Gaming Context ตามข้อกำกับที่เกี่ยวข้อง
Payment Architecture จึงไม่ควรถูกออกแบบ เพื่อหลีกเลี่ยง KYC, AML, PSP Restriction หรือข้อกำกับทางการเงิน ที่มีผลกับตลาดนั้น
ก่อน Production ต้อง Test Deposit มากกว่า Success Case
Withdrawal ต้อง Test ทั้ง State, Wallet และ Recovery
End-to-End Deposit และ Withdrawal ควรเห็น State ครบทั้งเส้น
Payment Workflow ที่ดีต้อง Recover เมื่อ Happy Path ไม่เกิด
Deposit Success แต่ Webhook ไม่มา
ตรวจ PSP State, Platform State, Wallet และ Reconciliation ก่อนสร้าง Credit เพิ่ม
Duplicate Webhook
Event เดิมไม่ควรสร้าง Wallet Credit ซ้ำ
Withdrawal Timeout
Timeout ไม่ควรถูกตีความว่า Failed โดยไม่ Query หรือ Reconcile
Withdrawal Returned
ต้องมี State Transition, Financial Handling, Operator Visibility และ Reconciliation
Wallet Update Fail
PSP Success แต่ Wallet Posting Fail เป็น Cross-system Inconsistency
Amount Mismatch
Amount จาก PSP ไม่ตรงกับ Platform Request ควรเข้าสู่ Control Path ตาม Design
Old Event Arrives Late
Event เก่า ไม่ควรทำให้ Current State ถูก Downgrade โดยไม่ตรวจ Ordering
Payment Demo ควรทดลองกรณีผิดพลาดมากกว่าดูแค่ Transaction List
Pending Deposit
Account → Transaction → Provider Reference → Current State → History → Wallet
Failed Withdrawal
Failure Reason → PSP Reference → Wallet State → Permitted Action → Audit
Duplicate Webhook
ส่ง Event เดิมซ้ำ แล้วตรวจว่า Financial Action ถูก Process ซ้ำหรือไม่
Manual Review
Open Queue → Review Transaction → Action → Audit
Reconciliation
PSP Reference → Platform Transaction → Wallet Transaction → Final Amount / Status
หากต้องการใช้ Demo เพื่อประเมิน Workflow จริง สามารถดู Demo ระบบ XGAMBET แล้วสร้าง Test Case จาก Transaction ที่ทีมต้องรับผิดชอบจริง
8 จุดที่ Operator ควรถามต่อทันที
8 คำถามที่ Operator ควรถามก่อนเลือกระบบฝากถอน
- Platform Transaction ID กับ PSP Reference เชื่อมกันอย่างไร?
- Deposit Final State ถูกยืนยันจากอะไร?
- Withdrawal มี State อะไรบ้าง?
- Duplicate Webhook ถูกจัดการอย่างไร?
- Timeout ถูก Resolve อย่างไร?
- Wallet Update เกิดที่ Stage ไหน?
- Failed หรือ Returned Transaction Recover อย่างไร?
- Platform, PSP และ Wallet Reconcile กันอย่างไร?
Workflow ที่ดีต้อง Recover ได้ ไม่ใช่แค่ Process Automatically
หลังเข้าใจ Workflow แล้ว สามารถดูภาพรวมระบบ และ Scope ของ Payment Owner Page ได้ที่ ระบบฝากถอนและ Payment XGAMBET
คำถามเกี่ยวกับ Workflow ระบบฝากถอนอัตโนมัติ
ระบบฝากถอนอัตโนมัติทำงานอย่างไร?
โดยทั่วไปเริ่มจาก Platform สร้าง Transaction, ตรวจ Validation, ส่ง Request ไป Payment Provider, รับ Status ผ่าน API/Webhook, Update Internal Transaction State, จัดการ Wallet และจบด้วย Backoffice Visibility กับ Reconciliation ตาม Architecture ที่ใช้
Payment Gateway กับ Wallet ต่างกันอย่างไร?
Payment Gateway หรือ PSP จัดการ External Payment Processing ส่วน Wallet ดูแล Financial State ภายใน Platform เช่น Balance, Debit และ Credit
Webhook มีหน้าที่อะไร?
Webhook ใช้ส่ง Event หรือแจ้งการเปลี่ยน Transaction State จาก External Provider กลับมายัง Platform โดย Platform ยังต้อง Verify Event ตาม Integration Design
Pending กับ Failed ต่างกันอย่างไร?
Pending หมายถึง Transaction ยังรอ Final State ส่วน Failed หมายถึง Provider หรือระบบ ระบุว่ารายการไม่สำเร็จ
Withdrawal Approved หมายถึงเงินถึงบัญชีแล้วหรือไม่?
ไม่จำเป็น Approved โดยทั่วไปหมายถึง Platform อนุญาตให้ Workflow ไปต่อ ขณะที่เงินถึงผู้รับ ต้องดู Final State ของ External Payout Workflow
ทำไมต้องป้องกัน Duplicate Transaction?
เพราะ Request, Retry หรือ Webhook เดิม สามารถเกิดซ้ำได้ หากไม่มี Protection อาจสร้าง Financial Action ซ้ำโดยไม่ตั้งใจ
Timeout ควรถือว่า Transaction Failed หรือไม่?
ไม่ควรถือว่า Failed โดยอัตโนมัติ เพราะ Timeout เพียงบอกว่า Platform ไม่ได้รับ Response ในเวลาที่กำหนด Provider อาจ Process รายการไปแล้ว จึงต้อง Query, รอ Event หรือ Reconcile ตาม Design
Reconciliation คืออะไร?
Reconciliation คือการตรวจว่า Reference, Status, Amount และ Currency ระหว่าง Platform, PSP และ Wallet สอดคล้องกันหรือไม่
ก่อนใช้ระบบฝากถอนจริงควร Test อะไร?
นอกจาก Success Case ควรทดสอบ Pending, Failed, Timeout, Duplicate, Delayed Webhook, Returned, Amount Mismatch, Wallet Posting Failure, Manual Review และ Reconciliation
ก่อนใช้ระบบฝากถอนอัตโนมัติจริง ให้ทดสอบ Transaction Lifecycle ทั้งเส้น
อย่าหยุดที่ Deposit และ Withdrawal ที่สำเร็จ แต่ต้องตรวจตั้งแต่ Internal Transaction ID, Provider Reference, Webhook, State History, Wallet Posting, Backoffice ไปจนถึง Reconciliation รวมถึง Pending, Failed, Timeout, Duplicate, Returned และ Wallet Mismatch เพื่อให้รู้ว่า Workflow สามารถ Detect, Recover และตรวจย้อนหลังได้เมื่อเกิด Exception