支付编排层选哪家：三家厂商的架构主张与退出成本

支付编排层选哪家：三家厂商的架构主张与退出成本

当你已经确认要上编排层——原因通常是多通道并行、需要按真实成本路由、或者换通道的频率已经高到自建撑不住——下一个问题就不是「要不要」，而是「买谁的」。而这时最容易犯的错，是打开三家的功能表逐项打勾。

三家的功能重叠度很高：都能管凭据、都能路由、都能串风控与 3DS、都有控制台。真正的分歧在于它们对同一件事给了三种不同回答：凭据归谁管、运营可见性归谁做、运维责任归谁担。这三个答案决定了你三年后的处境。

「该不该上、自建还是买」的判断方法见 支付编排层该不该上，本文只处理：在已经决定买的前提下，三家各卖什么主张，以及你该按什么顺序决策。

一、三家其实在卖三种不同的东西

1.1 保险库型：你买的是「换成通道的自由」

Spreedly 的自我定位是支付编排，但它的核心资产不是路由算法，而是保险库。它明确不做收单：既不是收单机构也不是支付服务商，交易清算仍由商户自己签约的网关、处理商或收单行完成。

理解这一点的意义：当你把卡数据交给一家网关，凭据就锁在那家网关里，换通道等于全量老客户重绑卡——这是绝大多数团队不敢换通道的真实原因，而不是接口难改。凭据存在自己的保险库时，换处理商的动作变成「把整库带走」，一次集成之后，再换通道的边际成本才接近于零。

1.2 运营型：你买的是「多家跑起来还能对得清账」

Primer 的三条产品线划得很清楚：Payments 管收单链路，Revenue 管钱对不对得上，Platform 管运营可观测性。这个划分本身就是它的主张——目标不是帮你多接一家支付方式，而是让多家同时跑起来之后还能对得清账。

它把支付运营当成一等公民：失败转移、可观测性、成本洞察与对账，这四件事在多数编排方案里是外挂或第三方补丁，而它做成了内建能力。

1.3 基础设施型：你买的是「控制权，附赠运维责任」

Gr4vy 采用了一个不太常见的自我定位：IaaS。这个定位的含义是它希望被当成基础设施采购，而不是被当成一家支付服务商采购。产品由五个模块组成：收单接入、结账组件、凭据托管、路由与成功率优化、数据与报表。

它的核心主张是一句话：PSP 应当是无状态的。理由是收单商有天然动机把交易往自己基础设施上导，因为那关系到它的边际收益。把 PSP 降格为可替换的资源，控制权才真正回到商户手里——代价是这份控制权要靠你自己的支付工程能力来兑现。

二、三家的机制差异

2.1 Spreedly：核心资产是保险库，不是路由

除了凭据主权，它还有三处值得单独看：

一次集成，后续换处理商的边际成本接近零。它把不同网关的差异吸收在同一层接口里，新增一家通道不需要重做前端与订单逻辑。

规则变更从研发期里拿出来。它的 Composer 让支付团队自己配置风控、路由与结算规则，而不必排研发排期。这条对增长期团队很实际——路由策略的调整频率往往远高于版本发布频率。

路由依据是实时的成本与授权率，用真实成交数据决定每一笔走哪条路，而不是用一份季度更新一次的静态权重表。

它的约束也很明确：不承担收单。商户号、保证金、行业准入审核、结算周期都不变，每个通道仍要单独签约。另外定价不公开、需与销售议价，学习成本压在支付工程侧——团队要理解各网关差异、令牌化机制与 3DS 流程。

2.2 Primer：把支付运营当成一等公民

它的四处能力构成一条链：

失败转移是内建能力。一笔交易被第一家拒掉后自动转投下一家，这个动作在自建方案里通常要写很多特例代码，做不好会出现「同一订单重复扣款」或「状态不一致」。

网络令牌化降低换通道的代价。卡凭据以网络令牌形式存在，换通道时不必重来一遍——这与 Spreedly 的保险库主张在方向上一致，但实现路径不同。

对账与成本洞察在同一条产品线里。对账与成本洞察都归在 Revenue 线下，意思是它把「钱对不对得上」当成产品问题而不是售后问题。对账本身的方法见 对账与账单下载操作手册。

运营可观测性单独成线。Platform 线解决的是「出问题时你能不能看见」，这在多通道场景里比路由算法更常成为瓶颈。

它的硬前提是：必须有 2 家以上通道才有意义。只有一家收单商的团队买它，等于为一个用不上的能力付费。另外它不能替代财务口径——会计政策、收入确认与税务仍在你这边。

2.3 Gr4vy：PSP 应当无状态

它的四处能力：

加 PSP 不改前端。启用新的 PSP 与反欺诈服务不需要改动收银台或新建接口，这是「无状态」主张的直接兑现。

支付方式覆盖广度。官网口径是一个集成可覆盖 400 以上的支付方式，这个量级的意义在于按国家接本地方式时不必逐个重做集成。具体清单与地区可用性以官网为准。

失败支付的挽回是可量化的收入。官网称失败支付最高可挽回一定比例的收入——这个数字是厂商口径，不能直接套到自己的业务，但方法论是对的：把失败率拆成「可挽回」与「不可挽回」，只对前者投入。整体成功率优化方法见 支付成功率优化。

IaaS 定位是一把双刃剑。它把控制权交给你，同时把运维责任也交给你。没有懂支付工程的团队，这份控制权会变成负债。

三、第一个决策：凭据归谁管

这是整篇最重要的一节，因为它决定了你三年后能不能换通道。

凭据的归属有三种状态：存在收单方或网关那里、存在编排层的保险库里、存在你自己的保险库里。三者的差别不在技术难度，而在迁移成本：

• 存在网关：换网关 = 全量客户重绑卡，实际不可行，于是你被锁死在一家通道上。
• 存在编排层保险库：换网关可以带走整库，但换编排层本身仍然困难。
• 存在自有保险库：迁移自由度最高，但你需要自己承担 PCI 范围与密钥管理。

因此第一个问题不是「哪家保险库更安全」，而是你愿意把「换通道的自由」寄存在谁那里。选 Spreedly 或 Primer 这类方案，你买到的是「换通道的自由」；但这个自由的前提是你不再更换编排层本身。这一点在合同期与迁移条款里必须写清。

PCI 范围会随凭据位置变化，合规范围的判定与 SAQ 选型见 PCI DSS 合规实务。

四、第二个决策：你要不要接管运维

编排层把控制权交给你，同时也把一类新的工作交给你：多通道的适配器维护、状态机与幂等、跨 PSP 对账、以及每一家的失败语义差异。

这一层工作无法被完全外包，只能被部分转移。三家的差别在于转移了多少：运营型（Primer）把可观测性、失败转移与对账做成产品，你少写代码但要对它的抽象建模；基础设施型（Gr4vy）把抽象做到最薄，你保留最大控制力，也保留最多自建工作。

判断标准是团队构成。有专职支付工程师、且把支付当核心竞争力的团队，更适合薄的抽象；没有专职团队、希望尽快稳定的业务，更适合厚的产品。 自建与外包的分界线见 支付每一层该自建还是买。

五、成本结构与退出成本

三家的定价都不公开，按交易规模与模块组合议价。因此在采购阶段必须把总成本拆成四块来问：

1. 固定平台费：与交易量无关的部分，规模小时占比很高。
2. 按量费用：按交易笔数或金额计，需要问清计费口径（授权、捕获、退款是否都计）。
3. 附加模块费：路由优化、对账、可观测性是否单独计费。
4. 退出成本：这一项几乎从不写进报价单，却是四年总成本里最大的一块。

退出成本至少包含三层：凭据能否完整导出、导出后对方网关是否接受这种格式、以及切换期间双跑造成的人力与对账成本。建议在合同里明确「凭据导出」的格式、时效与费用，并约定终止后的数据保留期限。

费率与成本审计的方法见 手续费对账；多通道带来的资金占用变化见 预留金与资金占用建模。

六、验收与上线清单

幂等与状态机的最小实现要点见 订单号设计与幂等表 与 多通道支付回调框架；从旧通道迁移的执行步骤见 支付通道迁移实操。

七、什么时候不该上编排层

四种情况，上编排层是负收益：

1. 只有一家通道且一年内不打算增加。编排层的价值来自「多」，单通道场景下它只增加一跳延迟与一层对账。
2. 没有支付工程能力。抽象越薄控制力越强，但也意味着适配器、状态机与对账都要自己写。
3. 客单价极高、笔数极少。这类业务的优化空间在人工审核与结算条件上，不在路由算法。
4. 合规上不能把凭据交给第三方。这时只能走自有保险库路线，编排层的保险库优势消失。

八、四个常见误判

1. 把编排层当收单方：三家都不提供收单资质，商户仍是每一家的签约方，商户号与保证金不变。资金架构的设计见 平台型业务的资金架构。
2. 以为上了编排层就能自动提高成功率：成功率提升来自「有第二条路可走」与「按真实数据选路」，前提是你确实接了多家并且路由策略在持续校准。
3. 忽略编排层自身也是一层依赖：它宕机时所有通道都不可用，可用性要求不能低于关键通道。
4. 只比按量费率，不比退出成本：前者是可见的年度支出，后者是四年后决定你还能不能换的隐性壁垒。

来源：16IDC 原创，各平台的产品范围、支付方式覆盖与计费口径以其官网文档及商务合同为准。