波仔
🕸️ 第八章 Web系统的开发原则
📄 一句话概括

网站收钱的第一原则是不碰卡号；链接方式、嵌入字段、直连 API 三条路的差别不在功能，而在自评问卷要填 22 项、中等还是 300 项以上。

📝 本节和前面几节的关系

8-8 讲的是把功能挪到边缘节点，这一节讲另一种【挪出去】——把最敏感的那部分交给支付服务商。教材 8-9 的并列关键词是【链接方式、API方式、令牌方式】——前两个是路，第三个是这三条路底下都要用的机制。

一、收钱这件事的第一原则：不碰卡号

卡号是整套支付体系里最敏感的一串数字。 它有一个很不客气的特性：一旦经过你的服务器，你就被纳入了 PCI DSS 的合规范围。

麻烦的是，这个范围进来容易出去难—— 只要有一次卡号从你的机器上流过，你就得按那套标准做审计。

所以三种外部连接方式的本质区别，只有一句话： 卡号在哪儿被输入。 在别人的页面上输入、在你的页面上输入、还是直接由你的服务器发给银行—— 这一个位置决定了你后面要承担多少。

二、三条路，各自的合规代价

先把总账列出来：

【合规范围】这一列不是形容词，它有一个可以数的指标——自评问卷要填多少项：

SAQ A 和 SAQ D 之间隔着的，基本上是【要不要专职安全团队】这个问题。 时间成本也差得远：跳转页几天就能上线，直连 API 通常要两三个月。

所以【链接方式】值不值，取决于你怎么看待【用户跳走一下】这件事。 看上去牺牲了体验，换来的是整台服务器从合规范围里消失。 这是一个可以用一次跳转换掉一整个团队的选择。

三、令牌方式：把卡号换成一张没有价值的替身

教材里说的第三种【令牌方式】，其实不是和前两种并列的路， 而是这三条路底下都要用到的机制。

它的做法很朴素：把卡号换成一张没有价值的替身。 你手里存的是替身，真正需要卡号的时候，由发卡网络拿替身去换。 替身被偷了也没用，因为它出了那一套体系什么都不是。

换来的收益，每一条都有量化：

最后一行是订阅生意最痛的地方：卡过期、换新卡，扣款就会失败， 而令牌能跟着换新——不需要用户做任何事。 这笔钱不是省下来的，是本来会丢掉的。

代价也很清楚：生成一个令牌约 0.01~0.05 美元， 每笔令牌交易约 0.002~0.01 美元。 放到量上算，这笔成本远低于它救回来的续费。

四、动手前的三个问题，顺序不能颠倒

真要做的时候，先把这三个问题按顺序回答一遍：

一、卡号会不会经过我的服务器？ 会——先把这一条改掉，其他事都是后话。

二、我能不能接受用户跳走一下？ 能——就别自建收银台，跳转页面几天上线、合规范围最小。

三、我做的是不是订阅？ 是——令牌化就不是可选项，因为 7%~12% 的续费靠它才拿得回来。

最后把这几组数字放在规模里看：到 2026 年底， 令牌化预计处理超过 1 万亿笔交易； 85% 以上的在线商户已经在用；70% 以上的金融机构报告诈骗率下降。

合规标准现在通行的是 PCI DSS v4.0.1—— 上一版 v4.0 的过渡期已经在 2025 年 3 月结束，还在用旧版就是不达标。 这条时间线值得记一下：合规标准也会过期。

五、动手 Demo：收钱的三条路——链接、接口、令牌

令牌带来的收益里，有两项可以直接算：通过率提升值多少钱，续费能救回多少：

print("  授权通过率 +3~10 个百分点：每 100 笔多成功 3~10 笔")
print("  月订阅收入 1 万元，挽回 7%%~12%% = %.0f~%.0f 元" % (10000 * 0.07, 10000 * 0.12))

实跑输出：

--------------------------------------------------------------------
收钱的三条路——链接、接口、令牌
--------------------------------------------------------------------
  网站要收钱，就不能自己碰卡号。于是有三种把活交给外面的方式，
  成本、控制权、合规责任完全不同。先看总账：

  方式                 开发量     合规范围     适合谁
  ------------------------------------------------------------------
  链接方式（跳转）     最低       最小         想最快上线的小团队
  嵌入字段             中等       小           要品牌感又不想担合规
  API 方式（直连）     最高       最大         有安全团队的成熟公司
  ------------------------------------------------------------------
  合规范围那一列的数字，指的是自评问卷要填多少项：

  自评级别     问卷长度       什么情况适用
  ---------------------------------------------------------
  SAQ A        最短           卡号全程不经过你的服务器
  SAQ A-EP     中等           你在页面上嵌了别人的支付脚本
  SAQ D        300 项以上     卡号进过你的服务器
  ---------------------------------------------------------
  所以【链接方式】值不值，取决于你怎么看待【用户跳走一下】这件事。
  看上去牺牲了体验，换来的是整台服务器从合规范围里消失。

  教材里说的第三种【令牌方式】，是这三条路都要用到的底层机制。
  它的做法是：把卡号换成一张没有价值的【替身】，
  真正需要卡号的时候，由发卡网络拿替身去换。

  换来的收益，每一条都有量化：

  收益                           幅度
  -------------------------------------------------
  PCI 合规范围缩小               60%~80%
  授权通过率提升                 3~10 个百分点
  欺诈损失下降                   85% 以上
  自动更新卡号，挽回订阅流失     7%~12% 的续费收入
  -------------------------------------------------
  最后一行是订阅生意最痛的地方：卡过期、换新卡，扣款就会失败，
  而令牌能自动跟着换新——不需要用户做任何事。
  代价也很清楚：

  项目             成本
  ---------------------------------
  生成一个令牌     0.01~0.05 美元
  每笔令牌交易     0.002~0.01 美元
  ---------------------------------
  把这些数字放进规模里看：到 2026 年底，令牌化预计处理超过 1 万亿笔交易；
  85% 以上的在线商户已经在用；70% 以上的金融机构报告诈骗率下降。
  现在通行的合规标准是 PCI DSS v4.0.1，
  上一版 v4.0 的过渡期已经在 2025 年 3 月结束——还用旧版就是不达标。

  动手前先问自己三个问题，顺序不能颠倒：
  卡号会不会经过我的服务器？→ 会，就先把这一条改掉。
  我能不能接受用户跳走一下？→ 能，就别自建收银台。
  我做的是不是订阅？→ 是，令牌化就不是可选项。

别把【+3~10 个百分点】当成小数字。 支付行业的净利本来就薄，多成的这几笔基本上全是利润。 而右边那 700~1200 元更直接——它不是收入增长，是本来要丢的钱被留住了。 这也是为什么订阅模式里，令牌化基本不讨论【要不要做】。

30 秒实验

  1. 在网上买一件东西，注意结账时地址栏有没有跳到别的域名、页面上有没有出现支付平台的名字。
  2. 打开你的任何一个月度会员后台，找【更新付款方式】这个入口——它背后就是令牌机制。
  3. 翻一下你收到的实体银行卡，看看上面印的是完整卡号还是部分数字，想想网站后台该存哪一份。

常见误区

  1. 错误：自己写收银台体验更好，所以更专业。——纠正：自建收银台等于把卡号请进你的服务器，直接落到 SAQ D（300 项以上）；跳转只牺牲一次体验，换来整台服务器离开合规范围。
  2. 错误：用了支付平台的 SDK 就自动合规了。——纠正：合规范围看的是数据流过哪里，不是你用了谁的库；只要卡号进过你的服务器就是 SAQ D。
  3. 错误：令牌化只是一个安全措施。——纠正：它同时是收入措施；自动更新卡号能挽回 7%~12% 的续费收入，这是订阅生意里最直接的一块钱。
自测三问（点开对答案） 1. 三种外部连接方式最大的差别是什么？ —— **卡号在哪儿被输入**——它决定了你的合规范围（SAQ A 最短、A-EP 中等、D 要 300 项以上）以及开发量。 2. 令牌方式解决的是什么问题？ —— **把卡号换成没有价值的替身**：合规范围缩小 60%~80%、通过率 +3~10 个百分点、欺诈损失 -85%，换新卡时还能自动更新，挽回 7%~12% 的续费收入。 3. 现在该按哪个版本的 PCI DSS 做？ —— **v4.0.1。** 上一版 v4.0 的过渡期已在 2025 年 3 月结束，还在用旧版就是不达标。

相关笔记