Skip to main content
A capture is rejected, or succeeds at the HTTP level but the acquirer declines it.
TL;DR — 422 means fix the window or amount and don’t retry as-is; a 200 with the authorization row unchanged (still AUTHORIZED) is an ordinary acquirer decline, not an error.

When this happens

  • You captured after the capture window closed (7 days by default) — 422 urn:radiumone:tx:capture-window-expired, and the authorization has already lapsed to AUTH_EXPIRED.
  • Your capture amount doesn’t exactly equal the authorized amount — 422 urn:radiumone:tx:capture-amount-mismatch. Partial capture isn’t supported in this API version.
  • The authorization expired mid-flight, between your check and your capture call (an automatic expiry job raced your request) — 409 urn:radiumone:tx:auth-expired-during-capture.
  • The acquirer itself declines the capture — this is a normal 200 response, but the response is the authorization row unchanged (still status: "AUTHORIZED"), not a new row and not "FAILED". The HTTP body alone can’t tell you the capture failed — watch for authorization.capture_declined / authorization.capture_failed.

What you see

What to do

1

Capture the exact authorized amount, within the window

Send amount equal to the authorization’s amount, before the capture window closes (API reference):
2

If the window already expired, start over

A 422 capture-window-expired (or an AUTH_EXPIRED transaction) can’t be captured — create a new authorization instead. See Capture an authorization: the capture window.
3

If the amount mismatched, fix the amount — don't retry as-is

422 capture-amount-mismatch means you sent the wrong figure. If you need to charge less than the authorization, capture the full amount and refund the difference once the batch closes, or void and re-authorize for the right amount.
4

Treat an acquirer-declined capture like any other decline

A 200 with the authorization’s status unchanged (still AUTHORIZED, not a new CAPTURED or FAILED row) isn’t a system error — it means the capture didn’t go through. Confirm via the authorization.capture_declined / authorization.capture_failed webhook and follow Handle declined payments for how to message it; retry with a new operation_id only after you’ve confirmed the decline.

Test it

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

Capture an authorization

The full-capture rule and the capture window.

Payment lifecycle

How AUTH_EXPIRED fits into the lifecycle.

Payment operation errors

The full URN catalog for transaction-state errors.
Last modified on September 15, 2026