PCI DSS compliance for custom eCommerce requires six control categories: secure network architecture (firewalls, network segmentation, no default credentials), cardholder data protection (encryption at rest with AES-256, tokenization, no storage of CVV/PIN), vulnerability management (regular patching, secure coding practices, penetration testing), access controls (unique IDs, MFA for admin access, least-privilege principles), monitoring and testing (log all access to cardholder data, quarterly vulnerability scans, annual penetration tests), and documented security policies.
This guide covers each requirement category, how tokenization reduces your compliance scope from 300+ controls to 22, the cost difference between PCI DSS levels, and the penalties for non-compliance in custom-built platforms.
What PCI DSS requirements apply to custom eCommerce?
PCI DSS v4.0 organizes its 12 requirements into six control categories. Custom eCommerce platforms face every one of these directly — unlike merchants on hosted platforms where the provider absorbs most of the compliance burden. When you own the code, you own the compliance.
Control Category | PCI DSS Requirements | Custom eCommerce Implementation |
|---|---|---|
Secure Network Architecture | Req 1: Install and maintain network security controls. Req 2: Apply secure configurations to all system components. | Firewall rules segmenting cardholder data environment (CDE) from public-facing app. No default passwords on any system component. Network segmentation validated with penetration testing. |
Cardholder Data Protection | Req 3: Protect stored account data. Req 4: Protect cardholder data with strong cryptography during transmission. | AES-256 encryption at rest. TLS 1.2+ for all transmission. Never store CVV, full track data, or PIN. Tokenize card numbers at the gateway before they reach your server. |
Vulnerability Management | Req 5: Protect all systems against malware. Req 6: Develop and maintain secure systems and software. | Secure coding practices in CI/CD pipeline. Static analysis on every pull request. Dependency scanning for known vulnerabilities. Quarterly external vulnerability scans by an Approved Scanning Vendor (ASV). |
Access Controls | Req 7: Restrict access by business need to know. Req 8: Identify users and authenticate access. Req 9: Restrict physical access to cardholder data. | Role-based access control (RBAC) on all CDE systems. MFA for every admin account. Unique user IDs with no shared accounts. Least-privilege enforced and reviewed quarterly. |
Monitoring and Testing | Req 10: Log and monitor all access to system components and cardholder data. Req 11: Test security of systems and networks regularly. | Centralized logging with tamper-evident storage. Quarterly ASV scans. Annual penetration testing by a qualified assessor. File integrity monitoring on critical system files. |
Security Policies | Req 12: Support information security with organizational policies and programs. | Documented security policy covering all 12 requirements. Annual security awareness training. Incident response plan tested annually. Formal risk assessment process. |
The critical difference between custom eCommerce and a hosted platform like Shopify: on Shopify, the platform absorbs Requirements 1 through 4 and most of 5 and 6. On a custom platform, your engineering team is responsible for all 12. This is not a reason to avoid custom — it is a reason to architect for reduced scope from day one.
How do you handle payment card data in custom eCommerce?
The single most important architectural decision in PCI-compliant custom eCommerce is where card data exists in your system. The correct answer: it should never exist there at all. Payment tokenization — where the customer's browser sends card data directly to the payment gateway, which returns a non-reversible token — means your server never sees, transmits, or stores a card number.
Three integration patterns determine your PCI scope:
- Direct post (highest risk). Your server receives raw card data from the customer's browser, then forwards it to the payment gateway. Your entire application is in PCI scope. This is how custom eCommerce was built in 2010. Do not do this in 2026.
- Server-side tokenization (medium risk). Your server receives card data but immediately tokenizes it through the gateway's API before processing or storing anything. Your server briefly handles raw card data — which keeps you in SAQ D territory with 300+ requirements. Better than direct post, but still a significant compliance burden.
- Client-side tokenization (lowest risk). The customer's browser communicates directly with the payment gateway via an embedded iframe or JavaScript SDK — Stripe Elements, Braintree Drop-in, or Adyen Web Components. Your server receives only a token. Card data never touches your infrastructure. This qualifies you for SAQ A: 22 requirements instead of 300+.
Client-side tokenization is the only pattern that makes sense for new custom eCommerce builds. The compliance cost difference between SAQ A and SAQ D is not marginal — it is the difference between a $5,000 annual compliance process and a $50,000+ one.
What's the difference between PCI DSS levels?
PCI DSS assigns merchants to one of four levels based on annual transaction volume. The level determines the type of compliance validation required — from a simple self-assessment questionnaire to a full on-site audit by a Qualified Security Assessor (QSA).
Merchant Level | Annual Transactions | Validation Requirement | Typical Annual Cost |
|---|---|---|---|
Level 1 | Over 6 million | Annual on-site audit by QSA. Quarterly ASV network scans. | $50,000–$200,000+/year |
Level 2 | 1–6 million | Annual SAQ completed by internal assessor. Quarterly ASV scans. | $10,000–$50,000/year |
Level 3 | 20,000–1 million (eCommerce only) | Annual SAQ. Quarterly ASV scans. | $5,000–$20,000/year |
Level 4 | Under 20,000 (eCommerce) or under 1 million (other channels) | Annual SAQ. Quarterly ASV scans recommended but not always mandatory. | $1,000–$5,000/year |
Most custom eCommerce businesses start at Level 3 or Level 4. The architecture decisions made during development determine whether compliance stays at $5,000/year or grows to $50,000+ as transaction volume increases. Building for SAQ A eligibility from the start means your compliance cost does not scale linearly with revenue.
How does tokenization reduce PCI DSS scope?
Tokenization reduces PCI DSS scope by removing cardholder data from your environment entirely. When card data never enters your server, the majority of PCI requirements — network segmentation, encryption at rest, key management, access logging for cardholder data — do not apply to your systems.
Here is how the two SAQ levels compare in practice:
Dimension | SAQ D (Full Scope) | SAQ A (Tokenized) |
|---|---|---|
Applicable requirements | 300+ individual controls | 22 controls |
Network segmentation | Required — CDE must be isolated from all other networks | Not required — no CDE exists in your environment |
Encryption at rest | Required for all stored cardholder data with documented key management | Not applicable — no card data stored on your systems |
Quarterly ASV scans | Required | Required |
Annual penetration testing | Required by a qualified assessor | Not required (recommended as a best practice) |
Key management | Full cryptographic key lifecycle: generation, distribution, storage, rotation, destruction | Not applicable — payment gateway manages all encryption keys |
Log monitoring for card data access | Required with tamper-evident, centralized storage and daily review | Not applicable — no cardholder data in your environment to log access against |
Typical annual compliance cost | $20,000–$200,000+ | $2,000–$10,000 |
The scope reduction is not a shortcut. PCI DSS explicitly rewards architectures that minimize cardholder data exposure. A custom eCommerce platform with client-side tokenization has a smaller attack surface and a simpler compliance burden than a hosted platform that processes cards server-side.
How much does PCI compliant eCommerce development cost?
PCI compliance adds cost in two areas: the initial build (architecture and security controls) and ongoing annual compliance (assessments, scans, and maintenance). The architecture decision — SAQ A versus SAQ D — determines both.
Cost Category | SAQ A Architecture | SAQ D Architecture |
|---|---|---|
Development premium | 5–10% above standard build cost | 20–40% above standard build cost |
Payment gateway integration | Stripe/Braintree/Adyen SDK with embedded iframe ($0 setup, per-transaction fees) | Direct API integration requiring PCI-compliant server infrastructure |
Annual compliance assessment | $2,000–$10,000 (SAQ + ASV scans) | $20,000–$200,000+ (QSA audit for Level 1–2 merchants) |
Ongoing security maintenance | Standard application security practices (patching, dependency updates) | Dedicated PCI controls maintenance, cryptographic key rotation, daily log review |
Total first-year compliance cost | $5,000–$15,000 | $50,000–$250,000+ |
The development cost difference is 15–30% higher for SAQ D architecture. But the annual compliance cost difference is 10–20x. Over a three-year period, SAQ A architecture saves $100,000–$500,000+ in compliance costs alone — before accounting for the engineering time spent maintaining PCI-specific controls that SAQ A eliminates.
What are the penalties for PCI DSS non-compliance?
PCI DSS is not a law — it is a contractual requirement enforced by the card brands (Visa, Mastercard, American Express, Discover) through your acquiring bank. The penalties are financial, operational, and reputational.
Consequence | Detail |
|---|---|
Monthly fines | $5,000–$100,000/month from acquiring bank until the merchant achieves compliance |
Increased transaction fees | Card brands can increase interchange rates by 1–2%, applied to every transaction until remediated |
Breach liability | If a breach occurs while non-compliant, the merchant bears full forensic investigation costs ($20,000–$500,000+) and card replacement costs ($3–$10 per compromised card) |
Account termination | Acquiring bank can terminate the merchant account — meaning you cannot accept card payments at all |
MATCH list | Terminated merchants are added to the Member Alert to Control High-Risk Merchants list, making it difficult to obtain a new merchant account for 5 years |
Brand damage | Public breach notification requirements in most US states and under GDPR. Customer trust is difficult to rebuild after a payment data breach. |
The MATCH list is the most damaging consequence. A merchant placed on the MATCH list cannot process card payments through any acquirer for five years. For an eCommerce business, this is effectively a shutdown order. The fine is survivable. Losing the ability to accept payments is not.
How Madgeek builds PCI-compliant custom eCommerce
We build custom eCommerce with payment tokenization from day one — the card number never touches your server. This reduces PCI scope from SAQ D (300+ requirements) to SAQ A (22 requirements), cutting compliance cost by 80%+.
Every custom eCommerce platform we deliver uses client-side tokenization through Stripe Elements, Braintree, or Adyen Web Components — depending on the client's geography and payment requirements. The architecture is designed so card data flows directly from the buyer's browser to the payment gateway. Your server handles tokens, not card numbers.
The same security-first architecture applies to our custom eCommerce platform builds — whether B2C storefronts handling high transaction volumes or B2B eCommerce platforms with complex pricing, tiered discounts, and multi-currency requirements. PCI compliance is an architectural decision, not an afterthought.
Written by
Abhijit Das
CEO
Building AI tools for businesses from legacy to new age SaaS startups
LinkedIn ↗Need a team to build this for your business?