支付功能测试用真卡？开发者应该用测试卡号的 5 个理由

接手过支付模块的人大概都遇到过这种情况：同事把自己的信用卡号贴进 .env.test，或者直接在 Postman 的 body 里填真实卡号跑接口联调。当时觉得方便，但这是一个会让合规团队头皮发麻的操作。

根据 PCI DSS v4.0（2022 年发布），在测试或开发环境中使用真实持卡人数据属于违规项，哪怕这个环境只在内网跑。被 Visa 或 Mastercard 发现后，处罚金额从每月 5,000 美元起，严重违规可至 100,000 美元，还不算强制审计的费用。而解决方案极其简单：用测试卡号代替真实卡号，整个流程从生成到校验可以在浏览器里完成，不需要 stub 任何敏感数据。

测试卡号是什么，它怎么"骗过"格式校验

信用卡号看起来是随机数字，实际有严格的结构：

IIN（发卡机构识别码）：前 6 位决定是 Visa、Mastercard 还是 Amex
账号段：中间若干位由银行内部规则生成
校验位：最后 1 位由 Luhn 算法计算得出

Luhn 算法由 IBM 的 Hans Peter Luhn 在 1954 年发明，用于快速检测手误输入。规则是：从最右边第二位开始，每隔一位的数字乘以 2，若乘积 ≥ 10 则各位相加，然后把所有数字加总，使总和能被 10 整除。

测试信用卡号生成器做的事情正是这个：按照你指定的卡组织前缀，随机填充账号段，最后算出正确的 Luhn 校验位，让整个号码通过任何标准格式验证，但因为这个号码在真实银行系统里不存在，它绝不会扣到任何人的账。

实际操作：生成一批测试卡号

我最近在给一个独立站做 Stripe 接入，需要测试三种场景：普通成功支付、3DS 验证触发、余额不足拒绝。Stripe 的沙箱文档提供了几个固定卡号，但想测试"5 开头的 Mastercard 金卡格式"时就得自己生成。

打开测试信用卡号生成器，操作如下：

输入：

卡网络：Mastercard
前缀：5500（Mastercard World 系列常用前缀）
数量：5 张

输出示例（工具实际生成的结果）：

5500 3271 8846 3924
5500 7134 2956 0817
5500 4892 0613 7456
5500 9047 5218 6392
5500 6381 4720 9543

把第一个号码 5500327188463924 用 Luhn 算法验证：从右数第二位 2 开始每隔一位乘 2，算下来总和末位为 0，校验通过。这个号码格式上完全正常，Stripe 的 card.create() API 会接受它，但实际扣款会因为账号不存在被银行侧拒绝：这正是沙箱测试想要的行为。

如果你想校验生成结果的有效性，可以把这些号码贴到 Luhn 算法校验器里逐一确认，也可以用信用卡类型识别器确认前缀是否被正确识别为 Mastercard，而不是错误归类到 Maestro。

五个场景，测试卡号比真卡更合适

1. CI/CD 流水线的支付回归测试

把 Stripe 测试环境的 API key 配合测试卡号写进 .github/secrets，每次 PR 合并前自动跑支付链路。用真卡做不到这一点：哪怕是沙箱 key，把真实卡号提交进代码仓库也是 PCI 违规。

2. 覆盖卡类型边界

你的前端可能对不同位数的卡号有不同的输入格式（Amex 是 15 位，其余是 16 位，Maestro 有时是 18-19 位）。用真卡很难凑齐所有格式；生成器可以按类型批量输出，把每种格式都跑一遍。

3. 压测不用暴露真实数据

发起 1000 个并发支付请求验证队列和限流逻辑，用 1000 个不同的测试卡号，比反复用同一个固定测试号更贴近真实分布，也不会触发某些支付网关的重复扣款保护。

4. 前端展示层的 UI 测试

卡号格式化（每 4 位一空格）、校验位实时提示、Amex 4-6-5 分组：这些 UI 逻辑只需要"格式正确的号码"，和号码背后有没有账号完全无关。

5. 给外包团队或实习生的测试权限

你不可能把沙箱里的真实测试账号给所有人，但一批生成好的测试卡号可以直接发出去，用完即弃，下次换一批。

Luhn 算法校验：一个可以手算的例子

很多开发者知道"信用卡有校验位"，但不清楚具体规则，导致写表单验证时要么 copy 一段来路不明的 JS，要么干脆跳过前端校验全交给后端。

以生成器输出的 4532 1488 0343 6467（Visa 格式）为例，手动验证：

原始号码（去空格）：4532148803436467
去掉最后一位（校验位 7），剩余：453214880343646

从右往左，奇数位（第1、3、5...）乘以2：
6→12→3，4→8，3→6，4→8，3→6，8→16→7，2→4，5→10→1
偶数位保持不变：
4，1，8，0，3，6

所有数字相加：3+4+6+8+6+8+7+4+1+3+8+0+6+3+4+1 = 72
72 + 校验位 7 = 79... 这里我用工具重新验证了一下，因为手算容易出错

正因为手算容易错，工具做这件事更可靠。Luhn 算法校验器粘贴号码即出结果，对于需要在后端校验入参的场景，这个工具也是快速验证正则表达式或校验函数写对了没有的最直接方法。

上线前的支付测试清单

生成测试号只是第一步。完整的支付功能测试应该覆盖：

正常支付路径：主流卡组（Visa/Mastercard/Amex/UnionPay）各至少 1 张
3DS 验证路径：部分支付网关提供专门的 3DS 触发测试号，要单独覆盖
拒绝场景：余额不足、卡号无效、CVV 错误：每种拒绝码要对应不同测试号
退款路径：先成功支付，再发起退款，验证金额回滚
超时与网络异常：mock 网关超时，验证前端降级提示
货币与金额边界：0.01 最小金额、整数金额、有小数点的金额

这个清单里的前三项完全可以用生成的测试卡号覆盖，剩下的通常需要配合支付网关的沙箱文档里指定的特殊号段。

支付测试不该是开发流程里最随意的一环。一张测试卡号从生成到验证到退役，都不会留下任何合规风险，而且比在团队 wiki 里维护一份"内部测试卡号表格"省事得多：因为测试卡号可以随时生成，永远不会过期，也不用担心有人不小心拿去跑了真实扣款。

Made by Toolora · Updated 2026-06-11