Skip to main content
The widget is a native web component. To use it, import the script, mount the element in your page, and hand it the session code your server just requested:
<ripio-crypto-widget> is the only public element. It works in any framework that supports native web components — React, Next.js, Vue, Angular — or standalone HTML.

Versions and integrity

There’s no fixed bundle.js. Each release publishes a versioned file, bundle.v<version>.<hash>.js, and its Subresource Integrity hash. Your Ripio contact sends you both with each release. Pin them in your snippet and update them when you adopt a new release:
  • With integrity, the browser refuses to run the file if a single byte differs from the release you pinned, so a tampered CDN can’t run code inside your page.
  • crossorigin="anonymous" is required alongside integrity.
  • The script tag is the only file you reference. The design tokens and translations ship inside the bundle. The widget loads its fonts by itself, from the same host.

Content Security Policy

When the widget is embedded in your page, your page’s CSP applies to it: it has to allow the widget’s host, its API’s host and Ripio’s token logo CDN. Your page’s origin also has to be registered with Ripio, or the widget can’t reach its API. See Infrastructure requirements for the exact directives and everything else to set up.

Attributes

The widget reads the session code once, redeems it, and then removes it: the code attribute is dropped from the element and the property is cleared. The code works only once, so reading it back afterwards gives you nothing to reuse — mint a new one each time you open the widget.
URL parameters win over attributes. This matters for WebView integrations: the app points the WebView at index.html#_co=…&_cu=…&_la=… and can’t set element attributes directly.
Language precedence: an explicit lang attribute or _la query param wins; otherwise the widget uses the language configured for your account; otherwise it falls back to es.

Passing parameters in the URL

For a WebView or an <iframe> pointed at the widget’s own page, pass the parameters in the URL fragment (after #), not the query string:
Browsers never send the fragment to a server, so the session code stays out of CDN access logs and out of every Referer header. The query string (?_co=…) is still accepted, but prefer the fragment. Either way, the widget removes _co from the address bar and the browser history as soon as it reads it; _cu and _la stay. See Mobile / WebView integration for a full example.

Language

The lang attribute (or _la query param) accepts:

Theming

The widget’s appearance follows your brand automatically once it’s configured on your account — see Theming. You can also override it yourself with CSS custom properties on your page:
These custom properties inherit into the widget’s Shadow DOM, so the widget repaints itself with no further wiring on your side. Your account theme, when there is one, takes precedence over your page’s values. --ripio-font-family only renders one of the fonts the widget ships.

Session expiry

When the session ends — it lasts one hour — or the code didn’t work, the widget shows a “session ended” screen and fires a ripio-session-expired event on the element. Listen for it, request a new code from your server, and call renew:
See Session lifecycle for every event the widget emits.

Behavior inside your page

  • The widget never navigates or routes through your page’s URL — no deep links, no hash routing. The one change it makes is removing _co from the URL once, at startup, if you passed the session code there.
  • Nothing inside it uses position: fixed; overlays and modals stay anchored to the widget’s own container, never the page viewport.
  • The widget doesn’t load any third-party analytics or session-replay script.