How it works
- Your server creates an access token, then a session.
- The shopper enters their card and the browser tokenizes it with Elements.
- Your server sends the token to check the rewards balance.
- Your server sends one purchase with the gross
amountand theloyaltyblock. 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
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 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.
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.
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, noloyaltyblock) 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.