Skip to main content
A call returns 503 or 500 with no business meaning behind it — a dependency was down, or something failed unexpectedly on RadiumOne’s side.
TL;DR — 503/500 on a create-type request behaves like a timeout: retry with the same idempotency key, with backoff — never a new one.

​
When this happens

  • 503 urn:radiumone:gateway:service-unavailable — a downstream service RadiumOne depends on is unreachable.
  • 503 urn:radiumone:gateway:vault-unavailable — the encryption-key service backing card tokenization is unavailable. RadiumOne returns this generic form deliberately, without leaking which key or vault path failed.
  • 500 urn:radiumone:gateway:internal-error — an unexpected failure that isn’t one of the above.

​
What you see

These URNs don’t all carry an explicit retry_allowed extension. Treat any 503/500 on a create-type request the same as a timeout — retry with the same idempotency key, never a new one, because the request may have partially processed before the failure surfaced.

​
What to do

1

Check for a retry signal first

If the error body carries retry_allowed, or the response has a Retry-After header, honor it directly — see Problem format and retries: retry rules.
2

Otherwise, branch on URN and retry_allowed, never on the HTTP code alone

Any 2xx response is a result you must branch on status — never on response_code (that’s the verbatim host/acquirer code; useful for support tickets, not for your app logic).
Balance inquiry also takes a request_id field, but it isn’t an idempotency key — there’s no dedup or replay store. Every call re-queries the rewards host, even with the same request_id.
Keys are 8–64 characters, [a-zA-Z0-9-] only, unique per merchant account. Generate one key per order attempt and persist it to your database before you send the first request — never mint a new key just to retry the same attempt. See Prevent duplicate payments.
PENDING means the outcome isn’t known yet — most often after a processor timeout. Don’t assume success or failure. Recover it one of two ways:
  1. Wait for a webhook (payment.*, authorization.*, refund.* — see Webhook event types).
  2. Call GET /v1/transactions/{id}/status for a live inquiry against the acquirer.
If you don’t have the transaction id yet — a client-side timeout before the first response arrived — replay the same request with the same request_id and body. The replay returns the stored transaction and its id, whatever status it’s reached. Never re-submit with a new idempotency key just because the first attempt is slow — that risks a second charge for the same order.
3

Retry with backoff, using the same key

Retry a purchase/authorize/refund with the same request_id, or a capture/void with the same operation_id. Add jittered backoff between attempts rather than retrying immediately.
4

Fall back to timeout handling if retries don't resolve it

If the outcome still isn’t clear after a retry, follow Handle timeouts and unknown outcomes — wait for the confirming webhook (recommended), or check status now if you don’t use webhooks or need an answer sooner, rather than continuing to retry indefinitely.

Problem format and retries

The full retry-rules reference.

Handle timeouts and unknown outcomes

The idempotent-retry pattern this page reuses.
Last modified on September 15, 2026