PCI Compliance for Card-Not-Present Businesses: What Changes Online
PCI DSS applies to every business that accepts card payments, but the practical checklist looks different once a card is never physically present. Card-not-present businesses — e-commerce stores, subscription services, phone and mail-order sellers — face a different set of risks than a retail counter, and PCI compliance shifts accordingly. This guide walks through what actually changes for an online or card-not-present business, building on the general requirements covered in our PCI DSS compliance checklist for small merchants.
Why Card-Not-Present Businesses Get Extra Scrutiny
In a face-to-face transaction, a chip or tap payment authenticates the physical card and often the cardholder's PIN or biometric approval. Online, none of that exists — a transaction is authorized based on card number, expiration date, CVV, and billing information alone, all of which can be stolen and reused without the actual card ever being present. That gap is exactly why card-not-present fraud rates run higher industry-wide than in-person fraud, and why PCI DSS treats e-commerce environments as carrying more inherent risk.
The practical result is that online merchants are held to the same core PCI requirements as anyone else, but the details of how those requirements are met — and how a merchant proves compliance — look substantially different from a retail store with a single countertop terminal.
Where Cardholder Data Actually Touches Your Systems
The first question for any card-not-present business is where card data flows through your own infrastructure versus a third party's. Many small e-commerce merchants use a hosted checkout page or an embedded payment iframe from their gateway provider, meaning card numbers never actually touch the merchant's own servers — they go directly from the customer's browser to the payment processor. This dramatically simplifies compliance, because the merchant's own systems fall outside the scope of storing or transmitting raw card data.
Merchants who instead build their own checkout form and pass card data through their own server before forwarding it to a processor take on a much larger compliance burden, because their web application, servers, and any logs or backups become part of the PCI-regulated environment. For most small and mid-size online businesses, using a hosted or tokenized checkout through a compliant payment gateway is the more practical path, both for security and for keeping the compliance workload manageable.
Self-Assessment Questionnaire (SAQ) Types That Apply Online
PCI DSS uses different Self-Assessment Questionnaire (SAQ) types depending on how a business processes payments, and card-not-present merchants typically fall into one of a few specific categories. A merchant using a fully hosted, redirect-based checkout (the customer is sent to the processor's own payment page) generally qualifies for a shorter questionnaire because their own systems have minimal contact with card data. A merchant using an iframe or API-based integration where their website's code interacts more directly with the payment flow, even without storing card numbers, typically falls under a more detailed questionnaire.
Getting the SAQ type right matters because it determines exactly which security controls need to be documented and verified. If you're not sure which category applies to your setup, your payment gateway or processor's support team can usually tell you based on how your checkout integration is configured.
Common Gaps Specific to Online and Phone-Order Businesses
A few gaps show up repeatedly in card-not-present businesses that don't appear the same way in retail. Storing card numbers in spreadsheets, email threads, or CRM notes to process phone or mail orders later is a frequent and serious violation — a virtual terminal or secure phone-payment tool exists specifically to avoid this. Website vulnerabilities like outdated shopping cart plugins, unpatched content management systems, or unsecured admin panels can expose a checkout flow to card-skimming malware (sometimes called "formjacking") even when the merchant never intended to store any data themselves.
Recurring billing and subscription businesses face an additional wrinkle: storing a customer's card on file for future charges requires either full PCI Level 1-style controls or, far more commonly and practically, using your payment processor's tokenization service, which stores a secure token in place of the actual card number. Tokenization is the standard, low-burden way most subscription businesses handle repeat billing without taking on the compliance weight of storing real card data themselves.
Ongoing Requirements, Not a One-Time Checklist
PCI compliance for online merchants isn't a document filed once and forgotten. Annual SAQ completion, quarterly vulnerability scans by an Approved Scanning Vendor if your business qualifies for that requirement, keeping website and e-commerce platform software patched and current, and reviewing who has administrative access to your website and payment integrations are all ongoing tasks. A checkout integration that was compliant at launch can drift out of compliance simply through unpatched plugins or an unmanaged third-party script added to the site later.
Card-not-present businesses should also pay attention to third-party scripts and plugins running on checkout pages — analytics tags, chat widgets, and marketing pixels have all been documented sources of e-commerce card-skimming incidents when compromised, even when the merchant's own code was never at fault.
How Expedio Payments Helps
Choosing a checkout setup that minimizes your PCI scope from the start is the single highest-leverage decision a card-not-present business can make. Our payment gateway solutions are built around hosted and tokenized checkout options specifically so most of the compliance burden stays with the gateway rather than landing on your own servers, and our team can help identify which SAQ type applies to your current setup and what, if anything, needs to change to close a gap. For merchants still working through the fundamentals, our PCI DSS compliance checklist for small merchants is a good starting point before diving into the online-specific details covered here.
Frequently Asked Questions
Does PCI DSS apply differently to online businesses than to retail stores?
The core PCI DSS requirements are the same for every business that accepts cards, but which specific controls apply and which Self-Assessment Questionnaire is used depends heavily on how the business handles card data. Card-not-present businesses typically face different SAQ types and different practical risks than a retail counter.
What is the easiest way for a small online store to stay PCI compliant?
Using a fully hosted or tokenized checkout through a compliant payment gateway is generally the simplest path, since it keeps raw card numbers off the merchant's own servers entirely and qualifies for a shorter Self-Assessment Questionnaire.
Can I store customer card numbers to make phone orders easier to process later?
Storing raw card numbers in spreadsheets, email, or general business systems is a serious PCI violation. A virtual terminal or your processor's tokenization service is the compliant way to handle phone and mail orders or repeat billing.
What is an SAQ and how do I know which type applies to my business?
A Self-Assessment Questionnaire (SAQ) is the PCI DSS document merchants complete to validate their own compliance, and the specific type depends on how card data flows through the business's systems. Your payment gateway or processor can typically tell you which SAQ type applies based on your checkout integration.
Is PCI compliance a one-time task for an e-commerce business?
No. It requires annual re-validation, and for many merchants, periodic vulnerability scanning and ongoing attention to website security, since an integration that was compliant at launch can drift out of compliance as software and third-party scripts change over time.