银行卡四要素核验怎么接：二/三/四要素选型、签名坑与结果排查

绑卡、代发、开户、提现——凡是涉及"钱从谁的卡进出"，第一步都是确认这张卡是不是这个人的。银行卡四要素核验就是干这个的：卡号、姓名、身份证号、银行预留手机号四项一起验，全部匹配才算通过。

这篇讲清二/三/四要素怎么选、联调最容易踩的坑、以及结果不符合该信谁。

一、二要素、三要素、四要素：验的东西根本不同

别把三档当成"严格程度的升级"，它们验的其实是不同维度的真实性：

档位	字段	验的是什么	拦得住什么

二要素	卡号 + 姓名	卡是否属于此人	用他人卡号冒名、错卡号
三要素	卡号 + 姓名 + 身份证号	卡是否属于此人，且身份信息真实	二要素 + 伪造身份的洗钱/套现
四要素	卡号 + 姓名 + 身份证号 + 银行预留手机号	卡是否属于此人，且手机号在银行侧绑定在这张卡上	三要素 + 拿到身份信息但控制不了预留手机的人

四要素的关键差异在最后一项：它验的是"手机号与卡在银行侧的绑定关系"，这个关系存在于银行核心系统里，用户无法伪造。所以四要素通过，意味着"这个人同时掌握卡、身份信息和银行预留手机"——这是绑卡支付场景能接受的信任级别。

选型判断只有一句话：这笔钱出去后能不能追回？

能追回（提现到同名卡、退款到原卡）→ 二要素够用

追不回（代付、放款、大额转账）→ 三要素起步

涉及支付通道绑卡、快捷支付签约 → 必须四要素（通道方也一定会要求）

二、联调最容易踩的坑：签名里没有身份证号和手机号

这是我最想提醒的一条，因为文档里写了但极容易被忽略：

四要素的签名只算 5 个字段：mall_id + realname + cardnum + tm + appkey。idcard 和 bankPreMobile 不参与签名。

后果是什么？签名永远算对，请求也永远发得出去，但如果 idcard 或 bankPreMobile 拼错了（少一位、参数名写成 bankMobile 之类），服务端不会因为签名错而拒绝——它会正常受理，然后返回"不一致"。

于是你会以为核验失败是数据问题，实际上是参数没传对。 联调期排查这类问题要花半天。

所以联调第一件事：打印完整请求参数，逐字核对 idcard 和 bankPreMobile 两个参数名与值。参数名是 bankPreMobile（银行预留手机号），不是 mobile、不是 phone。

三、逐档接口与字段

三档是三个独立端点，按需调用：

POST /v3/card2-server   二要素：卡号 + 姓名
POST /v3/card3-server   三要素：+ 身份证号 POST /v3/card4-server   四要素：+ 银行预留手机号

必填公共字段：mall_id（商户ID）、tm（13 位毫秒时间戳）、sign（MD5 签名）。

请求示例（四要素）：

mall_id=100001
realname=张三 cardnum=6222021234567890123 idcard=110101199001011234 bankPreMobile=13800138000 tm=1700000000000 sign=xxxxxxxxxxxxx

响应核心字段：

{
  "data": {     "code": "1000",     "message": "一致",     "card_type": "借记卡",     "bank_name": "中国工商银行"   },   "status": "2001" }

注意 card_type 和 bank_name 是附赠的——卡 BIN 解析出来的卡种与发卡行。这两个字段在支付路由、代发渠道选择、风控规则里都很有用，做一次核验顺便就把卡信息拿到了，不必再单独调卡 BIN 查询接口。

四、结果不对，该信谁

银行卡核验的结果口径比身份证核验更"硬"——因为数据来自银行/银联侧，不是靠姓名与证件号的比对规则。

"不一致"时按这个顺序排查：

手机号是不是银行预留的那个——四要素失败 80% 卡在这里。用户换了手机号没去银行更新，或者填的是常用手机而非开户预留号。这条要给用户明确的引导文案，不能只报"核验失败"；

卡号是否有误——拍照识别、手动输入的错位；顺带确认卡号位数（部分老卡为 19 位）；

姓名是否为开户名——对公账户、代持卡、亲属卡，卡主和操作人不是一个人；

证件号是否最新——换过身份证（如 15 位升 18 位、户口迁移）未在银行更新；

卡状态——已注销、已挂失、长期不动户，部分场景会返回不一致而非"卡状态异常"。

四要素失败时不要自动降级到三要素放行——这是风控红线。降级等于把"验证手机绑定"这一层直接拆掉，攻击者拿到身份信息就能过。降级只能由业务侧在有额外风控证据（如设备指纹、历史行为）时明确决定。

五、合规与安全：卡号比身份证号更要小心

银行卡号属于敏感个人信息，处理要求比一般个人信息严格：

传输：必须 HTTPS，敏感字段建议再加密；

存储：默认不存完整卡号。业务库只存卡 BIN（前 6 位）+ 后 4 位，中间掩码；需要复用卡号的场景（如代发、退款）走支付通道的 token 化，不要自己存全卡号；

日志：请求响应日志里卡号必须掩码，这是最容易漏的一处——排查问题时随手 log.info(request) 就把全卡号写进日志文件了；

留存期限：核验结果记录跟交易档案同周期，但完整卡号不在留存范围内（除非你是持牌支付机构且有 PCI 合规要求）。

数据留存的完整框架见核验数据留存的合规实践。

六、上线检查单

□ 选对档位：绑卡/快捷支付=四要素，提现/退款=二要素
□ 参数名核对：bankPreMobile（不是 mobile/phone） □ 签名只算 5 字段：mall_id+realname+cardnum+tm+appkey □ 字段格式：tm 为 13 位毫秒时间戳，非秒 □ 卡号掩码：业务库前6后4，日志全覆盖 □ 失败引导：区分"手机号非预留"与"卡号有误"，给用户可操作提示 □ 不自动降级：四要素失败不得回落三要素放行 □ 计费边界：明确"不一致"是否计费（通常计费，因上游已查询） □ 对账：批次结束核对调用量与账单

相关阅读

银行卡四要素核验接口：二/三/四要素三个端点，含免费试用额度

组合核验怎么设计：手机三要素与银行卡四要素：多产品线串联的流程设计

身份证实名认证接口接入全流程：如果是首次接入这类接口，先看这篇

接口对账设计

四要素核验的具体计费口径与并发配额随业务场景而定，开通时与商务确认；联调期有 100 次免费额度覆盖正常路径与异常路径的验证。