We have verified our domain but if the file is removed from the deployed site after verification will this impact using ApplePaySession.applePayCapabilities in real time?
We use that method from the JS api in our React app to determine whether or not to show the apple pay button.
When that function is called in the browser, do the apple servers ping the https://our.domain.com/.well-known/apple-developer-merchantid-domain-association URL at that time?
Or do they check for it periodically?
The reason for asking is that with our many environments we wonder if we can verify each environment's domain by adding the file once. The file will be wiped out by our CICD process as it goes up the environment stack through our development workflow.
Or do we need to maintain that file for each environment and add something to our build process?
You wrote:
We have verified our domain but if the file is removed from the deployed site after verification will this impact using ApplePaySession.applePayCapabilities in real time? [...]
No, when applePayCapabilities() is called in the browser, Apple doesn't point your /.well-known/ URL in real item. It checks:
- Device and OS capability (local, no network)
- Whether the user has an eligible card in Wallet
- Whether your domain is in Apple's stored registration records for the given Merchant ID
The domain check is a database lookup against the record Apple created when you verified, not a live fetch of your file.
Then, you wrote:
[...] Or do we need to maintain that file for each environment and add something to our build process?
Technically, it won't cause immediate breakage — but you shouldn't do it. Apple does periodically re-verify registered domains by re-fetching the file from your server. If Apple re-checks and the file is missing, the domain registration is silently revoked — and Apple Pay will start failing at merchant validation with no immediate warning, making it very hard to trace back to a deployment that removed the files hours, days, or weeks earlier.
Do not treat the file as a deployment artifact. Treat it as infrastructure. One suggestion is to store the file contention your secrets manager or environment config and serve it via a route in your app. It survives every deploy automatically. Otherwise, route the path through a CDN to object storage or restore the file as part of your CI/CD pipeline.
Cheers,
Paris X Pinkney | WWDR | DTS Engineer
