IOSOR

IOSOR ความรู้

เส้นทางหลักล้มเหลว: เส้นทางสำรองตามลำดับโดยไม่มีการหักเงินซ้ำ

เมื่อเส้นทางส่งข้อความหลักล้มเหลว ให้ทำตามเส้นทางสำรองตามลำดับที่บันทึกไว้ เพื่อให้ความตั้งใจของลูกค้าหนึ่งครั้งได้รับการชำระเพียงครั้งเดียว — สถานะแบบ white-label, ไม่มีแบรนด์ต้นน้ำ, ไม่มีการหักเงินเติมเงินซ้ำซ้อน.

เมื่อเส้นทางหลักไม่สามารถรับหรือส่งข้อความได้ ผู้ซื้อต้องการเส้นทางที่มีลำดับ ปลอดภัยทางการเงิน และแสดงผลอย่างซื่อสัตย์ใน UI ของลูกค้า การสลับสำรองไม่ใช่ “ลองทุกท่อจนกว่าจะมีอะไรติด” แต่เป็นลำดับที่กำหนดไว้: หลัก, จากนั้นสำรองหนึ่ง, จากนั้นสำรองสองหากมีการบันทึกไว้ — แต่ละเส้นทางมีจุดหยุดที่ชัดเจน กระเป๋าเงินจะแสดงการหักเงินที่เรียกเก็บได้ หนึ่งครั้ง สำหรับความตั้งใจของลูกค้าหนึ่งครั้ง แม้ว่าเส้นทางจะถูกสลับไปมาเบื้องหลังก็ตาม.

IOSOR เป็น CPaaS แบบเติมเงิน white-label แดชบอร์ดและ webhook จะไม่เปิดเผยแบรนด์ต้นน้ำ USD 20 คือยอดเติมเงินขั้นต่ำสาธารณะ (เกณฑ์นำร่อง) ไม่ใช่ค่าธรรมเนียมแรกเข้า การตรวจสอบเบื้องต้นใกล้ USD 1,000/เดือน คือเมื่อการสลับสำรองที่ไม่มีลำดับเริ่มมีค่าใช้จ่ายสูง บทความที่เกี่ยวข้อง: [เกตการสลับสำรองก่อนป้าย Live].

การสำรองตามลำดับไม่ใช่การ "สาดและอธิษฐาน"

เขียนลำดับก่อนการผลิต เส้นทางหลักจะให้บริการช่องทางเมื่อสุขภาพดี เมื่อมีการปฏิเสธอย่างรุนแรง, หมดเวลาเกินช่วงช่องทาง, หรือ vault ไม่พร้อม — ให้ย้ายไปยังเส้นทางถัดไป อย่าส่ง OTP เดียวกันไปยังสามเส้นทางพร้อมกัน อย่าสร้างลำดับใหม่ระหว่างเกิดเหตุการณ์.

การหักเงินหนึ่งครั้งสำหรับความตั้งใจของลูกค้าหนึ่งครั้ง

ปฏิบัติตาม [การกันยอดเติมเงินก่อนการหักครั้งแรก]: กันยอดหนึ่งครั้ง, ชำระหนึ่งครั้งเมื่อเส้นทางยอมรับหน่วย การสำรองภายใต้ความตั้งใจเดียวกันจะใช้รหัสเงินซ้ำ — [idempotency การลองใหม่ และเงิน]. การหักเงินครั้งที่สองสำหรับ “เส้นทางอื่น” คือข้อผิดพลาดทางการเงิน ไม่ใช่ความยืดหยุ่น.

สถานะ white-label เมื่อเส้นทางหลักล้มเหลว

UI ของลูกค้าและการส่งออกแสดงสถานะ IOSOR: ยอมรับแล้ว, รอดำเนินการ, ส่งแล้ว, ล้มเหลว, ต้องการความสนใจ — ไม่ใช่สตริงแบรนด์ของเส้นทาง ทีมปฏิบัติการอาจบันทึกเส้นทางที่ดำเนินการ; ผู้ซื้อต้องไม่เห็นมัน เมื่อสลับ ให้ปรับปรุงแถวความตั้งใจเดียวกัน: ผลลัพธ์และเวลาเปลี่ยน; รหัสเงินไม่เปลี่ยน.

เมื่อไม่ควรเรียกว่าการสลับสำรอง

กล่องขาเข้าต่ำพร้อมสถานะ ยอมรับแล้ว/ส่งแล้ว ที่ซื่อสัตย์คือการส่งมอบ — [คู่มือ SMS ส่งถึงต่ำ], ไม่ใช่การพลิกเส้นทางแบบสุ่ม DLR ล่าช้าหลังจากการยอมรับที่สมบูรณ์คือความหน่วง — [DLR ความหน่วง และการสลับสำรอง] — ไม่ใช่การหักเงินครั้งที่สองบนเส้นทางสำรอง การส่งซ้ำโดยผู้ใช้คือการกระทำใหม่ที่มีคีย์ของตัวเอง.

รายการตรวจสอบของผู้ซื้อสำหรับเส้นทางตามลำดับ

  1. ลำดับสำรองถูกเขียนและเป็นเจ้าของก่อน Live?
  2. แต่ละคลาสการสลับแมปกับการรอ, ล้มเหลว, หรือเส้นทางถัดไป?
  3. คีย์ idempotency หนึ่งเดียวครอบคลุมเงินหลักและเงินสำรอง?
  4. สถานะลูกค้าเป็น white-label โดยไม่มีแบรนด์ต้นน้ำ?
  5. เส้นทาง hold-fail ปล่อยอัตโนมัติโดยไม่มีผีที่ชำระแล้วเงียบๆ?
  6. เพดานการใช้จ่ายทำงานอยู่เพื่อไม่ให้พายุ failover ทำให้กระเป๋าเงินนำร่องว่างเปล่า?

เริ่มต้นกับ IOSOR

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

สรุป IOSOR

การสำรองเส้นทางหลักจะสำเร็จได้ก็ต่อเมื่อมีการกำหนดลำดับสำรองไว้ล่วงหน้าและผูกติดกับเจตนาทางการเงินเดียวอย่างเคร่งครัด การพยายามส่งเส้นทางแบบสุ่มขนานกันจะสร้างรายการเรียกเก็บเงินซ้ำและทำลายการติดตามสถานะข้อความข้ามจุดสัมผัสของลูกค้า

คู่มือนี้มีประโยชน์ไหม?

คู่มือที่เกี่ยวข้อง