支付每层自建还是买：三个判断问题与逐层判据

支付每一层该自建还是买：判断标准不是贵不贵，而是出事时谁兜

支付栈由七层左右组成，每一层都要回答"自建还是买"。多数团队用一张成本表来决定：自建要几个人月、采购要多少订阅费，比出便宜的那个。

这个算法漏掉了最关键的一项：出事的时候谁兜。payment 这个词在英文里同时意味着"付款"和"代价"，在架构决策上两者是一回事——便宜的那条路，代价通常延后到事故发生时结清。

问题一：出事时谁承担责任。 牌照类、清算类、争议裁决类的责任，只能由持牌机构承担，自建在合规上不成立，与成本无关。

问题二：这一层是不是你的差异化。 如果你的支付体验与竞争对手不会因此不同，那它就是基础设施，买比自己造划算。反过来，账户体系、定价模型、对账口径这类直接决定你能做什么业务的东西，外包出去就等于把差异化交出去。

问题三：这一层的变化速度是否超过你的迭代速度。 收单方与卡组织的规则变更频率、各地监管口径的调整频率，往往快于大多数团队的发布节奏。跟不上变化的层，应该买。

三个问题里只要有一个答案指向"买"，就基本可以定了。三个都指向"自建"才值得投入。

收单层：必须买。 收单资质是牌照与清算网络准入，不存在自建选项。能自建的只是"接哪几家、怎么组合"。

编排层：看收单家数与分流复杂度。 只有一家收单方时不需要；有两家以上且分流规则会变时才成立。上线前先确定令牌归谁管，否则编排只是一层转发。

认证层（3DS）：买服务，但决策权自留。 3DS Server 属于标准化服务，自建不划算。但"哪些交易主动申请免验证、哪些必须走挑战、哪些场景用哪类豁免"这套策略必须自己拿着，因为它是转化率与责任的权衡点。

风控层：买引擎，自留规则与阈值。 引擎与信号库自建成本极高且需要持续喂养数据。但业务规则、白名单、阈值与人工审核队列必须在自己手里——这些是业务判断，不是技术能力。

拒付处理层：买抗辩服务，自留证据留存。 抗辩提交与原因码模板可以外包，但证据（物流签收、服务记录、沟通留痕、登录与操作日志）只能你自己在生产系统里留。服务商能帮你组织材料，变不出材料。

资金管理层：必须买账户与清算，但账本要自建。 收款账户、换汇、清算通道都是持牌业务。但你自己的"可退余额账本""待结算明细""分账台账"必须自建——它们是业务事实，第三方接口只提供流水，不提供你的业务口径。

分期与 BNPL：买。 信贷风险由持牌方承担，自建等于自己开银行。

对账系统：自建。 这是少见的一层：应该自建。因为对账的本质是"把你自己的业务口径与外部流水对齐"，没有人比你更清楚你的业务口径。外部工具最多提供流水下载与差分比对，最后的差异归因永远在业务侧。

订单状态机与幂等：必须自建。 它不是一层产品，是贯穿所有层的地基。任何外包方案都不会替你定义"什么算成功、什么算失败、重试时怎么判断"。这层缺失时，再好的外部服务也会造成重复扣款或状态错乱。

错误一：自建"看起来很简单"的适配层。 写一个把交易转发给两家收单方的中间层，第一天确实简单。但每接一家要维护一套适配器，每家的认证方式、错误码、退款接口、结算文件格式都不同，收单方改一次版本就要跟着改一次。适配器维护是长期成本，不是一次性开发成本。

错误二：自建风控模型却没有标签数据。 风控模型需要"这笔最终是不是欺诈"的标签，而这个标签只来自拒付结果与人工审核结论。新业务前几个月没有足够标签，自建模型的效果通常不如直接用服务商的通用模型加几条硬规则。

错误三：自建账本却按第三方口径设计。 有些团队把"第三方给的结算流水"直接当账本用，表面省事，代价是业务一变就改不动——比如新增分账、新增部分退款、新增多币种结算时，发现数据结构里根本没有对应的位置，只能推翻重建。

无论多少层外包，这四件东西必须在自己系统里，且必须是第一等公民：

订单状态机与幂等键。 定义唯一的状态流转与唯一的去重依据。外部返回值只能作为状态变更的输入，不能直接决定状态。

可退余额账本。 每笔交易、每笔退款、每笔部分退款之后，这笔交易还剩多少可退，必须由自己维护。只依赖外部接口查询可退金额，在跨通道、跨时间的情况下会出错。

原始流水留存。 外部服务给的"统一格式"方便阅读，但排查问题时必须能穿透到原始请求与原始响应。原始数据要落库，且要能按订单号追溯。

决策日志。 风控为什么拦、认证为什么挑战、路由为什么走这条通道，三个决定必须记录在同一个可追溯的时间线上。否则出了争议，你既说不清也改不动。

刚上线、单一市场：收单、风控引擎、认证服务全部买；自建订单状态机、幂等与对账。这套组合的固定成本最低，且不会留下结构性负债。

开始跨境、两家以上收单：加编排层，同时把令牌托管理顺；风控从"用服务商默认"过渡到"自留规则"。此时最容易犯的错是先上编排再想凭据归属。

平台型业务：必须自建账本与分账台账，外部只提供账户与清算能力。这一阶段的复杂度不是技术问题，而是"钱不是你的"带来的合规与对账问题。

各层在整体架构中的位置见支付技术栈七层分工；编排层的自建与采购细节见支付编排层该不该上；状态机与幂等的具体设计见订单号与幂等设计；对账自建的做法见对账自动化脚本实现。更多支付方案可参见支付分类。

来源：16IDC 原创，牌照与清算相关的业务边界以当地监管规定与持牌机构条款为准。