流程
主扫模式下用户扫商户静态/动态码，被扫模式下商户扫用户付款码。订单号、商户标识与金额经收单系统路由至微信/支付宝等钱包。物联网售货机、充电桩等多用动态码防重放，4G 模组负责拉单与查询支付结果。
风险
码被替换、截屏盗刷与中间人攻击需终端固件与物理防拆配合；签名与时间戳校验必不可少。
对账
平台侧订单与支付渠道流水需日终对账，异常挂账需人工处理。
模组与终端工程细节
动态码场景下，屏幕刷新率、背光与二维码纠错等级会影响识读成功率；户外强光或低温液晶响应变慢时，用户扫码体验下降。4G 模组拉单与轮询支付结果时，应设置合理退避与超时，避免在弱网时频繁重试触发渠道限流。固件需校验二维码内容域名与签名，防止本地缓存被篡改；机具应配合物理防拆与启动完整性检测。对于离线码或双离线试点业务，更要区分风险等级与单笔限额，并在恢复联网后尽快补传终态。
风控、客诉与运营数据
同一终端短时间大量失败支付、金额异常或地理位置突变，应接入风控名单与实时拦截。客诉处理需要可追溯的订单号、码生成时间、支付渠道返回码与模组侧网络指标。运营上可统计高峰时段、失败码分布与机型分布，驱动固件优化与码策略调整。分账与发票若依赖支付成功回调，必须保证回调到达率与补单机制，否则会出现账务不平与用户体验受损。
工程实践补充
将「扫码支付」与模组全生命周期结合：EVT 阶段验证参考设计与天线方案；DVT 阶段做传导/辐射摸底与热成像；PVT 阶段固化校准与测试脚本。认证前核对目标国别法规与运营商入库要求，避免频段或 SAR 项缺失。量产线保留金样比对与抽检规则；售后能根据序列号反查软件版本、校准参数与关键器件批次。若客户要求远程运维，需同时设计安全升级、回滚与应急停机策略。
动态码载荷与支付终态机
二维码在支付里只是一张把订单带到钱包里的票面。主扫时用户扫商户码，被扫时商户扫用户的付款码。动态码的载荷应包含一次性的订单号、金额、商户标识和过期时间，钱包或收单系统据此生成待支付单。终态只有支付成功、明确失败和结果未知三种，未知必须再查询，不能靠屏幕上的码还在不在来判断。蜂窝模组负责向收单侧拉码、上送被扫结果和轮询终态，它不决定用户余额够不够。码的纠错等级、对比度和刷新时机影响的是能不能扫上，不是账是否成立。
使用条件是订单号在出码之前就生成并落库，码上的域名和签名能被固件校验，过期码不能继续轮询。户外强光和低温下液晶变慢时，应延长展示而不是连续重新拉单。离线或双离线若被业务允许，要有单笔限额和补传终态的义务，不能把离线成功当成已经清算。同一终端的失败次数、金额跳变要能触发停机，而不是只在云端报表里事后可见。
轮询退避与回调补单
弱网时最容易把轮询间隔缩到最短，渠道返回限流，终端又把限流当成支付失败重新出码，一笔消费变成多张待支付单。回调丢失时若直接出货，会付不成功也出货；若永远等回调，用户已扣款而货不出。补单必须用原订单号查询，不能生成新单再问一次。静态码贴在机身上被换掉，固件若不校验内容，钱会进到别人的商户号。
本地时钟不对会把未过期的码判成过期，或把过期码继续展示。分账若等支付回调才开始，回调缺口会变成某一方没有应收，规则见 支付分账。近场刷卡和扫码不要共用一个「支付成功」位，读卡失败不该写成钱包拒绝，见 NFC 支付。
出码、支付、出货要分成三张本地状态，不能只用一个成功标志。出码成功只说明屏幕上有一张待支付单；支付成功只说明渠道认可了扣款；出货成功才是货物离开货道。三者之间任何一段失败都要留下原因，尤其是支付成功但出货失败，这笔必须进入退款或补货队列，不能在下一张码生成时被覆盖。轮询返回限流时要拉长间隔并保持原订单，而不是立刻换一张新码。签名校验失败要停止展示并告警，防止贴在机身上的静态内容把后续动态码盖掉。本地时钟偏差过大时，应拒绝出码而不是展示一张云端认为已经过期的码。把这三态和渠道流水号一起保留到日终，补单和客诉才不会把两笔消费并成一笔。