Well I figured it out - for anyone still encountering this issue: My company has one domain to service multiple locations/storefronts. Each location has it's own separate Payment Processing account, requiring a unique Apple Pay Payment Processing Certificate/MerchantID. The docs and responses here made me think subdomains would be required, which is a headache in itself - especially since the Apple Pay Session must be started from that subdomain (not the parent domain). SOLUTION: If you register multiple MerchantIds within a single Apple Developer Identifier - all Domain Association Files tied to a certain domain are the same. So if you verify for one MerchantID, then add that same domain to another - it will count it as already verified. No need for subdomains. No need for swapping out Domain Association files. Really wish that Apple had made that clear.

I have multiple Apple Pay Merchant IDs for different locations, each requiring its own domain association file. This forces me to verify each Merchant ID on a separate subdomain. The problem: the Apple Pay session must be initiated from the verified subdomain. It works on 10171.example.com but fails on www.example.com. I want to keep a single top-level checkout domain without redirecting users to subdomains. Is there any supported way to do this, or is top-level navigation to the verified domain always required for multi-Merchant ID setups?