Mutual TLS
Last updated: April 29, 2026
You can connect to the Checkout.com APIs privately using Mutual TLS (mTLS). mTLS performs a two-way Transport Layer Security (TLS) certificate exchange, authenticating both the client and server before any data is transmitted.
Checkout.com supports two modes of mTLS connectivity:
- Certificate authentication — The client certificate acts as the credential. Checkout.com validates it against the trusted root registered during onboarding.
- JWT authentication (RFC 8705) — Adds an application-layer token on top of the mTLS connection. The JWT is cryptographically bound to the client certificate and can only be used with the matching private key.
mTLS connections use the following base URLs:
- JWT issuance
- Production:
https://mtls.access.checkout.com - Sandbox:
https://mtls.access.sandbox.checkout.com
- Production:
- API requests
- Production:
https://mtls.api.checkout.com/{path} - Sandbox:
https://mtls.api.sandbox.checkout.com/{path}
- Production:
The {path} value represents the resource from the API. For example, payments/{id}.
To authenticate with JWT over mTLS:
- Request a JWT via
mtls.access.checkout.comusing a valid certificate chain with a matching leaf certificate. - Use that same leaf certificate when making API requests to
mtls.api.checkout.com.
Information
JWTs issued via the mTLS route are incompatible with the standard api.checkout.com endpoint.
mTLS connectivity requires a private certificate authority (CA). The CA is responsible for issuing and digitally signing the leaf certificates, the final and specific certificates in an mTLS chain.
Information
Public and self-signed CAs are not supported.
You are responsible for providing the CA certificates to enable the private connection.
You are responsible for keeping the list of trusted root certificates up to date.
To update the list, follow the steps to enable mTLS and provide Checkout.com with the renewed certificates before the active certificates expire.
To enable mTLS connectivity:
- Generate the certificates with the CA.
- Send the following details to your Checkout.com solution engineer:
- Public certificates in a PEM, CRT, or CER file format, so that Checkout.com can store these as trusted roots
- The common name (CN) from your leaf certificate's
Subjectproperty
Your Checkout.com solution engineer will confirm when the setup is complete so that you can begin testing.
To form a full certificate chain for validation, you must provide the leaf and intermediate certificates with your HTTP requests.
Use the following cURL command to test the mTLS connection in your test environment:
If you receive a Connection reset by peer error, the certificate provided with the request could not be validated. This may be because:
- The certificate chain is incomplete because intermediate certificates were not provided.
- The leaf certificate was issued by an untrusted issuer.
- One or more certificates in the chain are invalid or expired.
If you receive a 401 status code, the client certificate was successfully validated, but the CN in the leaf certificate did not match the CN provided during setup. Check the CN values.