Skip to main content
Every purchase, authorization, capture, void, and refund is a transaction with its own status. This page is the map: what each status means, what moves a transaction between them, and where settlement and reversals fit in.

​
How it works

  1. A purchase or authorize request starts a transaction as PENDING.
  2. It resolves to AUTHORIZED (authorize) or CAPTURED (purchase), or ends immediately as DECLINED or FAILED.
  3. An AUTHORIZED transaction is captured (→ CAPTURED), voided (→ VOIDED), or lapses (→ AUTH_EXPIRED) if it isn’t captured in time.
  4. A CAPTURED transaction can still be voided while its settlement batch is open, or moves on into settlement (SUBMITTED → SETTLING → SETTLED).
  5. Once SETTLED, a refund creates a new transaction rather than changing this one.
  6. If an authorize, capture, void, or referenced refund request times out and its outcome at the processor is unknown, RadiumOne reverses it automatically (REVERSAL_PENDING → REVERSED) rather than leaving it FAILED — no merchant action needed.

​
Statuses

A decline is a normal 2xx response with data.status: "DECLINED", not an HTTP error — see Charge or authorize a payment.

​
FAILED, and what it does and doesn’t mean

FAILED means the transaction did not complete — either the acquirer returned a non-decline error code, or RadiumOne couldn’t place the request at all. It is not a guarantee that no funds moved. VOIDED and REVERSED are the only statuses that positively assert no money moved. When the outcome is genuinely unknown after an upstream timeout, RadiumOne never leaves the transaction FAILED — it sets REVERSAL_PENDING and issues a compensating reversal automatically (see Understand automatic reversals). Mechanically: an acquirer response code of 00 approves. A defined set of decline codes map to DECLINED. Every other non-00 code — including gateway- or host-level errors such as 91, 96, or 99 — maps to FAILED. This is why a FAILED result should always be confirmed with status inquiry rather than assumed to be a simple decline. INCONSISTENT is a rare row-level exception state, not the same thing as a settlement-batch rollup being indeterminate — if you ever see an unexpected aggregate state at the batch level, treat it the same way: contact support rather than guessing at the underlying transaction states.

​
Void or refund — not both

Void while the settlement batch is OPEN. Refund once it’s CLOSED. You can’t do either the other way around:
  • Voiding a transaction whose batch has already closed returns 409 urn:radiumone:tx:void-on-non-open-batch.
  • Refunding a transaction whose batch is still open returns 409 urn:radiumone:tx:refund-on-open-batch.
The boundary is the settlement batch closing, not the card network settling with the issuer. Check GET /v1/transactions/{id}/status or a settlement.* webhook if you’re unsure which state you’re in. See Resolve void and refund conflicts if you hit either error.

​
Settlement stages

Captured funds move through a settlement batch: SUBMITTED (queued), SETTLING (in progress at the acquirer), SETTLED (funds moved). See Settlement and reconciliation for batch webhooks and reconciliation.

​
Reversals

A REVERSAL_PENDING → REVERSED transition happens automatically when a processor times out after your transaction was already submitted for settlement. You don’t request a reversal — RadiumOne resolves it and reports the final state through a webhook. Treat REVERSAL_PENDING as “wait,” not as a failure.

​
Authorization expiry

An AUTHORIZED transaction that isn’t captured within the capture window (7 days by default, configurable per acquirer) automatically lapses to AUTH_EXPIRED. Capturing after that point fails with 422 urn:radiumone:tx:capture-window-expired — create a new authorization instead.

​
Next steps

Capture an authorization

Capture within the window, for the full authorized amount.

Void a payment

Release an authorization or reverse a capture while the batch is open.

Refund a payment

Return funds after the batch closes.

Settlement and reconciliation

Track batches end to end with webhooks.
Last modified on September 15, 2026