服务环境Environment
正式运行LIVE
https://api.blueglowdigital.com
* 官方正式环境 Base URL。各接口路径默认以此基地址进行调用。 * Official Production Base URL. All endpoint routes are mounted on this root path.
欢迎接入 BlueGlow Media 开放平台。本中心提供单账号/批量充值提交、订单与批次状态查询以及充值结果 Webhook 异步回调等全流程 OpenAPI。本文档记录了平台接口与规则的演进历程与最新变动。 Welcome to BlueGlow Media Open Platform. This portal provides full-lifecycle OpenAPI specifications for single/batch recharge submission, status queries, and asynchronous Webhook event notifications.

版本更新历史 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

平台所有 API 接口请求路径均需基于统一的正式基地址 (Base URL) 进行拼接。调用各接口前请确认使用以下正式环境地址: All API endpoint paths are mounted on the unified official Base URL. Please ensure all requests are dispatched to the following production host:
环境类型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 →

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 携带具体业务数据。 success is true, code is the HTTP status (202 for submit acceptance, 200 for queries), message is endpoint-specific (acceptance text for submit endpoints, not set/null for query endpoints), and result holds the business data.
  • 错误与链路追踪:Error & Trace Diagnostics: success 为 false,code 为对应 HTTP 状态码,message 为错误提示。对于业务处理/入参校验错误,result 包含业务错误枚举 errorCode 与 traceId;对于在请求进入业务处理前被拦截的授权、安全与限流拒绝,result 仅包含 errorCode,链路追踪 ID 统一通过响应头 X-Trace-Id 返回。 success is false, code is the HTTP status, and message is a human-readable description. For business/validation errors, result contains errorCode and traceId. For pre-API authentication/security/rate-limit rejections, result contains only errorCode, with the trace id returned in the X-Trace-Id HTTP response header.
  • 统一响应头:Global Tracing Header: 每个接口响应头中均包含 X-Trace-Id,联系平台技术支持时请提供该链路追踪 ID。 Every HTTP response includes an X-Trace-Id header. 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

此类校验在请求到达具体的充值业务前执行,作用于所有 API 接口。若未通过校验,请求将被拦截,返回统一响应结构,此时 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)

当充值业务规则校验未通过时,接口统一返回 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 请求均需要进行签名鉴权。调用方需要在 HTTP 请求头 (Header) 中携带相关认证参数和签名值。 To ensure request security and prevent tampering in transit, all API requests require HMAC-SHA256 signature authentication. Callers must provide authentication parameters and the calculated signature in HTTP request headers.

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));
}

接口说明 Endpoint Overview

  • 异步受理模式:Asynchronous Processing: 本接口为异步受理模式,调用返回 202 Accepted 表示平台已成功接收并持久化充值请求,后续充值状态请通过查询接口获取。 This endpoint operates asynchronously. A 202 Accepted response confirms persistence. Call query endpoints for final execution status.
  • 幂等与重试规范:Idempotency & Retries: 平台不提供自动重试机制;调用方发起网络重试时,必须复用相同的业务请求号 clientRequestNo,并重新生成当前时间戳、随机数 nonce 及对应的签名值。 When retrying due to timeouts, reuse the same clientRequestNo, but regenerate X-Timestamp, X-Nonce, and X-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
}

接口说明 Endpoint Overview

  • 查询维度:Lookup Scope: 调用方使用发起充值时提交的业务请求号 clientRequestNo 查询该订单的处理状态与执行明细。Query execution status using your original client request number.
  • 状态流转:Status Flow: 充值受理后状态为 PROCESSING(处理中),终态包括 SUCCESS(充值成功)与 FAILED(充值失败)。Status transitions from PROCESSING to final state SUCCESS or FAILED.
  • 轮询建议: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
}

接口说明 Endpoint Overview

  • 查询维度:Lookup Scope: 调用方使用充值受理成功后返回的平台充值单号 orderNo 查询该订单的处理状态与执行明细。Query execution status using the platform-issued order number.
  • 状态流转:Status Flow: 充值受理后状态为 PROCESSING(处理中),终态包括 SUCCESS(充值成功)与 FAILED(充值失败)。Status transitions from PROCESSING to final state SUCCESS or FAILED.
  • 轮询建议: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
}

接口说明 Endpoint Overview

  • 批量提交与拆解:Batch Splitting: 支持一次性提交多个充值账户的充值指令。平台成功持久化受理后返回 202 Accepted,后台将自动拆解并并发执行各个子充值单。Submit multiple recharge items in one batch. Handled asynchronously with 202 Accepted.
  • 批次幂等:Batch Idempotency: 批次重试需严格复用相同的业务批次号 batchNo。当遇到网络超时或不确定响应时,请勿更换批次号重试。Reuse the same batchNo when 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
}

接口说明 Endpoint Overview

  • 批次状态聚合:Aggregation: 根据批量提交时传入的业务批次号 batchNo 查询整批明细的处理进度,包括总笔数、成功笔数、失败笔数及整批终态。Query total, success, and failed counts along with batch final state.
  • 子单明细列表:Sub-orders Details: 返回结果中的 details 数组包含每个子请求号对应的平台单号、充值账户、充值金额以及各自的执行状态。The details array 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
}

接口说明 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"
}