对比 / Checkout
托管式 checkout 与自建 checkout
每个在线收款的商户都要回答这个问题：收集银行卡信息的页面，属于你，还是属于你的服务商？答案决定了你的 PCI 范围、新增一种支付方式的速度，以及卡组织新规落地时由谁来应对。这与其说是技术选型，不如说是在决定团队这一年该把精力花在哪里。
方案对比
决定取舍的七个问题
Dimension
托管式 checkout
自建 checkout
PCI 范围
极小。收集卡数据的页面属于服务商，你的服务器只会接触 token，不会接触卡号——通常是最轻量的自评估方式。
归你。直接处理卡数据会把你的系统纳入范围，随之而来的是设计、评估和每年的重新认证。
首笔支付上线时间
几天。创建订单、跳转、处理一个 webhook——大部分工作在于决定支付成功之后要做什么。
数月，而且长尾部分才是难点：3-D Secure、钱包弹层、错误状态、重试，以及每种支付方式的边缘情况。
新增支付方式
配置即可。新的支付方式随平台上线，直接开启；页面自动适配，你这边无需发版。
每次都是一个项目——集成、认证、UI 开发，以及每种方式都要长期维护。
对体验的控制力
高，但有边界：品牌、布局选项、自有域名，以及需要把支付嵌入页面时可用的嵌入式字段——都在服务商开放的范围之内。
完全掌控。如果你的 checkout 需要做真正特殊的事，不受任何他人限制。
转化优化
自动继承。支付方式排序、本地化、钱包支持和重试策略，随平台改进而提升，无需你自己做实验。
需要自己争取。针对你特定的转化漏斗，你可以做得比通用页面更好——前提是你有足够的流量和合适的人来认真去做。
持续跟进合规与更新
服务商的事。卡组织新规、SCA 变更、浏览器和钱包更新，都以平台更新的形式落地。
路线图上一条长期存在的事项——这项工作永无止境，却很少被优先排期，直到出了问题。
真实成本
按笔计费，清晰可见，与交易量成正比。
工程师薪资加认证费用，首笔支付之前就要投入，之后年年如此——通常被低估一个数量级。
01
托管式 checkout 何时胜出
对大多数企业、在大多数情况下都是如此。如果支付只是你收款的方式，而不是你出售的产品，那么 checkout 页面就不是你的优势所在——而自建的代价以最不起眼的方式支付：工程团队的一部分精力被长期占用在卡组织新规和支付方式集成上，而不是你的产品。托管页还能一并化解 PCI 问题，而这正是自建最大的隐性成本。
- 01支付是实现收入的手段，而不是产品本身
- 02你希望卡数据完全不在范围内，而不是小心地处理
- 03新的支付方式应当上线时，你这边无需发版
- 04你的工程师在客户真正购买的产品上更有价值
02
自建 checkout 何时胜出
当 checkout 本身就是产品时。为他人处理支付的平台、流程特殊到托管页无法表达的企业，以及交易规模大到零点几个百分点的转化提升就超过支付团队薪资的团队——这些情况确实存在，值得自建。监管要求卡数据处理环节位于自身网络边界之内，同样如此。低于这个规模，自建往往意味着以高昂的代价，重新发现托管式 checkout 存在的理由。
- 01支付本身就是产品——你代他人处理支付
- 02交易量足够大，边际转化提升超过团队成本
- 03监管机构或风险委员会要求该环节位于你的边界之内
- 04你的流程确实特殊，任何托管页都无法表达
03
Protocore 的定位
Protocore Gateway 是托管式方案，并且把常见的灵活选项直接内置，而不是另行销售：页面可运行在我们的域名或你的域名下，需要时可把支付字段嵌入你自己的布局，也可在你的应用中以原生方式呈现同一个 checkout。银行卡、钱包、银行转账和 USDC 汇聚在同一页面，并以同一个欧元金额、对应同一个订单编号完成结算。如果你的真实答案是第三种——你想做服务商而不是商户——同一平台也提供 whitelabel 版本，通常比从零自建网关更划算。
- 01托管页、自有域名、嵌入式字段或应用内——同一套集成
- 02银行卡、钱包、转账和 USDC 汇聚一页，以 EUR 结算
- 03从 checkout 到收据再到银行流水，始终是同一个订单编号
- 04支持 whitelabel，适合想做服务商而不是商户的你