We are an acquirer and PSP and we are building our Apple Pay on the Web integration, starting in India. Please tell us what is needed to enable merchants in other countries like Singapore, Hongkong, New Zealand, etc. Does one Platform Integrator ID and one set of certificates cover merchants in all countries? Which country code should the payment request carry for a merchant whose acquirer processes in a different country? Are there per-country requirements for networks, currencies or issuer participation that affect acceptance? Is there a published list of countries where the Registration API model is supported? Is any separate onboarding with Apple required per country?

We are an acquirer and PSP with our own payment gateway. Merchants can either: Use an Apple Pay payment page hosted by us, or Host their own payment page and submit payment data to us via server-to-server APIs. We are currently implementing Apple Pay on the Web using the Platform Integrator model. The acquirer-hosted payment page flow is clear to us, but we have a few questions regarding merchant-hosted payment pages. Our current understanding (please correct us if any of this is incorrect) We register each merchant using the Web Merchant Registration API as a Platform Integrator, with a unique partnerInternalMerchantIdentifier. Merchants do not have their own Apple Developer accounts. For merchant-hosted payment pages, the merchant's checkout domain is provided in domainNames. The domain verification file is downloaded from our Apple Developer account (Platform Integrator account), and the merchant hosts that file under the /.well-known/ path on their domain. The merchant registration created through the Web Merchant Registration API is then used for Apple Pay eligibility checks and merchant validation. Questions: Domain registration For a merchant-hosted payment page, is it correct to register the merchant's domain against that merchant's partnerInternalMerchantIdentifier registration? Verification file When onboarding multiple merchants: Is the same domain association file used across all merchant domains? Or is a unique verification file generated per merchant registration? Eligibility checks and Apple Pay button The "Supporting Apple Pay on Third-Party Browsers" documentation (Scenario 3) suggests that a payment service provider may provide a JavaScript library that loads apple-pay-sdk.js for merchants. For merchant-hosted pages, is it supported and recommended for the PSP/platform integrator to provide a thin wrapper library around: canMakePayments() applePayCapabilities() Apple Pay button rendering Session creation Or is Apple’s preferred approach that the merchant's checkout page interacts directly with Apple Pay JS APIs? PSP/acquirer decrypts the payment token If the PSP/acquirer is responsible for token decryption, we understand that encryptTo should be set to the Platform Integrator identifier. For merchant-hosted payment pages, are there any additional requirements beyond domain registration and merchant validation? Merchant decrypts the payment token We would also like to support a model where the merchant decrypts Apple Pay tokens directly. In that case, our understanding is that encryptTo must reference the merchant's identifier rather than the Platform Integrator identifier. Is that understanding correct, and are there any additional onboarding or registration requirements for that model? Merchant validation For merchant-hosted checkout pages, what is the expected implementation pattern for onvalidatemerchant? Specifically: Should the merchant's frontend send the validationURL to the PSP/platform integrator backend, which then performs merchant validation with Apple and returns the merchant session? Or is a different flow expected when using the Platform Integrator model? Any clarification or guidance would be greatly appreciated. Thank you.