ฝั่งฝาก (Deposit)

ผลลัพธ์ที่เป็นไปได้ ข้อบังคับของรายการ ข้อพิพาท และการสลับไปช่องธนาคาร

ระบบอื่นสร้าง session ฝากและดูแลหน้าโอน/แนบสลิปของผู้ฝาก หน้านี้อธิบายเฉพาะผลลัพธ์ที่ร้านค้าต้องรับมือ ติดตามสถานะด้วย GET /v1/p2p/public/flow/:flowId เพราะเหตุการณ์ระหว่างทางไม่มี webhook (ดู Webhook)

1. ผลลัพธ์ที่เป็นไปได้ของรายการฝาก

หลังจับคู่สำเร็จรอผู้ฝากโอนนับถอยหลัง 10 นาทีสลิปผ่านการตรวจPAYMENT_PAIDเครดิตเข้า payment เต็มจำนวนหักค่าธรรมเนียมจากเครดิต THB_P2Pwebhook → ร้านค้าdeposit_type: P2Pไม่มีคู่ค้าให้จับคู่PAYMENT_PAIDสลับไปช่องธนาคารตั้งแต่ตอนสร้างwebhook → ร้านค้าdeposit_type: CLASSICสลิปซ้ำกับที่เคยใช้PAYMENT_FAILEDreason: DUPLICATE_SIGNATUREwebhook → ร้านค้ายอด/บัญชีผู้โอนไม่ตรงสลิปถูกปฏิเสธรายการยังเปิดอยู่ แนบใหม่ได้จนหมดเวลาอ่าน HTTP error ที่ API แนบสลิปหมดเวลา ไม่มีสลิปที่ผ่านรายการหมดอายุขาถูกปล่อยกลับให้ผู้ฝากรายอื่นpoll payment/info หรือ flowโอนแล้วแต่อัปสลิปไม่ได้DISPUTEDล็อกไว้จนแอดมินตัดสิน ไม่หมดอายุเองpoll match/:matchId
มี webhook ไม่มี webhook — ต้อง poll หรืออ่านจาก response

2. ข้อบังคับของรายการฝาก

โอนภายใน 10 นาที

นับตั้งแต่ระบบเปิดเผยบัญชีปลายทาง

เกินเวลา = ไม่ถูกนับเป็นเครดิต ยกเว้นกดข้อพิพาทไว้ก่อน

โอนจากบัญชีที่ระบุไว้เท่านั้น

ต้องเป็น sender_bank + sender_account ที่ส่งตอนสร้างรายการ แม้ชื่อเจ้าของเดียวกันก็ใช้บัญชีอื่นไม่ได้

บัญชีอื่น = สลิปไม่ผ่าน ไม่ถูกเครดิต

QR ผูกกับรายการเดียว ใช้ครั้งเดียว

ห้ามเก็บไว้ใช้ซ้ำหรือแชร์ต่อ ฝากใหม่ต้องสร้างรายการใหม่

ใช้ซ้ำ = ตีเป็นสลิปซ้ำ (DUPLICATE_SIGNATURE)

ttl_seconds คืออายุของลิงก์หน้าชำระเงิน ส่วน 10 นาทีคือเวลาโอนจริงที่เริ่มนับตอนจับคู่สำเร็จ — คนละตัวกัน

3. ข้อพิพาท (dispute)

เมื่อโอนแล้วแต่อัปสลิปไม่สำเร็จ ผู้ฝากเปิด dispute ได้จากหน้า session (scope match:dispute) รายการจะถูกล็อกไว้แทนที่จะหมดอายุ จนกว่าแอดมินจะตัดสิน — ผลต่อฝั่งร้านค้าเป็นดังนี้ (ดูตารางเทียบสองทางที่หน้า Webhook)

ตรวจสถานะGET /v1/p2p/match/:matchIdmatch_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 เสมอ