> ## 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.

# Versioning and deprecation - Resources

> How RadiumOne versions the Payments API, hosted checkout, the Elements SDK, and webhook payloads, and where to track releases.

export const docsVersion = "1.0.3";

export const docsReleaseDate = "2026-09-16";

Every product in this documentation versions independently. Current versions and their status:

| Product | Version | Status |
| - | - | - |
| Payments API | v1 | <Badge color="green">Live</Badge> |
| Hosted checkout API | v1 | <Badge color="green">Live</Badge> |
| Elements SDK | 1.6.0 | <Badge color="green">Live</Badge> |

## Payments API and hosted checkout API

Both APIs are versioned in the URL path (`/v1/...`). A version stays stable for the fields and behavior documented here; additive changes (new optional fields, new enum values, new endpoints) ship within `v1` without a version bump. A breaking change — removing a field, changing a field's type, or changing default behavior — ships as a new path version, never as a silent change to `v1`.

## Elements SDK

The Elements SDK follows semantic versioning (`major.minor.patch`). Pin to a specific version (or a `major` range once you've verified compatibility) rather than always loading `latest`, so an SDK release can't change your integration's behavior without your action. A pre-release version (for example a `-beta.N` suffix) may change before general availability — see the [Beta notice](/get-started/choose-your-integration) on any Beta page.

## Webhook payloads

Every webhook envelope carries `payload_version: "v1"`. This is independent of the Payments API path version — check `payload_version`, not the API version, if you branch on webhook payload shape.

## Deprecation policy

RadiumOne's deprecation notice period and SDK support window (how long an older major SDK version keeps receiving fixes after a new major ships) are still being finalized. Until then, [contact support](/resources/support) to check on the status of a specific deprecation.

## Track releases

The version table above reflects each product's current status. [Contact support](/resources/support) for details on a specific release.

## Next steps

<Columns cols={2}>
  <Card title="Go-live checklist" icon="clipboard-check" href="/resources/go-live-checklist">
    Confirm you're ready before you switch a product's integration to production.
  </Card>

  <Card title="Support" icon="life-buoy" href="/resources/support">
    Ask about a specific version or deprecation timeline.
  </Card>
</Columns>