交易结果通知
支付、代付、退款等交易结果的异步通知约定
在交易到达终态后会向商户系统发送异步通知,用于同步支付、代付、退款等交易结果。
通知时机
以下场景通常会触发交易结果通知:
- 支付成功
通知仅表示平台已收到渠道结果,商户仍应通过查询接口做最终对账。
通知方式
- 协议:
HTTPS - 请求方式:
POST Content-Type:application/json- 编码:
UTF-8 - 通知地址:商户在接入时配置或每次请求时上送
通知报文
通知报文遵循统一请求报文结构,公共字段请参考请求报文。
{
"clientId": "60e55819aa99a10d42916bf3",
"trk": "传输秘钥 Base64",
"timestamp": 1788968481518,
"randomString": "e8fd19b3b67a4b60aae61243c69aa602",
"payload": "加密后的业务报文 Base64",
"charset": "UTF-8",
"signType": "RSA",
"sign": "平台签名 Base64"
}解密后的 payload
解密后的 payload 是 PaymentRecord 交易记录对象,与下单成功时返回的结果一致。
{
"id": "60e55819aa99a10d42916bf3",
"auditNumber": "202609211200001234",
"subAuditNumber": "M202609210001",
"issuerAuditNumber": "2026092122001234567890",
"totalAmount": 100.00,
"currency": "CNY",
"success": true,
"status": "SUCCESS",
"describe": "支付成功",
"remark": "",
"businessType": "PAYMENT",
"responseCode": "0000",
"responseMsg": "成功",
"terminalNo": "",
"storeNo": "",
"operatorNo": "",
"cancelled": false,
"refundAmount": 0.00,
"refundRecords": [],
"labels": {},
"original": null,
"createAt": 1788968481518,
"updateAt": 1788968481518,
"paymentAt": 1788968481518,
"merchant": {
"id": "merchant-id",
"merchantNo": "100100000000017",
"merchantName": "示例商户"
},
"settleInfo": {}
}示例值仅用于展示字段结构,实际值以平台返回为准;未用到的字段可能为 null 或省略。
关键字段
| 字段 | 说明 |
|---|---|
auditNumber | 平台交易号 / 系统流水号,建议作为幂等键 |
subAuditNumber | 商户订单号 / 请求方流水号 |
issuerAuditNumber | 发卡行流水号,例如支付宝、微信或银行卡流水号;UPI 支付时为 UTR |
totalAmount | 交易金额,单位为元 |
currency | 货币类型 |
success | 交易是否成功 |
status | 交易状态:SUCCESS、FAILURE、EXCEPTION、WAIT_PAYMENT、PROCESSING、CLOSE |
paymentAt | 支付完成时间,毫秒时间戳 |
refundAmount | 已退货金额,单位为元 |
refundRecords | 退款交易记录集合 |
original | 原始交易记录 |
签名与验签
商户收到通知后,应按签名计算规则校验 sign。
验签步骤:
- 使用平台公钥校验通知签名。
- 校验
timestamp、randomString、payload是否完整。 - 解密
payload,获取业务结果。 - 校验商户订单号、交易号是否与本地记录一致。
- 校验金额、币种和交易状态。
验签失败时不要更新订单状态,应记录告警并拒绝处理。
响应约定
商户处理完成后,应返回 HTTP 状态码 200
重试与幂等
- 平台在未收到成功响应时会按策略重试。
- 商户必须保证通知处理具备幂等性,同一交易号重复通知不能重复入账。
- 建议按
auditNumber+status建立幂等键。
安全建议
- 通知地址必须使用
HTTPS。 - 验签前不要信任任何业务字段。
- 不要将密钥、敏感信息打印到日志。
- 回调处理超时时,应先记录待处理状态,再通过查询接口确认最终结果。