同一域名下验证多个Apple Pay商户的解决方案咨询

方案1：合并多商户ID到同一验证文件（官方推荐） #

Apple Pay的域名验证文件为JSON格式，原生支持在merchant_id数组中添加多个商户ID。具体操作：

1. 分别为Checkout.com、Adyen对应的两个Apple商户ID，在Apple开发者后台发起域名验证，获取各自的apple-developer-merchantid-domain-association.txt文件。
2. 对比两个文件的domain_association字段值：
   • 若值完全一致，直接将两个商户ID合并到同一个文件的merchant_id数组中，示例如下：

     {
       "merchant_id": [
         "merchant.your-domain.checkout",
         "merchant.your-domain.adyen"
       ],
       "domain_association": "xxx..."
     }
     

   • 若domain_association值不同，说明商户ID可能归属不同Apple开发者账号，需将域名添加到所有关联账号中，重新生成包含全部商户ID的验证文件（或联系Apple开发者支持协助处理）。
3. 将合并后的文件部署到域名的/.well-known/路径下替换原有文件。此操作不会影响现有Checkout.com集成，Apple验证时会检查目标商户ID是否在文件的数组中，原有商户ID仍存在，验证状态将保持有效。

方案2：使用子域名隔离（完全无风险） #

若担心合并文件的潜在问题，可为Adyen的Apple Pay集成配置独立子域名（如pay.your-domain.com）：

1. 在Apple开发者后台为Adyen的商户ID发起子域名的验证请求，获取对应验证文件。
2. 将该文件部署到子域名的/.well-known/路径下。
3. 配置Adyen集成使用该子域名作为支付域名，主域名继续用原有验证文件服务Checkout.com的集成。
   这种方式完全隔离两个集成，不会对现有业务产生任何影响，是最稳妥的选择。

关于动态返回文件的可行性 #

Apple的域名验证请求不会携带任何标识商户ID的请求头或参数，无法通过动态判断请求来源返回对应文件，这个思路不可行。

关于“验证后永不复查”的风险 #

你提到的基于该假设的方案不可靠，Apple可能会定期复查域名验证状态，一旦原有文件被替换且未包含原有商户ID，现有集成可能失效，因此不建议采用。

内容的提问来源于stack exchange，提问作者callum