替代方案 / 協調
尋找支付協調（payment orchestration）替代方案
支付協調主打授權率與成本節省，兩者都是真的——但前提是達到一定規模，且擁有不只一家收單機構。低於這個規模，這一層只會多出一筆費用、一項依賴與多一道中繼，卻沒有任何路由收益。誠實的評估，要先釐清您落在這條線的哪一側。
評估
加上一層之前的六個問題。
您實際使用幾家供應商？
只有一家收單機構，就沒有可供路由的對象。所謂的收益，前提都是您有多家值得保留的合作關係。
授權率每提升一個百分點，對您值多少？
以您的年交易量乘算，再與這一層的費用加上營運所需的工程成本相比。交易量較小時，這筆帳往往算不過來。
您的拒絕問題真的出在路由嗎？
許多看似路由的問題，其實是支付方式涵蓋不足、checkout 在授權前就流失了客戶，或是 3-D Secure 政策設得過於嚴格。
誰負責結算款項？
協調層通常不負責——結算仍由收款的供應商處理，這表示除非協調層也解決這件事，否則您的對帳仍需橫跨多家供應商。
您的報表會變成什麼樣子？
在彼此不一致的供應商之間統一報表，往往才是真正的價值所在。請對方用您自己的供應商組合展示，而不是範例資料集。
這一層會帶來多少依賴風險？
您等於在每一筆付款的路徑上多加了一套系統。請詢問它效能降級時會發生什麼事，以及您是否能繞過它直接切換到供應商。
協調層真正適用的時機
當您已經因為沒有單一供應商能涵蓋您的市場、風險特徵或費率，而同時持有多家收單關係——而且交易量大到百分之零點幾也是一筆實在的金額。到了這個階段，依發卡行與跨境路徑進行路由、將軟拒絕轉送第二家收單機構，以及跨供應商的單一報表模型，就不再只是好點子，而是損益表上的一行數字。前提始終不變：您有多家值得保留的供應商。
- 01多家收單機構，因涵蓋範圍、備援或費率而保留
- 02交易量大到一個百分點的授權率勝過這一層的費用
- 03供應商之間的容錯移轉是業務需求
- 04跨越彼此不一致供應商的單一報表模型
何時是錯誤的投資
當您只有一家供應商，或您要解決的問題位於路由的上游。在單一 gateway 之上加一層，只會買到一筆費用和多一道中繼。如果付款失敗是因為客戶偏好的支付方式不在頁面上、checkout 在授權前就流失了客戶，或是 3-D Secure 對不需要驗證的流量發出了挑戰，那麼再多的路由也挽回不了——解法在 checkout，而不是在它之上。
- 01只有一家供應商——沒有可協調的對象
- 02流失發生在授權之前，而非授權當下
- 03真正的缺口是支付方式涵蓋，而非路由
- 04以您的交易量來看，費用高於路由帶來的收益
Protocore Gateway 的定位
我們是底層的那一層——一個負責收款並結算款項的 gateway——並把協調層中對單一供應商業務真正重要的部分直接內建，而不是在上方另外販售：以您看得懂的語言撰寫的路由政策、在客戶看到失敗之前改走替代路徑重試，以及營運人員能據以處理的拒絕原因。如果您確實達到多收單機構的規模，white-label 平台可以讓您的自有收單機構與我們的並行連接。多數提出這個問題的企業，需要的是更好的 gateway，而不是在現有 gateway 之上再加一層。
- 01內含路由政策與重試，無需額外的協調層費用
- 02真正負責結算的 gateway，以單一幣別結算
- 03在 white-label 平台上連接您自己的收單機構
- 04卡片、錢包、轉帳與 USDC，同一頁、同一個參考編號
FAQ
值得向任何廠商提出的問題。
不需要。協調層所販售的各項收益——路由、串接轉送、費率套利——都以多家供應商為前提。在單一 gateway 之上加一層，只是多一筆費用與多一道中繼，沒有任何可供選擇的對象。
可以，前提是您的拒絕確實屬於路由問題，且有替代路徑可以轉送。如果流失發生在授權之前——支付方式不對、checkout 太繁重、3-D Secure 政策過於激進——路由就無從著力。
通常不會。結算仍由實際收款的底層供應商處理，因此除非平台明確解決這一點，否則您的對帳仍會橫跨這些供應商。建議及早確認——這常讓人意外。
可以，只要您的 gateway 本身內建。當路由政策、軟拒絕重試與可讀的拒絕原因都屬於負責收款的 gateway 時，就不需要另外的平台。
找出您的問題究竟出在哪一層。
告訴我們您使用多少家供應商，以及付款在哪裡失敗。我們會直接告訴您，解法是路由、checkout，還是兩者皆非——包括答案不是我們的時候。