If you take card payments, PCI DSS applies to you - the question is how much of it. The standard scales by integration method: a store redirecting all card entry to its payment provider faces a questionnaire; a store touching card numbers faces an audit programme. Understanding which SAQ applies - and keeping yourself in the lightest honest category - is the core of PCI for Magento merchants.
The SAQ Landscape
Which Self-Assessment Questionnaire you complete depends on how card data flows:
- SAQ A (~22 requirements): card data never touches your systems - full redirect (PayPal Standard, hosted payment pages) or fully outsourced iframes where the fields are served by the PSP
- SAQ A-EP (~180 requirements): your site delivers the page but card data posts directly to the PSP (typical Stripe.js / hosted-fields style integrations)
- SAQ D (~330 requirements): card data transits or is stored by your systems - the “you really do not want this” tier
Magento’s own payment integrations (Braintree, PayPal, and modern PSP modules) are designed for SAQ A or A-EP. Custom payment forms posting card data to your Magento server land you in SAQ D - the single most expensive architectural mistake available in ecommerce.
Scope Reduction Is the Strategy
Every PCI decision follows one principle: keep card numbers off your infrastructure.
- Tokenise in the browser with the PSP’s own JavaScript/fields; your server handles only tokens
- Never log request bodies on payment endpoints (debug logging has leaked PANs into
system.logon real stores) - Never email, export, or store card data “temporarily” - temporary copies are how breaches happen
Under PCI DSS 4.0, even SAQ A merchants have real obligations: scripts on payment pages must be inventoried and authorised (6.4.3, 11.6.1), which for Magento means knowing every JS file your checkout loads - another argument for tag-manager discipline.
What the Merchant Actually Owns
Even fully outsourced, you own:
- Platform security: patched Magento and extensions, admin 2FA, least-privilege access - most Magento breaches are unpatched vulnerabilities, and a breached store serves skimmers regardless of PSP tokenisation
- The annual cycle: complete the SAQ honestly, pass quarterly ASV vulnerability scans if required for your SAQ type, fix findings
- Incident readiness: know who you call (PSP, acquirer, forensics) before you need to
The Skimming Reality
Magecart-style attacks - malicious JS skimming card fields - target exactly the Magento merchant segment. The defences are the ones from this article’s siblings: patched platform, 2FA, script integrity on payment pages, CSP headers. PCI 4.0 formalised much of this; treat it as the floor, not the ceiling.
PCI for a well-architected Magento store is a light annual exercise. Keep card data off your stack, keep the platform patched, complete your SAQ honestly - and the standard becomes paperwork instead of existential risk.