Part of our Compliance & Regulation series
Read the complete guidePCI-DSS Compliance for eCommerce: Payment Security & Tokenization
Card payment fraud losses exceeded $33 billion globally in 2025, and eCommerce accounts for 73% of all card fraud. The Payment Card Industry Data Security Standard (PCI-DSS) exists to combat this, and version 4.0 --- which became mandatory in March 2025 --- introduced significant new requirements that many eCommerce businesses are still scrambling to implement.
The good news: if you use a hosted payment solution like Shopify Payments or Stripe Checkout, your PCI scope is dramatically reduced. The bad news: it is never zero. Every eCommerce business that accepts card payments has PCI-DSS obligations, even if they never see a card number.
Key Takeaways
- PCI-DSS v4.0 introduces customized validation approaches and mandatory MFA for all access to cardholder data
- Tokenization eliminates 80-90% of PCI scope by replacing card numbers with non-reversible tokens
- SAQ selection determines your compliance burden --- choosing the right SAQ saves months of work
- Quarterly ASV scans and annual penetration testing are non-negotiable requirements
PCI-DSS v4.0: What Changed
PCI-DSS v4.0, released in 2022 and fully mandatory since March 31, 2025, represents the most significant update to the standard in over a decade. The key changes affect every eCommerce business.
Major Changes in v4.0
| Change | Impact | Deadline |
|---|---|---|
| Customized approach allowed | Companies can design alternative controls that meet objectives | Active now |
| Targeted risk analysis | Risk-based frequency for some controls (e.g., log reviews) | Active now |
| Enhanced authentication | MFA required for ALL access to CDE (not just remote) | March 2025 |
| Automated log review | Automated mechanisms to detect anomalies in audit logs | March 2025 |
| Script management | Inventory and integrity monitoring of payment page scripts | March 2025 |
| E-commerce skimming prevention | Mechanisms to detect unauthorized changes to payment pages | March 2025 |
| Targeted password requirements | Minimum 12 characters (or 8 if system cannot support 12) | March 2025 |
| Encryption of SAD before authorization | Sensitive authentication data must be encrypted if stored pre-auth | March 2025 |
The Script Management Requirement
Requirement 6.4.3 is particularly impactful for eCommerce: you must maintain an inventory of all scripts on payment pages and implement a mechanism to detect unauthorized changes. This means:
- Every JavaScript file loaded on your checkout page must be documented
- Content Security Policy (CSP) headers should restrict script sources
- Subresource Integrity (SRI) hashes should verify script content
- A monitoring mechanism must alert on unauthorized script changes
This requirement directly targets Magecart-style skimming attacks, where attackers inject malicious scripts into payment pages to steal card data.
Understanding Tokenization
Tokenization is the single most impactful technology for reducing PCI scope. It replaces sensitive card data with a non-sensitive token that has no exploitable value if breached.
How Tokenization Works
- Customer enters card details on the payment provider's hosted form (never on your server)
- Payment provider creates a token representing the card
- Your system stores only the token (e.g.,
tok_1MqLkJLkdIwHu7ixUAuBjz5Y) - For subsequent charges, you send the token to the payment provider
- The provider maps the token back to the actual card details and processes the payment
Tokenization vs. Encryption
| Aspect | Tokenization | Encryption |
|---|---|---|
| Reversibility | Not reversible (token is random) | Reversible with the key |
| PCI scope | Removes systems from scope | Systems remain in scope |
| Key management | No keys to manage | Key management required |
| Performance | Lookup-based, fast | Compute-based, slightly slower |
| Breach impact | Tokens are useless to attackers | Encrypted data is valuable if key is compromised |
Implementation with Major Platforms
Shopify: Tokenization is handled entirely by Shopify Payments. Merchants never touch card data. PCI compliance is covered by Shopify's Level 1 certification. You are responsible for SAQ-A.
Stripe: Use Stripe Elements or Stripe Checkout to ensure card data goes directly to Stripe's servers. Your backend only ever receives tokens. This qualifies you for SAQ-A or SAQ-A-EP depending on implementation.
Custom payment integration with Odoo: If you are building a custom eCommerce solution on Odoo, integrate with a PCI-compliant payment gateway (Stripe, Adyen, Authorize.net) using their hosted fields or redirect approach. Never process raw card data on your Odoo server.
SAQ Selection Guide
The Self-Assessment Questionnaire (SAQ) you must complete depends on how you handle card data. Choosing the right SAQ --- and architecting your payment flow to qualify for a simpler SAQ --- is the most important PCI decision you will make.
SAQ Type Selection Guide
| SAQ Type | Who It Is For | # of Questions | Requirements |
|---|---|---|---|
| SAQ-A | Fully outsourced (hosted payment page/iframe) | ~25 | Card data never touches your systems |
| SAQ-A-EP | Outsourced payment but your site controls the page | ~140 | Payment page on your domain, data sent directly to processor |
| SAQ-B | Imprint or standalone terminal only | ~40 | No electronic cardholder data storage |
| SAQ-B-IP | Standalone PTS terminals with IP connection | ~80 | Terminal connects to processor over network |
| SAQ-C | Payment application connected to internet | ~160 | Application processes cards but does not store data |
| SAQ-C-VT | Virtual terminal (manual key entry, web-based) | ~80 | One transaction at a time, no electronic storage |
| SAQ-D | Everyone else (stores, processes, or transmits) | ~330 | Full PCI assessment required |
Decision Flow
Do you redirect customers to a hosted payment page (Shopify Checkout, Stripe Checkout, PayPal)? If yes, SAQ-A.
Do you embed the payment provider's form on your page (Stripe Elements, Braintree Hosted Fields)? If yes, SAQ-A-EP. Your page hosts the form, but card data goes directly to the provider.
Does card data ever touch your server, even temporarily? If yes, SAQ-D. This is the full assessment and you should strongly consider re-architecting to qualify for SAQ-A or SAQ-A-EP instead.
Cost Implications
| SAQ Type | Typical Annual Compliance Cost | Effort Level |
|---|---|---|
| SAQ-A | $2,000 - $5,000 | Days |
| SAQ-A-EP | $10,000 - $30,000 | Weeks |
| SAQ-C | $20,000 - $50,000 | Weeks to months |
| SAQ-D | $50,000 - $300,000+ | Months |
The architecture decision to use hosted payment forms instead of processing card data yourself can save $50,000-$250,000 annually in compliance costs.
3D Secure 2.0: Liability Shift & Fraud Prevention
3D Secure 2.0 (3DS2) adds an authentication layer to online card transactions. When properly implemented, it shifts fraud liability from the merchant to the card issuer.
How 3DS2 Works
- Customer initiates payment on your site
- Your payment provider sends transaction data to the card issuer
- Issuer's risk engine evaluates the transaction (device fingerprint, transaction history, amount)
- Frictionless flow: Low-risk transactions are authenticated silently (no customer action needed)
- Challenge flow: High-risk transactions require additional authentication (biometric, OTP, app confirmation)
- Authentication result is returned and payment is processed
3DS2 Benefits
- Liability shift: Fraud liability transfers to the issuing bank for authenticated transactions
- Reduced fraud: 3DS2 reduces fraud rates by 40-60% compared to non-authenticated transactions
- Better UX: Frictionless authentication means 85-95% of transactions require no additional customer action
- Regulatory compliance: PSD2 Strong Customer Authentication (SCA) requires 3DS2 for EU transactions
Implementation Considerations
- Enable 3DS2 through your payment provider (Stripe, Adyen, and most providers support it natively)
- Configure risk-based authentication thresholds: apply 3DS2 to higher-risk transactions while exempting low-value or low-risk ones
- Monitor authentication rates: if too many transactions are challenged, review your risk signals
- Test both frictionless and challenge flows thoroughly before going live
Vulnerability Scanning & Penetration Testing
PCI-DSS requires both automated vulnerability scanning (quarterly) and manual penetration testing (annually) for all environments in scope.
Quarterly ASV Scans
An Approved Scanning Vendor (ASV) must perform external vulnerability scans every quarter. Requirements:
- Scans must cover all external-facing IP addresses and domains in the Cardholder Data Environment (CDE)
- All high-severity vulnerabilities (CVSS 4.0+) must be remediated and rescanned before the scan passes
- Passing scan reports must be retained for audit purposes
- Common ASVs: Qualys, Tenable, SecurityMetrics, Trustwave
Annual Penetration Testing
Requirement 11.4 mandates annual penetration testing of:
- Network segmentation controls (if used to reduce scope)
- External perimeter of the CDE
- Internal systems within the CDE
- Application-layer testing of payment applications
New in v4.0: Penetration testing must now explicitly verify that segmentation controls are working and that the CDE is properly isolated from the rest of the network.
Continuous Monitoring
Beyond quarterly and annual testing, PCI-DSS v4.0 emphasizes continuous monitoring:
- File integrity monitoring (FIM) on critical system files and payment page scripts
- Intrusion detection/prevention systems (IDS/IPS) at CDE network boundaries
- Automated log review for anomaly detection (new v4.0 requirement)
- Real-time alerting for unauthorized access attempts
Building a PCI-Compliant eCommerce Architecture
The most effective approach to PCI compliance is to minimize scope through architecture decisions.
Recommended Architecture
Tier 1: Payment page (minimal scope). Use hosted payment fields (Stripe Elements, Adyen Drop-in) embedded in an iframe on your checkout page. Card data flows directly from the customer's browser to the payment provider. Your server never sees it.
Tier 2: Application server (out of scope). Your eCommerce application (Shopify, Odoo, custom) handles order management, inventory, and customer data. It communicates with the payment provider via tokens only.
Tier 3: Data storage (out of scope for card data). Your database stores order details, customer information, and payment tokens --- but never card numbers, CVVs, or expiration dates.
Network Segmentation
If any part of your infrastructure processes card data, network segmentation is critical:
- Isolate the CDE in a separate network segment (VLAN, subnet, or VPC)
- Implement firewall rules that restrict traffic to and from the CDE
- Monitor all traffic crossing the segmentation boundary
- Test segmentation controls during penetration testing
For comprehensive compliance architecture guidance that extends beyond PCI-DSS, see our enterprise compliance handbook.
Frequently Asked Questions
Do I need PCI compliance if I only sell on Shopify?
Yes, but your scope is minimal. Shopify is a PCI-DSS Level 1 certified service provider, which means Shopify handles the heavy lifting. However, you are still responsible for completing SAQ-A annually and maintaining basic security practices: strong passwords, MFA on your Shopify admin, not storing card data outside of Shopify, and training staff on security.
What happens if my quarterly ASV scan fails?
You have the opportunity to remediate the identified vulnerabilities and request a rescan. There is no penalty for a failing scan --- only for not having a passing scan within the quarterly window. However, if you consistently fail scans and cannot demonstrate compliance, your acquiring bank may increase your processing fees, require a more stringent assessment, or in extreme cases, terminate your merchant account.
Is PCI compliance required by law?
PCI-DSS is not a government regulation --- it is a contractual requirement from the card brands (Visa, Mastercard, American Express, Discover, JCB). Compliance is enforced through your merchant agreement with your acquiring bank. Non-compliance can result in fines from the card brands ($5,000-$100,000/month), increased transaction fees, and liability for fraudulent transactions. Some jurisdictions (Nevada, Minnesota, Washington) have enacted laws that incorporate PCI-DSS requirements.
How does PCI-DSS relate to GDPR?
PCI-DSS and GDPR overlap in areas like access control, encryption, and incident response, but they have different focuses. PCI-DSS protects payment card data specifically, while GDPR protects all personal data of EU residents. A payment card number is also personal data under GDPR, so you need to comply with both. See our data privacy comparison guide for more on how different regulations interact.
What Is Next
PCI-DSS compliance is not optional for any business that accepts card payments. The good news is that modern payment platforms have made it dramatically easier by handling the most sensitive aspects of card data processing on your behalf. Your job is to choose the right architecture, complete the appropriate SAQ, maintain continuous security practices, and stay current as the standard evolves.
ECOSIRE helps eCommerce businesses build PCI-compliant payment architectures from the start. Our Shopify implementations leverage Shopify's Level 1 certification for minimal PCI scope, and our Odoo ERP integrations use tokenized payment flows that keep your systems out of PCI scope. Contact us for a payment security assessment.
Published by ECOSIRE — helping businesses scale with AI-powered solutions across Odoo ERP, Shopify eCommerce, and OpenClaw AI.
Written by
ECOSIRE TeamTechnical Writing
The ECOSIRE technical writing team covers Odoo ERP, Shopify eCommerce, AI agents, Power BI analytics, GoHighLevel automation, and enterprise software best practices. Our guides help businesses make informed technology decisions.
ECOSIRE
Scale Your Shopify Store
Custom development, optimization, and migration services for high-growth eCommerce.
Related Articles
AI Content Generation for E-commerce: Product Descriptions, SEO & More
Scale e-commerce content with AI: product descriptions, SEO meta tags, email copy, and social media. Quality control frameworks and brand voice consistency guide.
AI-Powered Dynamic Pricing: Optimize Revenue in Real-Time
Implement AI dynamic pricing to optimize revenue with demand elasticity modeling, competitor monitoring, and ethical pricing strategies. Architecture and ROI guide.
AI Fraud Detection for E-commerce: Protect Revenue Without Blocking Sales
Implement AI fraud detection that catches 95%+ of fraudulent transactions while keeping false positive rates under 2%. ML scoring, behavioral analysis, and ROI guide.
More from Compliance & Regulation
Cybersecurity for E-commerce: Protect Your Business in 2026
Complete ecommerce cybersecurity guide for 2026. PCI DSS 4.0, WAF setup, bot protection, payment fraud prevention, security headers, and incident response.
ERP for Chemical Industry: Safety, Compliance & Batch Processing
How ERP systems manage SDS documents, REACH and GHS compliance, batch processing, quality control, hazmat shipping, and formula management for chemical companies.
ERP for Import/Export Trading: Multi-Currency, Logistics & Compliance
How ERP systems handle letters of credit, customs documentation, incoterms, multi-currency P&L, container tracking, and duty calculation for trading companies.
Sustainability & ESG Reporting with ERP: Compliance Guide 2026
Navigate ESG reporting compliance in 2026 with ERP systems. Covers CSRD, GRI, SASB, Scope 1/2/3 emissions, carbon tracking, and Odoo sustainability.
Audit Preparation Checklist: Getting Your Books Ready
Complete audit preparation checklist covering financial statement readiness, supporting documentation, internal controls documentation, auditor PBC lists, and common audit findings.
Australian GST Guide for eCommerce Businesses
Complete Australian GST guide for eCommerce businesses covering ATO registration, the $75,000 threshold, low value imports, BAS lodgement, and GST for digital services.