E-commerce is where the gap between perceived PCI DSS simplicity and actual compliance complexity is largest. Many e-commerce merchants believe that using a reputable PSP fully outsources their PCI DSS obligation. In reality, the e-commerce environment — with its JavaScript-heavy front-end, third-party integrations, and complex data flows — introduces unique compliance challenges that PCI DSS v4.0 has specifically addressed.
E-Commerce Payment Architecture — The Three Models
| Architecture | How CHD Flows | Typical SAQ | Key PCI DSS Obligations |
|---|---|---|---|
| Fully hosted payment page (redirect) | Customer redirected to PSP payment page; no CHD touches merchant systems | SAQ A (if fully compliant) | Verify PSP compliance annually; manage JavaScript on all pages (6.4.3) |
| iFrame payment form | Payment form served from PSP within an iFrame on merchant page; CHD never on merchant server | SAQ A or SAQ A-EP (depends on iFrame implementation) | JavaScript management on parent page; verify iFrame integrity; confirm no JavaScript can reach into iFrame |
| JavaScript API / client-side tokenization | PSP JavaScript on merchant page collects CHD and sends directly to PSP; merchant receives token | SAQ A-EP | Full Requirement 6.4 compliance; JavaScript management; web application security; WAF |
| Server-side processing | CHD submitted to merchant server, which processes or forwards to PSP | SAQ D | Full 12 requirements apply to all systems handling CHD |
SAQ A — Strict Eligibility in v4.0
Under v4.0, SAQ A eligibility has become more demanding. To qualify: the merchant accepts only e-commerce or MO-TO (mail order/telephone order) card-not-present payments, all payment page functions are entirely hosted by a PCI DSS-compliant TPSP, the merchant does not electronically store, process, or transmit any account data, and the merchant has confirmed the TPSP is PCI DSS compliant with a current AoC.
| KEY IDEA | The entirely hosted standard for SAQ A is strictly interpreted under v4.0. If your payment page loads ANY scripts from your own domain — even a header/footer script, a chatbot widget, or analytics tracking — and those scripts affect the security of the payment page content, you may not qualify for SAQ A. The question QSAs ask is: can any script on or near your payment page access, modify, or exfiltrate payment form data? If the answer is uncertain, assume SAQ A-EP applies. |
JavaScript Skimming — The Magecart Threat
Magecart-style attacks inject malicious JavaScript into e-commerce payment pages to capture cardholder data in the browser before it is sent to the PSP. These attacks typically exploit: compromised third-party JavaScript libraries loaded by the payment page, supply chain compromises of legitimate marketing and analytics scripts, and cross-site scripting (XSS) vulnerabilities that allow injecting new script elements.
Requirement 6.4.3 — Script Management
All scripts loaded on payment pages must be inventoried, authorized, and integrity-verified. Implementation: create a payment page script inventory listing every script loaded (directly and by other scripts), document the business justification for each, implement Subresource Integrity (SRI) hashes for external scripts, implement Content Security Policy (CSP) headers restricting script execution to approved sources, and monitor for unauthorized script additions or changes.
Requirement 11.6.1 — Payment Page Change Detection
Organizations must implement a change and tamper detection mechanism that alerts personnel when HTTP headers or the content of payment pages are modified. Implementation options: automated page monitoring tools (HTTrack, VisualPing, or specialized solutions like Featurespace), cloud-based payment page integrity monitoring (Cloudflare Page Shield, Akamai Page Integrity Manager), or custom alerting that hashes payment page content and alerts on changes.
| IMPORTANT | Requirements 6.4.3 and 11.6.1 together represent PCI DSS's response to the Magecart attack wave that compromised thousands of e-commerce sites globally between 2018 and 2024. If your e-commerce site was among those compromised before these controls were implemented, these are now the preventive controls that would have stopped the attack. Both requirements are now fully active (mandatory since March 2025). |
API Security for Payment Integrations
Modern e-commerce platforms communicate with PSPs, fraud detection systems, and payment networks via APIs. PCI DSS applies to all these API communications when they involve CHD:
- All API connections transmitting CHD must use TLS 1.2 minimum (TLS 1.3 preferred)
- API authentication credentials (API keys, OAuth tokens) must be protected as sensitive credentials — not embedded in code, stored in secrets management
- API endpoints that handle CHD must be protected by WAF rules
- API rate limiting and anomaly detection to prevent enumeration attacks
- All API calls to payment processing endpoints must be logged (request, response status, timestamp, calling system)
PSP Selection and Management in Indonesia
Indonesian e-commerce merchants can significantly simplify PCI DSS compliance through strategic PSP selection.
| PSP | PCI DSS Status | Hosted Checkout | SAQ A Support | Key Features |
|---|---|---|---|---|
| Midtrans (GoTo Financial) | PCI DSS Level 1 Service Provider | Yes — Snap payment page | Yes | Tokenization, virtual account, GoPay integration, Indonesian bank coverage |
| Xendit | PCI DSS Level 1 Service Provider | Yes — XenPay checkout | Yes | Multi-currency, real-time disbursement, Indonesian bank integration |
| Doku | PCI DSS Level 1 Service Provider | Yes — Doku Checkout | Yes | Strong bank transfer and virtual account support, OVO wallet integration |
| Stripe | PCI DSS Level 1 Service Provider | Yes — Stripe Checkout / Payment Element | Yes | Global coverage, strong developer APIs, Stripe Radar fraud detection |
| Adyen | PCI DSS Level 1 Service Provider | Yes — Drop-in UI | Yes | Enterprise-grade, GPN integration for Indonesian domestic cards, Adyen tokenization |
| For Indonesian merchants choosing between local PSPs (Midtrans, Xendit, Doku) and global PSPs (Stripe, Adyen), both categories offer PCI DSS Level 1 service provider status. The local PSPs offer better coverage for Indonesian-specific payment methods (bank transfers, e-wallets, QRIS) but the global PSPs may have more mature fraud detection. Many Indonesian e-commerce organizations use both — a local PSP for domestic payment methods and a global PSP for international card transactions. |