Hosted checkout locks an existing customer email

A prefilled identity field can behave as documented

The existing customer parameter in Stripe's create-Session documentation explains this behavior. An existing Customer with a valid email supplies the non-editable address in that Checkout. If that Customer lacks a valid email, the same reference says the email supplied during the session is set on the Customer. These are different documented conditions; do not assume every prefilled address is locked for the same reason.

The source URL below identifies 2026-08-26.preview. Its existing-Customer rule is evidence for an investigation, not a guarantee about every Stripe connector, stable API version, embedded form or store account page. Begin by identifying the hosted Checkout flow and the integration's configured version. A generic report that a Stripe field cannot be changed is not enough to establish this cause.

Trace the address to the Customer actually supplied

Ask the authorized integration owner to inspect the existing record of the affected Session and, where retained, the request that created it. The useful fact is whether creation supplied a customer reference and which Customer it identified. Match that reference within the correct provider account to the store's intended buyer association. A matching email string alone is not a substitute for that reference chain.

Compare the observed Checkout email with the Customer email used at creation. A current Customer record can support the investigation, but if it was edited later it does not prove what the record contained when the Session began. Keep the observation time and any relevant recorded change time. If creation-time evidence is unavailable, say that the historical value is unknown rather than treating the current value as a snapshot.

Keep the distinction between a wrong address on the correct Customer and a wrong Customer supplied by the integration. The former is a contact-record correction question. The latter requires investigating the store-to-provider association before editing any person's details. If the Session did not use an existing Customer, this documented rule does not explain the locked field by itself.

Authorize the correction at the record that owns it

Use the merchant's established process to verify the correction request and the person entitled to make it. The person reporting the field may know the right address, but that report alone should not authorize changing a Customer associated with a different buyer. Record who approved the correction and which system is responsible for the address or Customer selection.

If the correct Customer has an outdated address, the authorized owner can determine the supported correction path for the installed integration. If the store selected the wrong Customer, have the maintainer resolve that association. Do not create a duplicate Customer, delete the existing one or remove the customer parameter simply to make the field editable; those actions would change more than the observed input state.

The cited prefill rule does not establish whether a change to the Customer updates an already-open Checkout Session. Ask the maintainer to confirm the existing Session's behavior before directing a buyer back to it. Do not promise that an old tab will refresh or that a new Session is required from this source alone. Preserve the original attempt and its payment state before deciding how checkout should continue.

Define what will show the issue is resolved

A useful resolution record identifies the intended Customer, the authorized address source, the correction performed if any, and the behavior subsequently observed in the real supported flow. The goal is correct identity association and an accurate address. A field remaining non-editable can be consistent with the documented rule; editability alone is not the acceptance condition.

For a Prism checkout-review consultation, describe the hosted flow, the observed field behavior and the record ownership question. Confirm investigation or implementation responsibilities, scope and fees before work. Do not send email addresses, customer exports, secret keys or private Checkout links through the public form. A functioning Checkout and a corrected Customer record do not establish approval to process a research-only business.

Hosted email source record

Use one copy for the actual affected Session. Record shortened internal references and comparisons such as matches or differs, not email addresses or private Checkout URLs. The documented explanation fits only when the Session's existing-Customer association and relevant email condition are established; otherwise keep the cause unresolved.

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.