Wallets disappeared when checkout moved to a subdomain
Review the actual pages that now present the wallet button and compare their hostnames with the domain records for the payment integration and account in use. Include a new checkout subdomain even when the homepage has not moved. Stripe documents domain registration for Apple Pay in Elements and embedded Checkout; hosted Checkout follows a different setup. The WooCommerce Stripe extension requires the domain to be enabled in Stripe’s payment-method domains for Apple Pay and Google Pay. An old homepage registration does not establish that the current checkout is covered, and a missing button alone does not establish the cause.
For: A research-only merchant whose wallet buttons stopped appearing after checkout moved to a different hostname or subdomain.
Record the old checkout address from the release record and the current address reached through the store’s real checkout journey. Use the final page after any redirect, not only the link a buyer clicks on the homepage. An origin identifies the scheme, hostname and port; keep the ordinary public page path alongside it so the maintainer can locate the surface being checked. Exclude session tokens and private payment-link parameters.
List any other actual surfaces on which this installation offers the same wallet, such as its product or cart pages. They may remain on the original host while checkout moves. Record each surface separately so a working button on one page does not stand in for a check on another. If payment is embedded, ask the maintainer to identify the containing page and integration rather than assuming the browser’s address bar fully describes the payment setup.
Mark which addresses were observed directly and which are known only from the migration plan. The first useful finding may be that the intended checkout URL and the live destination differ. Resolve that address question before requesting a domain change.
Apply the registration rule for the installed integration
Stripe’s Apple Pay documentation says Elements and embedded Checkout require each applicable domain to be registered. That includes the subdomain where the payment button is presented; a record for the old homepage does not establish a record for the new hostname. The same documentation says Stripe-hosted Checkout needs no extra Apple Pay configuration. Identify that distinction before treating all Stripe-related pages as an embedded integration.
For the WooCommerce Stripe extension, the saved official setup guidance states that the domain must be enabled on the Stripe account’s payment-method domains page for Apple Pay and Google Pay. Compare the current hostname with the actual record and its enabled state in the account the extension uses. A domain listed in an unrelated account or a screenshot from before the move is not evidence of the current connection.
Keep the full public origin in your investigation record, but follow the integration’s documented domain-registration process for what to enter. This worksheet is not a list of values to paste into a provider control. If another plugin or provider draws the button, obtain its own domain requirements before applying Stripe’s instructions.
Interpret the result without declaring the cause too early
If the current hostname has no matching applicable record, or its required record is disabled, document that specific mismatch and assign it to the authorized account owner and maintainer. It is a registration issue to resolve for that integration. Preserve the old and new records and the date of the authorized correction; do not remove an old record merely because one checkout route moved.
If the hostname and required domain state match, the domain comparison is complete but the disappearance remains unresolved. Stripe says Apple Pay can be hidden when device or integration requirements are not met. WooCommerce also documents product and checkout compatibility conditions that affect express-button visibility. Registration is a dependency, not proof that every wallet should render for every visitor.
Use the actual reported device and browser context where available, and document a fresh observation on a supported setup after the relevant correction. Keep the page, product and checkout path consistent enough to make the comparison meaningful. Record whether the button appears without submitting a payment. If the button returns, that establishes observed visibility at that address and time; it does not prove successful payment or identify every change that contributed.
Make the handoff specific to the domain move
Give the maintainer the old and current origins, the integration and installed version, the named wallet, the observed page, and the matching or missing domain state. Identify who can confirm the connected payment account and who can change the website. A precise unresolved question is whether the new payment surface has the registration required by this integration, not whether the whole store needs rebuilding.
For a Prism checkout-review consultation, provide the public website, the research-only products, the domain-change date and a concise description of which wallet disappeared on which page. Public support includes storefront review, processing preparation and help with provider website questions. Any implementation work, responsibilities, fees and terms need an agreed scope.
The contact request receives email follow-up; it does not book work, purchase a service or submit a processing application. Provider account eligibility remains separate from domain registration and from a visibly working button.
Origin-registration map
Use a separate sheet for each affected wallet surface. Record the real current origin, then map its hostname to the integration’s account record. Classify the comparison as matching, mismatched or unknown. Matching closes the domain-record question only; visibility needs its own dated observation.
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.
Origin-registration map. The last column is for temporary notes.
Mapping item
Evidence to read
Meaning of a mismatch or gap
Your finding
Old checkout origin
Evidence to readPrevious release record or dated observation of the actual former checkout address.
Meaning of a mismatch or gapThe old address identifies what changed; it does not establish current registration.
Current checkout origin
Evidence to readThe real destination after redirects, including the public page path and any maintainer-identified embedding arrangement.
Meaning of a mismatch or gapIf the destination is unknown, a homepage domain check is insufficient.
Other wallet surfaces
Evidence to readActual product, cart or other pages where the same integration presents the wallet.
Meaning of a mismatch or gapA remaining button on another hostname cannot verify the moved checkout.
Integration type
Evidence to readInstalled plugin and version, or confirmation of Elements, embedded Checkout or hosted Checkout.
Meaning of a mismatch or gapDifferent products have different requirements; do not infer the type from branding.
Provider domain record
Evidence to readThe exact hostname and required enabled or registration state in the connected account.
Meaning of a mismatch or gapA missing or disabled applicable record identifies a concrete dependency; an old screenshot leaves it unknown.
Verification owner
Evidence to readThe authorized account owner and the maintainer responsible for this surface.
Meaning of a mismatch or gapName who can confirm the account and who can make the agreed correction.
Observed result
Evidence to readDated button-visibility observation with page, wallet, device and browser context.
Meaning of a mismatch or gapButton visibility does not prove payment completion, legal status or provider approval.
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.
Limits
The documented Stripe and WooCommerce requirements apply to those integrations, not every wallet provider or plugin.
The cited Apple Pay rule distinguishes embedded and hosted Checkout. Do not extend that hosted exception to an unexamined wallet or integration.
Keep API secrets, private payment links, tokens, payment details and customer records out of the worksheet and the consultation form.
Stripe Apple Pay — checked 2026-09-21. Elements and embedded Checkout require applicable domains to be registered for Apple Pay; hosted Checkout needs no extra Apple Pay configuration. Device or integration requirements can also cause Apple Pay to be hidden.
Woo Stripe express checkout field and compatibility behavior — checked 2026-09-29. The recorded setup guide requires the domain enabled in the Stripe account’s payment-method domains for Apple Pay and Google Pay. It also describes product and checkout compatibility conditions affecting express-button visibility; registration alone does not establish display.
Prism solutions — checked 2026-09-21. Published support includes storefront review, processing preparation and help with provider website questions. Scope, fees and terms are discussed before work; the provider decides eligibility and account terms.
Prism contact — checked 2026-09-21. The inquiry asks for website, products and question, excludes card details, passwords and customer records, and receives email follow-up. It is not an appointment, purchase or processing application.