当报出表收到卡号时,第一个有用的问题往往不是付款是否获得批准.
问题在于输入在结构上是否合理,应向用户显示哪些网络规则。
开源软件包提供小客户端或服务器端的构件.
它能检测出11个品牌,去除空格和连字符,并应用了Luhn校验和.
它拥有零运行时间依赖性,并暴露出用于验证和品牌检测的CommonJS功能.
这个教程构建一个最小的节点.js检查,用已知的测试数字验证结果,并解释这种验证不能告诉你的.
TL; DR 数据 安装版本, 需要布尔结果和品牌时打电话, 只需要网络名称时就打电话 。
软件包不与支付处理器联系,不授权交易,不给数据做标记,也不证明卡片存在.
先决条件 你需要:节点.js 12或更新.
软件包在其元数据中声明。
没有。
一个终端和一个小的JavaScript文件.
该套件以麻省理工学院许可证发布.
下面的例子针对已发布的 npm 软件包版本,这也是我为这个行走而安装的版本.
安装软件包 创建示例目录并安装被绑定的版本: 平接版本使示例可以再生.
如果您稍后使用不同的版本,请在将行为复制到生产应用程序之前检查其README和包元数据.
构建最小的有用的检查 创建: 运行它: 期望的输出是: 葡萄牙属性名是包的公回形状的一部分.
消费 API 时保持原样,或将其映射到您边界的应用程序专用名称上 。
理解两个 API 路径返回对象 。
它首先脱去非数字字符,拒绝短于13个或长于19个数字的值,从所配置的前缀中检测出一个品牌,再运行Luhn计算.
返回品牌名称或.是同一函数的别名。
当UI需要修改一个图标或帮助消息后,完整数字才会被验证时,此功能是有用的.
执行范围比广泛范围更具体。
这对巴西品牌如Elo很重要, 其配置的前缀可以以.
首先进行的宽前缀检查可以将一个被支持的Elo例归类为Visa.
添加一个明确的应用边界 软件包接受一个字符串并在内部使其正常化,但您的应用程序应当决定如何处理空输入,粘贴内容,并形成错误.
一个小包装器可以将包的输出与UI消息分开: 这个包装器故意将检查和失败报告为输入问题.
这并不意味着有效的支票和意味着可以收取卡。
重新核查 存储器 README 记录了这些公开实例.
您可以用一行节点命令独立检查软件包 : 经核实的结果是: 对于应用程序测试套件, 添加格式化的大小写, 未知的前缀, 太短的值, 每个支持的网络, 以及已知的无效的校验和 。
在测试或固定装置中不要使用真正的客户卡号码。
为什么检查工作Brand检测是前缀与包源的规则相匹配.
Luhn校验是一种校验和计算法,从右侧将相位数相乘,当相乘值超过9时再减去9个,并检查总数是否可分出10个.
这种责任分工是有用的:前缀规则回答“哪个配置的网络可能类似?” 而Luhn回答“这个字符串是否满足校验和?” 既不执行授权,也不进行网络搜索。
失败模式和安全边界 有几个重要的限制: 一个有效的Luhn结果不能证明一张卡的发行,活动,资助,或由进入卡的人拥有.
前缀表格可能随着网络变化范围而过时.
审查软件包源并发布hi