How HTTPS Works
HTTPS secures the connection between a user's browser and a web server through a process called the TLS handshake. Before any data is exchanged, the browser and server agree on encryption parameters, verify the server's identity, and establish a shared session key. All subsequent data — form submissions, API responses, cookies, and card numbers — travels encrypted through this tunnel.
Understanding each step helps merchants and developers diagnose configuration issues and verify their payment flows are properly secured end to end.
DNS Resolution and TCP Connection
The browser resolves the domain name to an IP address and opens a standard TCP connection on port 443 — the default port for HTTPS. Plain HTTP uses port 80. This step is identical to HTTP; the security layer begins in the next step.
TLS Handshake Begins
The browser sends a "ClientHello" message listing the TLS versions and cipher suites it supports. The server responds with its chosen protocol version and cipher suite, plus its digital certificate containing the server's public key and identity information.
Certificate Verification
The browser validates the server's SSL/TLS certificate against a list of trusted Certificate Authorities (CAs) built into the operating system and browser. It checks that the certificate is valid, not expired, has not been revoked, and was issued for the exact domain being accessed.
Key Exchange
Using asymmetric encryption, the browser and server securely negotiate a shared session key without transmitting it directly over the network. All subsequent communication uses this key with faster symmetric encryption algorithms such as AES-256.
Encrypted Data Exchange
With the handshake complete, all HTTP traffic flows through the encrypted tunnel. Card numbers, session tokens, login credentials, and personal data are unreadable to anyone intercepting the connection — including internet service providers and network middlemen.
TLS vs SSL: What the Labels Mean
You will often see HTTPS described as using "SSL." This is legacy terminology. SSL (Secure Sockets Layer) was deprecated in 1999 following serious vulnerabilities. Modern HTTPS uses TLS 1.2 or TLS 1.3. If your server still accepts SSL 3.0, TLS 1.0, or TLS 1.1 connections, this is a PCI DSS v4.0 violation and must be remediated before your next audit.
Why HTTPS Matters
Consumer trust and regulatory compliance both depend on HTTPS being correctly implemented across your entire site — not just the checkout page. A single HTTP page in your payment flow can expose users to interception attacks and trigger compliance failures that affect your ability to accept cards.
The data on HTTPS adoption and its business impact is unambiguous and has only grown stronger over time.
- Over 95% of Chrome browsing time is spent on HTTPS pages globally, according to Google's HTTPS Transparency Report (2024). Consumers have been conditioned by years of browser warnings to distrust — and abandon — sites that display "Not Secure" in the address bar.
- Google confirmed HTTPS as a ranking signal in 2014 and has progressively increased its weight. Independent analysis by Moz and Ahrefs consistently shows HTTPS pages outranking equivalent HTTP pages, with the gap widening as Google rewards secure-by-default infrastructure.
- PCI DSS v4.0 mandates TLS 1.2 or higher on all systems that store, process, or transmit cardholder data. Fines for non-compliant merchants range from $5,000 to $100,000 per month, with escalating penalties for repeat failures.
Merchants who maintain mixed-content pages — HTTPS pages that load HTTP resources — face both data breach exposure and PCI compliance failures simultaneously. Both risks are preventable with a correct, site-wide HTTPS implementation.
Mixed Content Breaks More Than Trust
An HTTPS page that loads scripts or iframes over HTTP is a "mixed active content" page. Modern browsers block these resources silently, which can break checkout widgets, analytics tags, and third-party payment buttons without displaying an obvious error to the user. Always audit for mixed content after deploying HTTPS.
HTTPS vs. HTTP
The difference between HTTP and HTTPS is not cosmetic or optional for payment-facing sites. It determines whether data can be intercepted in transit, whether browsers trust your domain, and whether you are legally permitted to accept card payments under card network rules.
The table below compares the two protocols across dimensions that matter most to ecommerce merchants and payment developers.
| Feature | HTTP | HTTPS |
|---|---|---|
| Full name | HyperText Transfer Protocol | HTTP + TLS encryption layer |
| Default port | 80 | 443 |
| Data in transit | Plain text — readable by any interceptor | Encrypted — unreadable without the session key |
| Server authentication | None | Certificate validates server identity via CA |
| Browser indicator | "Not Secure" warning (Chrome, Firefox, Safari) | Padlock icon in address bar |
| Google ranking signal | Neutral or slight negative vs HTTPS | Positive ranking factor since 2014 |
| PCI DSS compliance | Not permitted for cardholder data pages | Required for all cardholder data transmission |
| HTTP/2 & HTTP/3 support | HTTP/2 unsupported by browsers in practice | Both HTTP/2 and HTTP/3 require HTTPS |
| Performance | No encryption overhead | TLS 1.3 reduces handshake to 1 round-trip; HTTP/2 multiplexing offsets any overhead |
| HSTS eligibility | No | Yes — browsers can be instructed to always use HTTPS |
HTTPS Is Also a Performance Upgrade
HTTP/2 and HTTP/3 — which deliver significant page-load improvements through multiplexing, header compression, and QUIC transport — are only available over HTTPS in all major browser implementations. Migrating to HTTPS is therefore simultaneously a security upgrade and a performance upgrade for your checkout and product pages.
Types of SSL/TLS Certificates for HTTPS
HTTPS requires a digital certificate issued by a trusted Certificate Authority. Certificates are not interchangeable — they differ in how thoroughly the CA has verified the identity of the certificate holder. Choosing the correct certificate type matters for both consumer trust and compliance audits.
Understanding the validation levels helps merchants select the right certificate for each domain in their payment infrastructure.
Domain Validated (DV) DV certificates verify only that the applicant controls the domain, typically through an automated email or DNS challenge. They are issued in minutes and are available free through Let's Encrypt with automated renewal. DV certificates provide encrypted connections but offer no assurance about the organization behind the domain. They are appropriate for internal tools, staging environments, and content blogs — but are generally insufficient for consumer-facing payment pages.
Organization Validated (OV) OV certificates verify both domain ownership and the legal identity of the organization. The CA confirms business existence through official government and business registries. OV certificates display organization details in the certificate metadata and are the standard choice for ecommerce merchants. Issuance typically takes one to three business days and requires submitting business registration documents.
Extended Validation (EV) EV certificates require the most rigorous vetting process, including legal, physical, and operational verification of the organization by the CA. Historically, browsers displayed the company name in a green address bar; modern browsers surface this information in the certificate details panel. EV certificates are recommended for large merchants, payment platforms, and any site where the cost of impersonation or phishing is high. Issuance takes one to five business days.
Wildcard and Multi-Domain (SAN) Certificates These are DV or OV certificates that cover multiple subdomains (wildcard: *.example.com) or multiple distinct domain names via Subject Alternative Names (SAN). They simplify certificate management for merchants operating multiple storefronts, regional domains, or microservice subdomains under a single certificate.
Best Practices
Implementing HTTPS correctly requires more than purchasing and installing a certificate. Misconfiguration is common and can silently undermine the security guarantees HTTPS is designed to provide, leaving payment flows exposed even when the padlock is visible.
For Merchants
- Enforce HTTPS site-wide, not just on checkout. Redirect all HTTP traffic to HTTPS using 301 permanent redirects at the server or CDN level. Session cookies captured on HTTP login pages can be used to hijack authenticated checkout sessions.
- Audit for mixed content regularly. Use browser developer tools or run your domain through SSL Labs after any third-party script or widget addition. Mixed active content is silently blocked by browsers and can break payment widgets without an obvious error.
- Automate certificate renewal. Let's Encrypt certificates expire every 90 days. Manual renewal workflows fail. Use Certbot with a cron job, or your hosting provider's built-in certificate manager. An expired certificate displays a hard browser block — no user can reach your checkout.
- Verify your payment provider's HTTPS posture. If you use a hosted payment page, embedded iframe, or redirect flow, confirm that your provider enforces HTTPS end to end and holds a current OV or EV certificate. Pass this requirement through to any subprocessors.
- Layer HTTPS with tokenization. HTTPS protects cardholder data in transit. Tokenization removes card numbers from your systems entirely. Both controls are necessary for a complete defense-in-depth payment security posture.
For Developers
- Deploy TLS 1.2 or 1.3 only. Explicitly disable TLS 1.0 and 1.1 in your web server, load balancer, and CDN configuration. These versions are deprecated by all major browsers and prohibited by PCI DSS v4.0. Use Mozilla's SSL Configuration Generator for server-specific directives.
- Enable HTTP Strict Transport Security (HSTS). The
Strict-Transport-Securityresponse header instructs browsers to always connect via HTTPS, eliminating the redirect window that SSL stripping attacks exploit. IncludeincludeSubDomainsandpreloadonce your configuration is verified stable. - Configure a strong cipher suite. Disable RC4, 3DES, NULL, and EXPORT ciphers. Prefer ECDHE key exchange with AES-GCM and ChaCha20-Poly1305 for forward secrecy and performance. Test with SSL Labs and target an A+ rating.
- Enable OCSP Stapling. This reduces certificate validation latency by having the server cache and serve the CA's revocation response, rather than forcing every browser to make a separate request to the CA's OCSP endpoint during the handshake.
- Add a Content Security Policy (CSP) header. HTTPS encrypts the channel but does not prevent malicious scripts from being injected into your page through compromised third-party dependencies. CSP restricts which domains may load resources, reducing exposure to Magecart-style formjacking attacks.
Common Mistakes
Even technically experienced teams make HTTPS configuration errors that leave payment pages vulnerable or trigger compliance failures. Most of these mistakes are invisible to end users until a breach or audit surfaces them.
The following errors appear repeatedly in PCI DSS assessment findings and incident post-mortems.
1. Securing checkout only, not the full session Merchants often apply HTTPS exclusively to /checkout or /payment pages while leaving login, account management, and cart pages on HTTP. Attackers can intercept session cookies on any HTTP page and replay them to access the authenticated HTTPS session — including the payment flow. HTTPS must cover the entire site without exception.
2. Letting certificates expire An expired certificate triggers a hard browser error that completely blocks user access. There is no way for a user to "click through" safely. Automated renewal via Certbot or a managed certificate service is non-negotiable. Set multiple alerting thresholds at 30, 14, and 7 days before expiry.
3. Supporting deprecated TLS versions for backward compatibility Servers that continue to accept TLS 1.0 or TLS 1.1 connections — often to support old Android or IE clients — are in direct violation of PCI DSS v4.0 regardless of whether those connections are ever used. Disable legacy TLS versions at the server level and document the change in your compliance records.
4. Skipping HSTS Without HSTS, a user navigating to example.com (no protocol specified) may briefly connect over HTTP before the 301 redirect fires. This millisecond-scale window is exploitable via SSL stripping, where an active network attacker intercepts the HTTP request and prevents the upgrade. HSTS eliminates the window by instructing browsers to always use HTTPS before making any connection.
5. Assuming HTTPS prevents payment fraud HTTPS authenticates the server and encrypts the channel. It does not authenticate the cardholder. A fraudster using a stolen card on an HTTPS checkout has the same encrypted, certificate-validated connection as a legitimate customer. Preventing payment fraud requires 3D Secure authentication, velocity checks, device fingerprinting, and behavioral fraud scoring layered above the HTTPS foundation.
HTTPS and Tagada
Every integration in Tagada's payment orchestration platform operates exclusively over HTTPS, and the platform actively enforces this requirement across all merchant-configured endpoints. HTTPS is not a configuration option in Tagada — it is the only permitted transport for any data touching payment flows.
When you configure a new PSP connector, webhook destination, or redirect URL in Tagada, the platform validates that the target endpoint uses a valid HTTPS certificate before activating the route. This prevents a common class of misconfiguration errors in multi-processor environments where merchants inadvertently register HTTP callback URLs that expose sensitive transaction data in transit.
HTTPS Enforcement Across Your Entire Orchestration Layer
Tagada enforces TLS 1.2 or higher on all outbound connections to payment processors, fraud tools, and acquiring banks. When you route a transaction across multiple PSPs through Tagada's orchestration engine, each hop in the routing path is independently validated for HTTPS compliance. Merchants operating in multi-PSP environments do not need to audit individual processor connection security — Tagada handles certificate validation, TLS version enforcement, and connection security centrally, shrinking the PCI DSS compliance surface area for teams running complex payment stacks.