Skip to main content
RadiumOne doesn’t expose a general list or get-by-ID endpoint for transactions. The one merchant-facing read is a live status inquiry: given a transaction 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_id to recover the id — see Handle timeouts and unknown outcomes.
  • A transaction is PENDING and you want to check whether it’s resolved instead of waiting for the webhook.
If you don’t have a transaction 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

API reference.
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_id is the only way to recover a transaction id you 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 id and 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.
See Handle timeouts and unknown outcomes for the full recovery walkthrough, and Webhook event types for the events that carry the same outcome asynchronously.

Errors

  • 404 — no transaction with that id on your merchant account
  • gateway: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.
Last modified on September 15, 2026