Following up on this - we've been considering an alternative approach and wanted to sanity-check it. Potential approach: Instead of registering a.com under our Apple account (which runs into the domain-association-file collision described above), Company A (the domain owner, a.com) creates a new Merchant ID under their own Apple Developer account specifically for us, Company B. The flow would be: B generates CSRs for both the Merchant Identity certificate and the Payment Processing certificate, and provides them to A. A uploads both CSRs into the new Merchant ID (in A's own developer account) and downloads the signed certificates from Apple. A also adds a.com as a registered domain under this new Merchant ID. Since a.com is already verified elsewhere under the same Apple Developer account (for their existing, separate Apple Pay integration), we'd expect this verification to be fast/immediate rather than requiring a fresh well-known file host. A sends the signed public certificates back to B. B holds the private keys throughout - A never has them - and uses the Merchant Identity certificate/key to perform merchant validation (create the Apple Pay session), and the Payment Processing key to decrypt the payment payload. This would let us operate entirely independently at runtime (our own certs, our own decryption), while sidestepping the domain-association file conflict, since the new Merchant ID lives under A's existing, already-verified account/domain relationship rather than requiring a second file at the same well-known path. Questions: Does adding a domain to a new Merchant ID under an account where that domain is already verified under a different Merchant ID actually skip re-hosting the well-known file, or does each Merchant ID require its own independent domain verification regardless of account-level history? Is there any restriction on a Merchant ID's certificates being requested via a CSR generated by, and private keys held by, a party other than the Apple Developer account holder? Does Apple check or care who controls the private key corresponding to a cert issued under someone else's account? Are there known issues with this pattern from a support/liability perspective — e.g., since A's account technically owns and can unilaterally revoke or delete the Merchant ID at any time, does that create any documented risk beyond the obvious "trust your counterparty" issue? Appreciate any insight - trying to determine whether this is a reasonable workaround or whether it just trades one set of problems for another.

Our design is for our backend to make the paymentSession call and return the response to the frontend. However, we are doing an exact field mapping while reading the response, which meant the backend errored out validation when it couldn't find domainName in the response. In addition, the "new" fields (like initiativeContext) being returned weren't mapped and hence not sent back to frontend, meaning signature validation later on would have failed as well. We can see the response format has now reverted back to the "old" format. Until that, ApplePay in our preprod environments was fully down. Would this change happen again? If so, is there a possibility of an announcement or notification so we can be better prepared?

sorry, title should have said domainName missing from create payment sessions response in sandbox