id you already have, RadiumOne asks the original acquirer for its current status and returns it — without writing anything.
This request requires a valid access token. See Authentication to obtain one with
POST /v1/auth/token before you continue.When to use it
- You have a transaction
id(from a create response, a replay, or a webhook) and want its current status before you decide what to do next. - A create-type call timed out and you’ve already replayed it with the same
request_id/operation_idto recover theid— see Handle timeouts and unknown outcomes. - A transaction is
PENDINGand you want to check whether it’s resolved instead of waiting for the webhook.
id yet, status inquiry can’t help — replay the original request with the same idempotency key first, or wait for the confirming webhook.
Steps
1
Query the transaction's status
2
Key the outcome on data.success
data.success (a boolean) is the field to branch on. data.status ("success"/"failed") is a convenience label derived purely from whether the acquirer’s response_code is "00" — it doesn’t consult the decline-code catalog the way data.success does, so in rare cases the two can disagree (an operator-catalogued approval on a non-"00" code reports data.success: true with data.status: "failed"). Never derive the outcome from data.response_code alone; that’s the verbatim acquirer code, for display and reconciliation only.Response fields
Relation to webhooks and replay
Status inquiry, webhooks, and replaying the same idempotency key are the three ways to learn a transaction’s outcome — reach for whichever fits the moment:- Replay with the same
request_id/operation_idis the only way to recover a transactionidyou never received — for example, a client-side timeout before the first response arrived. The replay returns the stored result, whatever it is. - Status inquiry is the safest tool once you already have an
idand want a live read against the acquirer. It’s read-only, so calling it repeatedly is always safe, and it needs no idempotency key of its own. - Webhooks push the eventual outcome to your server without polling. Prefer them for routine updates, and reserve status inquiry for on-demand recovery rather than scheduled polling.
Errors
404— no transaction with thatidon your merchant accountgateway:validation-error— the transaction has no acquirer snapshot to query (very old or unrouted rows)
Test your integration
See Test your integration for simulated timeout and status-inquiry scenarios.Go-live notes
- Use status inquiry for recovery, not routine polling — prefer webhooks for updates you don’t need on demand.
- Build the retry-with-same-key + status-inquiry path before you go live, not during your first production incident.
- Review the full go-live checklist.
Next steps
Handle timeouts and unknown outcomes
The full recovery walkthrough after a timed-out request.
Webhooks
Get transaction updates pushed to your server instead of polling.