Endpoint
POST /v3/refunds/status/check
Authentication and target
Use an account credential for its bound account, or a user credential with bothX-ISPB and X-Account-Number. If an account credential sends those headers, both must be present and must match its bound account. Platform credentials are not accepted. All requests require the standard HMAC-SHA256 headers.
The curl example below uses an ACCOUNT credential bound to the operated account, so it omits X-ISPB and X-Account-Number. If X-Client-ID identifies a USER credential, add both target headers and include their exact trimmed values in the canonical header set before calculating X-Signature.
Request body
Success data
The refund identifier and numeric transaction status. Status values are1 PENDING, 2 COMPLETED, 3 FAILED, 4 CANCELLED, 5 PROCESSING, 6 REFUNDED, 7 PARTIALLY_REFUNDED, and 8 DISPUTED.
Behavior and validation
Despite its name, this POST operation is not read-only: it can acquire a lock, query the payment rail, and persist a refreshed status. The original payer can see every state. For a recipient-side lookup that has not reached COMPLETED, the service can return a generic processing view. Poll with a fresh nonce on each request.Errors
Every call can fail for missing or invalid signature headers, an expired timestamp, nonce replay, an invalid body hash or signature, insufficient permission, or a downstream service error. Endpoint-specific errors include:4000for a missing refund ID.4003003when the refund is missing or inaccessible.501for status-query transport failure and mapped upstream errors.