A custom payment subdomain fails while the store works

Establish which address failed

Record the storefront hostname that was observed working and the payment hostname where the failure occurred. Keep the observation times and time zones. Distinguish a storefront page that cannot initiate checkout from a browser that has already reached the payment hostname and displays an error there. Those observations identify different places to start investigating, even when both are reported as checkout down.

Copy the exact visible error into the restricted incident record after removing any personal data or private URL tokens. Record whether a payment page appeared at all and whether the behavior is confirmed or only reported. The public worksheet needs the hostname and a sanitized observation, not a full customer-specific Checkout URL. A report from one path establishes that path's observed failure, not the health of every buyer journey.

Confirm the hosted product behind the branded address

Stripe documents custom domains as a separate feature for full hosted Checkout. The captured hosted Checkout guide says that this paid feature can serve Stripe-hosted Checkout pages on a subdomain of the merchant's custom domain. The merchant's branding therefore does not establish that the payment page is served by the same system as the storefront. Nor does a Stripe connection somewhere in the store establish that this particular checkout uses that feature.

Have the authorized account owner identify the product and the exact custom hostname recorded for it. Compare that hostname with the one in the observed failure and with the integration's intended destination. Keep the configured value, observed destination and underlying provider account or service record as separate facts. If the product cannot be identified, the next task is to retrieve the setup or handoff record; do not assume Stripe's feature rules apply to another provider or to an embedded payment form.

Assign owners using the configuration evidence

The domain administrator should compare the actual hostname configuration and any dated change record with the requirements for the identified service. This is an investigation request, not an instruction to change a DNS record. The store maintainer should establish which checkout destination the integration uses. The provider-account owner should preserve the custom-domain status or notice available in that account and open the corresponding support case when provider clarification is needed.

A mismatch between the destination observed and the configured hostname goes first to the maintainer responsible for that destination. A documented mismatch in domain configuration belongs with the authorized domain administrator. A provider-side notice or unexplained service state belongs in the provider case. When the records do not isolate the fault, give those owners the same timestamped evidence and name one business owner to coordinate their findings. Do not assign the cause to the storefront host merely because it manages the main website.

Recent changes are useful leads only when tied to dates and the affected component. Record a domain edit or checkout release if one actually occurred. Its proximity to the failure does not prove causation. If nobody can retrieve the domain or provider configuration, state exactly which record and authorized role are missing.

Keep recovery decisions separate from the initial diagnosis

A proposed repair should name the responsible owner, the specific configuration it changes and the observation that would demonstrate recovery of the affected route. This guide does not prescribe a DNS target, an alternate checkout address or a fallback payment method. Replacing a destination without establishing its relationship to the installed product would leave the original failure unexplained.

Keep any payment already attempted as a separate order-and-provider question; page availability alone does not establish its outcome. After authorized work, record whether the affected route is reachable and which parts of the journey remain unchecked. A page that loads is evidence of page availability, not proof of completed payment, fulfillment or provider approval.

For a Prism checkout-review consultation, share the public storefront, affected hostname, identified product and sanitized symptom. Describe the review or implementation help sought so scope, responsibilities, fees and terms can be agreed. Keep private Checkout links and credentials out of the inquiry. A consultation request does not promise immediate restoration or incident staffing.

Payment-domain dependency record

Build one record for the failing hostname. Compare observed, configured and provider-record values without copying a private payment URL. Use match, mismatch or unknown for each relationship; the first documented mismatch identifies a concrete investigation task, not necessarily the final cause.

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.