PlatformPayments Apps API

mTLS for Payments Apps
Client certificate is being rotated

Shopify will rotate the client certificate it uses to prove "this request really came from Shopify" starting June 15, 2026. The new certificate is signed by the same Certificate Authority (CA), so apps doing standard mTLS verification are unaffected. Only apps doing custom certificate verification need to take action by June 15.

On this page
  1. What's actually happening (30-second overview)
  2. Diagram: What mTLS is verifying
  3. Two deadlines: timeline
  4. Do I need to take action? Decision flow
  5. Cases that require action vs. cases that don't
  6. What to do (for custom verification)
  7. 5 key points engineers should know
  8. 3 business use cases
  9. One-line summary for pitching

1What's actually happening

Payments Apps use mTLS (mutual TLS) and a client certificate to confirm "is the caller hitting me right now really Shopify?"
That Shopify-side client certificate will be rotated to a new one starting June 15, 2026. The new certificate issigned by the same Certificate Authority (CA)as before, so standard verification requires no action.

Standard mTLS verification: no impact

Apps that only check whether the certificate chains up to a trusted CA will accept the new certificate as-is, since the CA is unchanged.No action required.

Custom verification: action required

Apps that check certificate-specific fields like the Common Name (CN) need toupdate their verification logic to accept the new certificate by June 15.

2Diagram: What mTLS is verifying

Certificate Authority (CA) Same CA signs both old and new certificates Shopify (client) Old client certificate New client certificate (1) Present certificate with request Payments App (server) (2) Validate the presented certificate Standard: Is the CA chain valid? Custom: Also inspect specific fields such as CN (3) Authentication OK = Confirmed the peer is Shopify Continue payment processing
mTLS (mutual TLS)What it is: Regular TLS only verifies the server's authenticity, but mTLShas the client also present a certificate so both sides verify each other's identity. Payments Apps use this to verify that "the caller is actually Shopify."
What's being updated this time is the client certificate Shopify presents. The signing CA is not changing, so standard validation that checks the CA chain will automatically trust the new certificate.

3Two deadlines: Timeline

Now No action needed if you use standard validation June 15, 2026 New certificate rollout begins / deadline for custom validation updates July 24, 2026 Current (old) certificate expires
6/15

The day the new certificate rollout starts

From this day, Shopify starts using the new client certificate. Apps performing custom validation mustbe ready to accept the new certificateby this date.

7/24

The day the old certificate expires

The current certificate expires on this date. To keep service uninterrupted, the update must be completed before then — that's the reason for this change.

4Do I need to take action? Decision flow

How does your Payments App validate the certificate? Does it inspect certificate-specific fields like CN? No (standard mTLS) No action needed Signed by the same CA Yes (custom validation) Action required By June 15 Update validation logic

5Comparison: when action is required vs. not

ItemStandard mTLS verificationCustom certificate verification
What is being verified Whether the certificate chains up to a trusted CA Certificate-specific fields such as CN (Common Name)
Impact of the new certificate No impact Passes through as-is since it is signed by the same CA Impacted May be rejected if the specific fields change
Required action None Required Update verification to accept the new certificate
Deadline — By June 15, 2026
If you are unsure whether you are doing "standard" or "custom" verification, double-check.CN If you have logic that string-matches against the certificate fingerprint or similar values, that counts as custom verification.

6What you need to do (for custom verification)

① Inventory your verification logic

Identify which fields of the certificate (CN, SAN, or other specific values) your app inspects to make its decision.

② Update to accept the new certificate

Modify your verification logic so authentication still passes with the new certificate.By June 15, 2026is when this needs to be in place.

③ Check the certificate details

For the actual values of the old and new certificates, refer to the "certificate details" linked from the changelog (this article does not include the specific values).

④ Verify connectivity before and after the switchover

Before the old certificate expires on 7/24, confirm in a staging environment that authentication with the new certificate works as expected.

Apps performing standard mTLS verification (CA chain validation only) do not need to takeanyof the above steps. Because the new certificate is signed by the same CA, there is no impact on live Payments Apps.

75 points engineers should keep in mind

mTLS

1. What is being updated is "Shopify's client certificate"

This refers to the certificate the Payments App uses to confirm that "the other party is the real Shopify." It is not the app's server certificate.

CA

2. The CA does not change — chain verification is unaffected

The new certificate is signed by the same certificate authority as the current one. If you are only doing chain verification against the CAs in your trust store, it will be trusted automatically.

3. What breaks is hardcoded CN / certificate-specific fields

CN Verification that directly matches against certificate-specific values can fail with the new certificate if those values change. This is the only pattern that requires action.

4. Two deadlines: 6/15 and 7/24

6/15 = start of the new certificate rollout and the deadline for updating custom verification. 7/24 = expiry date of the old certificate. For zero-downtime operation, prepare with this order in mind.

details

5. Check the actual certificate values via the link in the changelog

The body of the announcement focuses on operational notices, and concrete field values such as the CA name and the old/new certificates arenot included in this article's body. For details, refer to the "certificate details" linked from the article. If your verification logic depends on the CN, be sure to confirm the actual value differences against the real certificates.

8Three use cases you can apply to your work

Old cert New cert
USE CASE 1

Zero-downtime certificate renewal for your own Payments App

Problem
Your own Payments App checks the certificate's CN directly in a legacy implementation (custom verification). If the CN changes with the new certificate, payments could halt after the 7/24 expiry.
Action
By 6/15, take stock of the verification logic and update it to accept the new certificate. At the same time, shift toward CA chain-based verification so it can withstand future renewals as well.
Outcome
Payment processing continues uninterrupted even after the old certificate expires. Eliminates emergency response work every time a certificate is renewed.
Technical notes
Confirm the concrete field values of the old and new certificates via the "certificate details" in the changelog (not included in the article body). Verify connectivity with the new certificate in a staging environment in advance.
USE CASE 2

Cross-audit of Payments Apps under contract / maintenance

Problem
You maintain Payments Apps for multiple clients but don't have a clear picture of which use standard mTLS and which use custom verification. There is a risk of missing the 6/15 deadline.
Action
Audit certificate verification code across all apps and extract those that depend onCN or other specific fields. Build a list of apps requiring action and plan backwards from 6/15.
Outcome
Make the scope of impact visible early and proactively eliminate the risk of payment outages. Earn client trust through proactive communication.
Technical notes
Apps using standard verification (CA chain only) can be ruled out as not requiring action, so you can focus effort on the apps that actually need work.
USE CASE 3

Permanent design for certificate-rotation resilience

Problem
A structure where, even when the CA is the same, CN-pinned verification breaks every time the certificate itself is renewed — as in this case — triggering emergency response.
Action
Stop pinning verification to the CN or fingerprint, and permanently shift the policy to chain verification against the CA trust store as the standard.
Outcome
No code changes will be needed for future certificate renewals, continuously reducing the operational dependence on specific individuals and the risk of outages.
Technical notes
If additional constraints on specific fields are required for business reasons, choose items with low update frequency, or externalize them as configuration values so they can be switched instantly.

9One-line summary you can use in proposals

"Shopify is updating the mTLS client certificate used for Payments Apps starting 2026/6/15 (the old certificate expires 7/24).
It is signed by the same CA, so apps using standard mTLS verification require no action.
Custom validators that inspect certificate-specific fields like CN are the only ones that need updates by 6/15."