支付技术栈七层：收单、编排、3DS、风控、拒付、资金管理与 BNPL 怎么分工
很多团队第一次做支付时，以为要解决的是"调用一个接口把钱收进来"。业务走上正轨之后才发现，手上已经长出七套彼此耦合的东西：收单方、编排路由、3DS 认证、风控决策、拒付处理、跨币种资金归集，以及分期或账期方案。这七层不是厂商为了卖货编出来的概念，每一层都能独立出故障、独立被替换、独立影响收入。
把七层分清的价值很直接。眼前的故障到底属于哪一层、某个新供应商是补哪一层还是在跟已有的一层打架、该按什么顺序上，这些问题在没有分层认知时会一直被判断错。
一、为什么"接个支付"最后会长成一套系统
起点通常很简单：一个能发起卡交易的商户号，也就是收单方。这一步最容易让人低估后面的事。
第一个复杂来源是失败率。同一张卡在同一家收单方可能失败，换一家就成功；不同地区、不同卡种、不同金额区间的授权表现并不一致。想改善这一点，最朴素的做法是接第二家收单方，然后按规则分流——这就是编排层的起点。
第二个复杂来源是合规压力。欧洲的强客户认证要求、各地区对认证的规定、卡组织对责任转移的条件，让认证从"可选项"变成必须显式设计的一层。
第三个复杂来源是欺诈与拒付。交易成功不等于钱到手：授权之后还有清算，还有持卡人争议的时间窗。风控与拒付处理因此从"风控部门的事"变成支付栈的一部分。
第四个复杂来源是钱的去处。跨境业务里收单资金往往不能直接落到有实际经营的账户，需要换汇、归集、分配；平台型业务还要把钱分给多个卖家。
第五个复杂来源是转化。分期与先买后付不是营销插件，它引入了新的风险承担方和新的对账口径。
这五股力量叠加，就是七层的由来。
二、七层各自解决什么问题
2.1 收单层：决定钱能不能进来
收单方替你向发卡行发起授权请求，并承担清算与卡组织层面的合规义务。它的能力边界由三件事决定：有没有本地收单身份、覆盖哪些卡组织与本地支付方式、能给出多高的授权通过率。
这一层的真实价格不是费率表上的百分比，而是"费率与通过率共同决定的单笔收入"。同样标称费率的两个通道，通过率差几个百分点，单笔净收入就可能差一成以上。
判断要点：收单层回答的是"能不能收"，不是"体验好不好"。把转化率问题归到收单层，通常会修错地方。
2.2 编排层：决定这笔尝试从哪个通道出去
编排层不持有资金，也不替你做风控决策，它管两件事：路由与状态。按金额、卡种、地域、时段把交易分配到不同收单通道；某个通道超时自动重试到另一个；把各通道五花八门的结果统一成一套订单状态。
它真正的价值不是省费率，而是把"换收单方"从一次项目变成一次配置。但这个价值有前提：支付凭据必须托管在编排层或独立保险库里。如果令牌还留在原收单方，编排层就只是个路由器，换通道仍然等于让全部老客户重新绑卡。
判断要点：只有一家收单方时不需要编排层；有两家以上、且确实需要按规则动态分流时才成立。
2.3 认证层：3-D Secure 与责任转移
3DS 是一条链：商户或收单方 → 3DS Server → 卡组织 Directory Server → 发卡行 ACS → 结果回到商户。商户通常只直接接触 3DS Server，链条其余部分由收单行、卡组织和发卡行决定。
这一层的核心权衡是"通过率换责任"。认证真实完成且交易满足条件时，欺诈类拒付的责任会转移到发卡行；代价是部分用户会在挑战环节流失。免验证（frictionless）的比例由发卡行的风险模型与当地监管豁免共同决定，商户能影响但无法决定。
判断要点：3DS 是合规与责任工具，不是转化工具。把它当成"提升通过率的手段"是方向性错误。
2.4 风控层：判断该不该放行
风控层要在授权之前给出判断：放行、拦截、还是要求额外验证。它依赖的信号包括设备指纹、行为轨迹、账户历史、地址与卡段一致性等。
一个关键区分：交易级风控判断"这笔交易像不像欺诈"，身份级风控判断"这个人是谁"。前者适合无账号的一次性交易，后者适合有账号体系的业务——账号级信号可以跨订单累积，冷启动难度完全不同。
判断要点：风控层与 3DS 会互相干扰。被风控拦下的交易不会进入 3DS，而 3DS 挑战失败的用户也可能被风控记为异常。两层必须共享同一份决策日志，否则永远调不出稳定的阈值。
2.5 拒付处理层：付款成功之后的第二场仗
拒付是持卡人向发卡行发起的争议，有自己的时限、证据要求与成本结构。这一层要解决的是：在时限内取到证据、按原因码组织材料、提交抗辩、跟踪结果，并在失败时把损失正确记账。
判断要点：拒付成本不只是退回去的货款，还包括固定争议费、抗辩人工成本；拒付率过高时，收单方还可能追加保证金或直接终止合作。真正决定成败的是友好欺诈占比与证据留存能力，而不是抗辩话术。
2.6 资金管理层：钱进来之后去哪
这一层处理币种、归集、换汇、提现与分账。跨境业务里它往往比收单层更影响现金流；平台型业务里它决定"钱进谁的账户、由谁开票"。
判断要点：收单成功与资金到账是两个时间点，两者之间的敞口由这一层管理。冻结与滚动预留金也发生在这里，所以"账面余额"和"可提余额"必须分开建模，否则会对不上账，也说不清现金到底有多少。
2.7 分期与 BNPL：改变的是谁承担信贷风险
BNPL 引入一个新的风险承担方。对商户来说，判断标准不是"能不能提升客单价"，而是三个问题：谁承担消费者违约、退款时分期计划如何调整、商户折扣率能否被增量毛利覆盖。
判断要点：市场上有"不承担信贷风险、只占用持卡人原有额度"的模式，也有"平台垫资并承担违约"的模式。两者对商户的准入要求、折扣率与账期影响完全不同，不能按同一套标准比价。
三、不是每个业务都需要七层
是否要加一层，用三个维度判断就够了：交易规模是否支撑得起这一层的固定成本；当前的失败率或拒付损失是否已经超过这一层的成本；是否存在跨主体、跨币种、多卖家这类结构性问题，无法靠单点优化解决。
规模很小的单市场业务，收单加基础风控两层就足够。把七层一次性全上，固定成本与运维复杂度会先压垮团队，而收益要到很久之后才出现。
四、三套典型栈
轻量栈：一家收单方 + 收单方自带风控 + 收单方托管结账页。适合单一市场、单一币种、订单量不大的业务。优点是接入快、卡片数据合规范围最小；缺点是换收单方等于重建，历史客户需要重新授权。整体架构可以参考 独立站支付架构指南。
成长栈：两家收单方 + 编排层 + 独立风控 + 3DS 服务。适合已有跨境需求、开始在意授权通过率与拒付率的团队。关键前提是令牌托管在编排层，否则编排只是摆设。成功率的具体优化路径见 支付成功率优化指南。
平台型栈：在成长栈之上加资金管理层（分账、多币种、预留金建模）与分期层。适合市场平台、平台型 SaaS、需要替客户收款的业务。它的复杂度主要来自"钱不是你的"，而不是技术本身，可对照 聚合支付与分账结算 理解分账模型。
五、分层时最容易踩的四个坑
坑一：先买编排层，再想凭据归谁。 令牌留在旧收单方，编排层就只能做路由，换通道时老客户全部要重新绑卡，转换期续费率会明显掉一截。
坑二：用风控拦截去补 3DS 的缺口。 两层职责不同，互相顶替的结果是"该挑战的没挑战、该放行的被拦住"，两边指标都变差。两层的分工与接口见 3-D Secure 2 认证指南。
坑三：把拒付处理当成客服流程。 拒付有时限与证据格式要求，逾期即失去抗辩资格，因此它必须是有状态机、有倒计时的系统，而不是一张工单队列。原因码与举证材料见 拒付原因码与举证手册。
坑四：只算标称费率，不算总成本。 真实成本应写成"费率与通过率共同决定的收入，减去拒付损失、预留金资金成本与各层订阅费"。只比费率数字，几乎必然选错。各层费率口径见 支付网关费率对比。
七层里的卡片数据合规边界见 PCI DSS 合规实操指南；单通道替换的执行顺序见 支付网关迁移指南。更多支付方案可参见 支付 分类。
来源：16IDC 原创，各层能力边界、卡组织规则与合规要求以对应服务商官方文档与当地监管规定为准。