Skip to main content
Capture converts a reserved authorization into captured funds. In this version of the API, capture is all-or-nothing: the amount you send must equal the original authorized amount.
This request requires a valid access token. See Authentication to obtain one with POST /v1/auth/token before you continue.

Full-capture rule

amount in the capture request must equal the amount on the AUTHORIZED transaction exactly. Partial capture isn’t supported — if you need to charge less than the authorization, capture the full amount and refund the difference once the batch closes, or void the authorization and create a new one for the correct amount. amount.currency must also match the authorization’s currency — a capture naming a different currency is refused with 422 urn:radiumone:tx:currency-mismatch.

The capture window

Capture within your account’s capture window, which defaults to 7 days from authorization and can be configured shorter or longer per acquirer. Capturing after the window closes fails with 422 urn:radiumone:tx:capture-window-expired, and the transaction moves to AUTH_EXPIRED — see Payment lifecycle. Contact support to confirm your account’s configured window.

Steps

1

Capture the authorization

Send the transaction’s id and the same amount it was authorized for. API reference.
If the call times out, see Handle timeouts and unknown outcomes. If it fails with a window, amount, or expiry error, see Handle capture failures.

Handle the result

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. Capture responses are 200, including retries — a replayed capture with the same operation_id returns the same 200 result as the first attempt. On a network timeout or 5xx, retry with the same operation_id; never mint a new one for the same capture attempt.
operation_id replays never compare the request body. A retry with the same operation_id returns the original captured result even if the amount you sent this time is different — the original amount wins, silently. Use a new operation_id for a genuinely new operation. Reusing a capture’s operation_id for a void on the same transaction is rejected with 409 urn:radiumone:tx:duplicate-operation, not treated as a replay.

Errors

Full HTTP status and meaning for each of these is defined once on Problem format and retries — this list is only the capture-specific nuance:

Webhook

A successful capture emits payment.captured. A capture that fails at the acquirer emits authorization.capture_declined or authorization.capture_failed — see Webhook event types.

Test your integration

See Test your integration for capture-window and decline scenarios.

Go-live notes

  • Capture as soon as you can fulfil — don’t hold authorizations open longer than necessary.
  • Retry a timed-out capture with the same operation_id; check GET /v1/transactions/{id}/status if you’re unsure whether it went through.
  • Review the full go-live checklist.

Next steps

Payment lifecycle

See how capture fits into the full transaction lifecycle.

Void a payment

Release funds instead of capturing them.
Last modified on September 15, 2026