Components and appearance

Choose the fields your checkout needs, then apply an appearance at the provider or individual component level.

Component map

The framework components are thin wrappers around the corresponding custom elements.

PurposeReact and SolidWeb component
Checkout state and configBiasProvider<bias-provider>
All enabled payment methodsPaymentElement<bias-payment-element>
Card onlyCardElement<bias-card-element>
US bank account onlyUSBankAccountElement<bias-us-bank-account-element>
EmailContactElement<bias-contact-element>
Billing or shipping addressAddressElement<bias-address-element>
SubmissionSubmitButton<bias-submit-button>

Choose one payment surface

Mount exactly one payment surface under a provider:

  • PaymentElement shows every supported method in the checkout session. Its paymentMethodLayout is "tabs" by default and can be "radio".
  • CardElement selects card and only renders card fields. The session must enable card.
  • USBankAccountElement selects a US bank account and only renders bank fields. The session must enable us_bank_account.

Mounting a second payment surface, including a duplicate of the first, is a terminal configuration_error.

Collect shopper details

ContactElement collects and saves the shopper’s email. AddressElement accepts:

OptionTypeDefault
scope"billing" | "shipping""billing"
collectPhonebooleanfalse
appearanceAppearanceInherited

A billing address is attached to the payment method. A shipping address is saved to the checkout session. When both address scopes are present, the billing form can offer to reuse the shipping address. Contact and address values autosave while the shopper fills out the form and are flushed before payment submission.

Only mount fields your checkout needs. A mounted contact or address component registers its fields as required; an unmounted component does not block submission.

Configure appearance

Set appearance on the provider to theme the whole tree. Set it on a payment, contact, or address component to override that subtree. Component variables merge by key with provider variables, and component-level labelStyle wins.

<BiasProvider
    clientSecret={clientSecret}
    appearance={{
        labelStyle: "floating",
        variables: {
            colorPrimary: "#4f46e5",
            colorForeground: "#18181b",
            colorBorder: "#d4d4d8",
            borderRadius: "10px",
            fontFamily: "Inter, system-ui, sans-serif",
            fontSize: "16px",
            gap: "14px",
        },
    }}
>
    <ContactElement />
    <PaymentElement appearance={{ variables: { colorInput: "#fafafa" } }} />
    <SubmitButton />
</BiasProvider>

For web components, assign structured values as DOM properties:

const provider = document.querySelector("bias-provider");
provider.appearance = {
    labelStyle: "floating",
    variables: { colorPrimary: "#4f46e5", borderRadius: "10px" },
};

HTML attributes only carry strings, so an appearance attribute cannot represent this object.

Appearance options

labelStyle accepts "static", "floating", or "placeholder". The default is "static".

variables accepts optional CSS values for:

CategoryVariables
ColorscolorPrimary, colorBackground, colorInput, colorForeground, colorMutedForeground
FeedbackcolorPlaceholder, colorBorder, colorSuccess, colorError, focusRing
ShapeborderRadius, shadow
TypographyfontFamily, fontSize
Spacinggap

Replace the appearance object when updating it. Removing a variable from the new object removes the package-applied override and restores inheritance or the default.

SubmitButton has no component-level appearance prop. It inherits the provider theme and accepts only disabled and label.

Previous
Next

Built by Bias in California