处理要求
对于每一笔收到的回调,你都必须:- 先验证签名 : 见 认证与安全 了解签名验证详情
- 解析业务数据 并进行幂等处理
- 返回约定的成功响应
建议处理顺序
为了降低误更新、重复入账或过早判定终态的风险,建议按以下顺序处理回调:- 校验请求头与签名
- 解析
bizType、bizId、bizStatus - 对业务唯一标识做幂等检查
- 更新本地业务状态
- 返回成功响应
- 对关键资金事件结合查询接口做最终确认
触发与重试机制
触发条件 当订单状态发生变化(如支付成功、超时、取消、关闭或异常)时,GatePay 会向你配置的回调地址发送通知。 重试 如果你未返回约定的成功响应,或请求超时,GatePay 会按规则重试回调。 签名验证 处理前必须先验证所有回调签名。请参见 认证与安全 了解详情。回调消息结构
所有回调都包含以下顶层字段:
回调示例:
回调确认响应
请以 HTTP 200 返回以下 JSON 响应:bizType 枚举
总体说明
- 通知章节用于说明所有支付、退款、地址收款、静态地址收款、出金与机构相关回调的共性规则。
- 每类业务的详细回调字段解释,仍应以对应产品章节中的接入说明与 API Reference 共同理解。
- 如果你的业务同时接入多种支付方式,请务必按照
bizType分流处理,不要假设所有订单都共用同一回调字段集合。 - 不建议仅依据单次回调立即完成财务终态确认;对于关键资金动作,建议结合查单或详情查询接口完成最终核验。
支付产品与 bizType 对应关系
如果你的业务同时接入多种支付产品,建议先按“产品类型 -> bizType”建立内部映射:
本页已经整合常见事件目录与终态处理建议,可直接结合下文的业务分类继续阅读。
托管收银台支付通知
托管收银台支付遵循通用的PAY 回调模型。对于非地址支付,请使用 orderAmount 判断支付金额。有关支付接入的更多详情,请参见 支付。
退款通知
退款订单使用PAY_REFUND 回调类型。
- 退款查询与对账时,请优先使用商户侧唯一标识
refundRequestId。 - API 发起的退款与商户后台手工退款是两个不同操作入口,文档中的回调说明仅覆盖 API 集成场景。
- 退款状态推进建议同时结合回调与退款查询接口完成。
地址支付通知
PAY_ADDRESS 状态枚举
PAY_ADDRESS data 字段
TRANSFER_ADDRESS 状态枚举
TRANSFER_ADDRESS data 字段
说明:历史或不同业务流中,交易哈希字段可能表现为
txHash、tx_hash 或 hash,接入时建议按兼容方式解析。
CHAIN_ADDRESS 状态枚举
CHAIN_ADDRESS data 字段
静态地址收款通知
bizType:PAY_FIXED_ADDRESS
bizStatus: PAY_SUCCESS (入账成功)
data 字段
成功响应:
提现 / 出款回调
有关提现和出金操作,请参见 出金 了解详细回调结构和字段说明。 bizType:WITHDRAW
主单字段
子订单字段
机构 API 回调
bizType:INSTITUTION
bizStatus: INSTITUTION_ACCOUNT_SUCCESS 或 INSTITUTION_ACCOUNT_FAIL
有关机构账户相关通知,请参见 机构。
data 字段(JSON 字符串)
回调接入指南
接入要求
推荐处理流程
- 接收 回调请求
- 验证 使用商户密钥验证签名,具体规则可参考 认证与安全
- 提取 并解析
data字段 (JSON 字符串 → 对象) - 检查 幂等键 (例如 transactionId 或 merchantTradeNo)
- 存储 处理前持久化存储通知
- 处理 异步处理业务逻辑
- 返回
{"returnCode": "SUCCESS", "returnMessage": ""}并使用 HTTP 200
相关文档
常见事件目录
事件处理建议
- 优先按
bizType分流,不要假设所有回调都共享同一套字段 - 再按
bizStatus判断当前状态是否为中间态或终态 - 最后结合
merchantTradeNo、refundRequestId、batch_id等业务键做幂等更新
事件目录
终态处理原则
对于终态事件,推荐同时满足以下条件后再推进后续业务:- 签名验证通过
- 幂等校验通过
- 事件已经持久化
- 业务状态已经与本地订单、退款单或批次单一致

