少付意味着仍有欠款；多付意味着存在需要处理的超额收款。无论哪种情况，都不应临时决定退款，也不应再次要求客户支付全额。 应先核实实际到账情况，将款项与购买记录匹配，再分别决定是否履约，以及如何结清差额。
本指南以资产、网络和收款地址均正确为前提。如果这些信息不匹配，请改用网络选错事故处理指南。本文讨论的是收款信息匹配，但金额、到账时间或款项分配存在问题的情况。
以下控制措施是针对商家运营和工程实现的建议，并非 Yolfi 自动功能清单。文中示例仅作说明，不是真实客户事故。
先核实金额，再决定处理方式
保留原始付款请求：订单编号、要求支付的代币金额、网络、收款地址、报价依据，以及任何到期规则。将这些信息与经过独立核实且符合确认政策的收款记录比较，而不是与客户的钱包截图或余额估算比较。
应将以下三个数字分开记录：
- 应付金额： 付款说明要求支付的金额。
- 已核实收款： 实际收到、信息匹配且可分配至订单的转账。
- 未结差额： 扣除此前已分配款项、记入的客户余额和退款后，仍待处理的欠款或超额款项。
不要从客户的付款金额中扣除商家随后转账产生的费用。服务商费用和会计调整应与实际到账凭证分开记录。
如果交易所在提现时扣除手续费，实际到账金额可能少于客户原本打算支付的金额。应检查收款记录，而不是猜测。相反，Ethereum 上的标准 USDC 或 USDT 转账不会通过扣除 USDC 或 USDT 来支付 Ethereum 网络手续费：Ethereum 网络手续费以 ETH 支付。不要建议客户凭估算额外支付一笔稳定币来承担网络手续费。
实现时，应根据已核实的资产精度，使用精确的最小单位整数或精确小数进行比较。避免使用二进制浮点数比较，也绝不能仅因支付页面显示的小数位较少，就通过四舍五入抹去欠款。
金额异常决策表
可将下表作为内部政策模板。这些是业务分类，不是 Yolfi API 状态。
| 已核实情况 | 履约决定 | 金额处理措施 | 结案前的控制措施 |
|---|---|---|---|
| 在适用的时间规则内收到全额 | 满足确认要求后，仅履约一次 | 将收款分配至订单 | 检查此前的分配与履约记录 |
| 少于应付金额 | 暂缓履约，除非已有获批的让步安排 | 批准并跟踪补款请求、金额减免或退款 | 记录剩余欠款及负责人 |
| 多于应付金额 | 仅在满足收款接受规则时履约一次 | 审核超额部分，决定退款或按约定记入客户余额 | 将订单分配金额与超额部分分开 |
| 多笔转账合计达到所需金额 | 在确认允许合并计算且已完成核实前，暂缓履约 | 每笔符合条件的转账仅分配一次 | 不要假定服务商会合并付款 |
| 到期后收到全额 | 复核到账时间、报价及订单是否仍可履行 | 按政策接受，或另行商定处理方式 | 检查关联的替代付款请求 |
| 原始请求与替代请求均收到款项 | 绝不重复履约 | 对两笔收款进行核对并处理多余款项 | 锁定订单，防止重复操作 |
为每项异常指定明确的负责人和下一次进展告知期限。不能因为客服和财务都以为另一团队正在处理，就让收款一直处于未分配状态。
少付：只要求客户执行已批准的下一步
假设付款请求要求支付 100 USDC，但核实后仅收到 98 USDC，则欠款为 2 USDC。应保留原始收款记录，不要悄悄将其替换为显示收到 100 的新记录。
从以下方式中选择一种，并留存记录：
- 收取差额。 确认集成系统能够核对多笔独立收款。针对未付金额发出可跟踪的付款请求，关联同一订单，并提供当前有效的付款说明。
- 接受减免。 由获授权人员记录减免金额和会计处理方式。不要声称商家减免会改变服务商的付款认定规则。
- 退还部分付款。 在执行这笔独立的对外转账前，先商定退款条件和收款地址。
Yolfi 的部分付款常见问题说明，未付足的付款不会被确认，客户应联系商家。同时，只有商家系统支持时，才能向同一地址补款。因此，不要承诺只要补齐差额，原始 Yolfi 付款请求就会自动完成。
如果尚未验证拆分付款的处理能力，应先升级处理，再要求客户继续付款。保留首次部分付款的同时，又要求客户再次支付全额，很容易造成多付。
应在事故发生前制定小额欠款政策，例如明确审批限额、适用购买范围及审计理由。并不存在通用的容差百分比：BTCPay Server 文档说明了其自身可配置的少付容差，但这不能证明 Yolfi 提供相同设置。
多付：将销售款与超额款项分开
客户应付 100 USDT，实际支付 105 USDT。如果付款在其他方面均符合接受要求，应将 100 USDT 分配至购买记录，并将 5 USDT 记为待处理的超额款项。不要默认将差额视为额外收入，或据此增加产品权益。
让客户从可用且符合政策的方案中选择：退款，或经明确同意后记入客户余额。在达成一致前说明任何适用费用，并核查当地消费者保护及会计义务。金额小，并不意味着可以不告知客户就留存款项。
还应区分单笔多付与重复付款。针对一笔 100 USDT 的购买，收到两笔各 100 USDT 的转账，意味着有两笔收款，而不是一笔已更正的收款。保留两笔交易记录，仅履约一次，并单独审核额外的 100 USDT。
逾期付款：到期并不意味着已收款项无需处理
分别记录付款请求的截止时间、检测到转账的时间和确认时间。到期前已发现、到期后才确认的付款，与报价到期后才首次收到的转账，并不是同一种情况。应执行已记录的规则，不要自行假定存在通用宽限期。
对于逾期收款，应核查：
- 原报价是否仍然有效；
- 库存、服务容量或访问权限是否仍可提供；
- 是否已有另一付款请求为同一订单收款；
- 是否已经批准退款、记入客户余额或金额减免。
以代币计价、要求支付 100 USDC 的请求，与以法定货币计价后换算成加密货币的请求，未必应适用相同的逾期付款政策。保留原始报价；如需新报价，应明确告知客户，而不是改写历史价格。
如果必须创建替代付款请求，应在记录中将其关联到原订单，并提醒客户不要两笔都付。同时继续监控原付款尝试。关闭客服工单并不能阻止已提交的转账在之后得到确认。
安全退款，避免引发第二次事故
退款是一笔独立的对外付款，不是对入账转账的修改。Yolfi 的非托管服务说明指出，付款直接进入商家配置的钱包。不要假定 Yolfi 持有可供退款的余额，或会自动退还超额部分。
批准退款前，应完成以下检查：
- 确认原始收款、客户诉求和剩余可退金额。
- 通过既有客户联系渠道核验申请人身份。
- 获取并核实退款所用的资产、网络和收款地址。不要直接退回交易发送地址；该地址可能属于交易所或其他中介。
- 在遵守适用义务的前提下，商定退款总额、手续费承担方式和预计净到账金额。
- 按钱包安全政策取得审批，记录退款原因和审批人。
- 记录对外转账的交易编号，并在核实结果后再将退款标记为完成。
绝不要索取助记词或私钥。如果提交退款时超时，应先调查交易状态，再决定是否重发。响应不明确，并不能证明付款尚未广播。
让每种处理方式都具备幂等性
幂等性意味着重试不会重复执行业务操作。Stripe 的 Webhook 指南说明了 Stripe 事件可能重复、且顺序不受保证的情况。这是有用的工程参考，但不代表 Yolfi 的通知交付约定。
对于自己的集成系统，应采取以下措施：
- 使用服务商文档规定的验证流程，核验通知真实性。
- 持久化保存收到的事件，并使用文档规定的标识符去重。
- 使用网络和交易编号标识每笔收款；若同一交易包含多笔相关转账，还需加入转账索引或事件索引。
- 通过数据库约束或等效的事务控制，确保每笔收款仅分配一次、每个订单仅履约一次。
- 发送退款前，先为已批准的退款操作进行排他占用，防止并发任务重复转账。
重复的 Webhook 通知不等于另一笔付款。第二笔有效转账确实是另一笔收款，但仍不意味着可以再次发货。结案前，应同时依据钱包凭证和业务记录完成异常对账。
常见问题
应该接受少付一点点的付款吗？
只有在商家已批准的政策范围内才可以。单独记录减免，并核实付款会如何被认定；不要假定存在自动容差。
多付后应该自动退款吗？
在未核实资金归属、收款地址、金额及防重复控制之前，不应自动退款。除非经过测试和授权的流程能够安全处理，否则应将超额款项加入审核队列。
两笔部分付款可以支付同一订单吗？
如果政策允许，商家的记录可以将多笔收款分配至同一订单。但支付服务商是否会合并认定这些款项，必须另行核实。
总结：结清差额，而不只是关闭工单
先提供清晰的 Yolfi 支付链接，再将商家的异常台账与付款记录一并维护。只有当订单款项分配、履约决定、剩余差额，以及任何退款或记入客户余额的金额全部一致时，才应结案。这样才能避免一个小小的金额差异，演变为再次付款、重复交付或不安全的退款。
