Skip to main content
Once the shopper has chosen what to redeem (see Check a rewards balance), send one purchase request with the gross order amount and the redemption. RadiumOne redeems the points first, then charges the card for the residual — your server never calls a separate “redeem” endpoint.

How it works

  1. Your server creates an access token, then a session.
  2. The shopper enters their card and the browser tokenizes it with Elements.
  3. Your server sends the token to check the rewards balance.
  4. Your server sends one purchase with the gross amount and the loyalty block. RadiumOne redeems the points, then authorizes and captures the card for whatever remains.
This request requires a valid access token. See Authentication to obtain one with POST /v1/auth/token before you continue.

The amount is always gross

amount on the purchase is the gross order total, the same figure you’d send without any redemption. RadiumOne deducts the redeemed value — you never send the net amount yourself. Sending the net amount double-deducts the redemption.
Amounts are always integers in the currency’s minor unit. For example, 5000 for SGD means SGD 50.00.

Steps

1

Send the purchase with the loyalty block

Include the vouchers (and/or point_redeem_amount) the shopper selected from the balance inquiry, respecting each voucher’s max_redeemable. API reference.

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. The presence of a loyalty block in the response is your outcome signal. If it’s absent, no points moved and the card was charged in full — treat it exactly like a normal card purchase.

Outcomes

See Handle UOB Rewards redemption failures for the full walkthrough on each outcome above.
A degraded outcome isn’t an error response — it’s a normal 201 with status: "AUTHORIZED" and no loyalty block. If your integration only checks for a loyalty block on success, make sure you still capture or void the authorization; an uncaptured authorization will expire on its own capture-window timer, which may not be what you want for a completed order.

Webhooks

The webhook payload adds loyalty-specific fields alongside the usual transaction data: data.transaction.leg (PAYMENT or LOYALTY) and data.transaction.redemption (status, card_amount, points_amount). Branch on redemption.status independently of the transaction status — a declined redemption is a warning, not a failed payment. See Webhook event types for the full payload reference.

Test your integration

See Test your integration for partial, full, degraded and timeout scenarios.

Go-live notes

  • Confirm enablement (see the checklist) for your production outlet before relying on this in production.
  • Add monitoring for degraded (AUTHORIZED, no loyalty block) outcomes so an uncaptured authorization doesn’t go unnoticed.
  • Review the go-live checklist.

Next steps

Refunds and cancellations

What you can and can’t do after a redeemed sale.

Rewards with 3D Secure

Combining a redemption with 3DS — coming soon.
Last modified on September 15, 2026