简介JSON格式银行卡BIN码大全是一份面向前端开发者与支付相关技术人员的实用数据文件基于标准JSON键值结构整理银行BIN码信息可用于银行卡号识别、发卡行匹配与前端联动校验。BIN码即银行卡前六位是识别发卡机构的关键标识。压缩包内仅1个json文件大小约33KB轻量易用适合直接嵌入项目或作为本地对照表。目前已有1746人学习下载。通过解析文件中的BIN码对应关系开发者可获得银行名称、卡类型借记卡/信用卡、货币等关键属性快速实现用户输入银行卡号时即时显示发卡行的功能。资源强调实际应用中的数据更新、隐私保护、错误处理与HTTPS安全传输要点帮助使用者在实现便捷验证的同时兼顾合规与稳定性。整体结构简洁适合入门级开发者快速上手也可作为中级开发者补充校验逻辑的参考工具。1. 银行卡BIN码的JSON数据匹配和验证两件事一次讲清拿到一个卡号不想调外部接口只想快速判断它大概是哪个发卡机构、是借记卡还是信用卡、卡号本身构不构成合法编号——这正是银行卡BIN码数据的典型用途而JSON格式让这份数据可以直接被程序加载、索引和匹配。BIN是卡号开头的6位数字新发行的卡不少已经用到8位它像卡号的前缀身份证匹配BIN能锁定发卡机构范围、卡类型和卡组织归属验证则靠Luhn算法对整串卡号做最后一位校验。两个动作通常搭配出现先拿BIN定位再用Luhn判断合法支付表单、风控策略和卡管理后台基本都是这么工作的。需要这份JSON数据的是做支付、账务、表单体验或风控规则的开发者——不依赖外部接口一个数据文件就能完成大部分判断。BIN匹配错了先别怀疑数据玄学多半是匹配顺序或字段类型出了问题后面逐条说。2. 先定义一份不翻车的BIN码JSON结构最小字段集与Schema约束2.1 一个BIN条目应该存什么从匹配需求反推字段JSON本身没有强约束字段名和类型全靠约定所以第一步不是急着找数据而是先把每条BIN记录的字段定下来。我做这类数据时习惯从匹配结果反推匹配命中之后下游业务到底需要拿这些字段做什么最常见的诉求是三个展示给用户看发卡机构、卡类型、参与业务判断借记卡还是信用卡、是否支持Luhn、做统计国家/地区、卡组织归属。由此定出最小字段集不多不少。每条BIN记录建议包含以下字段bin6位或8位数字前缀类型必须是字符串后面会解释为什么不能用数字bank发卡机构展示名比如XX银行这种占位形式匹配命中后可以直接展示card_type卡类型取值建议限定为 debit、credit、prepaid 三种不要写自由文本network卡组织归属取值按业务定义常见的区分是 local国内卡组织和 international国际卡组织需要更细就扩展枚举country发卡国家或地区用两位ISO码比如 CN 这样的格式validate_luhn布尔值标记这条BIN对应的卡是否走Luhn校验个别特殊卡种可能不走。字段越少越不容易出错。我见过有人把卡面图案、客服电话、积分规则全塞进BIN数据里结果文件大了十几倍匹配性能没提升反而每改一个字段都要全量重新发布。BIN数据的定位是高频只读的静态资料跟卡种权益相关的信息应该放业务库按BIN关联取用而不是塞进这份JSON。一条典型的记录长这样{ bin: 622200, bank: XX银行, card_type: debit, network: local, country: CN, validate_luhn: true }这里的 bin 是虚构占位值正式数据里每个 bin 值必须全局唯一。如果同一个前缀在文件里出现两次匹配时就不知道返回哪条这是数据质量问题里最隐蔽的一种。后面去重逻辑会专门处理。2.2 用JSON Schema锁住字段类型前导零和数据歧义一起解决字段定了还得防止下游解析的人把类型搞错。最常翻车的点是 bin 用了数字类型。BIN码是「编号」不是「数值」它没有算术意义而且部分BIN段以0开头一旦被JSON解析成数字前导零直接丢失。比如某条BIN是 041234存成数字后变成 41234匹配时永远命中不了。这类问题在数据生成阶段看不出来因为写文件的人看到的还是原始字符串只有程序加载后才会暴露。用JSON Schema把类型约束写清楚是成本最低的防御手段。{ $schema: https://json-schema.org/draft/2020-12/schema, type: object, required: [version, bins], properties: { version: { type: string }, bins: { type: array, items: { type: object, required: [bin, bank, card_type, network, country, validate_luhn], additionalProperties: false, properties: { bin: { type: string, pattern: ^[0-9]{6}$|^[0-9]{8}$ }, bank: { type: string, minLength: 2 }, card_type: { enum: [debit, credit, prepaid] }, network: { enum: [local, international] }, country: { type: string, pattern: ^[A-Z]{2}$ }, validate_luhn: { type: boolean } } } } } }这段Schema里有几个重点。bin 用 pattern 限定只能是6位或8位纯数字既挡住非法值也强制它是字符串card_type 和 network 用 enum 而不是自由字符串把取值空间锁死避免有人写进 CreditCard 或 LOCAL_CARD 这类变体additionalProperties 设为 false意味着多加字段直接校验失败防止数据文件里混入注释字段或临时调试字段。我一般在数据发布流程里加一步文件生成后先跑一遍Schema校验不过就拒绝发布。这一步能拦截掉九成以上的脏数据。即使项目里没有专门的发布流程也可以在程序启动加载数据时用同一个Schema做一次启动期校验宁可启动慢几百毫秒也不要让脏数据进内存。2.3 数据规模与重复BIN这份JSON到底会有多大BIN码全量数据的规模没有很多人想象的那么夸张。全球活跃的卡BIN段大约在数万级别整理成上面的结构后JSON文件体积通常在几百KB到一两MB之间gzip 压缩后更小。这个体量意味着不需要上数据库不需要引入缓存中间件程序启动时直接读文件进内存构建哈希索引查询就是一次Map查找的事儿。很多团队把简单问题复杂化给几百KB的数据建表、建索引、做分片完全是过度设计。规模小不代表可以忽略数据质量。重复BIN是这份数据里最值得警惕的问题。同一个 bin 值出现多条记录可能是数据源合并时产生的也可能是不同渠道的数据互相覆盖。我的做法是在加载阶段做去重保留信息更完整的那条同时把重复情况记到日志里方便回溯数据源问题。seen {} for item in data[bins]: key item[bin] if key not in seen or len(item.get(bank, )) len(seen[key].get(bank, )): seen[key] item这段逻辑的优先级是长度更长的 bank 名称优先因为通常意味着数据源做了更完整的补全。实际项目里你可以把「保留哪条」的规则换成更新时间、数据源优先级但去重本身必须在数据进入索引前完成否则后续所有匹配结果都不可信。3. 拿卡号匹配BIN再用Luhn兜底一段代码跑通完整校验链路3.1 匹配的本质是前缀匹配不是相等判断BIN匹配最容易误解的地方在于它不是拿卡号和BIN做相等比较而是拿卡号的前6位或前8位和BIN前缀做比对。用户输入的卡号通常13到19位BIN只是开头的一小段。还有一个现实问题是6位BIN和8位BIN并存老卡大多是6位新发卡越来越多用8位。如果数据里同时有 6222 和 62220088 两条记录而卡号是 62220088...正确的匹配结果应该是更长的 62220088 这条因为它携带的信息更精确。这就是最长前缀匹配原则宁可命中更长的BIN也不要被短BIN抢先。所以匹配策略不能是「先到先得」也不能是「随便截6位查一下」。先查8位查不到再退回到6位才能保证命中率。3.2 用Python实现BIN匹配与Luhn校验完整代码下面这套代码是我常用的最小实现包含数据加载、索引构建、BIN匹配和Luhn校验不依赖第三方库。import json import re def load_bin_index(json_path): 加载BIN数据并构建按前缀长度分组的索引 with open(json_path, encodingutf-8) as f: data json.load(f) index {} for item in data[bins]: b item[bin] # 只信任字符串防止JSON解析成数字后前导零丢失 if not isinstance(b, str) or not re.fullmatch(r[0-9]{6,8}, b): continue key b # 同一前缀出现多条时保留bank字段更完整的一条 if key not in index or len(item.get(bank, )) len(index[key].get(bank, )): index[key] item return index def match_bin(card_number, index): 按最长前缀优先匹配BIN命中返回记录未命中返回None digits re.sub(r\D, , card_number) for cut in (8, 6): if len(digits) cut: key digits[:cut] if key in index: return index[key] return None def luhn_check(card_number): Luhn校验返回布尔值 digits re.sub(r\D, , card_number) if len(digits) 13 or len(digits) 19: return False total 0 for i, ch in enumerate(reversed(digits)): d int(ch) if i % 2 1: d * 2 if d 9: d - 9 total d return total % 10 0 def verify_card(card_number, index): BIN匹配 Luhn校验返回结构化结果 digits re.sub(r\D, , card_number) bin_info match_bin(card_number, index) if bin_info is None: return {status: unknown_bin, luhn_pass: None, bin_info: None} need_luhn bin_info.get(validate_luhn, True) luhn_pass luhn_check(digits) if need_luhn else True return { status: ok if luhn_pass else luhn_failed, luhn_pass: luhn_pass, bin_info: bin_info }几个关键点说明。match_bin 里的 for cut in (8, 6) 是整套匹配的核心先试8位再试6位保证最长前缀优先如果连6位都匹配不上返回 None调用方应该把这条卡号记录为「未收录BIN」。luhn_check 里的判断逻辑是从右往左奇数位从右数第1、3、5位直接累加偶数位翻倍后如果大于9就减9最后总和能被10整除则通过。validate_luhn 开关解决的是个别卡组织不走Luhn的情况默认取 True即大多数卡都要校验。这套代码可以原样放进一个Python服务里跑也可以照搬到其他语言。数据加载是一次性的index 构建好后整个运行期间只读不涉及并发写问题。匹配阶段时间复杂度是O(1)Luhn校验是O(n)性能瓶颈完全不在代码本身。3.3 匹配结果的三分类未收录、格式错、业务拒绝验证接口返回的状态不要只设计成 true/false因为调用方需要区分三种完全不同的情况BIN未收录表示这份JSON里没有覆盖这个前缀可能是数据不全也可能是新发的卡段还没同步。这类卡号不能简单判死建议走人工审核或降级策略而不是直接拒绝。Luhn失败表示卡号本身不符合校验规则大概率是输入错误或伪造卡号这类可以直接拦截不用再往下走业务流程。校验通过也不代表交易一定能成功只代表卡号结构合法、BIN被识别真正的可用性还要看发卡机构。返回状态含义建议动作unknown_bin前缀不在数据集中降级审核不要一刀切拒绝luhn_failed卡号Luhn校验不通过直接提示卡号有误okBIN命中且Luhn通过进入下一步业务校验把状态分清楚是因为下游逻辑差别很大。风控规则里 unknown_bin 的卡通常要提高风险等级luhn_failed 的卡可以直接进黑名单ok 的卡才能走正常流程。如果只返回一个布尔值这三类情况就被压扁了后续策略没法做差异化处理等于把判断逻辑全塞给了调用方。4. 把BIN数据落进真实业务前端本地加载与后端内存索引怎么选4.1 三种部署方式对比内置JSON、静态接口、独立BIN服务数据准备好了接下来是部署方式的选择。我在不同项目里分别用过三种方案适用场景差别很大没有绝对优劣。方案适用场景优势代价前端打包内置JSON表单卡号格式化、卡图标展示零网络延迟、可离线运行数据更新要等发版静态JSON放对象存储多端共用、低频更新不耦合业务代码、更新即时客户端要处理缓存更新独立BIN校验服务风控、交易前校验、多业务线复用统一管控、可审计、权限收敛增加一次网络调用依赖前端内置适合做体验类功能。用户在表单里输入卡号前6位立刻显示卡类型图标和发卡机构名称这种场景响应速度要求高而且数据敏感性低把BIN数据打进前端包是合理选择。静态JSON方案适合有多个前端、但不想为BIN数据专门做后端的团队——更新时替换文件即可前端在启动时拉取一次。不过静态文件方案要注意缓存文件名不带版本号的客户端可能拿到旧数据所以我会把版本号拼进文件名比如 bins-20250301.json从源头规避缓存问题。服务化方案适合风控场景。BIN判断是交易链路的一环需要对每次查询留日志需要控制谁有权限访问这份数据这时候把BIN数据收进后端服务里、对外只暴露校验接口是最干净的做法。代价也很明确支付链路里多一次内部调用虽然本地服务延迟很低但架构上多了一个依赖点需要做好降级方案。4.2 后端集成要点按长度降序的前缀索引后端服务加载这份JSON时推荐的做法是在内存里构建两个Map分别存放6位BIN和8位BIN匹配时先查8位Map再查6位Map。用Node.js实现大概是这样的import { readFile } from node:fs/promises; async function buildBinIndex(jsonPath) { const raw await readFile(jsonPath, utf-8); const data JSON.parse(raw); const indexByLength { 6: new Map(), 8: new Map() }; for (const item of data.bins) { const bin String(item.bin); if (!/^[0-9]{6,8}$/.test(bin)) continue; const bucket indexByLength[bin.length] || indexByLength[8]; bucket.set(bin, item); } return indexByLength; } function matchBin(cardNumber, indexByLength) { const digits cardNumber.replace(/\D/g, ); for (const len of [8, 6]) { if (digits.length len) { const hit indexByLength[len]?.get(digits.slice(0, len)); if (hit) return hit; } } return null; }这里把6位和8位分桶而不是混在一个Map里是为了让「先8后6」的遍历逻辑更直白。如果混在一个Map里匹配时要先算8位前缀查一次再算6位前缀查一次写起来也可以但分桶之后语义更清楚。String(item.bin) 是保险动作防止数据文件里bin字段被解析成数字虽然我们在Schema层已经约束过但运行时再做一次类型强转成本极低。还有一点容易被忽略正则过滤 CDN 数据时如果bin字段长度不在6到8位之间直接跳过不要抛异常。一份几千条的数据里出现一两条脏数据处理方式应该是跳过并计数而不是让整个服务启动失败。启动阶段把跳过的条目数打一条WARN日志比崩溃后排查半天更划算。4.3 校验接口的设计一次请求返回结构化结果如果选择服务化方案接口设计上我建议一次返回全部判断结果避免调用方先查BIN再自己做Luhn校验把两件事拆成两个请求。接口返回的结构化结果应该包含卡号脱敏后的展示值、BIN命中信息、Luhn校验结果、整体状态。import { createServer } from node:http; import { URL } from node:url; const index await buildBinIndex(./bins.json); createServer((req, res) { const url new URL(req.url, http://localhost); if (url.pathname ! /verify || req.method ! GET) { res.writeHead(404); res.end(); return; } const cardNumber url.searchParams.get(cardNumber) || ; const digits cardNumber.replace(/\D/g, ); if (digits.length 13 || digits.length 19) { res.writeHead(400, { Content-Type: application/json }); res.end(JSON.stringify({ error: invalid card length })); return; } const binInfo matchBin(cardNumber, index); const luhnPass luhnCheck(digits); res.writeHead(200, { Content-Type: application/json }); res.end(JSON.stringify({ maskedCardNumber: digits.slice(0, 6) ****** digits.slice(-4), bin: binInfo, luhnPass, status: !binInfo ? unknown_bin : luhnPass ? ok : luhn_failed })); }).listen(3000);接口先做卡号长度校验长度不在13到19位直接400这能挡掉大量无效请求。返回里的 maskedCardNumber 是给日志系统用的生产环境里不要记录完整卡号只记前6后4即使日志泄露也不会造成完整卡号泄露。status 字段汇总了BIN和Luhn两个结果调用方不需要自己拼逻辑。实际操作中这个接口前面还要挂权限校验、限流和超时熔断。BIN校验是高频调用单机QPS上千不是问题但一旦下游发卡机构数据没更新服务本身不会自动感知需要在监控里留意 unknown_bin 的比例如果这个比例突然上升多半是数据该更新了而不是服务出了故障。5. BIN匹配验证的常见坑前导零、长度覆盖与旧数据5.1 现象62开头的卡被短BIN抢先匹配某天线上反馈一批62开头的卡全部显示成了错误发卡机构。排查后发现数据里同时存在 62 这样的短前缀和 622200 这样的完整前缀匹配逻辑没有按长度优先级走先把 62 这条命中了。原因是匹配函数直接截了前6位做Map查找但数据文件里混入了长度为2、3位的非标准BIN截出来的前缀和这些短条目撞上了。解决方法是双管齐下加载数据时严格过滤只保留6位和8位条目匹配时固定按8位、6位的顺序降序尝试。两步缺一不可——只做前者挡不住数据源未来新增其他长度只做后者旧数据里的脏条目还在索引里照样会命中。5.2 现象BIN字段被JSON解析成数字前导零丢失这是最常见的数据类型坑。数据文件里明明写了 041234程序一加载变成 41234匹配时永远找不到。而且这个问题特别隐蔽因为大部分BIN不以0开头只有一小部分会触发往往是部分卡段异常不是全量故障。解决思路分两层。第一层是在Schema里约束 bin 必须是字符串发布前跑校验第二层是在加载代码里加防御发现bin字段是数字类型就转成字符串补零或者直接跳过并告警。我用的是后者因为不能保证所有下游都遵守Schema约定。补零逻辑要保留原始位数BIN是6位就补到6位是8位就补到8位不能用统一的长度去补。5.3 现象Luhn校验通过交易还是被拒有同学把Luhn校验结果当成交易成功的前置条件Luhn过了就认为卡一定能用结果线上支付还是被发卡机构拒绝。原因是Luhn只校验卡号的结构合法性——校验位算得对不对跟卡是否激活、余额是否充足、是否被冻结没有关系。一张被注销的卡片Luhn照样能通过。解决方法是把校验分层看Luhn和BIN负责格式层面的判断属于客户端或风控前置规则交易层面的可用性必须走发卡机构或收单渠道的实时返回。BIN库不是黑匣子它只回答「这个卡号长得像不像真的」回答不了「这张卡现在能不能刷」。把这两个问题分开排查交易失败时才不会找错方向。5.4 现象本地BIN库匹配不到新发的卡用户输入新办的卡系统提示卡号无法识别。原因很简单BIN库是静态数据银行新发行的卡段需要一段时间才能同步到公共数据源本地文件如果长期不更新自然匹配不到新卡段。解决方法是给数据加版本号并建立更新机制。我的习惯是每月从可信渠道拉一次全量更新更新时保留上个版本的文件新版本验证通过后再切换。匹配不到时不要直接拒绝用户至少在日志里区分「BIN未收录」和「卡号非法」前者需要数据更新跟进后者才是真正的输入错误。用户侧的表现也可以更友好未收录时继续走后续流程让发卡机构去判断而不是卡在入口。5.5 现象设备传进来的不是纯卡号做线下支付或读卡设备对接时拿到的数据往往不是干净的纯卡号磁道数据里可能带分隔符、前导标识或结束符。有次联调发现BIN匹配总是失败打了半天日志才发现传入字符串开头多了两个不可见字符正则过滤 \D 的时候把它们当普通字符处理掉了截取前6位自然对不上。解决思路是进入BIN匹配函数之前先做标准的卡号提取——用正则把纯数字部分摘出来再做长度判断最后才截取前缀。不要把提取逻辑和匹配逻辑混在一个函数里。接设备数据的同学尤其要注意设备厂商的文档里标注的字段格式和实际返回的字节流经常有出入拿到数据先打日志看原始内容再谈匹配。6. 收尾从静态JSON到带版本号的BIN服务6.1 给BIN数据加版本号和生效时间静态JSON用久了最难受的是不知道线上跑的是哪一份数据。我后来在JSON顶层加了版本信息结构从纯数组变成带元数据的对象{ version: 2025.03, effective_at: 2025-03-01T00:00:00Z, bins: [] }加载时把 version 字段打出来每次排查问题先确认版本对不对。多环境部署时这个版本号还可以用来做一致性校验——生产环境和预发环境加载的版本不一致说明发布流程有遗漏比查半天业务代码快得多。我的习惯是版本号用发布日期而不是自增序号看一眼就知道数据是什么时候的陈旧程度一目了然。6.2 从6位BIN到8位BIN匹配策略不用重写新发行的卡段越来越多使用8位BIN但存量卡还是6位为主所以真实场景是两种长度并存。前面代码里的降序匹配策略天然兼容这个过渡期8位命中就走8位没命中退回6位不需要改逻辑。要改的只是数据发布流程——新数据里混入8位条目时Schema里的pattern已经放开了6位和8位两种长度索引构建时按长度分桶匹配顺序固定整套机制对新旧数据一视同仁。跑了一段时间后我养成的习惯是每次更新数据版本先跑一批历史上已知的卡号回归测试确认老BIN的匹配结果没变、新BIN能正确命中再切线上流量。千万别拿生产环境当验证环境BIN这种静态数据完全可以在发布前自动验证完。一条一条比对手工测试太慢准备几十个覆盖各卡组织、各长度的测试卡号足矣全部跑一遍再发布比线上翻车后回滚省心得多。希望帮到你。本文还有配套的精品资源点击获取