Frontend Components

Styling

How to apply your own CSS to mounted SDK screens and components.

Why this matters

Solvimon components render inside shadow DOM. CSS from the host page cannot reach into that shadow DOM, so a stylesheet on your page has no effect on SDK output. To style SDK content, pass your overrides through the SDK configuration instead.

How it works

Pass a cssOverrides value to createSolvimonCore. The SDK injects those rules into each mounted instance’s shadow root as a <style data-solvimon-css-overrides> element, so they apply everywhere you mount a screen or component.

cssOverrides restyles the appearance of existing elements. It can’t add, remove, or reorder them, and it can’t change layout structure.

Write your overrides as plain CSS targeting the public sv-* classes, then pass that string as the cssOverrides option:

Pass cssOverrides to the core
1import { createSolvimonCore } from '@solvimon/sdk/core';
2
3const overrideStyles = `
4    .sv-root {
5        font-family: 'Avenir Next', Avenir, sans-serif;
6    }
7
8    .sv-checkout__submit {
9        background: #16a34a !important;
10        color: #ffffff !important;
11        border-radius: 999px !important;
12    }
13
14    .sv-order-summary {
15        background: #f0fdf4;
16        border: 2px solid #16a34a;
17        border-radius: 16px;
18        padding: 16px;
19    }
20`;
21
22const solvimon = createSolvimonCore({
23    environment: 'TEST',
24    locale: 'en-US',
25    cssOverrides: overrideStyles,
26});

Those overrides change the font, restyle the checkout submit button, and reframe the order summary:

Checkout order summary with default styling
Default
Checkout order summary restyled with cssOverrides
With cssOverrides

Your rules land in a <style data-solvimon-css-overrides> element inside each shadow root. If an override isn’t taking effect, that’s the first place to look in devtools: expand the SDK element’s shadow root and confirm your CSS is present and well-formed.

cssOverrides also accepts an array of CSS strings, which the SDK joins automatically.

!important

The SDK’s styles come from Tailwind utility classes set directly on the elements. When one of those already sets a property you’re overriding, your rule loses the cascade and has no effect; !important makes it win.

Rather than work out in advance which properties Tailwind already sets, let devtools tell you. Write the rule without !important, inspect the element, and add !important only to the properties that show up struck through. In the example above, the button needs it (Tailwind sets its background, text colour, and radius); the order summary doesn’t.

Styling hooks

Target the public sv-* classes. Do not rely on internal Tailwind utility classes; they are implementation details and can change between releases.

For example, the checkout screen maps to these hooks:

Checkout screen annotated with its sv-* styling hooks

HookDescription
.sv-rootRoot element for a mounted SDK screen or component.
.sv-screenFull-screen SDK entries, such as checkout or customer overview.
.sv-componentStandalone SDK component entries, such as invoices or payment methods.
.sv-actionSDK action buttons.
.sv-loadingLoading state wrapper.
.sv-errorError state wrapper.
.sv-checkoutCheckout screen root.
.sv-checkout__plan-customizationPlan customization block on the checkout.
.sv-checkout__express-payment-methodsExpress payment buttons (such as Apple Pay) on the checkout.
.sv-checkout__customer-formCustomer information form on the checkout.
.sv-checkout__payment-methodsPayment method selection block on the checkout.
.sv-checkout__order-summaryOrder summary panel on the checkout.
.sv-checkout__promotion-codePromotion code field on the checkout.
.sv-checkout__submitCheckout submit button.
.sv-order-summaryOrder summary block.
.sv-payment-methodsPayment methods component root.
.sv-payment-method-formPayment method form component root.

This table lists the common hooks, not every class. To find additional hooks, open your browser devtools and inspect the rendered SDK content inside its shadow root; any sv-* class is a valid target.

Classes follow a BEM naming convention: sv-block__element--modifier. Modifiers let you target specific states and variants, such as .sv-checkout--paid, .sv-error, or .sv-action--primary. Only the sv-* classes are part of the public styling surface; treat anything else you see in the shadow root as internal.

For brand colours, prefer the branding.colors options on Core. Use cssOverrides for finer-grained styling that those options don’t cover.