一笔转账不等于一个业务事件
PayIn 将订单支付定义为绑定具体结账、发票或业务交易的收款请求。[8] 充值模式则将地址分配给用户、账户或业务实体，不一定对应某一张发票。[9] 链上出现一笔转账，并不会自动告诉系统它清偿了什么义务。选择 API 前先写清楚：客户是在支付一笔具体订单，还是在增加账户可用余额？这个区别决定后续需要哪些记录，也决定谁来处理无法匹配的钱。
有明确应付款项时使用订单
建议订单记录包含商户编号、金额、资产、网络、收款目标以及明确的到期规则。PayIn 概念文档把少付、多付和逾期支付都列为集成前必须决定的问题。[8] 收到逾期款项后，不应覆盖原始订单请求来掩盖差异。先把观察到的转账关联到原请求，再另行记录接受、调查或退款决定。结账页面过期，只说明原付款条件到期，不代表后来到账的资金可以从账上消失。
维护客户余额时考虑充值模式
PayIn 的充值流程包含地址分配、检测转账、确认和商户内部账户入账。[9] 因而业务账本需要长期保留地址归属历史、网络和资产标识、转账标识、确认状态以及对应的入账记录。我们的建议是不要悄悄把长期收款地址重新分配给另一名客户。客户可能继续使用钱包里保存的旧地址。必须依靠历史归属处理这种转账，而不能只查看当前地址持有人就自动加款。
先写例外规则，再写成功流程
两种模式都需要规定如何处理分次支付、重复转账、错误资产、错误网络、多付款和过期付款。不要将一笔金额较大的转账直接当成两次购买，也不要因为地址熟悉就立即增加客户余额。PayIn 对账文档明确要求考虑逾期付款、金额不符与重复处理回调等情形。[7] 对无法确定的记录进入人工审核，并保留原始金额和事件。不要为了让报表合计相等而修改过去的事实。
建议的验收练习
在沙盒中分别建立一笔订单和一个充值账户。将同一个支付通知投递两次，最终应只产生一次经济结果。随后测试一笔逾期付款，以及一笔无法找到客户归属的转账。复核人员应能凭业务记录解释处理结果，而不是只能翻应用日志猜测。这是建议的测试场景，不是已执行的商户案例。地址归属与例外规则明确后，再确定链上确认要求和回调处理流程，让技术状态真正对应业务决定。