ฝั่งฝาก (Deposit)
ผลลัพธ์ที่เป็นไปได้ ข้อบังคับของรายการ ข้อพิพาท และการสลับไปช่องธนาคาร
ระบบอื่นสร้าง session ฝากและดูแลหน้าโอน/แนบสลิปของผู้ฝาก หน้านี้อธิบายเฉพาะผลลัพธ์ที่ร้านค้าต้องรับมือ ติดตามสถานะด้วย GET /v1/p2p/public/flow/:flowId เพราะเหตุการณ์ระหว่างทางไม่มี webhook (ดู Webhook)
1. ผลลัพธ์ที่เป็นไปได้ของรายการฝาก
2. ข้อบังคับของรายการฝาก
โอนภายใน 10 นาที
นับตั้งแต่ระบบเปิดเผยบัญชีปลายทาง
เกินเวลา = ไม่ถูกนับเป็นเครดิต ยกเว้นกดข้อพิพาทไว้ก่อน
โอนจากบัญชีที่ระบุไว้เท่านั้น
ต้องเป็น sender_bank + sender_account ที่ส่งตอนสร้างรายการ แม้ชื่อเจ้าของเดียวกันก็ใช้บัญชีอื่นไม่ได้
บัญชีอื่น = สลิปไม่ผ่าน ไม่ถูกเครดิต
QR ผูกกับรายการเดียว ใช้ครั้งเดียว
ห้ามเก็บไว้ใช้ซ้ำหรือแชร์ต่อ ฝากใหม่ต้องสร้างรายการใหม่
ใช้ซ้ำ = ตีเป็นสลิปซ้ำ (DUPLICATE_SIGNATURE)
ttl_seconds คืออายุของลิงก์หน้าชำระเงิน ส่วน 10 นาทีคือเวลาโอนจริงที่เริ่มนับตอนจับคู่สำเร็จ — คนละตัวกัน
3. ข้อพิพาท (dispute)
เมื่อโอนแล้วแต่อัปสลิปไม่สำเร็จ ผู้ฝากเปิด dispute ได้จากหน้า session (scope match:dispute) รายการจะถูกล็อกไว้แทนที่จะหมดอายุ จนกว่าแอดมินจะตัดสิน — ผลต่อฝั่งร้านค้าเป็นดังนี้ (ดูตารางเทียบสองทางที่หน้า Webhook)
| ตรวจสถานะ | GET /v1/p2p/match/:matchId → match_status — การเปิด/ปิด dispute ไม่มี webhook |
| ใครตัดสิน | แอดมินเท่านั้น ไม่มีระบบตัดสินอัตโนมัติ — รายการค้างอยู่จนกว่าจะมีคนกด และย้อนกลับไม่ได้ |
| ระยะเวลา | ไม่มี SLA ที่รับประกัน อาจนานเป็นชั่วโมงถึงเป็นวัน — อย่าตั้ง timeout ฝั่งร้านแล้วปิดออเดอร์เอง |
| ตัดสินให้ผู้ฝาก | payment กลายเป็น PAYMENT_PAID และส่ง webhook ตามปกติ ยอดที่ได้หักค่าธรรมเนียมฝากแล้ว · รายการถอนฝั่งตรงข้ามถูกส่งต่อรางธนาคารและยัง PENDING |
| ตัดสินให้ผู้ถอน | payment ไม่ถูกแตะ · ฝั่งถอนได้ event ปลายทางตาม outcome.result และคืนเงินตาม summary · reputation ของผู้ฝากถูกหัก |
4. classic fallback
ถ้าไม่มีคู่ค้าให้จับคู่ ระบบอาจสลับรายการไปช่องทางธนาคารในคำขอเดียวกัน — response จะคืนข้อมูลช่องทาง classic แทน match ของ P2P
- ยึด
payment.idเป็นคีย์กระทบยอด อย่าผูก logic กับช่องทางที่ขอ deposit_typeจะเป็นCLASSICแต่ยังเป็นออเดอร์เดียวกัน- ถ้าไม่ส่ง
order_idระบบจะสร้างให้เอง และorder_user_referenceกลายเป็นเลขบัญชีผู้โอน - client ต้อง parse response ได้ทั้งสองรูปแบบ ไม่ใช่สมมติว่าเป็น P2P เสมอ
