HTTP 400 status code

App & System Services Apple Pay
Ivy0905 OP
Created Jan ’26
Replies 1
Boosts 0
Views 247
Participants 2

Recently, we completed a merger with our parent company. We are currently integrated with Apple Pay in accordance with the “Apple Pay Payment Processing on the Web” guidelines.

Due to the change in the legal entity, we proceeded with the account migration process as outlined below:

  1. Creation of a new Apple Developer account and a new Apple Pay Identifier
  2. Removal of the Merchant Domain (dc2-web.happy.co.kr) from the existing Identifier
  3. Registration of the Merchant Domain (dc2-web.happy.co.kr) under the new Identifier

Using the Merchant Domain registered under the new Identifier and the Apple Pay Merchant Identity Certificate issued from the new Identifier, we attempted to obtain an Apple Pay session by sending requests to the following endpoint: https://apple-pay-gateway.apple.com/paymentservices/startSession

However, we are intermittently receiving failure responses with an HTTP 400 status code.

With regard to these intermittent failures, we would like to inquire whether there is any propagation delay on Apple’s servers when an Apple Pay Identifier is removed and re-registered under a new account, or if there could be any other possible causes for this behavior.

We would appreciate your guidance on this matter.

Answered by DTS Engineer in 893864022

Hi @Ivy0905,

You wrote:

[...] However, we are intermittently receiving failure responses with an HTTP 400 status code. [...] With regard to these intermittent failures, we would like to inquire whether there is any propagation delay on Apple’s servers when an Apple Pay Identifier is removed and re-registered under a new account, or if there could be any other possible causes for this behavior.

The intermittent 400 errors you've experienced are likely caused by a combination of server-side propagation delays and configuration mismatches introduced during the merchant ID migration.

However, in your situation, the propagation delay is the most likely cause. When you remove a merchant domain from one merchant ID and register it under a new one, Apple's payment gateway infrastructure doesn't update instantly. The Apple Pay servers are globally distributed and changes can take time to fully replicate.

Beyond propagation delay, there are a few common causes of a 400 error on /startSession after a merchant ID migration:

  • Domain name mismatch in the /startSession request body. The domainName field (and possibly the initiativeContext field) in your request body must exactly match the domain registered under your new merchant identifier, including subdomain.
  • Old merchant identity certificate is still being used. This is one of the most common post-migration mistakes. Your server must use the certificate generated from the new merchant ID, not the old one.
  • Domain verification file not server correctly on the new merchant account. After re-registering the domain under the new merchant ID, Apple re-verifies the domain associate file. If the file isn't served correctly, verification silently fails on Apple's side and subsequent /startSession calls return 400. make sure the domain association file downloaded from the new merchant ID (not the old one) is the one currently deployed, as the file content is different per merchant ID.
  • Merchant identity certificate not correctly converted for server use. When exporting the new certificate, an incorrect export or conversion can result in an invalid certificate being used for mTLS with Apple's payment gateway.

Cheers,

Paris X Pinkney |  WWDR | DTS Engineer

Replies  1
Boosts  0
Views  247
Participants  2
DTS Engineer OP
Apple
1d
Recommended

Hi @Ivy0905,

You wrote:

[...] However, we are intermittently receiving failure responses with an HTTP 400 status code. [...] With regard to these intermittent failures, we would like to inquire whether there is any propagation delay on Apple’s servers when an Apple Pay Identifier is removed and re-registered under a new account, or if there could be any other possible causes for this behavior.

The intermittent 400 errors you've experienced are likely caused by a combination of server-side propagation delays and configuration mismatches introduced during the merchant ID migration.

However, in your situation, the propagation delay is the most likely cause. When you remove a merchant domain from one merchant ID and register it under a new one, Apple's payment gateway infrastructure doesn't update instantly. The Apple Pay servers are globally distributed and changes can take time to fully replicate.

Beyond propagation delay, there are a few common causes of a 400 error on /startSession after a merchant ID migration:

  • Domain name mismatch in the /startSession request body. The domainName field (and possibly the initiativeContext field) in your request body must exactly match the domain registered under your new merchant identifier, including subdomain.
  • Old merchant identity certificate is still being used. This is one of the most common post-migration mistakes. Your server must use the certificate generated from the new merchant ID, not the old one.
  • Domain verification file not server correctly on the new merchant account. After re-registering the domain under the new merchant ID, Apple re-verifies the domain associate file. If the file isn't served correctly, verification silently fails on Apple's side and subsequent /startSession calls return 400. make sure the domain association file downloaded from the new merchant ID (not the old one) is the one currently deployed, as the file content is different per merchant ID.
  • Merchant identity certificate not correctly converted for server use. When exporting the new certificate, an incorrect export or conversion can result in an invalid certificate being used for mTLS with Apple's payment gateway.

Cheers,

Paris X Pinkney |  WWDR | DTS Engineer

HTTP 400 status code
First post date Last post date
 
 
Q