编码解码哈希加密格式化时间转换开发生成文本处理网络工具其他工具
首页 / 开发生成 / 测试卡号生成

测试卡号生成

生成测试用的合法卡号。

结果

这个工具能做什么

测试卡号生成用于快速造出一批“看起来像真的、能通过基本校验、但不对应任何真实账户”的虚构银行卡与信用卡号。开发支付相关功能时经常需要卡号作为输入,可真实卡号既不能也不该出现在测试环境里,而手动瞎敲的号码又过不了前端的 Luhn 校验,来回卡壳很耗时。这个工具按你选的卡种(如 Visa、万事达、银联)生成前缀正确、位数正确、末位校验位也正确的卡号,直接复制进表单或测试数据即可用。

它的核心是 Luhn 算法(又称模 10 算法),这也是几乎所有发卡机构给卡号加的一道防手误校验。生成时,工具先按卡种取一段固定的发卡行标识前缀(BIN/IIN,比如 Visa 以 4 开头、银联以 62 开头),中间的账户位用随机数字填满,最后单独反推出末位校验位:从右往左把偶数位数字翻倍、结果超过 9 就减 9,再把所有位相加,让总和能被 10 整除,这个凑整用的数字就是校验位。正因为校验位是反推出来的,生成的每个号码天然满足 Luhn,前端的合法性判断必然通过。

最典型的用法是测支付或注册表单的校验逻辑。比如写一个绑卡页面,想确认“输入非法卡号报错、合法卡号放行”这条分支,就用生成器分别造几个 Visa 和银联的号码贴进去,验证 Luhn 校验、卡种识别、每四位分组显示这些前端行为是否正确,而不必翻出自己的真卡。再比如给测试库做 seed 数据、或接口联调时给卡号字段填占位值,批量生成一串直接灌进去,既满足格式约束又不涉及任何真实信息。

需要强调一个常见误区:通过 Luhn 只代表号码“格式合法”,并不代表它是一张真卡。拿这些号码去真实支付网关或沙箱(Stripe、PayPal、支付宝、微信支付等)是刷不过的,网关只认它们官方指定的测试卡号(如 Stripe 的 4242 4242 4242 4242),随机生成的 Luhn 号码会被判为无效卡。所以本工具解决的是校验与格式层面的测试,真正的支付链路联调请用对应网关的沙箱卡。另外,卡号本身不含有效期和 CVV,这两项与 Luhn 无关,需要时自行补随机值即可;所有号码都在本地即时生成、不上传,但请务必只用于合法的开发测试。

测试卡号生成是一个免费的在线工具,打开网页就能用,不用下载也不用注册。平时大家搜的“测试卡号”、“信用卡号生成”、“银行卡号生成”,说的都是这个。

常见使用场景

使用方法

  1. 把内容粘贴到输入框(生成类工具直接设置选项)。
  2. 按需要选择选项,点操作按钮。
  3. 结果出现在下方,点「复制结果」即可带走。

常见问题

支持哪些卡种?
常见的国际与国内卡组织都能覆盖,如 Visa(4 开头)、万事达 Mastercard(51-55、2221-2720)、美国运通 Amex(34、37)、银联 UnionPay(62)、JCB、Discover 等,生成时会套用对应卡组织的正确前缀和位数。具体以工具提供的卡种选项为准。
生成的卡号能在真实支付或网关沙箱里跑通吗?
不能。它们只满足 Luhn 校验,不对应任何真实账户或额度;真实支付网关的沙箱(如 Stripe、PayPal、支付宝)只接受官方指定的测试卡号,随机生成的号码会被拒。这类工具适合测前端校验与格式,不适合测真正的扣款链路。
为什么生成的卡号每次都能通过 Luhn 校验?
因为末位的校验位不是随机的,而是根据前面所有数字用模 10 算法反推出来、专门凑成 10 的倍数的。只要前面的位固定,校验位就唯一确定,所以结果必然合法。
生成结果带分隔符吗?包含有效期和 CVV 吗?
复制得到的是卡号数字本身(页面显示时可能每四位分组便于阅读)。有效期和 CVV 与卡号无关、不参与 Luhn 校验,也不由本工具生成,测试若需要请自行填随机值。
用这些卡号安全吗?会不会上传我的数据?
号码在你的浏览器本地生成,不上传服务器,也不查询任何真实卡库,因此不涉及个人隐私数据。但请注意这些是虚构号码,仅限开发测试,冒用或用于欺诈等非法用途需自行承担法律责任。

相关工具

查看全部「开发生成」工具 →

相关名词解释