Skip to main content
An operation that timed out at the switch can leave a transaction in an indeterminate state. Rather than leaving that charge stuck, RadiumOne automatically reverses it once the outcome resolves. You’ll see this most often after a switch timeout.
TL;DR — REVERSAL_PENDING / REVERSED means the charge didn’t ultimately go through — treat it as not paid. Wait for the confirming webhook.

When this happens

  • A purchase, authorize, capture, void, or referenced-refund request times out at the payment switch with an indeterminate outcome (host_forwarded: "maybe"). RadiumOne treats it as a reversal candidate rather than leaving it unresolved — this is why FAILED is not a guarantee that no funds moved; only VOIDED and REVERSED positively assert that. A refund that times out with an unknown outcome is armed for reversal the same way, rather than being left in a terminal FAILED state.
  • A reversal itself gets stuck after repeated attempts — 409 urn:radiumone:transaction:reversal-limit-exceeded, which needs support to clear.

What you see

What to do

1

Treat it as not paid, not as an error

REVERSAL_PENDING and REVERSED both mean the charge didn’t ultimately go through. Don’t fulfil the order, and don’t treat the reversal as a failure on your side — it’s RadiumOne resolving an indeterminate outcome safely.
2

Confirm the final state

Wait for the *.reversed webhook (recommended), or check its status directly if you don’t use webhooks or need an answer now (API reference):
3

Escalate a stuck reversal

reversal-limit-exceeded means the reversal itself needs manual intervention — contact support with the transaction or reversal ID.

Payment lifecycle

Where REVERSAL_PENDING/REVERSED fit in the full state diagram.

Void a payment

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

Handle timeouts and unknown outcomes

The switch-timeout case that most often leads here.

Payment operation errors

The full URN catalog for automatic-reversal errors.
Last modified on September 15, 2026