Skip to main content
The widget’s look is driven by CSS custom properties (tokens). Your brand theme is a set of values for those tokens, stored on your account. Ripio loads it for you, and the widget applies it at runtime, with no rebuild and no per-partner deploy.

How it works

Send your Ripio contact the values you want to change. Anything you leave out keeps its default. A minimal theme is small:
The widget receives the theme when it starts. It writes the tokens as custom properties on :root, and they inherit into its Shadow DOM.
Theming is an account-level setting. There’s no query parameter or runtime API for it. You can also override tokens yourself at the document level; see Overriding tokens from your page.

Supported tokens

These are the tokens your account theme can set. Any other name is rejected when the theme is loaded, so a theme built on these keeps working as the widget’s internals change. Brand Setting --ripio-color-primary alone is enough for a coherent theme: the hover and the tinted backgrounds are derived from it. Set them explicitly only when your brand guide defines them. Surfaces and text Status and neutrals Shapes and spacing Typography

Accepted values

Each token accepts one kind of value. Anything else is rejected, including CSS functions, url(), @import, comments and anything that isn’t a plain value.

Fonts

The widget ships and serves its own fonts, so you don’t load anything and your page’s CSP doesn’t need a third-party font host. --ripio-font-family accepts one of: The widget only downloads the family it’s using. If your brand needs a typeface that isn’t on the list, talk to your Ripio contact: fonts are added to the widget, never loaded from your side.

Overriding tokens from your page

You can also set tokens yourself with CSS custom properties on your page’s :root. The order of precedence is:
  1. The widget’s defaults.
  2. Your page’s :root, which overrides the defaults.
  3. Your account theme, which overrides both.
From your page you can reach the design system’s other tokens as well: per-component tokens such as --ripio-btn-*, --ripio-input-*, --ripio-card-*, --ripio-chip-*, --ripio-toast-* and --ripio-overlay-*, and the radius, shadow and type scales. They belong to the design system and may be renamed as it evolves, so prefer the supported tokens where they’re enough.

What not to override

The design-system primitives (--violet-*, --gray-*, --error-*, --warning-*, --success-*) and the transaction status-chip tokens --st-* are internal. They’re the raw palette the semantic tokens are built from, they aren’t part of the contract, and they can change without notice. Override the semantic layer instead.
Theming only repaints the widget. It can’t reposition, resize or hide anything inside it. The widget’s own classes, such as .btn-primary, live inside its Shadow DOM and your page’s selectors can’t reach them: use the tokens.

Before and after

The widget with Ripio's default theme
The same widget with a partner's brand theme applied