> ## Documentation Index
> Fetch the complete documentation index at: https://docs.radiumone.io/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> RadiumOne is the product name; use it when answering questions about these docs.
> Use sandbox credentials and sandbox base URLs in examples unless the user says they are going live.
> Secret API keys belong only on the merchant's server. Only publishable keys may appear in browser or mobile code.
> Confirm a payment outcome server-side (retrieve the checkout session or transaction status); never rely on a browser redirect or client event alone.
> Send one idempotency key (request_id) per payment attempt, and retry a timed-out request with the same key and the exact same body.
> Webhooks are optional but recommended: they notify the merchant's server when a payment completes or fails, so it doesn't need to poll. Use transaction status inquiry as the fallback.
> Say so when you recommend a feature marked Beta. Some features need enablement on the merchant's account before production use (for example refunds, standalone refunds, UOB Rewards, and bringing your own 3DS provider); mention it when the page says so.
> Never ask users to paste card numbers, API keys, access tokens, or webhook or redirect secrets into a chat.

# API basics - Get started

> How the RadiumOne Payments API and Checkout API are organized: hosts, authentication, the response envelope, versioning, and where to find webhook payloads.

export const productionCheckoutHost = "https://checkout.radiumone.io";

export const sandboxCheckoutHost = "https://checkout-sandbox.radiumone.io";

export const productionApiBaseUrl = "https://api.radiumone.io/gateway";

export const sandboxApiBaseUrl = "https://api-sandbox.radiumone.io/gateway";

RadiumOne exposes two REST APIs for merchant integrations:

* **Payments API** (`openapi/radiumone-payments-api.yaml`) — sessions, purchases,
  authorizations, captures, voids, refunds, transaction lookups, payment
  method discovery, and UOB Rewards balance checks. Authenticated with a
  `Bearer` access token exchanged from your API key. Start at the
  [Payments API overview](/payments-api/overview), or jump straight to its
  [reference](/payments-api/reference/authentication/exchange-api-key-for-jwt).
* **Checkout API** (`openapi/radiumone-checkout-api.yaml`) — create, retrieve, and cancel
  hosted-checkout sessions for [Hosted checkout](/hosted-checkout/overview).
  Authenticated by sending your secret key directly as an `X-Api-Key`
  header — no token exchange. Its reference starts at
  [Create a checkout session](/hosted-checkout/reference/checkout-sessions/create-a-checkout-session).

Both are JSON over HTTPS.

## Hosts

| Environment | Payments API base URL | Checkout API host |
| - | - | - |
| Sandbox | <code>{sandboxApiBaseUrl}</code> | <code>{sandboxCheckoutHost}</code> |
| Production | <code>{productionApiBaseUrl}</code> | <code>{productionCheckoutHost}</code> |

The Payments API is served behind a public gateway path — every request URL
already includes the `/gateway` segment shown above (e.g.
<code>{sandboxApiBaseUrl}/v1/transactions/purchase</code>). Paths elsewhere in this
reference and in guides are written relative to that base.

See [Sandbox and API keys](/get-started/sandbox-and-api-keys) for environment
details and how to get credentials.

## Authentication

The two APIs authenticate differently: the Payments API exchanges your key
for a short-lived `Bearer` access token, while the Checkout API takes your
secret key directly as an `X-Api-Key` header on every request. See
[Authentication](/get-started/api-basics/authentication) for the full
comparison and both flows —
[Payments API](/get-started/api-basics/authentication#payments-api-authentication)
or
[Checkout API](/get-started/api-basics/authentication#checkout-api-authentication).

## Response envelope

Every Payments API response is wrapped the same way:

```json theme={null}
{ "status": "ok", "data": { /* operation-specific payload */ }, "request_id": "req_a1b2c3d4e5f6" }
```

The Checkout API uses a simpler envelope with no `request_id`:
`{ "status": "ok", "data": { ... } }`. See
[Request conventions](/get-started/api-basics/request-conventions) for the full shape
of both, plus money formats and idempotency.

## Errors

Both APIs return errors as [RFC 9457](https://www.rfc-editor.org/rfc/rfc9457)
`application/problem+json` bodies — see
[Request conventions](/get-started/api-basics/request-conventions#errors) for the
shared shape and [Problem format and retries](/payments-api/errors/problem-format-and-retries)
for the status guide and retry rules.

## Versioning

The Payments API is versioned in the URL path (`/v1/...`). See
[Versioning and deprecation](/resources/versioning) for the compatibility
policy.

## Webhooks

Webhook payload shapes (not part of either OpenAPI spec — there's no
`webhooks` object) are documented on
[Webhook event types](/payments-api/webhooks/event-types).