Skip to main content
A referenced refund returns money against a specific prior transaction, once its settlement batch has closed. It’s the normal way to refund a payment you (or the shopper) originated.

Refunds require enablement

Unlike most gateways, refunds are disabled by default on RadiumOne. This applies to both a referenced refund (this page) and a standalone refund — the acquirer channel your outlet routes through must have the REFUND operation explicitly enabled before either call succeeds. Without it, a referenced refund fails with 422 urn:radiumone:routing:capability-not-supported.
This request requires a valid access token. See Authentication to obtain one with POST /v1/auth/token before you continue.
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.

Partial and multiple refunds

Send an amount up to the original transaction’s amount minus any prior refunds already issued against it. You can refund the same transaction more than once — for example, refunding one line item now and another later — as long as the running total never exceeds the original amount.
Amounts are always integers in the currency’s minor unit. For example, 5000 for SGD means SGD 50.00.

Refund is a new transaction

A referenced refund creates its own transaction record with its own id and its own CAPTURED status on success — it doesn’t change the status of the original payment. Look up the refund by the id returned in the response, not by the original transaction’s id.

Steps

1

Refund the transaction

Send the original transaction’s id, a request_id for this refund attempt, and the amount to return. API reference.
If the call times out, see Handle timeouts and unknown outcomes. If it conflicts with the batch state or the remaining amount, see Resolve void and refund conflicts.

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). A retry with the same request_id is always replayed — you get the stored refund back, whatever its status, including DECLINED or FAILED. This is checked before any of the refund gates (batch state, window, cap) run, so a changed refundable amount since your first call never turns a replay into a 422. The match is: the same original transaction, the same amount, and a key that was previously used for a refund — reason isn’t compared. Any other reuse of the key (a different original transaction, a different amount, or a key already used for something other than a refund) returns 409 urn:radiumone:transaction:idempotency-body-mismatch instead of replaying.
Because a DECLINED or FAILED refund replays too, retrying the same request_id after a decline just returns the same decline again — it never becomes a second attempt. To genuinely retry after a declined or failed refund, mint a new request_id.
A wrong transaction_id in the path always returns 404, even if the request_id matches a stored refund — the 404 takes precedence over the replay.

Errors

Full HTTP status and meaning for each of these is defined once on Problem format and retries — this list is only the refund-specific nuance:

No original transaction to reference?

If you need to credit a card without a prior RadiumOne transaction, see Standalone refunds — a high-risk, separately gated operation.

Test your integration

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

Go-live notes

  • Request refund enablement for every acquirer channel you plan to refund through — it isn’t on by default, and there’s no self-service toggle. See Request enablement.
  • Refund only after you’ve confirmed the batch closed — check status or wait for a settlement.* webhook.
  • Track how much you’ve already refunded against a transaction; the gateway enforces the cap, but your own reconciliation should too.
  • Review the full go-live checklist.

Next steps

Standalone refunds

Credit a card with no original transaction — high-risk, gated.

Settlement and reconciliation

Confirm when a batch closes before you refund.
Last modified on September 15, 2026