Endpoint
POST /v3/refunds/details
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
Supply at least one identifier.Success data
The mapper-populated refund detail fields, including refund and settlement IDs, merchant order ID, decimal-string amount, numeric status, memo/reason, parties when available, and original settlement reference.Behavior and validation
The lookup is account-scoped. The original payer can view refund records across states; the recipient-side view is more restricted. Receiver information is populated only for completed refunds. Treat omitted generated fields as unpopulated, not as additional guarantees.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:4000when both identifiers are absent.4003003when the refund does not exist or is outside the caller’s accessible account scope.501for transaction-query transport failure and mapped upstream errors.