When WooCommerce Apple Pay is not showing, it's almost always one of five things: your domain isn't registered with Stripe, express checkout is off for that page or product, the shopper's Apple device or browser doesn't qualify, a cache or firewall is serving the checkout without Stripe's live data, or a Content Security Policy is blocking Stripe's scripts. Check them in that order. Most stores get the button back without anyone touching code.
The annoying part is that nothing tells you which one it is. Stripe only shows the Apple Pay button when every condition passes. If one fails, the button simply isn't there. No error for the shopper, and often nothing in the logs either.
I've built WooCommerce checkouts for stores like Wow Vastra, a UK Indian fashion boutique with a currency switcher and worldwide checkout, and Whitfield Service Station, an online ordering store in Dover, and Stripe payments are a normal part of my WooCommerce work. This guide assumes you're on the official WooCommerce Stripe extension. On WooPayments the causes are much the same but the settings live elsewhere, and WooCommerce keeps separate express checkout compatibility notes for it.
Why is Apple Pay not showing on my WooCommerce store?
Because one of Stripe's express checkout conditions isn't met. Apple Pay isn't a normal payment method on your checkout. It's an express checkout button, and it only appears when the site, the Stripe account and the device all qualify. WooCommerce's express checkout documentation lists the site side: a valid SSL certificate, the whole site on HTTPS, port 443 open, TLS 1.2 or later, and your domain enabled on Stripe's payment method domains page. On top of that, the visitor needs a compatible Apple device with a card in Wallet.
The symptom usually points you at the cause:
| Symptom | Likely cause | Where to look |
|---|---|---|
| Google Pay shows, Apple Pay doesn't | Domain not registered for Apple Pay, or a device issue | Stripe payment method domains, your test device |
| Neither wallet shows anywhere | Express checkout off, card payments off, or HTTPS problems | WooCommerce > Settings > Payments > Stripe |
| Shows on product pages, not cart or checkout | Page caching or firewall rules on cart and checkout | Cache plugin, host cache, Cloudflare rules |
| Missing on some products only | Product type, free product or tax setting | Product settings, tax settings |
| "Apple Pay domain registration failed" in admin | Verification blocked by a redirect, a firewall or a stuck setting | Stripe dashboard, server rules |
| Button vanished after a security change | Content Security Policy or Permissions-Policy | Browser console, response headers |
Is the problem your iPhone or your store?
Check the device first. If Apple Pay doesn't show in Stripe's own demo on the same iPhone or Mac, your store isn't the problem. This is the cheapest check there is, and it's a common false alarm. Stripe's wallet testing guide says the button only appears when:
- The Wallet app has at least one card in it.
- You're on a compatible Apple Pay device and a supported browser version.
- Safari is allowed to check for Apple Pay (Settings > Advanced > Allow websites to check for Apple Pay and Apple Card).
- You're not in a private window.
- You're in a supported Apple Pay region, and the device supports biometric authentication.
That same Stripe page has a live demo. Open it on the device you're testing with. No Apple Pay there? Then it's the device. If it shows in Stripe's demo but not on your store, the fault is on your site and you can carry on down this list.
Testing from India? You won't see it
Stripe's testing guide says it doesn't display Apple Pay in any mode for IP addresses in India. If your developer is in India, as I am, someone needs to check the store on a real Apple device in your own market.
One more thing about test mode: you still need a real card in Wallet. Stripe's note on testing Apple Pay explains that you add a real card and keep using your test API keys.
How do I register and verify my domain for Apple Pay in Stripe?
List every domain and subdomain that shows the button on Stripe's payment method domains page, then make sure the domain association file loads directly. You don't need an Apple Merchant ID or a certificate. Stripe deals with Apple's merchant validation for you. On the payment method domains page, www and shop subdomains each need their own entry, and Stripe says you register domains for testing too.
Normally the WooCommerce Stripe extension registers your domain and creates the file at /.well-known/apple-developer-merchantid-domain-association on its own. When that goes wrong, work through this:
- 1
Check the exact host
Open your checkout and note the host in the address bar, with or without www. That exact host must show as registered on Stripe's payment method domains page.
- 2
Open the association file
Visit /.well-known/apple-developer-merchantid-domain-association on that host. It should load directly as plain text, not as a redirect, a 404 or a firewall challenge.
- 3
Fix redirects and server rules
A www to non-www redirect, or a server rule that sends .well-known requests to the SSL certificate folder, can stop verification. Let the file load directly.
- 4
Re-run registration
Turn Apple Pay off and on again in the Stripe extension, or re-verify the domain in the Stripe dashboard, then check that the status shows as active.
Redirects cause this more than you'd think. In one WordPress.org support thread, verification kept failing because Stripe was checking a www domain that redirected to the bare domain. Creare Web Solutions wrote up a site where the "Apple Pay domain registration failed" warning came from Cloudflare security rules plus a stuck setting, and the Nginx config on that same site was sending .well-known requests to a folder outside the web root.
Running a marketplace on Stripe Connect with direct charges? Stripe's payment method domains guide says connected accounts' domains are managed through the API, not the dashboard.
Which WooCommerce settings hide the Apple Pay button?
There are five to check: the express checkout toggle, the page locations, the card payment method, the product type and your tax setup. Start at WooCommerce > Settings > Payments > Stripe > Payment Methods and find the Express checkouts section. Apple Pay and Google Pay switch on together. Each set of buttons has a Customize link where you pick the pages they appear on (product, cart and checkout). Tick only checkout and you'll never see the button on a product page.
Two settings catch people out regularly:
- Card payments must be on. WooCommerce says you generally can't use express checkout without the card method enabled.
- Some products never get the button. According to WooCommerce's express checkout documentation, express checkout buttons don't appear for non-default product types, composite products, products with file upload fields, free products or pre-orders that charge on release.
Tax is the one almost everyone misses. If a product doesn't need shipping and your store works out tax from the billing address, the Stripe extension hides the express buttons deliberately, so the tax doesn't come out wrong. From version 9.5.0 of the extension, a developer can override this with the wc_stripe_should_hide_express_checkout_button_based_on_tax_setup filter, as the WooCommerce express checkout documentation explains. I'd only do that if you're sure about how tax gets calculated afterwards. Also, under the button preview on the settings page, the extension lists any eligibility requirements you're missing. Read that before anything else.
Custom checkout fields are worth checking as well. If a plugin adds required checkout fields that the Apple Pay sheet doesn't collect, an express payment started from a product or cart page may be refused after the shopper has already approved it. Technically the button shows. From the customer's side, Apple Pay is broken, so test a full express payment whenever you add required fields.
Can caching or Cloudflare stop Apple Pay from showing?
Yes. Apple Pay needs live data from your store, like the current cart total and shipping options. Serve the cart or checkout from a page cache, or let a firewall block the Stripe extension's endpoints, and the button may never appear. In the Creare case above, Cloudflare was blocking /wp-json/, /wc-api/ and ?wc-ajax= requests. That's exactly why the buttons worked on product pages but not on cart or checkout.
What I check:
- /cart/, /checkout/ and /my-account/ excluded from page caching in the plugin, at the host and on the CDN.
- Cloudflare WAF, bot and rate-limiting rules not challenging WooCommerce's AJAX and REST endpoints.
- Stripe's scripts (js.stripe.com) and the Stripe extension's own files left out of any "delay JavaScript" or combine rules. Delay them and the button might only show after the shopper taps or scrolls. Or not at all.
LiteSpeed Cache, WP Rocket, your host's own cache: the exclusions are the same for all of them.
Can a Content Security Policy block the Apple Pay button?
Yes, and it usually happens right after someone tightens the security headers. If your Content Security Policy doesn't allow Stripe's domains, the scripts and frames behind the Apple Pay button get blocked. Stripe's integration security guide lists the directives it needs, and Report URI's summary of that guidance boils the core ones down to:
script-src https://js.stripe.com https://*.js.stripe.com
frame-src https://js.stripe.com https://*.js.stripe.com https://hooks.stripe.com
connect-src https://api.stripe.com
img-src https://*.stripe.com
Don't copy that blindly. Stripe updates the list, so check its guide for the current version first. And if Google Pay is on too, the Stripe plugin loads a script from pay.google.com as well, as this WordPress.org thread points out.
To catch a CSP block, plug an iPhone into a Mac, open the checkout and use Safari's Web Inspector. Violations show up in the console along with the blocked address. Then look at your Permissions-Policy header. If it sets payment=(), the browser blocks the payment features wallet buttons rely on. Stripe's docs say an iframe needs allow="payment" for Apple Pay, which tells you how much that one permission matters.
I maintain the HTTP Security Header plugin for WordPress, so I deal with this trade-off a lot. A strict policy is a good thing. A strict policy that breaks your checkout isn't. My CSP troubleshooting guide shows how to test a policy in report-only mode first, and the free Security Headers Checker shows exactly which headers your checkout page is sending.
Apple Pay shows but payments fail. Is that the same problem?
No, that's a different problem. If the button appears and the payment then fails, the issue is in the WooCommerce checkout or the Stripe account, not the button's visibility. Webhooks, 3D Secure and plugin conflicts are the usual suspects. Go to my guide on WooCommerce Stripe payments failing instead.
What should you ask a developer before they fix it?
Ask how they'll find the cause. With a missing Apple Pay button, the diagnosis is most of the job. The actual change is often a few minutes.
- Will you test on a real Apple device in my market with a card in Wallet, not just on your laptop?
- Will you work on a staging copy, or change live checkout settings during trading hours?
- Which page cache, CDN and firewall rules will you change, and will you write them down?
- If you change the CSP or Permissions-Policy, will you run it in report-only mode first?
- How will you confirm the fix on product, cart and checkout pages, with and without www?
Vague answers are a warning sign. The real risk is someone weakening your security, or switching off caching for the whole site, just to make one button appear.
Next step
Do the device check and look at Stripe's payment method domains page first. Between them, those two sort out a lot of cases. If Apple Pay still won't show, or it disappeared after a cache, Cloudflare or security change, I can track down the cause and fix the checkout without loosening the rest of the site. Have a look at my WooCommerce stores and online ordering service, or send me your store URL along with which pages and devices are affected.
