Skip to main content
Void cancels an AUTHORIZED or CAPTURED transaction before its settlement batch closes — no funds ever move (or captured funds are released before they settle).
This request requires a valid access token. See Authentication to obtain one with POST /v1/auth/token before you continue.

Void or refund, never 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 if you hit either error.

Steps

1

Void the transaction

Send the transaction’s id. An optional reason (up to 200 characters) is stored for your own records. API reference.
If the call times out, see Handle timeouts and unknown outcomes. If it conflicts with the batch state or an in-flight reversal, see Resolve void and refund conflicts and Understand automatic reversals.

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. Void responses are 200, including retries — a replayed void with the same operation_id returns the same 200 result. On a network timeout or 5xx, retry with the same operation_id.
operation_id replays never compare the request body — a retry with the same operation_id returns the original result even if something about the request differs. Use a new operation_id for a genuinely new operation. Reusing a void’s operation_id for a capture 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 void-specific nuance:

Reversal-pending

If a void races a processor timeout during batch submission, the transaction may instead resolve through the automatic REVERSAL_PENDING → REVERSED path described in Payment lifecycle. No action needed on your side beyond waiting for the confirming webhook.

Test your integration

See Test your integration for open-batch and closed-batch scenarios.

Go-live notes

  • Check the transaction’s status before voiding if you’re not sure whether its batch already closed.
  • Retry a timed-out void with the same operation_id, never a new one.
  • Review the full go-live checklist.

Next steps

Refund a payment

Reverse a payment once its batch has closed.

Payment lifecycle

See the full transaction state diagram.
Last modified on September 15, 2026