# 回调交易结果

# 回调接口验签

验签目的

API 请求在通过公网传输过程中,有被中间人篡改的风险。为确保回调数据的完整性与可信性,平台支持并强烈建议商户在接收回调时进行签名验签

设置方式

登录【收银台后台】→【开发者中心】→【回调地址】→ 添加/编辑。

验签步骤

验签逻辑与接口请求签名大体一致,区别在于数据来源为接收到的回调内容

  1. 获取签名

从 HTTP 请求 Header 中读取签名字段:

sign: {平台生成的签名字符串}
  1. 获取回调参数体

将回调 Body 中的 JSON 参数以 key-value 形式存入一个 Map(字典)结构中。

  1. 添加公共参数

从 Header 中再取出以下字段,并一并加入 Map 中参与验签:

  • access_key
  • timestamp
  • nonce
  1. 构造待签名字符串

将 Map 中的所有 key 按照 ASCII 字典序从小到大排序,并拼接为如下格式的字符串:

key1=value1&key2=value2&...&keyN=valueN
  1. 执行签名计算

使用商户后台绑定的 secret_key 对上述字符串进行以下处理:

  • 使用 HMAC_SHA1 算法加密
  • 将结果进行 Base64 编码,得到本地 sign
  1. 比对签名

将本地生成的 sign 与 Header 中平台传来的 sign 进行比对:

  • ✅ 一致 → 验签通过,可处理业务逻辑
  • ❌ 不一致 → 拒绝处理,建议记录日志以供排查

# 收款回调

当收款订单进入终态(如成功、失败)后,平台将向商户预设的 notifyUrl 发送如下回调数据。

回调数据示例

{
  "currencyType": "BRL",
  "orderActualAmount": "21.1",
  "orderId": "OCURRPAID202307270345431690429543531DOCKER020000000400000776",
  "orderFee": "0.1",
  "orderStatus": "Payment success",
  "payParam": "00020101...BC7A",
  "externalOrderId": "828905760411449635",
  "tradeNote": "123",
  "payTypeName": "PIX",
  "orderAmount": "21.1",
  "orderTime": 1690429544000,
  "payType": 101,
  "orderStatusCode": 2,
  "markStatus": 0,
  "orderPayTime": 1690429623000
}

回调参数说明

参数名 类型 说明
currencyType String 法币类型(如:BRL)
orderActualAmount String 实际订单金额。消费者实际支付的金额,有可能与创建时的订单金额不一致,以消费者实际支付为准。
orderAmount String 订单原始金额。创建订单时发起的金额。
orderFee String 订单手续费。按照实际订单金额(orderActualAmount)进行计算。
orderId String 系统订单号
orderStatus String 订单状态描述(如 Payment success)
payParam String PIX 支付字符串
externalOrderId String 商户订单号
tradeNote String 备注
payTypeName String 支付方式名称(如:PIX)
orderTime int64 订单创建时间(毫秒时间戳)
payType int64 支付类型,枚举值:101 101-PIX
orderStatusCode int64 订单状态码,枚举值: 1=待支付; 2=支付成功(终态)
markStatus int64 标记状态
orderPayTime int64 实际支付时间(毫秒时间戳)
errorMsg String 错误信息(可选)
errorMsgEn String 错误信息英文(可选)

Tips:手动回调机制说明

商户可在任何时间登录商户后台,手动触发订单回调

注意事项:

  • 请勿在订单未处于终态(如:未支付、处理中)时手动触发回调,以免造成业务逻辑异常。
  • 手动回调的返回数据中,订单状态信息为当前实际状态,请在业务侧根据状态判断是否进行处理。
  • 若订单尚未处于终态(如状态为处理中),平台在订单状态变更为终态后仍会再次主动发起通知,商户应做好业务冗余处理,确保幂等性,避免重复入账或通知冲突
  • 若订单已经是终态,在商户后台点击手动回调(不建议),平台还会再次发起通知,商户应做好业务冗余处理,确保幂等性,避免重复入账或通知冲突

# 代付回调

当代付订单进入终态(如成功、失败)后,平台将向商户预设的 notifyUrl 发送如下回调数据。

回调数据示例

{
  "currencyType": "BRL",
  "userInfoNo": "18171847684",
  "orderId": "OCURRDRAW202307270345461690429546358DOCKER020000000200000777",
  "userInfoType": "CPF",
  "accountType": "CPF",
  "orderFee": "0.2",
  "orderStatus": "Success",
  "externalOrderId": "472512322065926592",
  "tradeNote": "123",
  "payTypeName": "PIX",
  "orderAmount": "20.01",
  "orderTime": 1690429547000,
  "payType": 201,
  "userInfoName": "joy",
  "accountNo": "18171847684",
  "orderStatusCode": 8,
  "markStatus": 0,
  "orderPayTime": 1690443316000
}

回调参数说明

参数名 类型 描述
currencyType String 法币类型(如:BRL)
userInfoNo String 用户证件号
userInfoName String 用户姓名
userInfoType String 用户证件类型(如:CPF、CNPJ)
accountType String 收款账户类型(如:CPF、EMAIL、PHONE)
accountNo String 收款账户编号(例如 PIX CPF/邮箱/手机号)
orderId String 平台订单号
externalOrderId String 商户订单号
orderAmount String 原始订单金额
orderActualAmount String 实际到账金额(如有,以该金额为准)
orderFee String 手续费金额
orderStatusCode int64 订单状态码: 1-已受理; 2-银行处理中; 4-失败,未受理(终态) 8-成功(终态); 16-失败(终态);
orderStatus String 状态描述,如 "Success"
orderTime int64 订单创建时间(毫秒时间戳)
orderPayTime int64 实际支付完成时间(毫秒时间戳)
tradeNote String 商户备注信息
payType int64 支付方式编码,枚举值:201 201-PIX
payTypeName String 支付方式名称,枚举值:PIX
markStatus int64 标记状态
errorMsg String 错误信息(中文)
errorMsgEn String 错误信息(英文)

Tips:手动回调机制说明

商户可在任何时间登录商户后台,手动触发订单回调

注意事项:

  • 请勿在订单未处于终态(如:未支付、处理中)时手动触发回调,以免造成业务逻辑异常。
  • 手动回调的返回数据中,订单状态信息为当前实际状态,请在业务侧根据状态判断是否进行处理。
  • 若订单尚未处于终态(如状态为处理中),平台在订单状态变更为终态后仍会再次主动发起通知,商户应做好业务冗余处理,确保幂等性,避免重复扣款或通知冲突。

# 回调响应

说明

  • 所有回调均包含签名字段,建议商户务必对回调进行验签,确保回调内容未被篡改。
  • 商户在收到回调数据并处理完成后,需以 JSON格式 响应网关如下数据:

示例响应(成功)

{
  "code": 200,
  "success": true
}

回调补发机制说明(重要)🔥

为确保回调通知的稳定送达与业务一致性,平台设计了多次重试策略。当商户系统未能成功响应回调时(如网络超时、返回非200状态码等),系统将按以下规则进行回调补发:

回调重试节奏(共 4 次):

尝试次数 间隔时间(约) 说明
第 1 次 约 2 分钟后 首次失败后触发第一次重试
第 2 次 约 2 分钟后 第一次重试失败后触发第二次重试
第 3 次 再约 11分钟后 第二次重试失败后再次重试
第 4 次 再约 2分钟后 第三次重试失败后进入下一次重试

注意:以上间隔时间为系统内部调度间隔,商户后台所记录的“回调时间”包含了商户处理/响应时间,因此显示上可能与实际推送时间存在 1 分钟左右误差。

实际情况提醒

  • 当线上订单量较大时,回调可能存在队列延迟,请确保服务端支持高并发处理能力;
  • 每次回调均为幂等操作,建议商户侧务必支持幂等判断;
  • 最多 4 次重试推送仍失败后,则不再自动重试,建议通过后台手动触发回调。

回调响应参数

Param Type Required Description
code int 状态码,成功为 200
success boolean 响应是否成功

# 回调通知 URL 配置

支持两种通知地址配置方式:

  1. 【商户后台】配置统一回调地址
  • 可在「商户后台」→「开发者中心」中配置。
  • 适用于大部分订单共用的回调处理逻辑。

img

2.订单级别手动指定回调地址(notifyUrl)

  • 在创建订单接口中可传 notifyUrl 字段。
  • 若订单中指定了 notifyUrl 参数,则系统将仅使用该地址作为回调通知目标地址

地址优先级说明

订单中的 notifyUrl 优先级高于统一配置的回调地址。

响应状态码优先级说明

平台以 HTTP 响应状态码 (**status_code**) 是否为 200 作为通知是否成功的唯一判断标准

具体规则如下:

  • 只要商户系统返回 HTTP 200**,平台即认为回调成功**
    • 此时即使返回内容不是 { "code": 200, "success": true } 也会被忽略。
  • ❌ 如果返回 status_code ≠ 200(如 400/500)或无响应,则判定为失败,平台将自动进行重试推送。