Skip to main content
POST
cURL
This feature is in Beta. Behavior may change before general availability, and production access depends on your RadiumOne rollout. Contact support to confirm availability for your account.
A standalone (open, unreferenced) refund sends money to a card with no original transaction to bound it — no amount cap, no time window, and no card-token matching against a prior sale. It’s the right tool for a goodwill credit or a refund whose original transaction lives outside RadiumOne, but it also means a mistaken or compromised call can send an arbitrary amount to an arbitrary card.
This is a high-risk operation. It’s disabled by default: it requires the separate transaction-refund-unreferenced scope on your access token (not included by default on a narrowly-scoped secret key, though it is included in a secret key’s full default scope set — see Authentication), and the terminal/acquirer must explicitly support it.
This is a high-risk operation. Follow these practices:
  • Least privilege: request a secret key scoped to only the operations it needs, not a key with every scope.
  • Key storage: store secret keys in a server-side secrets manager, never in client code, source control, or logs.
  • Emergency revocation: if a key is compromised, rotate or revoke it immediately — see Emergency key revocation.
  • Monitoring: monitor refunds and settlements for unexpected activity and alert on anomalies.

When to use a referenced refund instead

If the original charge exists in RadiumOne, use POST /v1/transactions/refund/{transaction_id} instead — it derives the card from the original transaction and enforces an amount cap, which closes off most of the risk above.

Request

Same shape as a purchase, minus 3DS and loyalty fields: request_id (idempotency key), amount, card, channel, plus optional order_reference, reason, and metadata.

Idempotency

Idempotent on request_id, with the same replay semantics as every other create-type operation — see Request conventions.

Guide and failure scenarios

See Standalone refunds for the full guide, and Handle replays and idempotency conflicts and Fix operations unavailable for your outlet for what can go wrong.

Authorizations

Authorization
string
header
required

Bearer access token from POST /v1/auth/token. Treat it as an opaque string — do not depend on its internal encoding, which has changed before and isn't part of the contract.

Body

application/json

Request body for POST /v1/transactions/refund -- credit a card with no original sale.

Use this to credit a card when there is no earlier transaction to refund against. It is shaped like a sale and is routed and settled the same way, only in the opposite direction. Because it is not tied to an original transaction there is no amount limit, no time window and no card check, so the ability to send one must be enabled for your account, your acquirer and the device -- all of which are off by default.

amount
MoneyAmount · object
required

Refund amount as a {currency, value} money object.

card
CardToken · object
required

Card group carrying the network token to credit (no raw PAN). Required: with no original to derive the card from, the caller must name it.

channel
enum<string>
required

Transaction channel -- the source or manner of the payment, used to route the refund. The acquirer must have standalone refunds enabled on this channel.

Available options:
CARD_PRESENT,
ECOMMERCE,
MOTO,
PAYMENT_LINK,
IN_APP,
RECURRING
request_id
string
required

Merchant idempotency key for the refund transaction.

Required string length: 8 - 64
metadata
Metadata · object | null

Optional merchant-supplied metadata (max 10 KB, max 5 depth levels).

order_reference
string | null

Merchant's own reference for this credit. Stored, searchable, and forwarded to the acquirer for reconciliation. Acquirers impose their own limits and character rules (commonly 20 characters, alphanumeric) and will shorten the value to fit, so prefer short references using letters, digits, '-', '.' and '_', and put the varying part LAST -- values are shortened from the front.

Maximum string length: 128
reason
string | null

Optional human-readable reason for the refund.

Maximum string length: 200

Response

Successful Response

Standard success envelope. Every successful response has this shape, with the operation's own payload under data.

data
TransactionResponse · object | null

The operation's result. Its shape is documented per operation; omitted on responses that carry no payload.

message
string | null

Optional human-readable note. Omitted from the response when not set, which is the case for every payment operation today. Never parse it.

request_id
string | null

Correlation ID for this HTTP request, for logs and support. Send your own in the X-Request-Id header (letters, digits and hyphens, up to 36 characters -- other characters are stripped) or the gateway generates one. This is NOT the request_id idempotency key you send in a transaction body; the two are unrelated.

status
string
default:ok

Always ok on a successful (2xx) response. Errors use a different body shape entirely (RFC 9457 problem details), so branch on the HTTP status code, not on this field.

Last modified on September 15, 2026