OpenAPI 开发者文档更新记录 OpenAPI Developer Documentation Changelog
版本更新历史 Revision History
| 版本号Version | 更新时间Date | 变更类型Type | 更新内容说明Change Description |
|---|---|---|---|
| v1.6.0 | 2026-10-08 | 配置更新Config Update |
正式确定并发布生产环境服务基地址 (Base URL) 为 https://api.blueglowdigital.com
Officially released Production Base URL as https://api.blueglowdigital.com
|
| v1.5.0 | 2026-09-30 | 规范新增New Spec |
1. 新增「API 响应码与错误码规范」专题文档,置于签名规则前,梳理统一 Result 数据结构与链路追踪字段 traceId。2. 完善网关前置授权、IP 白名单、防重放及限流等前置安全错误码规范。 3. 规范化定义全量业务错误枚举( errorCode)及 18 种 RECHARGE_REJECTED 具体英文拒绝文案。
1. Added "API Response Codes & Error Codes" specification before signature rules, detailing unified Result schema and traceId.2. Documented pre-API authentication, IP whitelist, replay protection, and rate limiting error codes. 3. Standardized business error enums ( errorCode) and all 18 RECHARGE_REJECTED rejection messages.
|
| v1.4.0 | 2026-09-18 | 优化 / 完善Enhancement |
1. 回调通知增加 12 次阶梯重试机制,明确重试间隔(10秒至24小时)。 2. 回调请求 Header 中强调签名使用专门的回调密钥计算。 3. 精简单账号充值说明,对齐并标准化各状态查询接口描述。 1. Added a 12-attempt exponential backoff retry policy for Webhooks (10s up to 24h). 2. Specified that Webhook signature calculation uses the dedicated Callback Secret. 3. Streamlined single recharge descriptions and aligned all query endpoints. |
| v1.3.0 | 2026-09-18 | 新增能力Feature |
1. 新增「充值状态变更回调通知 (Webhook)」文档,支持充值终态的主动异步推送。 2. 规范化定义回调 Header(包含 X-Event-Id、X-Signature)及事件 Body 结构。
1. Added Webhook Notification specification for asynchronous final status delivery.2. Defined Webhook Headers (including X-Event-Id, X-Signature) and payload schema.
|
| v1.2.0 | 2026-09-17 | 安全修正Security Fix |
1. 修正签名验证算法:明确 6 行规范化结构拼接规则,引入 rawQuery 参与验签。2. 统一全平台各 API 请求 Header 参数定义,输出标准 Base64 签名串。 3. 补充基于标准 JDK 原生库的 Java 签名生成实现与 NodeJS 代码示例。 1. Corrected HMAC-SHA256 signature algorithm to 6-line canonical format including rawQuery.2. Standardized Base64 encoded output for all API request headers. 3. Added standard Java (pure JDK) and Node.js signature code examples. |
| v1.1.0 | 2026-09-15 | 新增接口Feature |
1. 扩充「批量账号充值提交」及「按批次业务号查询整批充值状态」接口。 2. 增加针对单笔充值按订单号和业务请求号的多维度状态查询能力。 1. Added Batch Account Recharge submission and batch status query endpoints. 2. Provided single recharge query by both client request number and platform order number. |
| v1.0.0 | 2026-09-08 | 初始发布Initial Release |
1. 发布开放平台基础 API 规范与签名鉴权规则。 2. 开放单账号充值提交基础接口。 1. Published platform baseline OpenAPI specifications and authentication rules. 2. Released single account recharge submission endpoint. |
服务地址 (Base URL) Service Base URL
| 环境类型Environment | 服务地址 (Base URL)Base URL | 状态说明Status |
|---|---|---|
| 生产环境Production | https://api.blueglowdigital.com |
正式运行Active |
接口与文档模块概览 Modules & Endpoints Index
| 模块名称Module | 类型 / 方法Type / Method | 接口路径 / 说明Path / Description | 操作Action |
|---|---|---|---|
| 响应码与错误码规范Response & Error Codes | DOC | 统一响应结构、HTTP 状态码、认证安全拦截码与业务错误枚举规范Unified Result schema, HTTP codes, authentication & business error enums | 查看规范 →View Spec → |
| API 签名验证规则API Signature Rules | DOC | 公共 Header 参数、HMAC-SHA256 签名算法及代码示例Common Headers, HMAC-SHA256 algorithm & code samples | 查看规则 →View Doc → |
| 单账号充值提交Single Account Recharge | POST | /v1/recharges |
查看接口 →View API → |
| 按请求号查询状态Query by Request No | GET | /v1/recharges/by-client-request-no/{clientRequestNo} |
查看接口 →View API → |
| 按平台单号查询状态Query by Order No | GET | /v1/recharges/{orderNo} |
查看接口 →View API → |
| 批量账号充值提交Batch Account Recharge | POST | /v1/recharges/batch |
查看接口 →View API → |
| 按批次号查询整批状态Query Batch Status | GET | /v1/recharges/batch/{batchNo} |
查看接口 →View API → |
| 充值状态变更回调通知Webhook Notification | DOC | Webhook 异步推送充值终态与验签机制Asynchronous Webhook event push & verification | 查看通知 →View Doc → |
API 响应码与错误信息规范 API Response Codes & Error Messages
0. 统一响应结构 (Response Envelope) 0. Unified Response Envelope
-
标准外层结构:Standard JSON Structure:
平台所有对外暴露的充值适配接口统一采用标准的
Result格式封装返回。 All exposed recharge OpenAPI endpoints consistently return the following JSON envelope. -
成功响应:Success Responses:
success为true,code为 HTTP 状态码(充值提交受理为202,查询接口为200);message在两类提交接口中返回受理提示文本,在三类查询接口中返回null(或空);result携带具体业务数据。successistrue,codeis the HTTP status (202 for submit acceptance, 200 for queries),messageis endpoint-specific (acceptance text for submit endpoints, not set/null for query endpoints), andresultholds the business data. -
错误与链路追踪:Error & Trace Diagnostics:
success为false,code为对应 HTTP 状态码,message为错误提示。对于业务处理/入参校验错误,result包含业务错误枚举errorCode与traceId;对于在请求进入业务处理前被拦截的授权、安全与限流拒绝,result仅包含errorCode,链路追踪 ID 统一通过响应头X-Trace-Id返回。successisfalse,codeis the HTTP status, andmessageis a human-readable description. For business/validation errors,resultcontainserrorCodeandtraceId. For pre-API authentication/security/rate-limit rejections,resultcontains onlyerrorCode, with the trace id returned in theX-Trace-IdHTTP response header. -
统一响应头:Global Tracing Header:
每个接口响应头中均包含
X-Trace-Id,联系平台技术支持时请提供该链路追踪 ID。 Every HTTP response includes anX-Trace-Idheader. Please provide it when contacting technical support.
成功响应示例 (200 / 202) Success Response Sample
{
"success": true,
"code": 200,
"message": "",
"result": { ... }
}
失败响应示例 (业务校验错误) Failure Response Sample (Business / Validation)
{
"success": false,
"code": 400,
"message": "Account does not exist or is invalid",
"result": {
"errorCode": "RECHARGE_REJECTED",
"traceId": "a1b2c3d4"
}
}
失败响应示例 (网关鉴权 / IP / 限流前置拦截) Failure Response Sample (Pre-API Auth / Security / Rate Limit)
// HTTP Response Headers:
// X-Trace-Id: 7f8a9b0c1d2e3f4a
{
"success": false,
"code": 403,
"message": "Source IP is not allowed",
"result": {
"errorCode": "IP_NOT_ALLOWED"
}
}
1. 接口成功响应对照表 1. Endpoint Success Responses
| 接口名称Endpoint | 请求方法与路径Method & Path | HTTP 状态码HTTP Code | 提示信息 (message)Message | 响应数据类型Result Payload |
|---|---|---|---|---|
| 单笔充值提交Single Recharge Submit | POST /v1/recharges |
202 | Recharge request accepted |
RechargeSubmitResponse |
| 批量充值提交Batch Recharge Submit | POST /v1/recharges/batch |
202 | Batch recharge request accepted |
BatchRechargeSubmitResponse |
| 按平台单号查询状态Query by Order No | GET /v1/recharges/{orderNo} |
200 | null (不设置not set) | RechargeStatusResponse |
| 按请求号查询状态Query by Client Request No | GET /v1/recharges/by-client-request-no/{clientRequestNo} |
200 | null (不设置not set) | RechargeStatusResponse |
| 按批次号查询整批状态Query Batch Status | GET /v1/recharges/batches/{batchRequestNo} |
200 | null (不设置not set) | BatchRechargeStatusResponse |
2. 授权认证、安全与限流错误码 (网关前置校验) 2. Authentication, Security & Rate Limiting Codes
result 仅包含 errorCode,链路追踪 ID 统一记录在 X-Trace-Id 响应头中。
These security checks run before the request reaches the API business layer and apply to every endpoint. On failure, result contains only errorCode, and the trace ID is returned via the X-Trace-Id response header.
| 业务错误码 (errorCode)errorCode | HTTP 状态码HTTP | 错误提示信息 (message)Message | 触发条件说明Trigger Scenario |
|---|---|---|---|
AUTH_HEADERS_MISSING |
401 | Missing OpenAPI authentication headers |
缺少必需的认证头参数(如 AppKey、时间戳、签名等为空)Required authentication headers are missing or empty |
AUTHENTICATION_FAILED |
401 | OpenAPI authentication failed |
凭证格式非法、appKey 未注册/被停用、或签名比对不匹配(出于安全考虑不公开具体原因)Invalid credential format, disabled appKey, or signature mismatch (cause not disclosed externally) |
TIMESTAMP_INVALID |
401 | Request timestamp is invalid or expired |
时间戳格式非法或超出允许的时钟漂移范围Timestamp is missing, invalid epoch-second, or outside allowed clock skew |
IP_NOT_ALLOWED |
403 | Source IP is not allowed |
请求来源 IP 不在 appKey 绑定的 IP 白名单内Source IP is not in the appKey's configured IP whitelist |
REQUEST_TOO_LARGE |
413 | Request body exceeds the configured limit |
请求体大小超过平台设定的单次传输字节限制Request body exceeds maxRequestBytes limit |
REPLAYED_REQUEST |
409 | Request nonce has already been used |
随机数 nonce 在防重放有效期内已被使用过Request nonce already used within replay-protection window |
RATE_LIMITED |
429 | Request rate limit exceeded |
请求超出 QPS 频率限制(响应头包含 Retry-After: 1)Request rate limit exceeded (returns Retry-After: 1 header) |
CREDENTIAL_STORE_UNAVAILABLE |
503 | Credential validation is temporarily unavailable |
凭证数据库连接超时或暂时不可用Credential database unreachable during validation |
SECURITY_STORE_UNAVAILABLE |
503 | Request security validation is temporarily unavailable |
防重放存储组件暂时不可用Replay-protection store unreachable |
RATE_LIMIT_STORE_UNAVAILABLE |
503 | Request rate limiting is temporarily unavailable |
限流控制存储组件暂时不可用Rate-limit store unreachable |
3. 业务错误码 (Business Error Codes) 3. Business Error Codes
| 业务错误码 (errorCode)errorCode | HTTP 状态码HTTP Code | 错误信息与说明Message & Description |
|---|---|---|
INVALID_REQUEST |
400 | Request parameters are invalid |
BATCH_SIZE_EXCEEDED |
400 | Batch item count exceeds the configured limit of N |
DUPLICATE_CLIENT_REQUEST_NO |
400 | clientRequestNo must be unique within a batch |
BATCH_REQUEST_NO_EXISTS |
409 | batchRequestNo already exists |
RECHARGE_REJECTED |
400* | 业务逻辑拒绝(通常为 400;详见第 4 节具体拒绝原因)Business rejection (typically 400; see Sec 4 for details) |
META_SERVER_INVALID_RESPONSE |
502 | 通道服务响应数据不一致(详见第 5 节)Inconsistent response payload returned (see Sec 5) |
META_SERVER_CALL_FAILED |
502 | Recharge service returned an invalid response |
META_SERVER_DISABLED |
503 | Recharge service is temporarily unavailable |
META_SERVER_INTERNAL_TOKEN_NOT_CONFIGURED |
503 | Recharge service is temporarily unavailable |
META_SERVER_UNAVAILABLE |
503 | Recharge service is temporarily unavailable |
INTERNAL_ERROR |
500 | Internal service error |
*注:对于 RECHARGE_REJECTED,HTTP 状态码透传下游业务状态码(通常为 400)。若下游未返回状态码或返回 5xx,则自动降级为 502。若批次号冲突则单独返回 409(BATCH_REQUEST_NO_EXISTS)。
*Note: For RECHARGE_REJECTED, the HTTP status is the upstream status returned for a business rejection (typically 400). If upstream returns 5xx or null, HTTP status degrades to 502. 409 conflict is reported as BATCH_REQUEST_NO_EXISTS.
4. RECHARGE_REJECTED 业务拒绝提示明细 (HTTP 400) 4. RECHARGE_REJECTED Rejection Reasons (HTTP 400)
result.errorCode = "RECHARGE_REJECTED",具体的业务拒绝原因通过 message 字段返回:
When business validation fails, the API returns HTTP 400 with result.errorCode = "RECHARGE_REJECTED". The exact rejection reason is provided in the message field:
| 错误提示信息 (message)Error Message (message) | 触发原因说明Scenario / Reason |
|---|---|
clientRequestNo already exists |
业务请求号已存在(幂等冲突)clientRequestNo already exists (idempotency conflict) |
operationType only supports 'in' |
操作类型不支持(仅支持入账)Operation type only supports 'in' |
Recharge amount must be at least 0.01 |
单笔充值金额低于最小额度 (0.01)Recharge amount lower than minimum (0.01) |
Account does not exist or is invalid |
目标充值账户不存在或无效Target account not found or invalid |
Account status does not allow recharge |
账户状态受限(如冻结/注销,不允许充值)Account status does not permit recharge |
Channel does not exist or is invalid |
指定充值渠道不存在或已失效Recharge channel not found or invalid |
PhotonPay (GZY) channel requires a minimum single recharge amount of 20 |
光子易渠道单笔充值金额不得低于 20PhotonPay channel requires minimum amount of 20 |
The account's owning customer does not exist |
账户归属的客户主体不存在The account's owning customer does not exist |
appKey is not associated with a valid OpenAPI client |
请求凭证未关联到有效的接口调用主体appKey is not associated with a valid OpenAPI client |
appKey bound user or customer does not match the request context |
请求凭证绑定的主体与当前请求上下文不符appKey bound user or customer does not match context |
customerId does not match the account's owning customer; operation not permitted |
客户编号与账户所属主体不一致,无权操作customerId mismatch with account owner; operation not permitted |
Single recharge amount exceeds the limit |
单笔充值金额超过平台最大限额Single recharge amount exceeds maximum limit |
Daily cumulative recharge amount exceeds the limit |
日累计充值金额已达上限Daily cumulative recharge amount exceeds limit |
The account already has a recharge request in process; please do not submit duplicates |
该账号当前已有处理中的充值,请勿重复提交The account already has a recharge request in process |
Exactly one of orderNo or clientRequestNo must be provided |
状态查询参数必须且仅能提供其一Exactly one of orderNo or clientRequestNo must be provided |
batchRequestNo is required |
批量状态查询缺少批次号参数batchRequestNo parameter is required |
Recharge order does not exist |
充值订单不存在或无权访问Recharge order not found or unauthorized |
<customerName>'s fund pool balance is insufficient |
资金池余额不足以扣减充值金额Customer's fund pool balance is insufficient |
5. 响应不一致异常明细 (HTTP 502) 5. Inconsistent Response Messages (HTTP 502)
| 错误提示信息 (message)Error Message (message) | 触发场景说明Scenario |
|---|---|
Recharge service returned inconsistent order information |
单笔充值或状态查询响应中缺少订单号或信息冲突Missing order number or inconsistent identity in single submit/query |
Recharge service returned inconsistent batch information |
批量提交响应中批次号、子单列表或计数校验不一致Inconsistent batch request number or items in batch submit |
Recharge service returned inconsistent batch status information |
批量状态查询响应中总笔数与子单详情列表不匹配Inconsistent total count and item count in batch query |
6. 批量充值子单明细错误 (Batch Item-Level Errors) 6. Batch Item-Level Errors (202 Accepted Items)
POST /v1/recharges/batch)整体持久化受理即返回 HTTP 202(success = true),即便部分子单未通过业务校验。调用方应遍历响应中 items 数组,针对未受理项(accepted = false),根据明细级 errorCode 与 errorMessage 处理:
A batch submit (POST /v1/recharges/batch) returns HTTP 202 with success = true even if some items fail validation. Inspect each item's accepted field. Rejected items (accepted = false) contain granular errorCode and errorMessage:
| 子单级错误码 (errorCode)errorCode (item level) | 子单错误信息 (errorMessage)errorMessage |
|---|---|
CLIENT_REQUEST_NO_EXISTS |
clientRequestNo already exists |
ACCOUNT_NOT_FOUND_OR_INVALID |
Account does not exist or is invalid |
ACCOUNT_STATUS_NOT_ALLOWED |
Account status does not allow recharge |
CHANNEL_NOT_FOUND_OR_INVALID |
Channel does not exist or is invalid |
GZY_MIN_AMOUNT |
PhotonPay (GZY) channel requires a minimum single recharge amount of 20 |
CUSTOMER_NOT_FOUND |
The account's owning customer does not exist |
APPKEY_NO_OPENAPI_CLIENT |
appKey is not associated with a valid OpenAPI client |
OPENAPI_CLIENT_CONTEXT_MISMATCH |
appKey bound user or customer does not match the request context |
CUSTOMER_MISMATCH |
customerId does not match the account's owning customer; operation not permitted |
AMOUNT_EXCEED_PER_REQUEST |
Single recharge amount exceeds the limit |
AMOUNT_EXCEED_PER_DAY |
Daily cumulative recharge amount exceeds the limit |
TOO_MANY_PROCESSING_ORDERS |
The account already has a recharge request in process; please do not submit duplicates |
AMOUNT_BELOW_MIN |
Recharge amount must be at least 0.01 |
CASH_POOL_INSUFFICIENT |
<customerName>'s fund pool balance is insufficient |
RECHARGE_REJECTED |
Any other rejection reason not listed above |
API 签名验证规则 API Signature Authentication Rules
1. 公共请求头参数 (Headers) 1. Common Request Headers
每次调用接口时,客户端必须在 Request Header 中包含以下字段: The client must include the following headers on every API invocation:
| 请求头 (Header)Header | 描述Description | 示例 / 说明Example / Note |
|---|---|---|
| X-App-Key | 开发者分配的 App KeyAssigned Developer App Key | your_app_key_here |
| X-Timestamp | 当前时间的 Unix 时间戳(秒级别)Unix epoch timestamp in seconds | 1678888888 |
| X-Nonce | 随机字符串(建议 32 位 Hex 字符)Random string (32-character hex recommended) | 1eaf4cbb81d947e69d140a65415d0f71 |
| X-Signature | 根据下方规则计算得出的签名值 (Base64)HMAC-SHA256 signature (Base64) | 详见下方计算规则See calculation rules below |
注意:Notice: 必须妥善保管与 App Key 对应的 App Secret,绝对不要将其放在请求中传输。App Secret 仅用于在本地计算签名。 Keep your App Secret confidential. Never transmit it over HTTP/HTTPS. It is used strictly for local signature generation.
2. 签名计算规则 2. Signature Calculation Process
签名的生成依赖于 HMAC-SHA256 算法,最终输出为 Base64 编码字符串,分为以下三个步骤: The signature is generated using HMAC-SHA256 and encoded in Base64, structured in three steps:
步骤一:计算 Body Hash Step 1: Compute Body Hash
将 HTTP 请求体 (Body) 的原始字符串数据(UTF-8 编码),使用 SHA256 算法进行哈希计算,并将结果转换为十六进制小写字符串 (Hex)。
Hash the raw HTTP Body (UTF-8 encoded) with SHA256 and convert the digest to lowercase hexadecimal string.
注意:如果当前请求没有 Body(如 GET 请求或 Body 为空),则对空字符串 "" 进行 SHA256 计算得出 Hex。
Note: For requests without body (e.g. GET requests), compute SHA256 on empty string "".
步骤二:构建规范化请求字符串 (Canonical Request) Step 2: Build Canonical Request String
将请求的 6 项关键要素严格按以下顺序拼接,各项之间使用换行符
进行分隔。格式如下:
Join the 6 elements strictly in order using newline character
:
HTTP_METHOD + "
" +
REQUEST_PATH + "
" +
RAW_QUERY + "
" +
X_TIMESTAMP + "
" +
X_NONCE + "
" +
BODY_HASH
步骤三:计算最终签名 (Signature) Step 3: Generate Base64 Signature
使用分配的 App Secret 作为秘钥,对步骤二生成的规范化字符串进行 HMAC-SHA256 运算,并将输出转换为 Base64 字符串:
Calculate HMAC-SHA256 using App Secret as the key over the canonical string and encode as Base64:
Signature = Base64(HMAC_SHA256(CanonicalRequest, AppSecret))
3. 代码示例 3. Code Samples
Java (Pure JDK javax.crypto)
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
import java.nio.charset.StandardCharsets;
import java.security.MessageDigest;
import java.util.Base64;
public class SignUtil {
public static String sha256Hex(String data) {
try {
MessageDigest digest = MessageDigest.getInstance("SHA-256");
byte[] hash = digest.digest((data == null ? "" : data).getBytes(StandardCharsets.UTF_8));
StringBuilder hexString = new StringBuilder();
for (byte b : hash) {
String hex = Integer.toHexString(0xff & b);
if (hex.length() == 1) hexString.append('0');
hexString.append(hex);
}
return hexString.toString();
} catch (Exception e) {
throw new RuntimeException(e);
}
}
public static String hmacSha256Base64(String data, String secret) {
try {
Mac mac = Mac.getInstance("HmacSHA256");
SecretKeySpec keySpec = new SecretKeySpec(secret.getBytes(StandardCharsets.UTF_8), "HmacSHA256");
mac.init(keySpec);
return Base64.getEncoder().encodeToString(mac.doFinal(data.getBytes(StandardCharsets.UTF_8)));
} catch (Exception e) {
throw new RuntimeException(e);
}
}
public static String generateSignature(String method, String path, String rawQuery,
String timestamp, String nonce, String body, String secret) {
String bodyHash = sha256Hex(body == null ? "" : body);
String canonicalRequest = String.join("
",
method.toUpperCase(), path, rawQuery == null ? "" : rawQuery,
timestamp, nonce, bodyHash);
return hmacSha256Base64(canonicalRequest, secret);
}
}
JavaScript (CryptoJS / Node.js)
const CryptoJS = require("crypto-js");
function generateSignature({ method, path, rawQuery = "", timestamp, nonce, body = "", secret }) {
const bodyHash = CryptoJS.SHA256(CryptoJS.enc.Utf8.parse(body)).toString(CryptoJS.enc.Hex);
const canonicalRequest = [
method.toUpperCase(), path, rawQuery, timestamp, nonce, bodyHash
].join("
");
return CryptoJS.enc.Base64.stringify(CryptoJS.HmacSHA256(canonicalRequest, secret));
}
单账号充值提交 Single Account Recharge Submission
接口说明 Endpoint Overview
-
异步受理模式:Asynchronous Processing:
本接口为异步受理模式,调用返回
202 Accepted表示平台已成功接收并持久化充值请求,后续充值状态请通过查询接口获取。 This endpoint operates asynchronously. A202 Acceptedresponse confirms persistence. Call query endpoints for final execution status. -
幂等与重试规范:Idempotency & Retries:
平台不提供自动重试机制;调用方发起网络重试时,必须复用相同的业务请求号
clientRequestNo,并重新生成当前时间戳、随机数nonce及对应的签名值。 When retrying due to timeouts, reuse the sameclientRequestNo, but regenerateX-Timestamp,X-Nonce, andX-Signature.
请求 Header 参数 Request Headers
| 参数名Header | 类型Type | 必填Required | 说明与示例Description & Example |
|---|---|---|---|
| X-App-Key | string | 必填Yes | 调用凭证 AppKeyAssigned AppKey |
| X-Timestamp | integer | 必填Yes | 当前时间戳(秒)Current timestamp (seconds) |
| X-Nonce | string | 必填Yes | 防重放随机字符串Anti-replay random string |
| X-Signature | string | 必填Yes | HMAC-SHA256 签名串 (Base64)HMAC-SHA256 signature (Base64) |
| Content-Type | string | 必填Yes | application/json |
请求 Body (application/json) Request Body (application/json)
| 参数名Field | 类型Type | 必填Required | 说明与示例Description & Example |
|---|---|---|---|
| clientRequestNo | string | 必填Yes | 调用方业务请求号,示例: APIFOX-20260915-0005Client unique request number |
| accountId | string | 必填Yes | 充值账号 ID,示例: 333333Recharge target account ID |
| amount | number | 必填Yes | 充值金额,示例: 27Recharge amount |
{
"clientRequestNo": "APIFOX-20260915-0005",
"accountId": "333333",
"amount": 27
}
返回响应 (202 Accepted) Response (202 Accepted)
{
"success": true,
"message": "充值请求已受理",
"code": 202,
"result": {
"orderNo": "RC202609070001",
"clientRequestNo": "APIFOX-20260907-0001",
"status": "PROCESSING"
},
"timestamp": 1788786000000
}
按调用方业务请求号查询状态 Query Recharge by Client Request No
接口说明 Endpoint Overview
- 查询维度:Lookup Scope: 调用方使用发起充值时提交的业务请求号
clientRequestNo查询该订单的处理状态与执行明细。Query execution status using your original client request number. - 状态流转:Status Flow: 充值受理后状态为
PROCESSING(处理中),终态包括SUCCESS(充值成功)与FAILED(充值失败)。Status transitions fromPROCESSINGto final stateSUCCESSorFAILED. - 轮询建议:Polling: 建议调用方采用指数退避或合理时间间隔(如 1~3 秒)进行轮询,以避免高频无效请求。Polling interval of 1-3 seconds is recommended.
请求 Header 参数 Request Headers
| 参数名Header | 类型Type | 必填Required | 说明与示例Description & Example |
|---|---|---|---|
| X-App-Key | string | 必填Yes | 调用凭证 AppKeyAssigned AppKey |
| X-Timestamp | integer | 必填Yes | 当前时间戳(秒)Current timestamp (seconds) |
| X-Nonce | string | 必填Yes | 防重放随机字符串Anti-replay random string |
| X-Signature | string | 必填Yes | HMAC-SHA256 签名串 (Base64)HMAC-SHA256 signature (Base64) |
路径参数 (Path Parameters) Path Parameters
| 参数名Field | 类型Type | 必填Required | 说明Description |
|---|---|---|---|
| clientRequestNo | string | 必填Yes | 调用方提交充值时的原始请求号Original client request number |
返回响应示例 (200 OK) Response Example (200 OK)
{
"success": true,
"code": 200,
"message": "查询成功",
"result": {
"orderNo": "RC202609070001",
"clientRequestNo": "APIFOX-20260915-0005",
"accountId": "333333",
"amount": 27,
"status": "SUCCESS",
"failReason": null,
"finishTime": "2026-09-15 10:20:30"
},
"timestamp": 1788786050000
}
按平台充值单号查询状态 Query Recharge by Platform Order No
接口说明 Endpoint Overview
- 查询维度:Lookup Scope: 调用方使用充值受理成功后返回的平台充值单号
orderNo查询该订单的处理状态与执行明细。Query execution status using the platform-issued order number. - 状态流转:Status Flow: 充值受理后状态为
PROCESSING(处理中),终态包括SUCCESS(充值成功)与FAILED(充值失败)。Status transitions fromPROCESSINGto final stateSUCCESSorFAILED. - 轮询建议:Polling: 建议调用方采用指数退避或合理时间间隔(如 1~3 秒)进行轮询,以避免高频无效请求。Polling interval of 1-3 seconds is recommended.
请求 Header 参数 Request Headers
| 参数名Header | 类型Type | 必填Required | 说明与示例Description & Example |
|---|---|---|---|
| X-App-Key | string | 必填Yes | 调用凭证 AppKeyAssigned AppKey |
| X-Timestamp | integer | 必填Yes | 当前时间戳(秒)Current timestamp (seconds) |
| X-Nonce | string | 必填Yes | 防重放随机字符串Anti-replay random string |
| X-Signature | string | 必填Yes | HMAC-SHA256 签名串 (Base64)HMAC-SHA256 signature (Base64) |
路径参数 (Path Parameters) Path Parameters
| 参数名Field | 类型Type | 必填Required | 说明Description |
|---|---|---|---|
| orderNo | string | 必填Yes | 平台充值订单号,如 RC202609070001Platform recharge order number |
返回响应示例 (200 OK) Response Example (200 OK)
{
"success": true,
"code": 200,
"message": "查询成功",
"result": {
"orderNo": "RC202609070001",
"clientRequestNo": "APIFOX-20260915-0005",
"accountId": "333333",
"amount": 27,
"status": "SUCCESS",
"finishTime": "2026-09-15 10:20:30"
},
"timestamp": 1788786050000
}
批量账号充值提交 Batch Account Recharge Submission
接口说明 Endpoint Overview
- 批量提交与拆解:Batch Splitting: 支持一次性提交多个充值账户的充值指令。平台成功持久化受理后返回
202 Accepted,后台将自动拆解并并发执行各个子充值单。Submit multiple recharge items in one batch. Handled asynchronously with202 Accepted. - 批次幂等:Batch Idempotency: 批次重试需严格复用相同的业务批次号
batchNo。当遇到网络超时或不确定响应时,请勿更换批次号重试。Reuse the samebatchNowhen retrying a batch. - 子单独立性:Sub-order Isolation: 批次内各子单独立执行,部分子单失败不会影响其余子单的正常充值。Sub-orders are executed independently; failure in one item does not affect others.
请求 Header 参数 Request Headers
| 参数名Header | 类型Type | 必填Required | 说明与示例Description & Example |
|---|---|---|---|
| X-App-Key | string | 必填Yes | 调用凭证 AppKeyAssigned AppKey |
| X-Timestamp | integer | 必填Yes | 当前时间戳(秒)Current timestamp (seconds) |
| X-Nonce | string | 必填Yes | 防重放随机字符串Anti-replay random string |
| X-Signature | string | 必填Yes | HMAC-SHA256 签名串 (Base64)HMAC-SHA256 signature (Base64) |
| Content-Type | string | 必填Yes | application/json |
请求 Body (application/json) Request Body (application/json)
| 参数名Field | 类型Type | 必填Required | 说明Description |
|---|---|---|---|
| batchNo | string | 必填Yes | 批次业务请求号(调用方生成)Client-generated batch number |
| items | array | 必填Yes | 充值子项明细列表Recharge item details array |
| └─ subRequestNo | string | 必填Yes | 子单调用方请求号Sub-order request number |
| └─ accountId | string | 必填Yes | 充值账户 IDAccount ID |
| └─ amount | number | 必填Yes | 充值金额Amount |
{
"batchNo": "BATCH-20260915-001",
"items": [
{
"subRequestNo": "REQ-001",
"accountId": "333333",
"amount": 50
},
{
"subRequestNo": "REQ-002",
"accountId": "444444",
"amount": 100
}
]
}
返回响应 (202 Accepted) Response (202 Accepted)
{
"success": true,
"message": "批量充值已持久化受理",
"code": 202,
"result": {
"platformBatchNo": "BAT20260915000001",
"batchNo": "BATCH-20260915-001",
"totalCount": 2,
"status": "PROCESSING"
},
"timestamp": 1788786100000
}
按批次业务号查询整批充值状态 Query Batch Recharge Status
接口说明 Endpoint Overview
- 批次状态聚合:Aggregation: 根据批量提交时传入的业务批次号
batchNo查询整批明细的处理进度,包括总笔数、成功笔数、失败笔数及整批终态。Query total, success, and failed counts along with batch final state. - 子单明细列表:Sub-orders Details: 返回结果中的
details数组包含每个子请求号对应的平台单号、充值账户、充值金额以及各自的执行状态。Thedetailsarray provides the status of every sub-item.
请求 Header 参数 Request Headers
| 参数名Header | 类型Type | 必填Required | 说明与示例Description & Example |
|---|---|---|---|
| X-App-Key | string | 必填Yes | 调用凭证 AppKeyAssigned AppKey |
| X-Timestamp | integer | 必填Yes | 当前时间戳(秒)Current timestamp (seconds) |
| X-Nonce | string | 必填Yes | 防重放随机字符串Anti-replay random string |
| X-Signature | string | 必填Yes | HMAC-SHA256 签名串 (Base64)HMAC-SHA256 signature (Base64) |
路径参数 (Path Parameters) Path Parameters
| 参数名Field | 类型Type | 必填Required | 说明Description |
|---|---|---|---|
| batchNo | string | 必填Yes | 批量充值提交的业务批次号Batch number |
返回响应示例 (200 OK) Response Example (200 OK)
{
"success": true,
"code": 200,
"message": "查询成功",
"result": {
"batchNo": "BATCH-20260915-001",
"platformBatchNo": "BAT20260915000001",
"totalCount": 2,
"successCount": 2,
"failCount": 0,
"status": "COMPLETED",
"details": [
{
"subRequestNo": "REQ-001",
"orderNo": "RC202609150001",
"accountId": "333333",
"amount": 50,
"status": "SUCCESS"
},
{
"subRequestNo": "REQ-002",
"orderNo": "RC202609150002",
"accountId": "444444",
"amount": 100,
"status": "SUCCESS"
}
]
},
"timestamp": 1788786200000
}
充值状态变更回调通知 (Webhook) Recharge Status Webhook Notification
接口说明 Endpoint Overview
- 触发机制:Trigger Mechanism: 当充值订单状态发生变更(成功或失败)时,平台将主动向调用方配置的回调地址发起 HTTP POST 请求,推送充值终态数据及签名认证信息。 When a recharge order reaches a final state (SUCCESS or FAILED), the platform sends an HTTP POST push to your configured callback endpoint.
-
重试机制:Retry Policy:
回调通知共重试 12 次。第 1 次为即时推送;若响应非 2xx 或网络超时,后续各次重试的延迟时间间隔依次为:
10秒、30秒、1分钟、5分钟、15分钟、30分钟、1小时、3小时、6小时、12小时、24小时。若 12 次重试均失败,则后续不会再发起推送。 Webhook notifications retry up to 12 times. 1st attempt is immediate. If non-2xx response or timeout occurs, subsequent retry delays are:10s, 30s, 1m, 5m, 15m, 30m, 1h, 3h, 6h, 12h, 24h. If all 12 attempts fail, no further push will be made.
请求 Header 参数 Request Headers
| 请求头 (Header)Header | 类型Type | 必填Required | 说明与示例Description & Example |
|---|---|---|---|
| Content-Type | string | 必填Yes | application/json; charset=utf-8 |
| X-App-Key | string | 必填Yes | 调用方分配的 App KeyClient App Key |
| X-Timestamp | integer | 必填Yes | 推送请求时间戳(秒)Push timestamp (seconds) |
| X-Nonce | string | 必填Yes | 防重放随机字符串Anti-replay random string |
| X-Event-Id | string | 必填Yes | 回调事件唯一标识 ID,示例: evt_2100831915776983042_SUCCESSUnique event ID for deduplication |
| X-Signature | string | 必填Yes | HMAC-SHA256 签名串 (Base64)。签名生成规则与 API 签名生成规则一致,但 secret 使用回调密钥 HMAC-SHA256 signature (Base64). Same canonical calculation rules as API requests, but signed with the dedicated Callback Secret. |
请求 Body (application/json) Request Body (application/json)
| 参数名Field | 类型Type | 必填Required | 说明与示例Description & Example |
|---|---|---|---|
| eventId | string | 必填Yes | 回调事件唯一 IDUnique event ID |
| eventType | string | 必填Yes | RECHARGE_STATUS_CHANGED |
| appKey | string | 必填Yes | 接收方的 App KeyReceiver App Key |
| customerId | string | 必填Yes | 客户编号Customer / Merchant ID |
| orderNo | string | 必填Yes | 平台充值订单号Platform recharge order number |
| clientRequestNo | string | 必填Yes | 调用方提交充值时的原始请求号Original client request number |
| accountId | string | 必填Yes | 充值目标账户 IDTarget account ID |
| amount | number | 必填Yes | 实际充值金额Recharge amount |
| status | string | 必填Yes | SUCCESS / FAILED |
| failureCode | string | 可空Nullable | 失败错误码(成功时为 null)Failure error code (null on success) |
| failureReason | string | 可空Nullable | 失败原因描述(成功时为 null)Failure description (null on success) |
| occurredAt | string | 必填Yes | 状态变更时间(ISO-8601)Event timestamp (ISO-8601) |
Body JSON Sample:
{
"eventId": "evt_2100831915776983042_SUCCESS",
"eventType": "RECHARGE_STATUS_CHANGED",
"appKey": "meta_E-HNGb7FfzM916trGCWiA9dB",
"customerId": "93",
"orderNo": "2100831915776983042",
"clientRequestNo": "APIFOX-20260908-00874",
"accountId": "c9dabd2aa2a311f1b5b60242c0a80002",
"amount": 1,
"status": "SUCCESS",
"failureCode": null,
"failureReason": null,
"occurredAt": "2026-09-18T14:23:48.777+08:00"
}