A card-present transaction has to clear authorization in under two or three seconds end to end, and a meaningful share of that budget is spent before a single byte of application data moves. If the connection between a gateway and a processor needs a fresh TCP handshake and a fresh TLS handshake on every call, the round trips add up to real, measurable delay, and that delay sits on top of whatever the routing and infrastructure layer already costs you. This piece stays below that layer and looks directly at the handshake: where the round trips actually come from, which TLS 1.3 and QUIC features remove them without changing the security guarantees a payment API depends on, and which shortcuts carry too much risk to ship on a payment path even though they work fine for a content site.
Why a 100 Millisecond Handshake Is a Business Problem, Not Just a Network One
A TCP and TLS handshake that costs 80 to 150 milliseconds reads as a rounding error to most engineers outside the payments team. It is not one to the business. Authorization latency feeds directly into cart abandonment, into issuer timeout thresholds, and into the per-transaction SLA a payment gateway has signed with its merchants.
Processors and card networks enforce hard timeout windows, often in the single-digit seconds, across the full chain from merchant to acquirer to issuer and back. A handshake that eats 100 milliseconds per hop, repeated across two or three hops in that chain, is not a rounding error against a three-second budget. It is a meaningful fraction of it, and it is fraction you lose before the authorization logic has done any work at all.
The handshake cost also compounds unevenly. A customer on a fast fiber connection to a nearby data center barely notices it. A customer on a mobile network crossing a continent to reach a gateway feels every extra round trip as real, multiplied latency, because each round trip on a high-latency path costs more wall-clock time than the same round trip on a short one. Fixing the handshake is one of the few latency levers that helps the worst-case customer more than the best-case one, which is exactly the customer a payment API can least afford to lose mid-checkout.
Counting the Round Trips: From TCP SYN to First Application Byte
Before optimizing anything, it helps to count what a cold connection actually costs. A plain TCP handshake is one round trip: SYN, SYN-ACK, ACK. TLS 1.2 added two more round trips on top of that in its full handshake, which is why TLS 1.2 over a fresh TCP connection could cost three round trips before any application data moved.
TLS 1.3 cut that to one round trip for a full handshake, so a cold connection running TLS 1.3 over TCP costs two round trips total: one for TCP, one for TLS. On a path with 80 milliseconds of one-way latency between a merchant’s gateway and a processor’s data center, that is roughly 160 milliseconds spent before the first application byte arrives, before the processor has even started evaluating the authorization request.
Each of those round trips is pure wall-clock time that no amount of application-level optimization can claw back, because the packets simply have to cross the distance and come back. The only ways to reduce it are to remove round trips from the handshake itself, to avoid a cold handshake altogether by reusing an existing session or connection, or to shorten the physical or network distance the packets travel, which is the layer covered separately from this one. Everything in this article is about the first two.
TLS 1.3’s 1-RTT Handshake and the Real Risk Behind 0-RTT Early Data
TLS 1.3’s move to a single round trip for a full handshake is the single biggest handshake latency win available to a payment API, and it should be table stakes at this point. If a gateway or processor endpoint is still negotiating TLS 1.2 by default, that is the first thing to fix, independent of anything else in this piece.
TLS 1.3 also defines a 0-RTT mode, where a returning client sends application data in its very first flight of packets, before the handshake has finished, using a key derived from a previous session. This is where payment engineers need to slow down. 0-RTT data has no protection against replay. An attacker who captures that first flight can resend it, and the server has no handshake-level way to distinguish the replay from the original request, because the point of 0-RTT is that the server processes the data before confirming the client is who it claims to be.
For a GET request to a content server, a replayed request is harmless. For a payment authorization call, a replayed request can mean a duplicate charge, a duplicate refund, or a duplicate transfer, and that is not a risk that belongs anywhere near an authorization path. Some teams try to mitigate this with idempotency keys at the application layer, and idempotency keys are good practice regardless, but they are a different control solving a different problem, and relying on them to paper over 0-RTT replay at the transport layer is the kind of shortcut that works until a specific adversarial scenario proves it doesn’t.
The practical guidance for a payment API: enable TLS 1.3’s 1-RTT handshake everywhere, and leave 0-RTT early data disabled on any endpoint that accepts a state-changing request. If a CDN or load balancer in front of the API has 0-RTT on by default, check it explicitly rather than assuming it is off.
Session Resumption and Tickets: Skipping the Handshake for Returning Clients
The handshake cost that matters most in production is not the cold handshake, it’s the one a returning client pays unnecessarily because session resumption isn’t configured well. TLS session resumption, via session tickets in TLS 1.2 and TLS 1.3’s PSK-based resumption, lets a client and server skip the full cryptographic handshake on a reconnect and instead derive new session keys from a previously established secret.
Done correctly, this turns a 1-RTT full handshake into a 0-RTT or 1-RTT abbreviated handshake, without the replay risk that comes with sending early application data, because resumption on its own doesn’t require the client to send request data before the handshake completes. That distinction matters: resumption and 0-RTT early data are often discussed together because TLS 1.3 supports both through the same PSK mechanism, but a payment API can adopt resumption for the handshake speedup while still refusing early data for the request itself.
A few things determine whether resumption actually helps in a gateway-to-processor context:
- Ticket lifetime and rotation. Tickets that expire too quickly force full handshakes more often than necessary; tickets that live too long increase the exposure window if a ticket key is ever compromised. Most payment infrastructure settles on ticket lifetimes measured in hours, not days, with regular key rotation.
- Ticket key synchronization across load balancers. If a gateway sits behind multiple TLS-terminating nodes and they don’t share ticket encryption keys, a client that resumes against a different node than the one that issued the ticket will fail resumption and silently fall back to a full handshake. This is a common, easy-to-miss source of handshake latency that looks like a configuration problem rather than a protocol one.
- Connection affinity for long-lived integrations. Server-to-server calls between a gateway and a processor are often better served by keeping connections open (covered below) than by relying on resumption at all, since resumption only helps when a connection has already been torn down.
Session resumption is worth tuning carefully for client-facing TLS termination. For the gateway-to-processor leg, connection reuse usually matters more.
TCP Fast Open: Why Most Payment Networks Still Keep It Disabled
TCP Fast Open (TFO) lets a client include application data in its initial SYN packet, using a cookie from a previous connection to skip the normal three-way handshake wait. In principle it saves a full round trip on repeat connections, which sounds like exactly what a payment API wants.
In practice, most payment networks keep it off, for reasons that mirror the 0-RTT problem. TFO data arrives before the handshake is complete and before the server has confirmed the client isn’t replaying a captured SYN packet. An attacker who intercepts a TFO cookie and the accompanying data can replay that SYN, and depending on what the first bytes of application data trigger, that replay can have the same duplicate-transaction risk as TLS 0-RTT replay, compounding rather than independent of it when both are enabled together.
There’s a second, more mundane reason TFO stays disabled on a lot of payment infrastructure: middlebox compatibility. A meaningful fraction of corporate firewalls, older load balancers, and some ISP-level network equipment still mishandle TCP options they don’t recognize, and TFO’s cookie option is exactly the kind of extension that can cause a connection to stall or drop on a path that doesn’t expect it. For a payment API, a connection that silently fails because an intermediary firewall choked on a SYN option is a worse outcome than a connection that’s merely a few milliseconds slower. The cautious default, shared by most PCI-scoped environments, is TFO disabled on internet-facing payment endpoints, with it reserved at most for trusted, fully-controlled internal links where both ends are known and the replay surface is closed off by other means.
Keepalive Tuning and Connection Pooling Across Gateway and Processor Calls
The cheapest handshake is the one you never have to do a second time. For the server-to-server calls between a payment gateway and an acquiring processor, or between microservices inside a payment stack, connection pooling and keepalive tuning typically deliver more latency reduction than any single handshake optimization, because they eliminate the handshake from the request path entirely for the vast majority of calls.
A few settings are worth checking directly rather than assuming the defaults are fine:
- Keepalive timeout on both ends. If a load balancer’s idle timeout is shorter than the backend’s, connections get torn down from one side without the other knowing, and the next request pays for a fresh handshake that didn’t need to happen.
- Maximum requests per connection. Some HTTP client and server libraries cap how many requests a single connection can serve before forcing a reconnect, as a defensive measure against memory growth. For a high-throughput processor integration, a cap set too low recreates the same handshake cost you were trying to avoid.
- Pool size versus concurrency. A connection pool sized below peak concurrent request volume forces new connections, and therefore new handshakes, exactly at the moments when latency matters most: traffic spikes.
- DNS re-resolution behavior. Long-lived pooled connections can mask a DNS change behind a processor’s load balancer for longer than intended, which is a different problem but worth knowing about when you tune pools for longevity over freshness.
None of this is specific to payments, but the cost of getting it wrong is specific to payments, because a handshake that only happens occasionally for a low-traffic internal service is invisible, while the same handshake happening on a fraction of authorization calls at peak volume shows up directly in tail latency.
QUIC and HTTP/3: Deciding Whether Payment Traffic Should Leave TCP Behind
QUIC bundles the transport and TLS handshake into a single round trip and carries TLS 1.3 natively, which on paper makes it a strong candidate for cutting handshake latency on payment traffic. It also handles connection migration better than TCP, which matters for mobile clients moving between networks mid-session.
QUIC also has its own 0-RTT mode, carrying the same replay exposure described above, so the same rule applies: usable for client-facing read paths, not for state-changing authorization calls, without the same idempotency caveats.
The bigger practical question for a payment API isn’t the protocol’s handshake math, it’s the surrounding infrastructure. QUIC runs over UDP, and a meaningful number of corporate networks, some mobile carriers, and some older middleboxes still rate-limit or outright block UDP traffic, which means a payment API that moves exclusively to HTTP/3 risks losing connectivity for a subset of clients rather than speeding it up. Most fintechs that have adopted QUIC have done so for client-facing edge traffic, with automatic fallback to TLS 1.3 over TCP, rather than for the gateway-to-processor leg, where both ends are known, controlled, and already optimized through connection pooling. QUIC is worth a pilot on inbound client traffic; it’s a harder sell for backend-to-backend calls where TCP connection reuse already removes most of the handshake cost.
Measuring Handshake Latency in Production Instead of Guessing at It
Every recommendation above depends on knowing where your actual handshake time goes, and that’s not something to infer from protocol documentation. TCP connect time, TLS handshake time, and time to first byte are three separate measurements, and conflating them hides which part of the chain is actually slow.
Most TLS libraries and load balancers expose handshake timing directly: TLS handshake duration, resumption hit rate, and 0-RTT acceptance rate are standard metrics in modern load balancers and service meshes. Capturing those per upstream, rather than as a single blended average, usually reveals that one specific processor integration or one specific region is driving most of the tail latency, rather than the handshake being uniformly slow everywhere.
It’s also worth measuring resumption hit rate specifically. A configuration that looks correct on paper can still have a low resumption rate in practice if ticket keys aren’t synchronized across nodes or if client libraries aren’t caching sessions the way you assume they are. Tracking that rate over time, and alerting when it drops, catches configuration drift before it shows up as a general latency regression that’s harder to trace back to its cause.
Handshake tuning works best as one layer in a stack of latency decisions rather than a standalone fix. For the routing and infrastructure choices that sit above it and compound with everything covered here, see the infrastructure stack that actually cuts cross-region latency.