What is IPsec? Internet Protocol Security Explained

IPsec (Internet Protocol Security) is a suite of network-layer protocols that authenticates and encrypts each IP packet travelling between two endpoints. It runs in two modes: transport mode protects only the packet payload and is used host-to-host, while tunnel mode wraps the entire packet inside a new one and is what powers site-to-site and remote-access VPNs. PCI DSS Requirement 4 lists IPsec VPN as an acceptable way to transmit cardholder data across open, public networks, which is why it still underpins most acquirer and processor links.

IPsec, sometimes called an IP-layer VPN, sits below the application layer. That's the bit that matters for payments. TLS protects a single application connection (one HTTPS request, one API call). IPsec protects every packet leaving one network for another, no matter what application sent it. So when a merchant data centre talks to its processor over a leased private link, an IPsec tunnel can carry authorisation traffic, settlement files, batch reconciliation, and management traffic all at once, without each app having to worry about its own crypto.

How IPsec actually works

Three components do the work. The Authentication Header (AH) confirms a packet hasn't been tampered with and came from who it claims, but doesn't encrypt it. Encapsulating Security Payload (ESP) is the one most deployments use — it encrypts the payload (and in tunnel mode, the whole packet) and can also authenticate it. Internet Key Exchange version 2 (IKEv2) is the negotiation layer: it's how the two endpoints agree on which ciphers to use, prove their identities to each other, and rotate keys before they get stale.

Once the tunnel is up, packets get rewritten on the way out and rewritten back on the way in. Anyone sniffing the public internet between the two sites just sees encrypted blobs with the public IPs of the two gateways on them — they can't tell whether it's a card authorisation or someone's email.

Where IPsec shows up in payments

Card processing has used IPsec for the better part of two decades, mostly because acquirers wanted private connectivity to their merchants without the cost of actual leased lines. A typical pattern looks like this:

• Merchant data centre to acquirer or processor — the classic site-to-site IPsec tunnel, usually carrying ISO 8583 authorisation messages, settlement batches, and chargeback files
• POS estate to head office — store routers terminate an IPsec tunnel back to a central concentrator, so card data captured at the till never crosses the public internet in clear
• Cloud workload to on-prem — when a payment app runs in a VPC and needs to talk to a legacy on-prem CRM or ledger
• Remote engineer to production — a few processors still require IPsec remote-access VPN before you can hit the management plane of card systems

For a PCI DSS assessor, an IPsec tunnel is one of the easier ways to satisfy Requirement 4. The cipher suite has to be current (AES-GCM, SHA-256 or better, 2048-bit RSA or ECDSA for IKE auth — DES, MD5, and weak Diffie-Hellman groups are out), the keys have to rotate, and you need to be able to prove all of that. But it's a well-trodden path.

IPsec vs TLS

The honest answer is most new payment integrations skip IPsec and use TLS 1.2 or 1.3 over HTTPS. It's simpler — there's no tunnel to provision, no NAT-traversal headaches, no certificate exchange between two firewalls. A REST API call to an acquirer goes out over the internet protected by TLS, the same way any other web traffic does.

Where IPsec still wins is on the older, chattier links. A site-to-site tunnel is one piece of infrastructure protecting hundreds of flows; TLS would have to be set up, monitored, and renewed for each one. So you'll see TLS for new gateway APIs and IPsec for the legacy 24/7 batch and authorisation links that processors aren't in a hurry to re-platform.

What it means for phone payments

For Paytia and other contact-centre payment platforms, IPsec rarely shows up in the customer-facing path — that's all TLS now. Where it does matter is the back-end leg: the encrypted card data leaving our PCI DSS Level 1 environment for the acquiring bank. Whether that hop runs over IPsec or TLS depends entirely on the acquirer's preference, and several of the larger UK acquirers still mandate IPsec for production card flows.