Stripe 的卡资料能搬走，Link 凭据为什么另算

摘要

换支付服务商的预算表里，最容易少算的一笔，可能是请老顾客再掏一次卡。

不是每位顾客都需要这么做。问题恰恰在于，商户得先知道谁需要。把所有老顾客装进一个“客户数据可迁移”的大纸箱，盖上盖子，再去比较新旧处理费，账就已经算粗了。客户姓名、过去的订单，以及下一次能不能照旧完成付款，是三件不同的东西。

Stripe 的卡资料导出说明把分界写得很清楚：它会协助把卡资料安全移交给新的处理商，但通过 Link 保存的支付凭据不进入这份导出。对准备搬家的商户而言，先要认清箱子里到底装了什么。

Link 的吸引力也很具体。按照 Stripe 的Checkout 文档，已经登录 Link 的顾客可以复用保存的付款信息，即使最早保存这些信息的是另一家商店的结账页。一位新客第一次来买东西，付款时就可能享有熟客般的顺手。

这份便利相当聪明。小店不必先积累多年交易，才有机会让一个顾客少填几格。钱包把别处形成的熟悉感带到了新店门口。商户得到的是现成的付款体验，买家得到的是少一点重复劳动。

但“我的店服务过这个顾客”和“我的店能把这套付款凭据带往下一家处理商”并非同一本账。第一次见面就能认出的熟客，首先可能是钱包的熟客。商户买到服务的效果，并未因此买断实现这个效果的全部资料。

Stripe 的Link 说明描述了识别、一次性验证码和自动填写付款及配送信息的过程，用户也能管理自己的 Link 账户。消费者在其中有自己的账户和选择。把他简化成商户数据库里一行可装箱的资产，恰好漏掉了最有行动能力的那个人。

考虑一个准备换服务商的商店，作为说明这个问题的假设。它有一批回头客，有些留下了可以迁移的普通卡资料，有些主要使用 Link，还有些可能另有可用的付款方式。商店可以在新系统里保留顾客姓名和消费记录，却仍要逐组确认下一笔钱怎样付进来。

如果另有合适的凭据，过渡可能简单。如果新路径要求顾客重新输入，工作就从资料搬运转到顾客沟通：在什么时候提示，在哪一步填写，谁处理疑问，失败后如何把购物车留住。这里没有真实商户样本可给出损失率；实际凭据覆盖和顾客重新填写后的付款结果，才会改变成本判断。

少填几格有价值，重新填几格也有成本。两件事可以同时成立。支付团队庆祝的快捷体验，到了迁移项目里，可能成为需要重建的工作。这个成本未必巨大，但它不会因为采购表只留了一栏“每笔费率”而自动消失。

更准确的比较，是看换供应商之后，同一批顾客能完成什么。一个完整的客户名单很适合做汇报；一个能顺利付款的回头客更适合做生意。

Stripe 也在提供跨处理商工具。其Orchestration 文档介绍多处理商路由和失败重试，但截至本文核查时，它仍处于私人预览，支持范围明确排除 Link。

这给采购讨论补上了另一条分界。交易今天走哪条处理路径，与付款凭据能否脱离原有服务独立迁走，是不同问题。把两家处理商接进流程，不能替代对钱包凭据范围的检查。多一条路，得先确认要走的那辆车获准上路。

具体功能还得具体看。功能支持表列明，部分处理商支持网络令牌；因此，把所有令牌一概说成搬不动，只会把真正的边界说糊。该页还介绍可选择启用的错误保护：遇到不支持的功能时，付款可能改由 Stripe 处理。原处理商为 Stripe 的故障转移另有例外。最终处理路径和最初选择的路径，需要分开核对。

文件交接、交易分流、钱包复用，各有自己的规则。采购合同里一个响亮的“开放”，替不了这三项验收。

对商户来说，合理的选择并非见到依赖就拔插头。一个刚开张的店，可能更需要今天少掉一笔放弃付款，而不是为了假想中的迁移把结账体验搞得繁琐。成熟商户则可能愿意为另一种付款路径付出更多维护成本。它们面对的是不同的生意。

真正值得挑刺的是把共享钱包的便利，直接当成自己已经拥有的迁移能力。前者按顾客体验兑现，后者在退出时接受检验。供应商可以把前者做得很好，而后者仍然需要商户另付努力。

Link 把熟客式的付款体验带给一家家商店。商户应该欢迎这份便利，也应该在换服务商的预算里认清它的边界。搬走客户表那一天，收银台还得开门。