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.
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 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.
id. An optional reason (up to 200 characters) is stored for your own records. 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.
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:tx:void-on-non-open-batch— refund insteadtransaction:single-leg-void-forbidden— see Pay with pointsgateway:validation-errortx:duplicate-operation— the sameoperation_idreused for a different operation on this transaction (e.g. a capture)
Reversal-pending
If a void races a processor timeout during batch submission, the transaction may instead resolve through the automaticREVERSAL_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.