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.

We are an Apple Pay consumer and observed elevated response times and intermittent timeouts affecting the create‑session API (apple-pay-gateway.apple.com/paymentservices/paymentSession) between approximately 8:01 PM and 8:35 PM PST today. We are reaching out to understand whether there were any service disruptions during this timeframe, as we do not see corresponding updates on the system status pages. We would like to confirm whether this behavior was related to a broader Apple Pay issue or specific to our integration.

We have been using ApplePay on the web for years, but we are running into a problem since today in sandbox where domainName is missing from the create payment sessions request. We haven't changed anything related to this request any time recently. Static payment sessions url being hit in sandbox: https://apple-pay-gateway-cert.apple.com/paymentservices/paymentSession request format: "merchantIdentifier": "merchant.com.identifier", "displayName": "Test Store", "initiative": "web", "initiativeContext": "test.example.com", "domainName": "test.example.com" response format: { "epochTimestamp": 1763533367972, "expiresAt": 1763536967972, "merchantSessionIdentifier": "<merchantSessionIdentifier>", "nonce": "<nonce>", "merchantIdentifier": "<merchantIdentifier>", "displayName": "Test Store", "signature": "<signature>", "initiative": "web", "initiativeContext": "test.example.com", "signedFields": [ "merchantIdentifier", "merchantSessionIdentifier", "initiative", "initiativeContext", "displayName", "nonce" ], "operationalAnalyticsIdentifier": "Test Store:<identifier>", "retries": 0, "pspId": "<pspId>" } Production create session request to https://apple-pay-gateway.apple.com/paymentservices/paymentSession is behaving as expected, sending the following fields as response: epochTimestamp, expiresAt, merchantSessionIdentifier, nonce, merchantIdentifier, domainName, displayName, signature, operationalAnalyticsIdentifier, retries, pspId Claude seems to suggest this is a response when Messages for Business is enabled, but this ApplePay Payment Processing merchant is only configured for Apple Pay on the Web. Any ideas or pointers to check for? We are worried this will spill over in production as well, which will break our ApplePay integration. Thanks in advance!