替代方案 / 编排
寻找支付编排的替代方案
支付编排主打提升授权通过率和节省成本，两者都真实存在——前提是达到一定规模，且拥有多家收单机构。低于这一规模，这一层只会增加费用、依赖和多一跳，却没有任何路由收益。诚实的评估，要从判断你处于这条线的哪一侧开始。
评估
增加一层之前，先问六个问题。
你实际在用几家服务商？
只有一家收单机构，就没有可路由的对象。所谓收益，都以你有理由保留的多家合作关系为前提。
授权通过率提升一个百分点，对你值多少？
按你的年交易量算出来，再与这一层的费用加上运行它所需的工程投入相比。在较小的交易量下，这笔账很少算得过来。
你的拒付问题真的是路由问题吗？
许多看似路由的问题，其实是支付方式覆盖不足、收银台在授权前就流失了用户，或是 3-D Secure 策略设置过于激进。
谁来结算资金？
编排层通常不负责结算——结算仍由收款的那家服务商完成，这意味着你的对账依然横跨多家服务商，除非这一层也解决了这个问题。
报表会变成什么样？
在口径不一的各家服务商之间统一报表，往往才是真正的价值所在。请用你自己的服务商组合来演示，而不是演示数据集。
这一层会带来多大的依赖成本？
你在每笔支付的链路上都多加了一个系统。请问清楚它出现性能下降时会怎样，以及能否绕过它直接切换到某家服务商。
编排真正适用的场景
当你因为没有任何一家能覆盖你的市场、风险状况或费率而同时持有多家收单合作关系，并且交易量大到零点几个百分点都是真金白银时。到了这一步，按发卡行和支付通道路由、把软拒付级联到第二家收单机构、跨服务商统一的报表模型，就不再是锦上添花，而是损益表上的一行数字。前提始终不变：有多家你有理由保留的服务商。
- 01多家收单机构，因覆盖范围、冗余或费率而保留
- 02交易量大到一个百分点的通过率超过这一层的费用
- 03服务商之间的故障切换是业务要求
- 04口径不一的各家服务商，统一为一个报表模型
何时是错误的投入
当你只有一家服务商，或你要解决的问题在路由的上游。在单一网关之上再加一层，换来的只是一笔费用和多一跳。如果支付失败是因为客户偏好的支付方式不在页面上、收银台在授权前就流失了用户，或 3-D Secure 对不必要的流量发起了验证，再多的路由也挽回不了——解决办法在收银台，而不在它之上。
- 01只有一家服务商——没有可编排的对象
- 02流失发生在授权之前，而非授权之时
- 03真正的缺口是支付方式覆盖，而非路由
- 04在你的交易量下，费用超过路由收益
Protocore Gateway 的定位
我们是底层的那一层——一个负责收款并结算资金的网关——并把编排中对单一服务商业务真正重要的部分内置其中，而不是在上面另行出售：用你熟悉的语言编写的路由策略、客户看到失败之前在备用路线上的重试，以及运营人员可以据此行动的拒付原因。如果你确实达到了多收单机构的规模，whitelabel 平台可以把你自己的收单机构与我们的并列接入。大多数问这个问题的企业，需要的是更好的网关，而不是在现有网关之上再加一层。
- 01内置路由策略和重试，无需额外的层费用
- 02真正负责结算的网关，统一一种币种
- 03在 whitelabel 平台上接入你自己的收单机构
- 04银行卡、钱包、转账和 USDC，同一页面，同一个参考号
FAQ
值得向任何供应商提出的问题。
不需要。编排所宣传的每一项收益——路由、级联、费率套利——都以多家服务商为前提。在单一网关之上，这一层只是一笔费用和多一跳，没有任何可供选择的对象。
可以，前提是你的拒付确实属于路由类问题，并且有备用路线可以转发。如果流失发生在授权之前——支付方式不对、收银台过重、3-D Secure 策略过于激进——路由就无从下手。
通常不会。结算仍由收款的底层服务商完成，因此你的对账依然横跨这些服务商，除非平台明确解决了这一点。建议尽早确认——很多人会因此感到意外。
可以，如果你的网关已包含此功能。路由策略、软拒付重试和可读的拒付原因，只要是负责收款的网关自带的，就不需要另外的平台。
先弄清你的问题出在哪一层。
告诉我们你在用几家服务商，以及支付在哪里失败。我们会直截了当地告诉你，解决办法在路由、收银台，还是都不在——包括答案不是我们的时候。