Can two Apple Pay integrations coexist on one domain?

Question

Created 3d

Replies 1

Boosts 0

Participants 1

We're an ecommerce/payments platform where tenants embed our Apple Pay checkout into their existing website via an iframe. Our checkout is served entirely from our own domain (b.com) - none of our code runs in the tenant's top-level context. We manage Merchant Identity certificate and Payment Processing certificate, shared across tenants, and tenants are onboarded by registering their domain against our Merchant Id.

Our specific scenario: a tenant's domain (a.com) already has its own, independent Apple Pay integration - their own Merchant ID, their own Merchant Identity/Payment Processing certs, and their own apple-developer-merchantid-domain-association file already hosted at a.com/.well-known/, used for a different part of their business with a different PSP.

We now want to embed our checkout (iframe source = b.com) into a different part of a.com's site, registered under our own Merchant ID, without disrupting a.com's existing integration.

We understand that per Apple's iframe guidance, the parent/top-level page domain must be registered and passed as initiativeContext during merchant validation - so b.com (our iframe source) being registered isn't sufficient on its own; a.com (the top-level document) also needs to be registered, under our merchant bucket, concurrently with its own existing registration under its separate Merchant ID.

Given that:

Is it supported for the same domain (a.com) to be registered concurrently under two unrelated Payment Merchant IDs - ours for the embedded flow, and the tenant's own for their existing flow? Our analysis says no, but we'd appreciate a definitive answer.
If so, how is domain verification expected to work in that case? The well-known path (a.com/.well-known/apple-developer-merchantid-domain-association) can only serve one file - how should a.com host verification for two independent registrations at the same domain and path?
Is there a documented or recommended pattern for this "platform iframe on domain X, where domain X already has its own separate, unrelated Apple Pay merchant registration" case, distinct from the general "PSP registers a merchant's domain" flow?

We've read the Web Merchant Registration API docs and the "Apple Pay Web and Ecommerce site hosting Multiple Merchants on a Single Domain Site" thread, but those address a single integrator managing many merchants, not two independent integrators needing to register the same top-level domain simultaneously.

Answer 1

leroyjv OP

3d

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.