Hello! We use Apple's "master account" scheme to register new clients trough API due to the fact that the number of merchant IDs in a developer account cannot exceed 100 records. It's been almost a year since we successfully used the master account ( ex. "merchant.com.xxx") and register clients via Postman. At the moment, the certificates for the master merchant ID start to expire on July 11 which will affect all customers which is under Master ID. We know that when updating certificates at the identifier level(our master id), new universal identity certificate files that we use to send to the merchants (merchant_id.pem, privkey.key) will be generated for authentication on the merchant side, as well as a new keystore. Since many of our clients are integrated with current files and keystores and have live traffic, we would like to know—is it possible to update certificates on the master account without changing the keystores and certificate identities? The impossibility of this will entail a large gap when switching to new certificates. Thanks in advance for your answer.
Hi @TBAbnxxm1337,
You wrote:
[...] is it possible to update certificates on the master account without changing the keystores and certificate identities?
The short answer is: No — not fully. But downtime can be completely avoided with the right approach.
Regardless of the solution, keystones must change. Apple's certificate issuance always requires a new CSR, which means a new key pair is generated. The private key changes on every renewal — there is no mechanism in Apple's PKI to re-sign an existing key. Since the private key is different, any keystore or .p12 bundle that contains both the certificate and the private key must also be updated.
There is a minor bit of relief if your clients load the certificate and private key as separate files (e.g., merchant_id.pem and privkey.key independently), you can reuse the existing private key by generating the new CSR from it:
# Generate a new CSR from your EXISTING private key
openssl req -new \
-key privkey.key \ # <-- same key, no change to this file
-out renewal.csr
Submit that CSR to Apple for Apple Pay, and only the .pem file changes. However, if clients bundle both into a PKCS#12 / JKS keystore, both files change regardless.
Despite all of this, you can still achieve zero downtime. Apple Pay allows two active merchant identity certificates simultaneously for the same Merchant ID. This is the mechanism designed specifically for this situation.
The rotation procedure is:
- Generate and issue the new certificate now — both certs are valid simultaneously.
- Test the new cert against Apple's sandbox endpoint to confirm it works.
- Stage the new cert in production alongside the old one — run both in parallel.
- Migrate clients to the new cert at your own pace during the overlap window.
- Decommission the old cert only after confirmation 100% of traffic has moved.
This fives you weeks or months of overlap to coordinate the migration with no gap in service.
The real issue is that the "main" merchant certificate has been distributed to external clients. This is the root cause of your coordination problem. Every future renewal will face this same challenge.
The correct aggregator architecture is to centralize validation so clients never hold the certificate at all.
Under this model, clients call your API endpoint to get the merchant session. When you rotate certs, you update one place and clients are completely unaffected. This is the recommended pattern for aggregators.
Cheers,
Paris X Pinkney | WWDR | DTS Engineer
