ColdPaid API: เดิม vs ใหม่
เทียบ flow และสิ่งที่ทีมต้องตัดสินใจ — อัปเดต 16 ก.ค. 2026
API เดิม (api.coldpaid.com/external/v1) ยังใช้งานได้ปกติ — production ไม่กระทบ
ColdPaid ออก API ใหม่ “Bank Manager API” ที่ coldpaid.com/api ซึ่งเป็นคนละ contract ทั้งชุด
หน้า docs เหลือแค่ตัวใหม่
LIVEFlow ปัจจุบัน (API เดิม — รันอยู่บน production)
ผู้เล่นกดถอนเงิน
▼
Kafka → wallet-consumer (case “KBIZ”)
สร้าง record status
header:
body:
initiating แล้ว
POST api.coldpaid.com/external/v1/transfersheader:
X-API-Keybody:
bankAccountId (เราเลือกบัญชีต้นทางเอง), toBankCode “004” (รหัสตัวเลข),
toAccountNumber, toAccountName, amount
▼
ได้
transferIdPending
▼
ColdPaid ยิง webhook (ลงทะเบียน URL ล่วงหน้า)✅ ตรวจลายเซ็นได้
POST /v1/kbank/coldpaid/webhook พร้อม header X-Webhook-Signature (HMAC-SHA256)
▼
TRANSFER_PROCESSING
→ Processing
TRANSFER_WAITING_OTP
รอ OTP — ธนาคารส่ง SMS OTP → เรา capture ผ่าน
POST /v1/kbank/:agent/withdraw → ส่งกลับด้วย POST /transfers/:id/otp
TRANSFER_COMPLETED
→ Success ✅
TRANSFER_FAILED / CANCELLED
→ Failed + คืนเงิน
fallback: cron
CheckColdPaidStuckProcessing ทุก 5 นาที → GET /transfers/:id ถ้า webhook หาย
ใหม่Flow ของ API ใหม่ (Bank Manager API)
ผู้เล่นกดถอนเงิน
▼
POST coldpaid.com/api/transfer
header:
body:
Authorization: Bearer (เปลี่ยนจาก X-API-Key)body:
bank_code “KBANK” (รหัสตัวอักษร ไม่ใช่ตัวเลข), to_account, amount,
callback_url (แนบ URL ไปกับรายการ ไม่ต้องลงทะเบียนล่วงหน้า)
⚠️ ไม่มี
bankAccountId: เลือกบัญชีต้นทางเองไม่ได้แล้ว ColdPaid จัดคิวหา device ให้เอง (kbiz / ttb)
▼
ได้
queue_id
status: queued → processing
▼
ColdPaid ยิง callback มาที่ callback_url⚠️ ไม่มีลายเซ็นเลย
ใครก็ปลอม payload ได้
▼
transfer.completed ห้ามเชื่อทันที!
ต้อง
GET /api/transfer/{queue_id} ยืนยันกับ ColdPaid ก่อน แล้วค่อย mark Success ✅
(มีสลิปให้ดึง GET /api/slip/{queue_id})
transfer.failed ห้ามเชื่อทันที!
ยืนยันแบบเดียวกัน → Failed + คืนเงิน
⚠️ ไม่มี OTP flow แล้ว
โค้ด SMS OTP capture ทั้งชุดจะไม่ได้ใช้
⚠️ ไม่มี KMA แล้ว
เหลือ device kbiz กับ ttb (ttb เป็นของใหม่)
🆕 ของแถมเงินเข้า
device อ่าน SMS/notification เงินเข้าแล้วยิง webhook
deposit.received ให้อัตโนมัติ
(คล้าย KBANK SMS-parsing ที่เราทำเองอยู่ แต่ ColdPaid ทำให้)
ตารางเทียบสั้นๆ
| หัวข้อ | เดิม | ใหม่ | |
|---|---|---|---|
| Auth | X-API-Key | → | Bearer |
| Endpoint สั่งโอน | /external/v1/transfers | → | /api/transfer |
| การเลือกบัญชีต้นทาง | เลือกได้ (bankAccountId) | → | ระบบจัดคิวเอง ควบคุมไม่ได้ |
| รหัสธนาคาร | ตัวเลข เช่น “004” | → | ตัวอักษร เช่น “KBANK” มี UOB / UOBT ด้วย |
| Webhook | ลงทะเบียนล่วงหน้า + HMAC | → | callback_url ต่อรายการ ไม่เซ็น |
| OTP | มี | → | ไม่มี |
| สถานะ | 6 แบบ | → | 4 แบบ ตัวเล็ก |
| Device | kbiz + kma | → | kbiz + ttb |
| ของใหม่ | — | → | deposit webhook + slip endpoint 🆕 |
แล้วเราต้องทำอะไร? (decision flow)
วันนี้: API เดิมยังใช้ได้ ✅
(ตรวจสอบแล้ว 16 ก.ค. 2026) → ไม่ต้องรีบ
▼
Phase 0: ถาม ColdPaid 3 คำถาม
① external/v1 จะปิดเมื่อไหร่?
② KMA เลิกรองรับถาวรใช่ไหม?
③ ขอ API key ตัวใหม่
② KMA เลิกรองรับถาวรใช่ไหม?
③ ขอ API key ตัวใหม่
▼
ถ้าเดิมจะปิด
Phase 1-4: SDK ใหม่ + webhook ใหม่ (secret-in-URL + poll-verify) + เปลี่ยน bank codes + แก้หน้าสมัครบัญชี
งานขนาด ~ gateway ใหม่ 1 ตัว
งานขนาด ~ gateway ใหม่ 1 ตัว
ถ้าขนานกันต่อ
ยังไม่ต้องทำอะไร เก็บสเปคไว้
ทุกกรณี
branch
feature/coldpaid-kma-reenable พักไว้ อย่าเพิ่ง merge จนกว่าข้อ ② ชัด
จุดที่ต้องตัดสินใจตอนนี้
ร่างคำถาม Phase 0 ส่ง vendor เลย หรือเตรียม SDK v2 คู่ขนานระหว่างรอคำตอบ