代付回调

method: POST

content-type: application/json

回调通知

状态处理原则

请仅处理 Status 为 4 (成功) 或 16 (失败/撤单) 的回调通知，其余中间状态请直接忽略！

回调参数

属性	类型	必填/签名	描述	示例
Timestamp	long	是	当前时间戳 精度：秒（10位 UTC）	1655997847
AccessKey	string	是	商户 AccessKey	BlVnlKWz...
Amount	string	是	实际支付金额 单位：元。请以该实际金额为准处理业务	100.01
Status	int	是	订单状态 请只处理 4 或 16	4
OrderNo	string	是	商户订单号	PR2023...
Ext	string	条件	扩展字段 非空则参与签名。若下单未传则返回 null	test_data
Comment	string	条件	订单备注/描述 非空则参与签名。例如代付失败原因	余额不足
Attachments	string	条件	图片附件 非空则参与签名。	https://...
Sign	string	不参与	签名串 详见 签名规则页	390bb71d...

---

响应要求

商户后端接收到异步回调并处理完成后，必须返回 ok 两个字符（不带引号）。

• 若返回非 ok 字符串，平台将进行 5 次 尝试重发回调。
• 请商户务必做好接口的 幂等性设计 和 防重保证。

动态签名逻辑说明

为了兼容后续可能增加的参数，请对接人员按照以下动态判定方式处理签名逻辑：

判定规则

有值则签名，无值则剔除。

参数状态	是否参与签名	举例
参数为空字符串 ""	不参与	NewExt: ""
参数有实际值	必须参与	NewExt: "abc"

---

回调重试机制

次数	间隔时间	备注
第 1 次	立即发送	首次通知
第 2 之后	以5s,10s,20s,40s,80s,120s,120s...的频率推送	持续推送2小时后不再推送，直到收到 ok 或达上限

💡 建议

建议商户在处理回调逻辑前，先判断单号 OrderNo 是否已经处理过（成功或失败），若已处理则直接回复 ok，避免重复入账。

{
    "time_stamp": "1613719331",
    "mch_no": "1611906847",
    "nonce": "9ZD0fWnWg1VPRlOV",
    "sign": "facd256530a70690475ef32f0184deba900b5d890c51057587c62fb77118bc59",
    "pay_type": "ALI_QR",
    "amount": "10000",
    "currency": "CNY",
    "fee": "0",
    "out_order_no": "test0001",
    "trade_no": "wd2021020900000006",
    "status": 3,
    "attach": "123",
    "remark": "支付异常"
}

代付订单状态表

状态流转提示

中间状态：状态 1 到 3 属于处理过程中的状态，请勿作为业务入账依据。

结算状态：状态 4 为成功的最终业务状态，状态 16 为失败的。

撤消状态：状态 5 为平账，表示撤回了成功订单，该状态不会发起回调，仅查询订单会返回

开发者注意事项

状态判定：仅当状态为 4 (成功) 或 16 (撤单) 时，订单才会发起回调。

中间状态：除 4 和 16 以外的所有状态（如 1, 2, 3）均视为处理中，5(平账: 撤回成功订单，不会发起回调)请勿进行业务结算，需继续等待回调或发起查询。

失败退款：状态为 16 时，商户余额已自动退回，请将此状态作为最终失败状态处理。