PCI Compliance for E-Commerce

This article is for educational purposes only and does not constitute professional compliance advice or legal counsel. PCI DSS requirements and standards evolve, and you should consult with a qualified compliance professional about your specific situation.

You run an e-commerce site that takes credit cards online. Your situation is fundamentally different from a physical retail store that swipes cards or a service business that processes payments manually. Your compliance obligations, your architectural options, and your risk profile are all shaped by the fact that you're handling payment data in a digital environment where decisions about how you process cards directly affect your PCI scope and compliance cost. Understanding your architectural options—how you handle payment forms, whether you ever see the actual card number, which payment processor you use—prevents you from either building unnecessary complexity that inflates your compliance burden or discovering too late that your architecture violates PCI requirements.

Website Security and HTTPS: Non-Negotiable

If your website accepts card data in any form—payment forms, checkout flows, even temporary storage of credit card numbers during processing—that entire connection must be encrypted with HTTPS. This is non-negotiable. It's not a best practice recommendation. It's a requirement. Transmitting an unencrypted credit card number is an instant PCI failure, and your acquiring bank will shut you down if they discover it.

HTTPS uses encryption to protect data in transit between the customer's browser and your server. Without HTTPS, anyone on the network path—your ISP, a compromised router, an attacker on the same WiFi network—can see the credit card number being transmitted. With HTTPS, the data is encrypted and only your server can decrypt it. The encryption is so fundamental that browsers now flag unencrypted sites as unsafe. If someone visits your payment page in an unencrypted HTTP connection, modern browsers will show a warning that something is wrong. Most customers will abandon the transaction rather than continue.

The critical detail that trips up some organizations is scope. If your customer lands on an unencrypted HTTP page, then you redirect them to HTTPS for payment, that moment of unencrypted traffic is a violation. HTTPS needs to be in place from the moment they land on any page where they might enter payment information. That usually means HTTPS for your entire site, not just the checkout page. Most modern hosting providers and CDNs make HTTPS automatic and free through services like Let's Encrypt. Setting it up is a basic requirement, not an advanced security practice.

SSL and TLS Versions: Why Old Protocols Are Not Allowed

HTTPS requires encryption protocols, specifically SSL or TLS. Here's where it gets specific: PCI requires modern versions of TLS only. Specifically, PCI DSS 4.0 requires TLS 1.2 or higher. Older versions—SSL 2.0, SSL 3.0, and the early TLS versions 1.0 and 1.1—are no longer acceptable for PCI compliance. This requirement exists because those older protocols have known weaknesses that attackers can exploit.

Many legacy systems and older web server configurations still support these old protocols because they're backwards compatible. If you haven't explicitly disabled them, your server might still be allowing connections using SSL 3.0 because the server defaults to supporting everything it knows about. From a customer experience perspective, that's fine—modern browsers use TLS 1.2 or 1.3 anyway. But from a PCI compliance perspective, allowing old protocols means you're vulnerable to attacks specifically targeting those versions. PCI requires disabling anything older than TLS 1.2.

The configuration is straightforward if you know what you're looking for. Most web servers have a configuration file where you specify the minimum TLS version allowed. Disabling older protocols is typically one or two configuration lines. If you're using a payment processor that handles HTTPS for you, they've likely already done this. If you're hosting your own payment pages, verify with your hosting provider or your system administrator that TLS 1.2 or higher is the minimum version your server allows.

Shopping Carts and Checkout Flows: The Scope Question

E-commerce sites often build their own shopping carts and checkout flows. This is where the critical PCI question arises: who handles the credit card number? If your site collects the credit card number from the customer and then processes it yourself, you're accepting full PCI scope for that data. That means storing it securely, transmitting it securely, logging securely without storing the actual card number, and meeting all of PCI's requirements for systems that handle cardholder data.

The safer approach is outsourcing the payment collection to a payment processor using their hosted payment page or an integrated payment form. With this approach, the customer enters their credit card directly into a form controlled by the payment processor, not your site. Your site never sees the actual card number. The processor handles the encryption, the PCI compliance, and the security. This completely removes cardholder data from your responsibility.

Many popular payment processors like Stripe, Square, PayPal, and others offer this kind of hosted payment flow. The customer clicks "Pay," gets redirected to the processor's payment page, enters their card information, and the processor handles everything. Your site then receives a confirmation that payment succeeded or failed. You never touch the actual card data. This is significantly simpler from a PCI perspective.

If you're building your own payment form, understand that you're accepting responsibility for handling sensitive cardholder data. Most small to medium e-commerce businesses should avoid this responsibility entirely by using hosted payment solutions. The complexity and risk isn't worth the marginal benefit of customizing your checkout flow. If you do need to build a custom payment form, at minimum use a payment processor's API where you send encrypted card data directly to them without your server ever seeing unencrypted card numbers.

Tokenization: Eliminating the Biggest PCI Headache

Tokenization is a technique where a payment processor replaces the actual card number with a token that only the processor can decrypt. Here's how it works: the customer's card data is encrypted immediately and sent to the processor, which decrypts it, processes the payment, and returns to you a token that represents that card. Your system stores the token, not the actual card number. When you need to charge that card again—for a recurring payment or a follow-up transaction—you send the token to the processor, which decrypts it and processes the transaction.

From a PCI perspective, this is transformative. You're no longer storing actual cardholder data. You're storing tokens, which are useless to attackers. If someone breaches your database, they find tokens, not card numbers. The processor retains the encryption keys, so they're the only ones who can decrypt tokens into actual card data. Your PCI scope is dramatically reduced.

If your payment processor supports tokenization, using it is almost always the right choice. It reduces your compliance burden, reduces risk, and typically costs nothing extra. Most major processors offer tokenization by default. You're not paying more for this feature; you're just using what's available. This is one of the simplest ways to reduce compliance complexity.

Payment Processors and Hosted Solutions: Shifting Responsibility

Payment processors like Stripe, Square, PayPal, and others handle cardholder data on your behalf. When you use a processor, you're essentially saying, "You handle the payment processing and the PCI compliance. I'll handle the business logic and the customer experience." The processor maintains PCI compliance at their level, which reduces your compliance obligations.

The lowest-PCI-scope approach is using a processor with a hosted payment page. Here's the flow: your customer is ready to checkout. Your site displays a "Pay" button or link that redirects to the processor's payment page. The customer enters their card information on the processor's secure page, not your page. The processor processes the payment and redirects back to your site with the result. You never handle cardholder data; the processor does.

This architecture is attractive because your PCI scope is minimal. You're not storing, processing, or transmitting cardholder data. The processor is. Your compliance obligation is to use the processor securely and ensure your site itself is secure, but you're not responsible for credit card handling.

Many small and mid-market e-commerce businesses should default to this approach. The simplicity and security benefit outweighs any benefit from building custom payment handling. The trade-off is that you're relying on the processor's infrastructure, so you need to ensure they're trustworthy and maintain good security practices.

The Liability Question: You're Still Responsible

Here's a critical misconception that needs correction: using a payment processor doesn't eliminate your liability for card data breaches. If your website is compromised and cardholder data is stolen, you can still be held liable. This applies even if the cardholder data is technically stored by your processor rather than on your own servers. Your customers' banks hold you responsible as the merchant. Your acquiring bank holds you responsible. The PCI Council's penalties apply to you as the merchant.

What a payment processor does provide is shared responsibility. The processor is also liable for their own security controls. If your site is compromised because of a processor vulnerability, the processor shares liability. If your site is compromised because of your own security failure while the processor was secure, you bear full liability. This is why choosing a processor with strong PCI compliance practices and good security is important. You're trusting them with your customers' data, but you're still ultimately responsible for due diligence in selecting them.

The practical implication: your overall security posture matters. Your payment processor's security matters. Your choice of whether to use hosted payments or custom payment handling matters. If you're going to handle payment data yourself, you need comprehensive security. If you're using a processor, you need to verify they're legitimate and secure.

Making the Right Architectural Choice

For most e-commerce businesses, the decision is straightforward. If you can use a hosted payment page from an established processor, do that. You avoid PCI scope entirely, you reduce risk, and you reduce complexity. If you need a custom checkout experience, use a processor's payment form API where the card data is encrypted before your site ever sees it. Tokenization should be enabled automatically. Your compliance burden is minimal.

Only build your own payment processing if you have a specific business reason that justifies it and you have deep security expertise. Examples might include if you're a payment processor yourself, or if you're a very large company with sophisticated security infrastructure. For almost every other situation, outsourcing payment processing to a reputable processor is the right choice. You're not saving money by building it yourself; you're taking on risk.

The cost of using a payment processor is typically transaction fees—2 to 3 percent per transaction or a per-transaction flat fee plus a percentage. For a $100,000 annual transaction business, that's $2,000 to $3,000 per year. Most small businesses find this significantly cheaper than the cost of maintaining PCI Level 1 or Level 2 compliance internally. You're paying the processor to handle the complexity for you, and that's usually a great deal.

You now understand the critical architectural decisions for PCI compliance in e-commerce: whether you handle card data directly or shift it to a processor, whether you store card numbers or use tokenization, and whether you accept PCI scope or delegate it to a trusted processor. The simplest and most secure approach is using a processor with hosted payment pages and tokenization—you avoid handling cardholder data entirely and minimize your compliance burden. If you need custom payment flow, use a processor's API that handles encryption and tokenization, further minimizing your scope. The most expensive and risky approach is building your own payment processing or storing cardholder data directly—only pursue this if you have a specific business justification and advanced security expertise. For most e-commerce businesses, the processor-hosted approach is both the simplest and the smartest.

Fully Compliance provides educational content about IT compliance and cybersecurity. This article reflects general information about PCI DSS requirements for e-commerce as of its publication date. PCI DSS requirements, merchant levels, and processor capabilities evolve—consult a qualified compliance professional and your acquiring bank for guidance specific to your e-commerce environment.