有哪些异常情形？订单还能成功吗？
Waffo 会把不符合规范的转账归入以下情形之一——您提交工单时，支持团队使用的就是这些标签。
表格贯穿两条规则：结算始终基于订单
金额，绝不基于实际转账金额；向购物者退回资金
不是您账户上的退款——没有退款订单，也不会出现在您的退款报表里。
购物者多付了——多出来的归我吗？
不。订单按订单金额完成，多出部分不属于您。所以永远不要 用链上金额来核对稳定币订单。购物者少付了或付晚了——我还能发货吗？
不能。两种情形都不算支付成功，所以不要凭您自己观察到的 链上转账发货。请引导购物者在支付页面的支付窗口内， 一次转账付足全部订单金额。链错了、代币错了、或者用了旧地址——会自动解决吗？
不会。WRONG_TOKEN、WRONG_CHAIN 和 NO_MATCH_ORDER 永远不会自动
处理：订单不会成功，资金也不会自行
退回。请携交易哈希、链、代币和订单 id 提交支持工单。
NO_MATCH_ORDER 的常见原因是复用了收款地址——地址是
按订单签发的，所以如果您缓存了地址或让购物者付了两次，第二笔
转账不会匹配任何订单。
我自己在哪里能看到这些异常情形？
您能看到的是订单：它要么到达了最终成功状态，要么 没有。上述一切说的是资金去了哪里，而不是 订单，并且这些情形都不会在您账户上创建退款订单——所以 它们也永远不会出现在您的退款列表或退款报表中。 于是当购物者坚称已付款时只剩一条路：把订单 id 连同 购物者能提供的交易哈希、链和代币一起提交给 支持团队。这四项事实就是识别该情形的依据。退款稳定币订单时我必须发送什么？
每笔 USDC 和 USDT 退款都必须填写退款目标地址。请把地址放在/api/v1/order/refund 的 extendInfo 里。外层 extendInfo 的值是一个
包含 JSON 的字符串，不是嵌套的 JSON 对象。
下面是完整的请求体示例。请把每个占位值替换为订单和购物者的实际值：
refundAmount 必须填写订单的全部可退金额，否则退款会以 A0014（“Order cannot be refunded due to refund rules”）拒绝。退款地址必须适用于原支付
使用的链。对 USDC 或 USDT 订单这是必填的，省略它退款将无法成功（Portal 退款抽屉里该字段同样必填）——请求会在前置参数校验时失败，返回 A0003，错误信息为
Parameter validation failed ( missing refund optional field )，
msgParams.missingFields 中会包含 extendInfo.refundAddress；对法币订单它是不必要的，传了会被忽略。
请把这当作一次集成变更：
如果您已经在调用退款 API，之后又接入稳定币，请先更新您的
退款路径。请自行向购物者收集地址——Waffo 无法
联系您的购物者索要。
我能退到另一条链，或者任意钱包吗？
两者都不行。链从原支付读取并锁定；退款请求上没有 链参数，任何试图传入的都会被忽略。 链决定接受哪种地址格式，退款处理时会按 该链的格式校验地址：
被拒绝的地址会失败并附带具体原因，链上没有任何资金移动。请用修正后的地址重新发起退款，并在重发前检查
remainingRefundAmount。
请使用自托管（EOA）钱包地址，不支持合约地址；Portal 的退款抽屉里也写明了同样的规则。
Portal 应用相同的约束：在退款抽屉中，链是原支付链的
只读标签，标注为*“Refund must use the
same chain as the original payment,”*，地址字段在您输入时按该
链的格式校验。
稳定币订单可以部分退款吗？
稳定币订单能否部分退款，取决于您自己协议上该支付方式的退款形态，以及订单所走的渠道路由是否支持部分退款。请在 Service → Payin 的Refundable
列，或您配置响应中的 refundAllowed 确认——四种形态及其编码在
读懂您的支付方式配置中说明。如仍无法确认，请联系你的对接人。