How SSL/TLS Works
SSL/TLS secures communication through a process called the handshake, which establishes an encrypted channel before any application data is transmitted. Understanding the steps helps merchants and developers know exactly what they are relying on to protect payment credentials.
Client Hello
The browser (or API client) initiates the connection by sending a list of supported TLS versions and cipher suites to the server, along with a random value used later in key generation.
Server Hello & Certificate
The server selects the highest mutually supported TLS version and cipher suite, then sends its encryption certificate — containing its public key and identity — signed by a trusted Certificate Authority.
Certificate Verification
The client checks the certificate against its trusted CA store, verifies it has not expired, and confirms the domain name matches. If anything fails, the connection is aborted and a security warning is shown.
Key Exchange
Both parties use the certificate's public key (and ephemeral keys in TLS 1.3) to derive a shared session secret without ever transmitting it directly over the network. This is where forward secrecy is established.
Encrypted Channel Open
With the session keys established, all subsequent data — including card numbers, CVVs, and authentication tokens — travels encrypted. Neither passive eavesdroppers nor active network intermediaries can read the payload.
Why SSL/TLS Matters
The payment industry's reliance on SSL/TLS is not theoretical — the consequences of operating without it are immediate and severe. The data consistently shows that both buyers and regulators treat TLS as a baseline expectation, not an optional enhancement.
Google's Transparency Report shows that over 95% of page loads in Chrome are now served over HTTPS, meaning a non-TLS checkout page stands out immediately as anomalous and untrustworthy. Studies by the Baymard Institute have found that 18% of users abandon checkout specifically because they do not trust the site with their card details — and a missing or invalid certificate is the most visible trust signal of all.
From a compliance standpoint, the PCI Security Standards Council mandated the retirement of TLS 1.0 by June 2018 and strongly recommends TLS 1.2 or higher. Any merchant still running TLS 1.0 or 1.1 is out of scope for a passing PCI compliance assessment. The Ponemon Institute's 2023 Cost of a Data Breach Report put the global average cost of a payment data breach at $4.45 million — a figure that dwarfs any investment in proper certificate management.
TLS Version Support
As of 2024, TLS 1.0 and 1.1 are disabled by default in all major browsers (Chrome, Firefox, Safari, Edge). If your payment API or checkout page still negotiates these versions, expect connection failures with modern clients.
SSL/TLS vs. End-to-End Encryption
SSL/TLS and end-to-end encryption are both essential security controls in payment systems, but they protect data at different points in its journey and provide different guarantees. Conflating the two is a common source of compliance misunderstanding.
| Dimension | SSL/TLS | End-to-End Encryption (E2EE) |
|---|---|---|
| Scope | Protects data between two network endpoints (client ↔ server) | Protects data from originating device to final destination, passing through intermediaries opaquely |
| Who can decrypt | The receiving server can decrypt and read the data | Only the intended final recipient can decrypt |
| Intermediary access | The server (e.g., payment gateway) sees plaintext after decryption | No intermediary — including the platform operator — sees plaintext |
| Use in payments | Mandatory for all card data transmission | Used in point-to-point encryption (P2PE) solutions |
| Certificate required | Yes — issued by a CA | No standard certificate requirement |
| PCI DSS relevance | Required for data in transit (Requirement 4) | Used to reduce PCI scope via P2PE (Requirement 3) |
| Protects against | Network eavesdropping, MITM attacks | Insider threats, compromised intermediary servers |
The practical implication: a payment platform can have valid TLS on every endpoint and still expose card data to its own infrastructure. E2EE or tokenization addresses that residual risk.
Types of SSL/TLS Certificates
Not all TLS certificates offer the same level of identity assurance. Payment pages in particular should use certificates that clearly signal legitimacy to buyers.
Domain Validated (DV) certificates are the most basic tier. The CA verifies only that the applicant controls the domain — no company identity check is performed. They are issued in minutes and are appropriate for internal tools or blogs but lack the visual trust signals expected on a checkout page.
Organization Validated (OV) certificates require the CA to verify the legal existence of the organization. The company name appears in the certificate details. This is the minimum recommended tier for any page that accepts payment input.
Extended Validation (EV) certificates involve the most rigorous identity verification — legal name, address, and operational existence. While major browsers removed the green address bar in 2019, EV certificates still provide stronger identity assurance visible in certificate inspection and remain preferred by enterprise payment platforms.
Wildcard certificates (e.g., *.tagada.io) cover all subdomains of a single domain and are useful for platforms that run checkout on subdomains like checkout.tagada.io. However, a compromise of the private key exposes all subdomains simultaneously — a risk to weigh against operational convenience.
Multi-domain (SAN) certificates cover multiple distinct domains in a single certificate and are common in payment orchestration platforms that operate across several branded domains.
Best Practices
Correct TLS configuration is one of the highest-leverage security investments a payment business can make. The following practices reflect current PCI DSS requirements and industry standards.
For Merchants
- Enforce HTTPS sitewide. Redirect all HTTP traffic to HTTPS with a 301 permanent redirect and set HTTP Strict Transport Security (HSTS) headers so browsers never attempt plain HTTP connections.
- Do not host payment forms on pages without TLS. Even if you embed a hosted payment field from a provider, the parent page must be served over HTTPS — browsers will block mixed content.
- Monitor certificate expiry. Use an automated monitoring service or Let's Encrypt with auto-renewal. Set expiry alerts at 30 and 7 days minimum. A lapsed certificate on your checkout is a complete outage.
- Require TLS 1.2 or higher on your payment provider integrations. If your server-side code calls payment APIs, ensure your HTTP client is configured to reject TLS 1.0/1.1 connections.
- Display trust indicators. Show the padlock, your company name in the certificate (OV or EV), and security badges where appropriate. These directly reduce checkout abandonment.
For Developers
- Test your TLS configuration with SSL Labs. Qualys SSL Server Test grades your configuration and flags weak cipher suites, insecure renegotiation, and outdated protocol support. Aim for an A or A+ rating.
- Enforce strong cipher suites. Disable RC4, 3DES, and export-grade ciphers. Prefer ECDHE cipher suites for forward secrecy.
- Enable OCSP Stapling. This reduces TLS handshake latency by bundling the certificate revocation check into the handshake rather than requiring a separate CA lookup.
- Pin certificates for mobile SDKs. If you build a native payment app, implement certificate pinning to defend against rogue CA certificates being installed on user devices.
- Validate TLS certificates in server-to-server calls. Never disable certificate validation (
verify=Falsein Python requests, for example) in production code that touches payment APIs — this creates a trivially exploitable MITM vulnerability.
Common Mistakes
Even experienced engineering teams make predictable TLS mistakes that introduce compliance gaps or security vulnerabilities.
Running mixed content. A page served over HTTPS that loads scripts, iframes, or images over HTTP is flagged by browsers and breaks the security model. Payment pages are especially vulnerable — a single HTTP-loaded script can intercept form input before it reaches the TLS layer.
Forgetting internal services. Merchants often correctly configure TLS on their public checkout page but leave internal payment microservices, webhook endpoints, or admin APIs on HTTP. PCI DSS Requirement 4 applies to all transmission of cardholder data, not just public-facing pages.
Using self-signed certificates in production. Self-signed certificates provide encryption but no identity verification. They trigger browser warnings that destroy customer trust and are explicitly prohibited for public-facing payment pages under PCI DSS.
Ignoring certificate chain completeness. A certificate is only as trustworthy as its chain back to a root CA. Missing intermediate certificates cause validation failures on some clients — particularly older Android devices and certain server-to-server HTTP clients — while appearing fine in desktop browsers.
Neglecting TLS on outbound webhooks. If your platform sends payment event webhooks to merchant endpoints, those endpoints must also serve valid TLS. Sending order confirmation data containing card-adjacent information to an HTTP endpoint is a data breach risk and a PCI violation.
SSL/TLS and Tagada
Tagada Pay's payment orchestration layer enforces TLS 1.2 as a minimum on all inbound and outbound connections — no legacy protocol negotiation is permitted. This ensures that merchants integrating Tagada's APIs inherit a hardened transport baseline without additional configuration.
Tagada and TLS Compliance
When you route payments through Tagada, all connections between your checkout, Tagada's orchestration layer, and downstream processors are encrypted with TLS 1.2 or TLS 1.3. Tagada's infrastructure is assessed against PCI DSS requirements, which means the transport security of the orchestration layer is covered under Tagada's compliance scope — reducing your own PCI surface area.
Merchants using Tagada's hosted checkout components receive valid TLS out of the box — the payment form lives on Tagada's TLS-certified domain, which means card input never traverses the merchant's own server unencrypted. This architecture directly reduces the merchant's PCI DSS scope while maintaining the TLS protections buyers expect.