组合核验怎么设计：手机三要素与银行卡四要素的接口逻辑、计费与错误处理
组合核验是多次调用还是独立接口的判断标准,手机三要素/银行卡四要素的内部逻辑差异(关联查询vs银行通道),结果分级/签名对照/超时配置三个设计要点,与批量组合场景的完整评估清单。
对接实名认证类接口的团队，迟早会遇到一个需求：一次核验不只是一项，而是多项一起做——姓名+身份证+手机号同时验证（三要素）、银行卡+身份证+预留手机一起核（四要素）、或者一次注册流程里串行做多次核验。这篇文章讲清楚"组合核验"的接口设计逻辑：它是多次单接口调用的封装，还是独立接口？批量与组合的边界在哪？组合调用时计费和错误码怎么处理？
先回答：组合核验是"多次调用"还是"一个接口"
两种形态在行业里都存在，选型时要分清对方给的是哪种：
形态一：客户端组合（调用方多次调用单要素接口）
自己按顺序调二要素、再调手机三要素，自己编排逻辑。优点是灵活（每一项的结果可以单独决策），缺点是三次网络往返、三次计费窗口、三次失败重试逻辑，且组合期间的一致性要自己维护——第一项通过第二项失败时，前面的结果怎么算？
形态二：服务端组合（服务商提供多要素接口）
直接调"手机三要素"（姓名+身份证+手机号一次核验）或"银行卡四要素"（卡号+姓名+身份证+预留手机）。服务商内部完成多数据源比对，一次返回综合结果。一次往返、一次计费、一致性由服务商保证。
判断标准：如果组合项之间有权威数据源级别的关联（手机号是否实名在该名下），必须用形态二——这种关联数据只有权威库知道，自己"先核 A 再核 B"拼不出这个结论。如果只是流程上的先后（先验证身份再开通账户），那是业务编排，不属于组合核验范畴。
三要素与四要素：内部逻辑其实不同
容易混淆的一点："多要素接口"内部并不是简单地把多个二要素拼起来。
手机三要素（姓名+身份证号+手机号）：权威库核验的是"三个字段是否登记在同一人名下"——这是一次关联查询，不是三次独立查询。返回也不同于二要素的"一致/不一致"：部分服务商提供"详版"结果，能区分"手机号与姓名一致但证件号不一致"等中间态——这些中间态对风控非常有价值（说明手机是本人的但证件填错了，引导重填即可，不必拒绝）。
银行卡四要素（卡号+姓名+身份证号+预留手机）：核验的是"这四项在银行侧登记是否一致"，链路走到银联/银行通道，时延和不确定性都高于二要素（银行通道偶发性超时是常态）。设计上要有心理预期：四要素的超时率和错误码丰富度都高于二要素，重试与对账机制要更扎实。
计费差异也要注意：三要素、四要素的单次成本高于二要素（查询的数据源更多），但低于"分别调用多个二要素+其他接口"的总和——这也是组合接口存在的经济理由。
组合核验的三个设计要点
1. 结果结构：综合结论 + 分项明细
好的多要素接口返回"综合是否通过"的同时，给出分项细节（哪些字段一致、哪些不一致）。调用侧的处理逻辑因此可以分级：
调用前确认：服务商默认返回综合结论还是分项明细、详版是否需要申请开通。
2. 参数与签名的对应关系
多要素接口的签名串不一定包含全部业务参数（以真实接口为例：银行卡三/四要素的签名串不含身份证号/预留手机，手机三要素签名不含手机号——详见接入文档的签名对照表）。这是对接时最容易翻车的一条：拿"A 参数全拼进签名"的直觉去做，必然签名错误。每个接口的签名公式以官方文档的对照表为准，封装时逐接口显式声明。
3. 超时与重试按最慢链路配置
组合接口的耗时 = 链路中最慢的那个数据源。银行卡四要素要按银行通道的节奏给读超时（30 秒级），重试纪律参考之前超时篇的决策树——但要注意：四要素重试前必须确认幂等键（银行通道的重复扣验虽然少见，但争议处理比纯数据源核验麻烦）。
批量与组合的组合：一次真实的采购评估
把前面几篇的框架串起来看一个典型需求："新商户入驻，需要批量核验 5000 个商户的法人身份 + 经营者手机三要素。"
评估清单：
□ 核验维度：法人二要素 + 手机三要素（两个接口，业务编排）
□ 批量节奏：分片限速（按服务商配额），错峰执行 □ 授权链：商户入驻协议中含实名授权条款，版本号落库 □ 结果分级：综合结论 + 分项明细，不一致项走人工复核而非直接拒绝 □ 计费预估：通过率假设 92%，按"实际计费码"折算真实成本 □ 幂等：商户 ID + 入驻批次号做幂等键，防重复核验 □ 对账：批次结束后与服务商账单核对，争议单走申诉
这套清单里最重要的是结果分级：批量场景必然出一批"部分不一致"，提前定义好这些用户的处理路径（补充材料？人工审核？拒绝？），比事后临时决定体面得多。
相关资源
合规提示：多要素核验涉及的信息维度更多，采集前的授权协议要覆盖全部采集字段（《中华人民共和国个人信息保护法》敏感个人信息条款），分项结果的存储同样适用最小必要原则。