4. 扣款文件与数据准备
批量扣款的第一道工程关口不是调用支付接口，而是把“要扣谁的钱、扣多少、什么时候扣”变成一份可被系统稳定解析、可校验、可追溯、可重跑的文件。文件与数据准备阶段一旦出错，后续的重试机制只会把错误放大。本节围绕文件格式、数据校验、加密解密、对账文件与批量任务生成五个环节展开。
一、核心原理：文件是批量的“契约”
批量扣款系统通常由业务系统、文件生成服务、渠道网关、银行/清算机构、对账系统共同参与。它们之间不通过实时接口逐笔交互，而是通过文件契约交换指令与结果。文件契约包含四层约定：
- 结构层：字段顺序、分隔符、定长/变长、编码（GBK/UTF-8）、行结束符。
- 语义层：金额单位（分/元）、币种、借贷标志、业务类型、协议号含义。
- 安全层：摘要算法、签名证书、对称密钥、加密范围。
- 控制层：文件头、文件尾、总笔数、总金额、批次号、校验位。
只有四层同时成立，文件才具备“可被对方无歧义执行”的能力。很多生产事故并非接口报错，而是文件头总金额与明细汇总不一致，导致渠道整批拒收。
关键判断：文件不是“导出数据”，而是“可执行指令集”。任何字段缺失、单位不一致、编码错乱，都会在渠道侧被解释为另一笔业务。
二、方法流程：从数据准备到批量任务生成
一个可落地的准备流程通常包含以下步骤：
- 数据抽取：从合同、账单、还款计划中筛选到期、状态正常、未冻结的扣款明细。
- 数据清洗：统一金额单位、去除非法字符、补全协议号、校验卡号/账号格式。
- 文件生成：按渠道模板生成明细文件与文件头尾，写入批次号与生成时间。
- 数据校验：执行格式校验、业务校验、汇总校验、重复校验。
- 加密签名：对文件体加密，对摘要签名，生成密钥密文。
- 对账文件准备：生成本方对账基准文件，供日终与渠道对账使用。
- 批量任务生成：创建批次任务，绑定文件、渠道、重试策略、执行窗口。
下面是一个典型的文件头与明细结构示例：
H|BATCH20240612001|20240612|3|150000|20240612103000
D|P202406120001|6222020200112233|张三|10000|CNY|01
D|P202406120002|6222020200114455|李四|50000|CNY|01
D|P202406120003|6222020200116677|王五|90000|CNY|01
T|3|150000|8F3A2C1D其中 H 为文件头，D 为明细，T 为文件尾。文件尾的总笔数与总金额必须与明细严格一致，摘要用于渠道侧快速校验文件完整性。
三、数据校验：四道防线
校验不是一次动作，而是分层拦截。建议至少设置四道防线：
| 防线 | 校验内容 | 失败处理 |
|---|---|---|
| 格式校验 | 字段数量、长度、编码、日期格式、金额为数字 | 整行剔除并记录错误码 |
| 业务校验 | 协议状态、扣款金额上限、账户状态、重复扣款 | 单笔挂起，不进入文件 |
| 汇总校验 | 总笔数、总金额、批次号唯一性 | 整批拒绝生成 |
| 安全校验 | 签名、摘要、密钥版本、证书有效期 | 阻断发送并告警 |
常见误区：只做格式校验就发送文件。格式正确但业务非法的数据，会在渠道侧产生大量失败明细，重试机制反而造成重复扣款风险。
四、加密解密与对账文件
渠道通常要求文件体使用对称密钥加密（如 AES），再用渠道公钥加密对称密钥，最后对密文摘要做签名。解密方按相反顺序验签、解密钥、解密文件体。工程上要特别注意密钥版本管理与换密钥期间的兼容，否则会出现“文件能生成但对方解不开”的故障。
# 生成对称密钥并加密文件体
openssl enc -aes-256-cbc -salt -in batch.txt -out batch.enc -pass file:key.bin
# 对密文做摘要并签名
openssl dgst -sha256 -sign private.pem -out batch.sig batch.enc
# 渠道侧验签与解密
openssl dgst -sha256 -verify public.pem -signature batch.sig batch.enc
openssl enc -d -aes-256-cbc -in batch.enc -out batch.txt -pass file:key.bin对账文件是批量扣款的“结算凭证”。本方需在发送扣款文件的同时，生成一份包含批次号、明细唯一号、金额、协议号的对账基准文件。日终将渠道返回的成功/失败明细与基准文件逐笔比对，差异进入差错处理。对账文件建议使用独立文件，不与扣款指令文件混用，避免职责不清。
五、批量任务生成与可视化
批量任务不是简单地把文件丢给渠道，而是把文件、渠道、执行窗口、重试策略、对账规则绑定为一个可调度、可监控、可重跑的单元。任务生成时需要写入批次号、文件路径、文件摘要、渠道编码、计划执行时间、最大重试次数、失败处理策略。
六、误区复盘与工程建议
- 误区一：文件生成即发送。缺少校验与签名，渠道拒收后才发现问题，浪费执行窗口。
- 误区二：对账文件事后补。对账基准应在发送前生成并落库，否则差异无法定位。
- 误区三：批次号不唯一。重跑时无法区分新旧文件，容易造成重复扣款。
- 误区四：密钥硬编码。换密钥需改代码，风险高且不可审计。
工程建议：把“文件生成—校验—加密—任务创建”做成幂等流水线，每一步落库并记录状态；批次号作为全局唯一键，任何重跑都基于同一批次号生成新版本文件，而不是覆盖旧文件。
文件与数据准备的质量，直接决定批量扣款的成功率与重试机制的有效性。把契约定义清楚、把校验做扎实、把对账基准留完整，后续的失败重试才有可靠的数据基础。