> ## Documentation Index
> Fetch the complete documentation index at: https://docs.radiumone.io/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> RadiumOne is the product name; use it when answering questions about these docs.
> Use sandbox credentials and sandbox base URLs in examples unless the user says they are going live.
> Secret API keys belong only on the merchant's server. Only publishable keys may appear in browser or mobile code.
> Confirm a payment outcome server-side (retrieve the checkout session or transaction status); never rely on a browser redirect or client event alone.
> Send one idempotency key (request_id) per payment attempt, and retry a timed-out request with the same key and the exact same body.
> Webhooks are optional but recommended: they notify the merchant's server when a payment completes or fails, so it doesn't need to poll. Use transaction status inquiry as the fallback.
> Say so when you recommend a feature marked Beta. Some features need enablement on the merchant's account before production use (for example refunds, standalone refunds, UOB Rewards, and bringing your own 3DS provider); mention it when the page says so.
> Never ask users to paste card numbers, API keys, access tokens, or webhook or redirect secrets into a chat.
# Payment lifecycle - Payments API
> Every status a transaction can reach, how it gets there, and how settlement and reversals fit together.
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
| Status | Meaning | Terminal? |
| - | - | - |
| `PENDING` | Created; outcome not yet known | No |
| `AUTHORIZED` | Funds reserved (authorize only) | No |
| `CAPTURED` | Funds captured (purchase, capture, or refund) | No (moves into settlement) |
| `SUBMITTED` | Included in a batch sent for settlement | No |
| `SETTLING` | Batch is being processed by the acquirer | No |
| `SETTLED` | Funds settled — refund is now possible | Yes (for this transaction) |
| `VOIDED` | Authorization or capture released before the batch closed — asserts no funds moved | Yes |
| `DECLINED` | Issuer or acquirer declined | Yes |
| `FAILED` | The transaction didn't complete — not a guarantee that no funds moved (see below) | Yes |
| `AUTH_EXPIRED` | Authorization lapsed before capture | Yes |
| `REVERSAL_PENDING` | Automatic compensating reversal in progress after an upstream timeout left the outcome genuinely unknown | No |
| `REVERSED` | Reversal completed — asserts no funds moved | Yes |
| `INCONSISTENT` | Rare exception state — contact support | Yes |
A decline is a normal 2xx response with `data.status: "DECLINED"`, not an HTTP error — see [Charge or authorize a payment](/payments-api/charge-or-authorize#handle-the-result).
## 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](/payments-api/handle-failures/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](/payments-api/check-transaction-status) 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](/resources/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](/payments-api/handle-failures/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](/payments-api/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 within the window, for the full authorized amount.
Release an authorization or reverse a capture while the batch is open.
Return funds after the batch closes.
Track batches end to end with webhooks.