ทางเลือก / Orchestration
มองหาทางเลือกแทน payment orchestration
Orchestration ขายด้วยอัตราอนุมัติและการประหยัดต้นทุน ซึ่งเป็นจริงทั้งคู่ เมื่อมีขนาดธุรกิจระดับหนึ่งและมี acquirer มากกว่าหนึ่งราย ต่ำกว่านั้น เลเยอร์นี้เพิ่มแค่ค่าธรรมเนียม ความพึ่งพา และอีกหนึ่งฮอป โดยไม่ได้ประโยชน์จาก routing การประเมินที่ซื่อสัตย์เริ่มจากการดูว่าคุณอยู่ฝั่งไหนของเส้นนั้น
ประเมิน
หกคำถามก่อนเพิ่มเลเยอร์
จริงๆ แล้วคุณใช้ผู้ให้บริการกี่ราย?
ถ้ามี acquirer รายเดียวก็ไม่มีอะไรให้ route ประโยชน์ที่เสนอทั้งหมดสมมติว่าคุณมีหลายความสัมพันธ์ที่มีเหตุผลต้องรักษาไว้
อัตราอนุมัติหนึ่งจุดมีค่าเท่าไรสำหรับคุณ?
คูณออกมาตามยอดต่อปีของคุณ แล้วเทียบกับค่าธรรมเนียมของเลเยอร์บวกงานวิศวกรรมที่ต้องใช้ดูแล ที่ปริมาณน้อย ตัวเลขแทบไม่เคยออกมาคุ้ม
ปัญหา decline ของคุณเป็นเรื่อง routing จริงหรือ?
หลายอย่างที่ดูเหมือนปัญหา routing จริงๆ คือการรองรับช่องทางไม่ครบ checkout ที่ทำให้ลูกค้าหลุดก่อน authorization หรือนโยบาย 3-D Secure ที่ตั้งเข้มเกินไป
ใครเป็นผู้ชำระเงินให้คุณ?
โดยปกติ orchestrator ไม่ได้ทำ การชำระยอดยังอยู่กับผู้ให้บริการที่รับชำระ แปลว่าการกระทบยอดของคุณยังคงข้ามหลายผู้ให้บริการ เว้นแต่เลเยอร์นั้นแก้เรื่องนี้ด้วย
รายงานของคุณจะเป็นอย่างไร?
การทำรายงานจากผู้ให้บริการที่ข้อมูลไม่ตรงกันให้เป็นมาตรฐานเดียว มักเป็นคุณค่าที่แท้จริง ขอดูกับชุดผู้ให้บริการของคุณเอง ไม่ใช่ชุดข้อมูลเดโม
เลเยอร์นี้ทำให้คุณพึ่งพาเพิ่มขึ้นแค่ไหน?
คุณเพิ่มระบบหนึ่งเข้าไปในเส้นทางของทุกการชำระเงิน ลองถามว่าเกิดอะไรขึ้นเมื่อระบบทำงานด้อยลง และคุณ failover ข้ามไปหาผู้ให้บริการโดยตรงได้หรือไม่
เมื่อไรที่ orchestration คือคำตอบจริงๆ
เมื่อคุณมีความสัมพันธ์ด้าน acquiring หลายรายอยู่แล้ว เพราะไม่มีรายใดรายเดียวครอบคลุมตลาด โปรไฟล์ความเสี่ยง หรืออัตราของคุณได้ และปริมาณธุรกรรมสูงพอที่เศษเสี้ยวของเปอร์เซ็นต์คือเงินจริง ณ จุดนั้น การ route ตามผู้ออกบัตรและ corridor การ cascade soft decline ไปยัง acquirer รายที่สอง และโมเดลรายงานเดียวข้ามผู้ให้บริการ จะไม่ใช่แค่ไอเดียที่ดี แต่เป็นบรรทัดใน P&L เงื่อนไขเบื้องต้นไม่เคยเปลี่ยน คือต้องมีหลายผู้ให้บริการที่คุณมีเหตุผลจะเก็บไว้
- 01หลาย acquirer ที่เก็บไว้เพื่อความครอบคลุม ความสำรอง หรืออัตรา
- 02ปริมาณที่อัตราอนุมัติหนึ่งจุดมีค่ามากกว่าค่าธรรมเนียมของเลเยอร์
- 03Failover ระหว่างผู้ให้บริการเป็นข้อกำหนดทางธุรกิจ
- 04โมเดลรายงานเดียวข้ามผู้ให้บริการที่ข้อมูลไม่ตรงกัน
เมื่อมันคือการซื้อที่ผิด
เมื่อคุณมีผู้ให้บริการรายเดียว หรือปัญหาที่คุณแก้อยู่เกิดก่อนขั้น routing การเพิ่มเลเยอร์เหนือ gateway ตัวเดียวได้มาแค่ค่าธรรมเนียมและอีกหนึ่งฮอป และหากการชำระเงินล้มเหลวเพราะช่องทางที่ลูกค้าชอบไม่อยู่ในหน้า เพราะ checkout ทำให้ลูกค้าหลุดก่อน authorization หรือเพราะ 3-D Secure ท้าทายทราฟฟิกที่ไม่จำเป็น การ route เท่าไรก็กู้คืนไม่ได้ ทางแก้อยู่ที่ checkout ไม่ใช่เหนือมัน
- 01ผู้ให้บริการรายเดียว — ไม่มีอะไรให้ orchestrate
- 02การสูญเสียเกิดก่อน authorization ไม่ใช่ที่ขั้นนั้น
- 03ช่องว่างที่แท้จริงคือการรองรับช่องทาง ไม่ใช่ routing
- 04ค่าธรรมเนียมสูงกว่าประโยชน์จาก routing ที่ปริมาณของคุณ
Protocore Gateway เหมาะตรงไหน
เราคือเลเยอร์ชั้นล่าง คือ gateway ที่รับชำระเงินและชำระยอดให้ โดยมีส่วนของ orchestration ที่สำคัญต่อธุรกิจที่ใช้ผู้ให้บริการรายเดียวติดตั้งมาในตัว แทนที่จะขายเป็นเลเยอร์ด้านบน ได้แก่ นโยบาย routing ที่เขียนด้วยภาษาที่คุณคุ้นเคย การ retry ผ่านเส้นทางสำรองก่อนที่ลูกค้าจะเห็นความล้มเหลว และเหตุผลของการ decline ที่ผู้ดูแลระบบนำไปดำเนินการต่อได้ หากคุณถึงขนาดหลาย acquirer จริงๆ แพลตฟอร์ม whitelabel เชื่อมต่อ acquirer ของคุณเองควบคู่กับของเรา ธุรกิจส่วนใหญ่ที่ถามเรื่องนี้ต้องการ gateway ที่ดีกว่า ไม่ใช่เลเยอร์เหนือตัวที่มีอยู่
- 01มีนโยบาย routing และ retry ให้ ไม่มีค่าเลเยอร์
- 02Gateway ที่ชำระยอดให้จริง ในสกุลเงินเดียว
- 03เชื่อมต่อ acquirer ของคุณเองบนแพลตฟอร์ม whitelabel
- 04บัตร วอลเล็ต โอนเงิน และ USDC ในหน้าเดียวและเลขอ้างอิงเดียว
FAQ
คำถามที่ควรถามทุกเจ้า
ไม่ต้อง ประโยชน์ทุกอย่างที่ orchestration ขาย ไม่ว่าจะเป็น routing, cascading หรือการเก็งกำไรจากอัตรา ล้วนสมมติว่ามีหลายผู้ให้บริการ เมื่ออยู่เหนือ gateway ตัวเดียว เลเยอร์นี้คือค่าธรรมเนียมกับอีกหนึ่งฮอป โดยไม่มีอะไรให้เลือก
ได้ ถ้า decline ของคุณเป็นเรื่อง routing จริงและมีเส้นทางสำรองให้ส่งไป แต่ถ้าการสูญเสียเกิดก่อน authorization เช่น ช่องทางไม่ครบ checkout ที่หนักเกินไป หรือนโยบาย 3-D Secure ที่เข้มเกินไป routing ก็ไม่มีอะไรให้ทำ
โดยทั่วไปไม่ การชำระยอดยังอยู่กับผู้ให้บริการต้นทางที่รับชำระ ดังนั้นการกระทบยอดของคุณยังคงข้ามผู้ให้บริการเหล่านั้น เว้นแต่แพลตฟอร์มจะแก้เรื่องนี้ให้อย่างชัดเจน ควรยืนยันตั้งแต่ต้น เพราะหลายคนไม่คาดคิด
ได้ ถ้า gateway ของคุณมีให้ในตัว นโยบาย routing การ retry เมื่อเจอ soft decline และเหตุผลการ decline ที่อ่านเข้าใจได้ ไม่จำเป็นต้องใช้แพลตฟอร์มแยก เมื่อเป็นส่วนหนึ่งของ gateway ที่รับชำระเงินอยู่แล้ว
หาให้เจอว่าปัญหาของคุณอยู่ที่เลเยอร์ไหน
บอกเราว่าคุณใช้ผู้ให้บริการกี่ราย และการชำระเงินล้มเหลวตรงไหน เราจะบอกตรงๆ ว่าทางแก้คือ routing, checkout หรือไม่ใช่ทั้งสองอย่าง รวมถึงกรณีที่คำตอบไม่ใช่เรา