How it works
Components
- Your checkout page (browser) — the page you build; loads the SDK and mounts the card iframe.
- Your server — holds your secret key; creates sessions and charges tokens.
- CDN — serves the versioned, SRI-pinned SDK script.
- Card iframe (browser, RadiumOne-hosted) — the only place that ever sees the raw card number.
- Payments API gateway — binds cards to tokens and processes charges.
- Card networks & issuer — authorize the payment.
- Issuer ACS — runs the 3D Secure challenge.
Data flows
The letters match the flow tags in the diagram. See Modules and packages for which package loads the SDK (flow A) for your stack, and Accept a card payment for flows B-F end to end.PCI scope: only the iframe sees the card
With Elements, card fields render inside RadiumOne-hosted iframes and tokenize the card before it reaches your server. Your website never touches raw card data, which keeps your PCI DSS scope reduced compared to handling card numbers directly. The card iframe is the only place in this whole picture that ever holds a raw card number — not your checkout page’s JavaScript, not your server, and not RadiumOne’s own gateway logs (the gateway receives the card already encrypted as a JWE and only decrypts it inside its tokenization boundary). Compare this to hosted checkout, where the card fields render on a RadiumOne-hosted page instead of an iframe on yours — the PCI-scope outcome is the same, but Elements is the integration to reach for when you need the fields inside your own checkout UI.Data and trust boundaries
Four mechanisms keep the pieces above honest about who can see what:1
Publishable vs. secret key
The browser only ever holds a publishable key (
r1pk_…), which can create Elements/ThreeDS instances and bind sessions — never charge, capture, void, or refund. Your secret key (r1sk_…) stays server-side.Never use a secret key (
r1sk_…) in browser code, mobile apps, or anywhere a shopper can inspect it. Secret keys belong on your server only.2
pubkey_jws signature verification
pubkey_jws is a compact JWS your server relays byte-for-byte from session creation. The card iframe verifies its signature, key ID, session binding, and expiry before it trusts the encryption key inside — your checkout page’s JS only checks the wire shape, never the cryptographic proof.3
Subresource Integrity
The npm loader bakes in an SRI hash automatically; the CDN
<script> tag needs one from your release notes. Either way, a tampered script fails to load rather than running silently. See Install and load Elements.4
Content Security Policy
script-src and frame-src scope which origins your page will load the SDK script and card iframe from. Adding 3D Secure needs a few more directives, scoped to just your checkout and return routes. See Content Security Policy.Next steps
Modules and packages
Every package and runtime object Elements ships, and which one you need.
Install and load Elements
Add the SDK to your page with npm, CDN, or React.
Accept a card payment
Mount a card field and charge your first test payment.
Content Security Policy
The CSP directives Elements needs, and why 3D Secure needs a few more.