The Stripe payment iframe matches the page because it reads the same CSS variable

Every service page on the site sets a CSS custom property called --service-accent on its outermost container. Software pages set it to purple. Audio pages set it to cyan. Production pages set it to emerald. Accessibility pages set it to fuchsia. Musician pages set it to orange. Every component inside the page — the sidebar, the form, the navigation, the product cards — reads that variable for accent-coloured text, borders, and backgrounds. The Stripe payment iframe needs to match. The CheckoutWizard passes an appearance object to the Elements provider with five tokens. The colorPrimary is set to var(--service-accent, #60a5fa) — the CSS variable with a blue fallback in case the variable is missing. The colorBackground is the same near-black used across the dark theme. The colorText matches the site's text colour. The colorDanger is red-400. The borderRadius is eight pixels. The fontFamily is set to inherit. Six lines configure the entire payment form's visual identity. When a client checks out on the audio page, the payment form highlights in cyan. On the software page, it highlights in purple. The Stripe iframe reads the CSS variable at render time and applies it to the input focus states, the submit button, and the card brand icons. No conditional logic in the component. No service-to-colour mapping. The same appearance object works for all five services because the CSS variable is already set by the page above it. The theme property is set to night — Stripe's built-in dark mode — so the iframe background, text, and input styling align with the site's dark-first design. Light mode overrides in globals.css swap the accent colours but the Stripe Elements config does not need to change because the CSS variable resolves to the light variant automatically.