การเชื่อมต่อ API การชำระเงินคริปโต ทีละขั้น

โฟลว์หลัก

เกตเวย์ส่วนใหญ่เปิด REST API ที่มีวงจรชีวิตเดียวกัน คุณเรียกมันฝั่งเซิร์ฟเวอร์ (อย่าเปิดเผยกุญแจ API ในเบราว์เซอร์) และคุณถือเว็บฮุก — ไม่ใช่การเปลี่ยนเส้นทางเบราว์เซอร์ — เป็นแหล่งความจริงว่าคำสั่งซื้อชำระแล้วหรือไม่

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

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

การสร้างใบแจ้งหนี้

ใบแจ้งหนี้ผูกจำนวนเฉพาะกับคำสั่งซื้อเฉพาะในเวลาจำกัด ส่งรหัสคำสั่งซื้อของคุณเป็น metadata เพื่อให้เว็บฮุกจับคู่กลับได้โดยไม่ต้องเดา และจัดเก็บรหัสใบแจ้งหนี้ที่เกตเวย์ส่งกลับ

ราคาที่เสนอหมดอายุ — เกตเวย์ล็อกอัตราไว้ไม่กี่นาที เก็บวันหมดอายุและสถานะของใบแจ้งหนี้ไว้เพื่อให้ UI ของคุณแสดงตัวนับถอยหลัง และเพื่อให้การชำระที่มาสายถูกจัดการเป็นกรณีกระทบยอด ไม่ใช่คำสั่งซื้อที่สูญหาย

เว็บฮุกคือแหล่งความจริง

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

ทำให้การจัดการเว็บฮุกเป็น idempotent เกตเวย์ส่งซ้ำ ดังนั้นเหตุการณ์ 'ชำระแล้ว' เดียวกันอาจมาถึงสองครั้ง ให้ล็อกการประมวลผลของคุณด้วยรหัสเหตุการณ์หรือใบแจ้งหนี้ และทำให้การส่งซ้ำไม่มีผล ส่งกลับ 2xx อย่างรวดเร็วและทำงานช้าแบบอะซิงโครนัสเพื่อให้เกตเวย์ไม่หมดเวลาและส่งซ้ำโดยไม่จำเป็น

การยืนยันและความสิ้นสุด

การชำระอาจถูกมองเห็น (ใน mempool หรือด้วยศูนย์การยืนยัน) นานก่อนที่มันจะสิ้นสุด ตัดสินใจเกณฑ์การยืนยันที่เหมาะกับจำนวนและเชน และส่งมอบเมื่อถึงเกณฑ์เท่านั้น สำหรับการชำระสเตเบิลคอยน์ยอดเล็กบนเชนเร็วสิ่งนี้รวดเร็ว สำหรับยอดใหญ่ให้รอนานกว่า

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

การกระทบยอดและรูปแบบข้อผิดพลาด

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

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