Apple Pay domain verification: every reason it fails

Apple Pay refuses to appear unless Apple can prove you control the domain the button is on. The check is strict, it happens on every domain and subdomain separately, and when it fails the button simply does not render, with nothing useful in the console.

How verification works

You register the domain with your payment provider. The provider gives you a small file. You publish it at a fixed path, and Apple fetches it from that exact URL over HTTPS. If the fetch succeeds, the domain is registered and the button renders for Safari users with a card in their wallet.

The file lives at /.well-known/apple-developer-merchantid-domain-association. No extension, no redirect, served as plain text.

Every reason it fails

• The file is not reachable. Open the URL in a private window. If you see a 404, a login page, or your theme 404 template with a 200 status, Apple sees the same thing.
• A redirect. Any redirect at all, including the http to https redirect or a trailing slash rule, fails the check. It must be a direct 200.
• The web server hides dot directories. Many Nginx and Apache configurations block anything starting with a dot. The .well-known path needs an explicit allow rule.
• A security plugin or firewall. WAF rules and hotlink protection often block unknown user agents. Apple fetcher is not a browser.
• A CDN serving a stale 404. Purge after uploading, then test from outside your own network.
• Wrong file for the environment. Sandbox and live files are different, and so are files from different providers.
• Wrong host. www and the bare domain are two registrations. So is every staging subdomain.
• A certificate problem. An incomplete chain that browsers tolerate will still fail a strict fetch.
• The file was edited. An editor that adds a byte order mark or a trailing newline breaks it. Upload the original bytes.

The button still does not show, and the domain is verified

Then the problem is on the browser side, and the list is short:

• The page is not served over HTTPS, including every asset on it.
• The device has no card in the wallet. Apple Pay does not render an empty button, and Safari on a Mac needs a paired iPhone or a Mac with Touch ID.
• The browser is not Safari. Apple Pay on the web does not run in Chrome on macOS.
• Your currency or country is not enabled on the merchant account.
• The cart contains something the configuration excludes, for example a subscription when recurring wallet payments are not enabled.
• A JavaScript error earlier in the page stopped the payment script from running. Check the console before anything else.

A five minute test routine

1. curl the association file and check for a 200 and the raw content, not HTML.
2. curl it again with a redirect flag off, to prove there is no redirect.
3. Re-run verification in the provider dashboard, and read the exact error text.
4. Load the checkout in Safari on a device with a wallet card, with the console open.
5. Test the bare domain and the www domain separately.

Google Pay has no equivalent domain file, which is why it often works while Apple Pay does not on the same checkout. That asymmetry is the fastest clue that you are looking at a verification problem rather than a payment problem. The wallets page covers the rest of the setup.