快递柜系统设计（下）：支付与识别

快递柜系统设计下支付体系与 OCR 识别文章目录快递柜系统设计下支付体系与 OCR 识别一、支付体系三套流程投递扣费超时收费充值流程二、柜子租用不是每单都扣费三、OCR 识别不用手输运单号脱敏电话的匹配不是替代扫码是补充四、二维码贯穿全系统的身份凭证五、总结钱怎么扣、运单怎么认、柜子怎么租。这些是投递和取件背后的支撑系统。一、支付体系三套流程快递柜的钱有三个来源投递扣费、超时收费、充值储值。投递扣费投递成功后自动从快递员账户余额扣费。快递员是预充值模式——先充钱后投递。不是每次投递拉微信支付太慢。投递成功 → 后端查询快递员余额 │ ├─ 余额够 → 自动扣费 → 记录交易 → 更新余额 │ └─ 余额不够 → 记录欠费 → 不阻塞投递扣费失败不回滚投递。因为包裹已经在柜子里了不能因为欠费让人家取不出来。欠费会在下次充值时自动抵扣。超时收费取件时发现超时触发即时支付。这次是拉微信/支付宝——不是从余额扣因为取件人不是快递员没有账户。柜机生成二维码 → 显示在屏幕上 │ ▼ 用户微信扫码支付 │ ▼ 后端收到支付回调 → 验证 → 开门微信/支付宝的回调是异步的。柜机在等回调时显示支付处理中收到成功回调后自动开门。超时用户取消支付则关闭二维码。充值流程快递员在手机 APP 上充值手机 APP填写充值金额 → 生成订单 │ ▼ 后端记录订单 → 拉微信/支付宝支付 │ ▼ 支付成功 → 后端更新余额 → 如果有欠费自动抵扣充值跟投递扣费是两个独立的闭环。充值走即时支付投递扣余额。互不阻塞。二、柜子租用不是每单都扣费有些场景下快递员不是按件付费而是按月/按年租柜子手机 APP查询租用方式 │ ▼ 后端返回可租方案柜型、租用时长、金额 │ ▼ 快递员选择方案 │ ▼ 后端记录租用方式 → 扣费租用期间该快递员使用指定柜型的柜子不再每件扣费。投递流程里加一层判断先查该快递员是否有租用合同有就跳过扣费。三、OCR 识别不用手输运单号快递员投递时扫描快递条形码获取运单号和收件人电话。但不是所有条形码都包含了电话信息。手机 APP 提供了 OCR 识别手机 APP打开摄像头 → 连续拍照快递面单 │ ▼ 后端 → 百度 OCR转发图片 │ ▼ OCR 返回识别结果手机号、运单号 │ ▼ 后端记录识别结果 │ ├─ 识别到带 * 的脱敏电话 → 查历史投递记录匹配完整号码 └─ 匹配不到 → 不修改保留脱敏状态 │ ▼ 返回手机号和运单号给 APP → 后续继续投递流程关键设计脱敏电话的匹配OCR 识别到138****1234。后端查该快递员的历史投递记录如果投过13812341234的包裹就把星号还原。匹配不到保留脱敏——宁愿缺着不猜错。伪代码实现// OCR 识别运单信息 function OCR识别(图片数据, 快递员ID): // 调百度 OCR result 百度OCR.recognize(图片数据) phone result.手机号 waybill result.运单号 // 脱敏电话匹配 if phone contains *: // 查历史投递记录 history SELECT DISTINCT 收件人电话 FROM 投递记录 WHERE 快递员ID快递员ID AND 收件人电话 LIKE CONCAT(phone前3位, %, phone后4位) if history is not None: phone history // 匹配到了还原 // 匹配不到保留脱敏的 phone return {电话: phone, 运单号: waybill} // 投递扣费 function 快递员扣费(快递员ID, 费用): // 先查是否有租用合同 合同 SELECT * FROM 租用合同 WHERE 快递员ID快递员ID AND 开始日期TODAY AND 结束日期TODAY if 合同 is not None: return // 有合同不扣费 账户 SELECT * FROM 快递员账户 WHERE 快递员ID快递员ID if 账户.余额 费用: UPDATE 快递员账户 SET 余额余额-费用 WHERE 快递员ID快递员ID INSERT INTO 交易记录(快递员ID, 类型投递扣费, 金额-费用) else: INSERT INTO 欠费记录(快递员ID, 金额费用, 状态未抵扣) // 不回滚投递 // 充值自动抵扣欠费 function 充值(快递员ID, 金额): 订单 INSERT INTO 充值订单(快递员ID, 金额, 状态待支付) payUrl 微信支付.统一下单(订单ID, 金额) // 等待支付回调 callback 等待支付回调(订单ID) if callback.ok: // 先抵欠费 欠费清单 SELECT * FROM 欠费记录 WHERE 快递员ID快递员ID AND 状态未抵扣 抵扣金额 min(金额, SUM(欠费清单.金额)) for 欠费 in 欠费清单: if 抵扣金额 0: break UPDATE 欠费记录 SET 状态已抵扣 WHERE ID欠费.ID 抵扣金额 - 欠费.金额 余额增加 金额 - (SUM(欠费清单.金额) - 抵扣金额) UPDATE 快递员账户 SET 余额余额余额增加 WHERE 快递员ID快递员ID UPDATE 充值订单 SET 状态已支付 WHERE ID订单ID return 充值成功不是替代扫码是补充条形码扫描优先——快、准。条形码扫不出来或信息不全时才用 OCR。OCR 是兜底手段不是主路径。四、二维码贯穿全系统的身份凭证从登录到支付二维码在快递柜系统里用了三次场景生成方使用方用途快递员登录后端柜机显示手机 APP 扫身份认证扫码取件公众号柜机扫描用户身份 快递列表超时支付后端柜机显示用户微信扫支付二维码是无接触身份凭证。柜机不需要 NFC、不需要刷身份证——扫码就完成身份验证和支付跳转。防重放靠时效性登录二维码过期后失效支付二维码一次有效。五、总结下篇的三套支撑系统系统做了什么支付体系投递扣余额、超时拉微信支付、充值走即时支付。扣费失败不回滚投递OCR 识别百度 OCR 读运单号手机号脱敏电话查历史匹配二维码登录、取件、支付三个场景复用同一套二维码生成/验证逻辑加上上篇的投递和中篇的取件取回整套快递柜系统的核心设计就完整了。不是技术堆栈是状态机 多方协同 支付闭环三样东西组合后的产物。跟前面写的政务系统用的是同一套设计思维——只是场景从社保大厅移到了小区楼下。