评估
六个问题，分出高下。
哪些支付方式，在同一个页面上？
不看宣传册上的数量，而看客户真正会选的那些方式，是否呈现在同一个页面上。需要跳转，或要另外对接的支付方式，你往往用不起来。
最终到账的是什么币种？
如果答案因支付方式而异，你买到的就是一个对账难题。请明确询问：加密货币或跨境支付，最终会在你的账户里生成什么，以什么币种。
你要承担多少 PCI 范围？
真正的托管页面，即使嵌入你自己的页面布局，也能让卡数据远离你的服务器。请问清楚你的系统会存储什么，以及由此带来的评估要求是什么。
是否全程只有一个参考号？
收银台、收据、webhook、付款和退款，都应带有你提供的那个参考号。在系统之间映射两套标识符，正是月末对账出错的地方。
迁移究竟涉及什么？
已存储的银行卡应以 token 形式迁移，让订阅用户无需重新输入信息；在旧服务商完成结算期间，两家服务商应能并行运行。
出了问题，谁来回应？
客服工单队列，与编写结算代码的团队，是两种完全不同的服务。当付款看起来不对时，只有这一点最重要。
人们为什么离开收银台服务商
很少是因为费率更低。实际上通常是四种原因之一：客户需要的支付方式，服务商不愿接入；对账模式让财务一到月末就发怵；售后支持在最关键的时刻掉链子；或者路线图停滞不前，而支付世界却一直在变。找出哪一个是你的原因，就是整个评估的关键——一家在其余三方面都很出色的服务商，依然可能是错误的选择。
- 01客户想要的支付方式，迟迟不会上线
- 02对账每月要耗费某人好几天
- 03结算出问题时，没有人负责
- 04产品跟不上支付方式的发展
更换究竟要付出什么代价
集成方面比团队预期的更省力，边缘环节则比预期的更费力。下单调用和 webhook 处理通常一周即可完成；真正需要规划的是后续的收尾——不能中断的已存储银行卡和订阅，仍需沿旧服务商通道原路退回的退款，以及两套系统同时运行的一段时期。任何值得更换的服务商，都应该在你签约之前，而不是之后，就把这些收尾工作讲清楚。
- 01集成：一个订单端点、一次跳转、一个签名 webhook
- 02收尾：已存储银行卡、订阅、处理中的退款、并行运行
- 03退款始终沿收款所用的通道原路退回
Protocore Gateway 的定位
对于上述六个问题，我们的回答是：银行卡、钱包、银行转账、本地支付方式、BNPL 和 USDC 集中在一个页面上；所有款项均以欧元结算；即使支付字段嵌入你的页面布局，处理卡数据的环节仍由我们承担；一个参考号贯穿从收银台到银行流水的全程；已存储银行卡以 token 形式迁移，并与旧服务商并行运行；回应你的，正是编写这套系统的人。是否值得更换，取决于上述四种原因中哪一个是你的——如果你只是想要更低的费率，我们大概不是合适的选择。
- 01所有支付方式集中一页，统一结算为一个欧元金额
- 02从收银台到付款再到退款，一个订单参考号
- 03迁移规划包含并行运行，token 迁移亦在其中
- 04背后是产品工作室，而非客服层级
FAQ
值得向任何供应商提出的问题。
可以，迁移期间也应当如此。新订单指向新服务商，旧服务商继续完成自身支付的结算和退款——退款始终沿收款所用的通道原路退回，因此旧集成要保持运行，直到最后一个退款期结束。
不应该。已存储的银行卡以 token 形式在服务商之间迁移，如果你运营订阅业务，这是最需要问清楚的一点——让所有已存储银行卡重置的迁移，只会造成用户流失，算不上迁移。
集成本身通常一周。真正决定时间表的是围绕它的计划——并行运行、token 迁移、旧服务商的最后一个退款期——通常以周而非月来计算。
那就先向你现在的服务商要一个上线日期，再去评估其他方案。为了一种支付方式而更换服务商，投入大而收益有限，除非同一场沟通让你发现了上述另外三个问题。
让我们来过一遍这份清单。
在我们的演示收银台上完成一笔真实支付，然后告诉我们你现在的服务商没通过六个问题中的哪几个。我们会如实告诉你，这个季度是否值得更换。