Mutual TLS (mTLS) extends TLS so both client and server present X.509 certificates during the handshake. Card networks require mTLS for token service APIs: only enrolled token requestors with network-issued client certificates can provision tokens or fetch cryptograms.
mTLS certificate lifecycle is operational work: renewals, revocation checks, separate sandbox and production credentials, secure storage in HSM or secret managers. Expired client certs cause hard outages with no graceful degradation because networks reject the connection entirely.
Merchants rarely hold network mTLS certs themselves when using a PSP-only stack; the PSP’s vault acts as intermediary. Direct scheme access via Veliro means Veliro operates mTLS to networks while you integrate with REST and API keys, a deliberate simplification of a complex trust chain.
Understanding mTLS clarifies why “turn on network tokens” in a PSP dashboard is not the same as owning tokens under your TRID. The certificate identity on the wire determines who the network considers the token requestor.
Calendar mTLS renewals ninety days ahead with network ops on the hook; unlike TLS web certs, scheme client certificates often require manual enrollment workflows that cannot be fully automated with ACME.