Skip to main content
RadiumOne.init() and loadRadiumOne() validate the publishable key synchronously, before any network request. A bad key throws immediately in your own code — it’s never a silent failure.
TL;DR: init throws an ElementsError right away → confirm you passed a publishable key (r1pk_…) that matches your CDN/npm build’s channel.

When this happens

  • No key was passed, or it isn’t a string.
  • A secret key (r1sk_prod_… / r1sk_test_…) was passed instead of a publishable key.
  • The key’s prefix isn’t r1pk_prod_, r1pk_test_, or r1pk_mock_.
  • The key’s channel doesn’t match the loaded bundle: a test/mock key with a production CDN or npm build, or a production key with a staging/sandbox build.

What you see

What to do

1

Check the key prefix

Confirm you’re passing a publishable key (r1pk_…), never a secret key (r1sk_…). Secret keys must only ever be used server-side.
2

Match the key to the bundle

A test/mock key (r1pk_test_… / r1pk_mock_…) needs the sandbox CDN or a @beta npm build; a production key (r1pk_prod_…) needs the production CDN or the @latest npm build from a production release. loadRadiumOne() already routes the CDN choice for you based on the key prefix — the mismatch case is mainly an npm channel/key mismatch (loader:integrity_unset).
3

Wrap init in a try/catch during setup

Since the throw is synchronous, catch it at the same call site as RadiumOne.init() / loadRadiumOne(), not inside your payment-submit handler.

Prevent it

  • Keep sandbox and production keys in separate environment configs so a build can’t accidentally ship the wrong one.
  • Never hardcode a key in a shared snippet or template that’s reused across environments.

Install and load Elements

The full key-validation error table.

Sandbox and API keys

Where to find your publishable and secret keys.
Last modified on September 15, 2026