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 with422 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 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.
id and the same amount it was authorized for. API reference.Handle the result
Any 2xx response is a result you must branch onstatus — never on response_code (that’s the verbatim host/acquirer code; useful for support tickets, not for your app logic).
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:
- Wait for a webhook (
payment.*,authorization.*,refund.*— see Webhook event types). - Call
GET /v1/transactions/{id}/statusfor a live inquiry against the acquirer.
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:tx:capture-window-expired— the authorization moves toAUTH_EXPIREDtx:capture-amount-mismatch— must equal the authorized amount exactly (see Full-capture rule)tx:currency-mismatchgateway:validation-errortx:duplicate-operation— the sameoperation_idreused for a different operation on this transaction (e.g. a void)
Webhook
A successful capture emitspayment.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; checkGET /v1/transactions/{id}/statusif 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.