Verified domains do not settle the iframe question
An Apple Pay button that appears on a checkout page but disappears when that page is embedded has a real public counterpart: a developer reported exactly this after verifying both the parent and iframe domains. That question demonstrates a troubleshooting need, not a measured failure rate or a diagnosis of your implementation.[3]
Separate three decisions: which hostnames are registered, whether the browser permits the embedded origin to request payment, and whether Apple Pay is eligible in the current environment. Stripe documents registration and iframe requirements separately; completing registration alone does not remove the origin restriction.[1] This guide covers Stripe Elements and embedded Checkout, not general customer consent, native Apple Pay merchant setup, or a claim about PayIn functionality. Research was checked on 2026-09-23; the examples below are proposed checks, not executed payment tests.
1. Inventory exact hostnames before changing code
Stripe requires registration of every domain showing the relevant payment method, including top-level domains and subdomains. Its examples distinguish example.com, shop.example.com and www.example.com.[1] Do not treat a root-domain entry as evidence that every storefront hostname is covered.
- Record the top-level page URL and the URL loaded into your own checkout iframe, including any final redirect destination.
- Extract the hostname from each and compare it with the registered domain list in the intended Stripe account and environment.
- Record whether each domain is enabled. Stripe says disabling a domain removes the relevant methods from Elements or embedded Checkout on that domain.[1]
- Identify the person responsible for adding a new storefront or preview hostname before that deployment is used for checkout.
The documented registration endpoint is POST /v1/payment_method_domains, with a hostname such as domain_name=shop.example.com.[1] This is a request shape, not a command executed here. Keep secret-key operations on an authorized server or administrative tool, not inside the browser fragment.
2. Compare origins, not just domain ownership
Stripe defines matching origins by protocol, full hostname and port when specified. Its iframe rule requires the iframe origin to match the top-level origin, with the documented Safari 17+ exception.[1] Owning both sites does not make their origins identical.
For example, https://shop.example.com embedding https://pay.example.com is cross-origin because the hostnames differ. Using a different explicit port also changes the comparison. These are illustrative applications of Stripe's definition, not browser-test results. First write the two origins next to each other; do not spend another hour repeating domain registration when the unresolved branch is an origin mismatch.
For a cross-origin iframe in Safari 17+, Stripe requires allow="payment" and registration of the source domain loaded by the iframe.[1] A conceptual markup example is <iframe src="https://pay.example.com/checkout" allow="payment"></iframe>. Check the actual deployed iframe rather than assuming a component configuration survived rendering. The attribute is a browser permission configuration; it is not proof of customer authorization, successful collection, or universal browser support.
3. Resolve environment and account scope
Testing requires domain registration too. Stripe allows registration in a sandbox, or registration in live mode that also registers the domain in sandboxes automatically; it explicitly says to register in live mode before launch. For local testing it suggests an HTTPS domain obtained through a tool such as ngrok.[1] Therefore a successful sandbox experiment should not be your only evidence for production readiness. Record the environment and exact hostname that you inspected.
For Connect direct charges, Stripe documents using the platform secret key with the connected account ID in the Stripe-Account header when registering the domain. For destination charges or separate charges and transfers, it says to use the platform secret key without that header.[1] Confirm the charge architecture before choosing the registration context. This is a domain-registration decision, not a procedure for recovering missing PaymentIntents.
Do not add unrelated Apple provisioning work to this Stripe path: Stripe says it handles Apple Pay merchant validation behind the scenes and that you do not need to create an Apple Merchant ID or CSR for this integration.[1]
4. Keep eligibility separate from configuration
The Express Checkout Element shows active, supported and configured methods. Browser and currency support still matter, and its documentation says payment buttons appear only in supported countries.[2] This guide is relevant to eligible Stripe web integrations across supported markets; it does not establish availability in every country, or for every customer device.
Stripe's current Express Checkout documentation says Apple Pay on non-Safari desktop browsers requires paymentMethods.applePay set to always. It also warns that this option does not force a wallet to appear on unsupported platforms or with unsupported currencies.[2] Do not generalize the Safari cross-origin exception into a guarantee for every browser. If no wallet is available, provide another payment route; the current documentation identifies availablepaymentmethodschange as the event for observing availability.[2]
5. Close the investigation with a reproducible record
Our recommended handoff contains the parent origin, iframe origin, rendered payment permission attribute, browser and operating-system versions, intended account and environment, domain-registration state, and observed wallet availability. Compare the same checkout opened directly and embedded on the same device. Change one branch at a time and record the actual result; do not label a configuration edit as a passed payment test.
If the direct page works but embedding fails, prioritize the origin and iframe-permission branch. If both fail, review registration, account context and eligibility without assuming embedding is the cause. These are editorial diagnostic priorities, not guaranteed resolutions. Escalate with a minimal reproduction and sanitized observations rather than secret keys, payment credentials or an unsupported statement that Apple Pay never works in iframes.
Sources and dates
Official documentation supplies current technical requirements. The community question supplies qualitative demand only. All sources were retrieved on 2026-09-23; retrieval dates are not publication dates. No live account or payment test was performed.
- [1] Stripe: Register domains for payment methods. API variant consulted. Publication and update dates not stated; checked 2026-09-23.
- [2] Stripe: Express Checkout Element. Publication and update dates not stated; checked 2026-09-23.
- [3] Stack Overflow: Apple Pay in an iFrame with verified domains. Question by Azianmike, published 2023-02-09; question edit date not supplied by the API. Full question and answer retrieved 2026-09-23. The 2023-11-01 answer is historical context, not the authority for today's browser behavior.