Quick answer: If you take payment cards online, PCI DSS requires you to disable early TLS (TLS 1.0 and older SSL) for environments that handle card data by 30 June 2018. Move checkout and payment endpoints to TLS 1.2 (and strong ciphers), confirm with your host and payment provider, and test so legitimate customers are not locked out while insecure protocols are turned off.
This is a checklist-style guide for merchants and site owners, not a QSA audit document. When in doubt, ask your host, gateway and Qualified Security Assessor. The deadline is firm enough that waiting until June is a bad plan.
Why this deadline exists
Older SSL/TLS versions have known weaknesses. The payments industry has been pushing merchants and providers toward TLS 1.2 for years. PCI DSS requirements for early TLS migration culminate in disabling TLS 1.0 (and SSL) for cardholder data environments by 30 June 2018. TLS 1.1 is also on the path out of favour; TLS 1.2 is the practical target today.
If your checkout still negotiates TLS 1.0, you risk failing PCI assessments, payment provider requirements and, more importantly, exposing customers to weaker encryption.
Related background on certificates and HTTPS generally sits in our Let’s Encrypt and HTTPS migration SEO guides. This article focuses on protocol versions for payment pages.
What “payment pages” means in practice
Think beyond the single /checkout/ URL:
- Your hosted checkout pages
- Payment gateway iframes and redirect endpoints you control
- APIs that pass or receive card data (most modern setups avoid touching raw PAN; still secure the session)
- Admin tools that handle card-related operations if in scope
- Any subdomain that is part of the cardholder data environment
If you use a full redirect to a gateway (PayPal hosted, Stripe Checkout-style flows, hosted pay pages), much of the card entry UI may live on the provider. You still must harden your site: account login, order review over HTTPS, callbacks, and any pages that sit in scope per your PCI approach (self-assessment questionnaire type depends on how you integrate).
Checklist: what to change
1. Ask your host which TLS versions are enabled
Open a ticket or check the control panel. You want TLS 1.2 enabled and TLS 1.0 (and SSL 3.0) disabled on the virtual host that serves checkout. Many hosts already default to modern protocols; some shared environments still allow TLS 1.0 for “compatibility.”
2. Confirm your CDN / reverse proxy
Cloudflare and similar proxies terminate TLS. Check their SSL/TLS settings so the edge does not offer TLS 1.0 to browsers even if the origin is fine (or the reverse). Align edge and origin.
3. Check certificates are valid and current
Protocol version and certificate validity are separate. Expired certs break checkout regardless of TLS 1.2. Automate renewal where you can.
4. Review payment gateway requirements
Stripe, PayPal, Adyen, Authorize.Net and banks have published TLS 1.2 requirements and timelines. Read your provider’s notices. Some already refuse TLS 1.0 connections from integrations.
5. Scan your site
Use SSL Labs’ SSL Test (Qualys) or your scanner of choice on the checkout hostname. Look for offered protocols and overall grade. Retest after changes.
6. Test real browsers you still support
Disabling TLS 1.0 mainly affects very old browsers and OS combinations (older Android, ancient desktop browsers). Decide whether those users must upgrade or use another payment path. Document the business decision.
7. Update internal integrations
ERP, fulfilment and middleware that call payment APIs over TLS 1.0 need upgrades too. A pretty checkout does not help if your back-office sync fails PCI review.
8. Coordinate with developers on cipher suites
Weak ciphers can undermine a modern protocol version. Use current recommended cipher lists from your stack vendor or Mozilla SSL Configuration Generator (pick an intermediate profile unless you have exotic constraints).
9. Fix mixed content on checkout
HTTPS pages loading HTTP scripts or forms undermine trust and can break modern browsers. Clean mixed content as part of the same hardening pass. Chrome’s Not Secure warning direction makes plain HTTP increasingly painful anyway.
10. Document for PCI evidence
Keep notes: date TLS 1.0 disabled, SSL Labs screenshot or report, host confirmation, gateway emails. Auditors and partners ask for evidence.
WooCommerce and common CMS stores
On WooCommerce, the store runs on your WordPress host; card data often goes to a payment plugin’s gateway. Still:
- Force HTTPS for checkout pages
- Keep WordPress, WooCommerce and payment plugins updated (WordPress security habits apply)
- Disable TLS 1.0 at the server/CDN
- Test add-to-cart through paid order on a real card in sandbox/live as appropriate
Plugins cannot “enable TLS 1.2” by themselves if the server still offers only older protocols.
Customer communication
You rarely need a marketing campaign for TLS versions. If analytics show a slice of users on ancient browsers, a short FAQ (“update your browser to pay securely”) on the checkout help page is enough. Do not surprise a large corporate buyer segment without warning if your B2B traffic includes locked-down old IE environments; give them time to arrange exceptions or alternate payment.
Timeline to follow now (mid-March)
| When | Action |
|---|---|
| This week | SSL Labs scan; open host/CDN tickets |
| Within two weeks | Disable TLS 1.0 on staging; regression test checkout |
| Before end of April | Disable on production; monitor error rates |
| May | Re-scan; file evidence; confirm gateway compliance mail |
| By 30 June 2018 | Early TLS must be off for in-scope payment flows |
Waiting until late June leaves no room for stubborn hosting stacks.
How this interacts with HTTP/2 and modern stacks
Many hosts enable HTTP/2 alongside modern TLS. That pairing is good for performance, but HTTP/2 does not excuse weak protocols. Get TLS 1.2 working first, then confirm HTTP/2 is optional sugar on top. See our notes on HTTP/2 for the performance angle once security baselines are met.
If you terminate TLS at a load balancer, ensure health checks and internal HTTP links do not accidentally encourage mixed content on the public checkout URL. Public browsers must see a clean HTTPS checkout with modern protocols end to end from their perspective.
FAQ
Does Let’s Encrypt give me TLS 1.2 automatically?
Certificates work with whatever protocols the server enables. Let’s Encrypt does not replace server configuration.
Are we safe if we only use a hosted payment page?
Safer for card data scope, but your site still needs modern HTTPS for sessions and trust. Read your SAQ type and provider guidance.
Will disabling TLS 1.0 hurt SEO?
No. It is a security requirement. HTTPS quality helps users and aligns with browser warnings; it is not a keyword trick.
What about TLS 1.3?
Support is emerging in stacks and browsers. TLS 1.2 remains the PCI baseline target for this deadline; enabling 1.3 where available is a bonus, not a substitute for disabling 1.0.
Next step
Treat 30 June as a hard milestone. If you need a security and performance pass on the storefront (HTTPS, hosting, checkout plugins), we can help under turn visitors into customers with a practical hardening plan.
