The merchant theme does not style every payment field

Locate the text before assigning its owner

A payment area can contain merchant headings, a plugin’s explanatory text, provider-rendered inputs and system controls. Treat each visible piece separately. Record the checkout URL, the exact label or message that is difficult to read, and whether it is outside or inside the payment component. Keep screenshots free of entered payment or customer details.

Then ask the installation record to identify the component: platform, payment extension or custom integration, and component name. Stripe Payment Element documentation describes an embedded payment interface; it does not establish that every field beside a Stripe logo is Payment Element. A hosted page, CardElement and Payment Element are not interchangeable styling targets. If the component is unknown, the next task is to identify it, not to add more theme overrides.

Choose the supported appearance surface

For an integration that actually uses the Elements Appearance API, themes supply a starting appearance, variables adjust shared visual values, and rules target documented component classes and states. Those rules are allowlisted. They are not a general invitation to use arbitrary private or descendant CSS selectors. Match the requested change to the documented option before promising that it is possible.

CardElement instead uses the Style object. A proposed repair written for the Appearance API therefore needs a component check before implementation. Where a plugin owns the integration, record which setting or maintained customization supplies the appearance configuration. A provider option existing in documentation does not establish that the installed plugin exposes it in its editor.

Keep typography and platform limits visible in the request. Stripe discusses font loading separately and recommends at least 16-pixel inputs on mobile. Its documentation also identifies operating-system limits on dropdown styling on macOS. If the unreadable item belongs to that surface, record the limitation and the affected device rather than treating an unavailable theme control as proof of a broken store.

Describe a readability outcome that can be checked

“Match the brand” is too broad to close a readability defect. Name the foreground text, its background, the field state and the device where the problem appears. Normal, focused, selected and error states deserve separate observations when they are involved in the report. A change to the normal input colour does not establish that error text or a selected option remains readable.

For text covered by WCAG 2.2 criterion 1.4.3, the stated minimum contrast ratio is 4.5:1, with exceptions. The criterion includes an exception for logo or brand-name text; that does not turn ordinary payment instructions into exempt branding. Record the measured ratio and applicable criterion, or write “not measured.” A provider theme name and a successful colour change are neither measurements nor evidence of whole-checkout conformance.

After the assigned owner makes the agreed change, compare the same component and affected states on the actual checkout. Record which setting changed and what the reader can now see. Stop before entering payment details or submitting a paid order; a visual observation does not need a transaction.

Turn the ownership map into a scoped request

If the problem is merchant copy outside the payment component, assign the page or theme setting. If it is a documented provider-rendered state, assign the integration’s supported appearance configuration. If the interface has an operating-system limit or no confirmed supported option, keep that constraint in the request and ask the responsible implementer to explain the available remedy. These are distinct outcomes of the same worksheet.

For a Prism checkout-review consultation, describe the website, research-only products, affected component and readability issue. Confirm whether the requested assessment or implementation is included when scope, responsibilities, fees and terms are discussed. Keep screenshots containing customer records and all payment credentials out of the public form. Follow-up is by email; submitting the inquiry does not book work or apply for processing.

Payment appearance ownership

Complete one copy for each affected visible component. Use the installed configuration and the actual screen; leave an undocumented control unknown. The map is ready for assignment when one owner and one supported change address the observed readability problem.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.