For a PCI-sensitive web service, use TLS 1.2 or TLS 1.3 for encrypted transport, disable older protocol versions, and keep every checkout path on HTTPS; protocol choice alone never proves PCI DSS compliance.
Use a modern protocol baseline
The pci.hosting guide describes TLS 1.2+/1.3-only connections with HSTS enforced. In practical terms, that means permitting TLS 1.2 and TLS 1.3 and refusing obsolete versions such as TLS 1.0 and TLS 1.1. Apply the same thinking to every hostname and endpoint that can participate in checkout, including redirects, embedded resources, administrative paths, and monitoring endpoints that expose status or access information.
Protect the whole browser journey
HTTPS on the final card-entry page is not enough if the page that loads it is plain HTTP or includes mixed content. A mixed-content page can let an attacker alter the handoff before a processor-hosted form appears. Keep links, forms, scripts, styles, and frames on HTTPS, and use HSTS so compliant browsers do not silently fall back to HTTP. Check redirects and alternate hostnames, not just the preferred URL.
Separate host controls from merchant checks
The hosting environment can enforce its transport and server policy, but the merchant owns the application and payment page. Confirm that your CMS, plugins, themes, custom code, and third-party scripts do not create an HTTP checkout path or weaken the browser policy. Review TLS settings after application changes and retain the relevant change record. If your own code can influence an embedded payment page, the SAQ A-EP responsibilities still apply even when the card number never reaches your server.
Verify settings after changes
Test the negotiated protocol on public endpoints after certificate, web-server, proxy, or application changes. Confirm redirects, embedded frames, and API calls still use HTTPS, and record the change. A browser lock icon is useful feedback, but it does not test every endpoint or prove that the merchant's other controls are complete.
Do not treat TLS as a badge
TLS protects data in transit; it does not decide your SAQ, replace patching, create a script inventory, or satisfy logging and access-control duties. A hosted redirect may support an SAQ A assessment, while an embedded flow controlled by your code may require SAQ A-EP. Storing card numbers can lead to SAQ D regardless of the transport layer. Read the SAQ guide and the checklist, and use the ticket form for scoped guidance.