SAQ A vs SAQ A-EP — Which One Are You?

Last updated: 29 May 2026

If you've ever picked up the v4.0.1 SAQ A document, looked at the 22 controls, then opened SAQ A-EP and counted the ~191 controls, the difference feels disproportionate. Same merchant type. Same broad description ("e-commerce, fully outsourced card handling"). One questionnaire fits on a few pages. The other reads like a junior SAQ D.

The difference is real and it's not arbitrary. SAQ A vs SAQ A-EP is the PCI Council's answer to a specific architectural problem: what happens when an e-commerce merchant claims they've outsourced card handling, but their own JavaScript is running on the same page where the card is captured. The merchant doesn't store or transmit the PAN in the usual sense — but their code is sitting two milliseconds away from it, with full DOM access, every time a customer pays.

This guide walks through the technical line between the two SAQs, the architectural patterns that put you on each, and the integration change that drops most merchants from A-EP back to A. We'll also cover why most "drop-in" payment widgets count as A-EP even when the PSP markets them as PCI-compliant, and what evidence your QSA actually wants to see at the next assessment.

What SAQ A vs SAQ A-EP actually measures#

Both SAQ A and SAQ A-EP are designed for e-commerce merchants who've handed card processing to a PCI-validated third party. Neither is intended for merchants who store PANs, run their own payment gateway, or accept card-present transactions. So far, so similar.

The split happens at the level of who controls the code that runs on the page where the card is entered. SAQ A says: nothing of yours runs on that page. The customer is either looking at a payment page hosted entirely on the PSP's domain (full redirect), or at an iframe served from the PSP's origin where your page can't reach into it. Your job is to confirm the customer ended up on the right PSP page, then handle the redirect back when they're done.

SAQ A-EP says: some of your code runs on the page during the transaction. You don't store the PAN. You don't transmit it across your servers. But your JavaScript, your CSS, your HTML structure, your script loaders are all on the same page as the form the customer is typing into. From PCI's perspective, you're now sharing the security boundary with the PSP — and that boundary has to be hardened.

The ~191 controls in SAQ A-EP exist to harden that shared boundary. ASV scanning of your web infrastructure, annual penetration testing, network segmentation evidence, vulnerability management, secure development practices, file integrity monitoring on your payment page, malware controls. The kind of work you'd expect on SAQ D — minus the cardholder data storage requirements, because the merchant still doesn't store PANs.

The control counts at a glance

The cost gap isn't the headline. The headline is that SAQ A-EP carries most of the technical compliance machinery of SAQ D — ASV scans, pen tests, segmentation — for a merchant who genuinely doesn't see card numbers. That's a lot of compliance overhead to carry for an architecture that often started as "the easy integration" the PSP recommended.

Why merchants end up on SAQ A-EP without realising#

If you'd asked the merchant on day one whether they wanted to be on SAQ A or SAQ A-EP, most would pick A. The trouble is the decision is rarely framed that way. The PSP sales engineer demonstrates a drop-in checkout, the developer integrates it in an afternoon, the checkout works, the merchant ships. Six months later, the QSA points out that the integration is SAQ A-EP, not SAQ A, and there's a quarterly ASV scan to set up.

The patterns that put you on SAQ A-EP without an explicit decision:

JavaScript SDKs and drop-in checkouts

The merchant's checkout page loads a JavaScript library from the PSP. The library renders form fields that look like an iframe but are actually rendered inside the merchant's DOM. The customer types their card number, the SDK collects it from those fields, and POSTs it directly to the PSP's API. The merchant's page doesn't "see" the PAN in the sense of having a variable holding it — but the page hosts the code that does.

Stripe Elements is the canonical example. Stripe is explicit in their own documentation that Elements is SAQ A-EP. Adyen's Web Components have the same property. Worldpay's WPG drop-in does too. Most modern "developer-friendly" PSP integrations are SAQ A-EP by design, because the trade-off the PSPs made was UX (full design control, smooth in-page flow, no redirect) at the cost of merchant compliance scope.

The merchants who realise this in advance can make an informed choice. The merchants who don't get the surprise at their next assessment.

Hosted iframes with merchant JS on the parent page

The PSP serves the card form in a genuine iframe from their own domain. So far, so SAQ A. But the merchant's parent page is running analytics tags, A/B test scripts, session replay tools, marketing pixels, chatbots. Each of those scripts has full access to the parent DOM and can, in theory, manipulate the iframe's wrapping elements, read URL parameters that flow back from the iframe, or hijack the page-level events the iframe emits.

This one is debated among QSAs. Strict reading: any merchant JS on the page that hosts the iframe means the parent page is in the cardholder data flow, even if the iframe itself is fully isolated. Pragmatic reading: if the iframe is genuinely cross-origin and the merchant has script integrity controls, the merchant is on SAQ A.

The defensible position is to (a) keep the parent page as bare as possible during the payment step, (b) use Content Security Policy headers that restrict what scripts can load, (c) inventory every script that runs on the payment page, and (d) get the QSA's position in writing before assessment. Bringing the question to the QSA later costs more than asking up front.

Server-side proxy patterns

The merchant's server captures the form submission and POSTs it onward to the PSP's API. The server-side code touches the PAN for a few milliseconds before forwarding. Some merchants assume "we don't store it, so we're SAQ A" — they're not. Server-side proxying is processing and transmitting, both of which are independently disqualifying.

This pattern is closer to SAQ D than SAQ A-EP, because the server tier itself is in the cardholder data environment. Logs need to be sanitised, error handling needs to keep PANs out of stack traces, the server's host OS, the application runtime, and the network it sits on all come into scope.

The five eligibility checks for SAQ A#

If you want to be on SAQ A — the genuinely light 22-control version — work through these in order. The first "no" tells you that you've slipped into SAQ A-EP or worse.

1. Card-not-present only. SAQ A is e-commerce, MOTO, and phone payments. Anything card-present (terminal, mPOS, ATM, kiosk) takes you out immediately to SAQ B, B-IP, C, P2PE, or D depending on the specific hardware.

2. Card capture form served entirely by a PCI DSS-validated third party. The HTML, the JS, the CSS that make up the form must originate from the PSP's domain. Either as a full redirect (the customer's URL bar shows the PSP's domain during entry) or a true cross-origin iframe (the iframe's src is the PSP's domain and the iframe's contents are completely opaque to the parent).

3. No merchant code processes, transmits, or stores PANs at any point. Including back-end systems, including "helpful" features like remembering the last four digits, including writing card numbers to logs for debugging.

4. The PSP issues tokens for any post-payment use case. If you want to do recurring billing, refunds, or card-on-file charges, the PSP gives you a token. You store the token. The token is useless outside the PSP's environment with the right credentials. PANs do not come back to you.

5. The merchant's evidence base supports the SAQ A claim. Current AOC from the PSP. Inventory of any scripts on the payment page. Tamper-detection controls in place. Documented data flow showing the PAN going straight from cardholder to PSP. Staff awareness training. Annual self-assessment.

The first four are about architecture. The fifth is about discipline. Both have to hold for SAQ A to be the right answer.

The five disqualifiers that put you on SAQ A-EP#

If any of these are true, you're on SAQ A-EP, not SAQ A:

1. Drop-in JavaScript SDK on the merchant origin. Stripe Elements, Adyen Web Components, Worldpay WPG drop-in, Braintree Hosted Fields, Checkout.com Frames. All SAQ A-EP, by the PSPs' own admission in their compliance documentation.

2. Merchant-rendered form posting to the PSP. Even if the POST uses HTTPS and the PSP processes the request, the form HTML being merchant-controlled means the merchant's origin handles the card data on submit.

3. Tag managers or analytics on the payment page. The grey area discussed earlier. Strict QSAs treat any merchant JS on the payment page as putting the merchant in the data flow. Get the position in writing before you ship.

4. Single-page application with client-side routing. If your checkout flow runs inside a React/Vue/Angular SPA that handles the routing between cart and payment, your application bundle is loaded on the payment view. The PSP iframe inside the SPA doesn't change that — the SPA is the parent.

5. Anything that touches the PAN before redirect. Validating card number format client-side. Auto-formatting digits with spaces. Card brand detection from the BIN. All of these read the PAN before submission and put you on SAQ A-EP. The PSP's iframe should do that work, not your code.

How to drop from SAQ A-EP back to SAQ A#

The good news is that A-EP isn't a one-way door. Most merchants who land on A-EP did so because the PSP's drop-in SDK was the path of least resistance, not because the architecture demands it. The PSPs all offer SAQ A-eligible integration modes as well — they just don't lead with them.

Step 1: Identify your current integration pattern

Open your checkout page in a browser. Right-click the card number field and inspect. If the field is inside an iframe element whose src attribute points to the PSP's domain (stripe.com, adyen.com, worldpay.com, paymentsense.co.uk), check whether the iframe is genuinely cross-origin or whether your page's JavaScript can interact with it. If the field is a plain input with the PSP's library managing it via JavaScript, that's an SDK — SAQ A-EP.

The fastest tell: in DevTools console on the payment page, type document.querySelector('input[name*="card"]'). If you get a DOM element back, the form is on your origin. If you get null because everything's inside an opaque iframe, you might already be on SAQ A.

Step 2: Choose the PSP integration mode that's SAQ A-eligible

Every major PSP offers at least one SAQ A-eligible mode, even if it's not the one their docs promote first.

Stripe has Stripe Checkout (the hosted page mode) — full redirect to checkout.stripe.com, customer enters card on Stripe's domain, redirects back to your success URL. SAQ A. The Elements integration that gets all the marketing attention is SAQ A-EP. Stripe documents both.

Adyen offers their Hosted Payment Pages (HPP) integration — redirect to checkoutshopper-live.adyen.com, form on Adyen's domain. SAQ A. Their Web Drop-in and Components are SAQ A-EP.

Worldpay offers their Business Gateway hosted payment page — redirect to secure.worldpay.com. SAQ A. Their Custom JS integration is SAQ A-EP.

For phone payments, the DTMF masking architecture with true channel separation is the audio equivalent — the customer's keypad audio is split off at the carrier or SBC layer and routed direct to a PCI-validated endpoint. The merchant's contact centre never touches the digits. SAQ A applies because the merchant's environment is fully out of the data flow.

Step 3: Migrate the integration

For most PSP migrations from SDK to hosted page, the work is a few days. Replace the drop-in code with a server-side call that creates a hosted-payment-session and returns the redirect URL. Send the customer to that URL. Handle the success/failure redirect back. Update the order-confirmation flow to use the PSP's webhook callbacks rather than the SDK's success event.

The trade-off you're making is brand control. The hosted page looks like the PSP, not like you. Some PSPs offer light theming (logo, colours, fonts); others give you a generic-looking page. For most merchants, the compliance cost saving outweighs the brand cost — especially since the customer has already been on your site for the cart steps, sees the PSP's URL only for the card-entry moment, then redirects straight back to your branded confirmation page.

For SPAs, you'll need to break out of the client-side router for the payment step. A full server-side redirect is cleanest. Don't try to embed the hosted page in an iframe inside your SPA — that puts you straight back into the "merchant JS on payment page" problem.

Step 4: Decommission the A-EP evidence collection

Once you've migrated and the new architecture has been live for a quarter, you can stop collecting some of the SAQ A-EP evidence. Quarterly ASV scans are no longer required on your web tier (you'll still want vulnerability scanning for general security hygiene, but not for PCI). Annual penetration testing on the payment page becomes optional. Network segmentation between your application tier and the rest of your infrastructure no longer needs to be evidenced for PCI purposes.

What stays: payment page script inventory (now for the redirect/iframe parent — much smaller surface), PSP AOC collection, the SAQ A questionnaire itself, staff awareness training, third-party management documentation. The annual overhead drops from £25-55k to £8-15k.

Step 5: Tell your acquirer

Acquirers track the SAQ type you self-certify to. Switching from A-EP to A is a meaningful change in your risk profile, so they want to know. Submit the new SAQ A at your next renewal cycle, with documentation of the architecture change. Most acquirers will accept this without a fuss; some want a QSA letter confirming the new integration is genuinely SAQ A-eligible. Plan for a desk review fee of £2-5k if your acquirer asks for one.

The tamper-detection and script-management controls that bite both#

One area where SAQ A and SAQ A-EP both have teeth is the v4.0.1 requirements around payment page script management (6.4.3) and tamper detection (11.6.1). Both SAQs require these. The control text is identical between the two.

For SAQ A merchants, these requirements apply to whatever scripts execute on the page that hosts the PSP iframe (or, for redirect flows, the page that handles the redirect-back from the PSP). Even though the card-entry page itself is on the PSP's domain, your origin still has a role in the transaction flow and the Council has decided your scripts matter.

What 6.4.3 requires: an authorised inventory of every script that loads on the payment page, with documented business justification for each. "Why is the chat widget on the payment page?" is a question the QSA will ask. "Why is the marketing analytics tag loaded here?" — they'll ask that too. Scripts that don't have a clear justification get removed.

What 11.6.1 requires: a tamper-detection mechanism that alerts when the script inventory changes unexpectedly. Subresource Integrity (SRI) hashes on script tags. Content Security Policy reporting. Commercial tools like Source Defense, Akamai Page Integrity Manager, or Jscrambler that monitor for unexpected script behaviour. Whichever approach you take, the alert has to fire when something changes — and you have to investigate the alert.

Both controls came into force on 31 March 2025 as part of the v3.2.1 → v4.0.1 transition. If you self-certified SAQ A before that date and haven't updated your evidence collection, your next acquirer audit will flag the gap. The fix is small but it needs doing.

What the QSA actually reviews at A vs A-EP#

If you bring a QSA in for a desk review on SAQ A, the review takes about a day. They'll ask for: the PSP's current AOC, your script inventory, evidence that tamper detection is active and tested, your data flow diagram, your staff awareness training records, your third-party management documentation (PSP contracts, service definitions), and your self-completed SAQ A. They'll check that the architecture genuinely matches what the SAQ A controls cover. If everything lines up, they sign off and bill you somewhere between £2-5k for the work.

SAQ A-EP is meaningfully more work. The QSA will want: everything from the SAQ A list above, plus quarterly ASV scan reports for the last 12 months, the most recent internal and external penetration test report, network segmentation evidence (firewall rules, VLAN configuration, application-tier isolation), your vulnerability management programme documentation, your secure coding standards, file integrity monitoring evidence for the payment page, and your malware detection coverage. They'll also typically observe a deployment to see that change management is working as documented. The work is 1-2 weeks. The bill is £8-20k for the desk review, plus the ASV scan fees and pen test fees you've been paying through the year.

You can do SAQ A-EP without a QSA — same as SAQ A, both are self-assessments by definition — but the QSA fee is small relative to the rest of the SAQ A-EP overhead, and the desk review is useful for catching gaps before the acquirer does.

The cases where SAQ A-EP is the right answer#

It's not always wrong to be on SAQ A-EP. A few scenarios where the trade-off makes sense:

Brand-critical checkout UX. If your conversion data shows that a full redirect to a PSP-hosted page costs you measurable revenue (cart abandonment, drop-off at the payment step), the SAQ A-EP overhead might be cheaper than the lost conversions. We've seen this in luxury fashion, where the design discontinuity of the PSP page genuinely hurts. Run the numbers before assuming.

Subscription / SaaS flows with card-on-file. If you're collecting cards primarily for recurring billing, a single SDK-based capture moment that tokenises immediately can be cleaner than a full redirect that the customer experiences only once. The compliance overhead is real but the development simplification is real too.

Existing investment in SDK-based architecture. If you've built six years of checkout work on top of Stripe Elements and your team knows the SDK intimately, a migration to hosted checkout for SAQ A purposes might cost more in development and bug risk than the £15-40k/year compliance saving. Accept the A-EP overhead and document the decision.

The honest test is: "Have we considered SAQ A and explicitly chosen A-EP because the trade-off favoured EP for our situation?" If yes, A-EP is defensible. If no — if you're on A-EP because the PSP's onboarding guide pointed you at the SDK and you didn't realise there was a choice — the migration to A is usually worth the cost.

Worked example: a UK D2C retailer drops from A-EP to A#

A direct-to-consumer fashion retailer running on Stripe Elements through their Next.js storefront. Annual revenue around £18M, all card-not-present. Compliance overhead before the project: SAQ A-EP, £38k/year (QSA desk review £8k, ASV scans £4k, annual pen test £18k, internal staff time on evidence collection roughly £8k).

The trigger for the project was the v4.0.1 transition. The retailer's QSA flagged that the tamper-detection requirements under 11.6.1 were going to add operational overhead — the Next.js bundle deployed multiple times a week, each deploy changed the script hashes on the payment page, and every change generated a tamper-detection alert that needed investigating. The retailer was looking at adding a part-time security analyst to manage the alert flow.

Instead, they switched the payment step from Stripe Elements to Stripe Checkout (the hosted page mode). Development time: three engineering days. The flow now: customer fills cart, clicks pay, server creates a Checkout Session, customer redirects to checkout.stripe.com, enters card on Stripe's page, redirects back to a thank-you page on the retailer's origin. The thank-you page is bare HTML — no analytics scripts, no chat widget, nothing that could leak into the payment moment.

Outcomes after one full year:

Compliance overhead: dropped to £11k/year (QSA desk review £3k, no ASV requirement on the merchant origin, no pen test on the payment tier, internal staff time roughly £6k, plus PSP AOC management and staff training £2k). Net saving: £27k/year.

Conversion impact: A/B-measured at 1.8% lower conversion on the redirect flow versus Elements. The retailer's gross margin on the lost conversions was about £180k/year — meaningfully more than the £27k compliance saving. The retailer would not have switched if compliance had been the only factor.

What tipped the decision: the v4.0.1 tamper-detection burden plus the cost of the security analyst they would otherwise have hired (estimated £55k fully-loaded) made the all-in arithmetic favour SAQ A. Net of conversion impact, the year-one move saved approximately £100k. Year two onward, the saving narrows because the conversion lift would have repeated annually — but the retailer has invested the time savings into other conversion optimisation work that closed most of the gap.

The case is unusual in that conversion ran against the migration. For most merchants we see, the redirect flow has zero measurable conversion impact (customers are already mid-purchase, the redirect adds two seconds, the brand cost is largely invisible). For brand-critical sites it pays to A/B-test before committing.

What changes between SAQ A and SAQ A-EP under v4.0.1#

The v3.2.1 → v4.0.1 transition completed on 31 March 2025. Both SAQs picked up changes. The relative position didn't change, but the absolute control burden on each shifted slightly.

SAQ A grew from 14 controls under v3.2.1 to 22 under v4.0.1. The eight new controls cover payment page script management (6.4.3), tamper-detection mechanisms (11.6.1), expanded third-party service provider management (12.8), and a handful of refinements to the existing wording on physical security and policy documentation. The net effect is that SAQ A is a bit less light than it used to be — but still dramatically lighter than A-EP.

SAQ A-EP control count stayed roughly stable around 191. The same script management and tamper-detection requirements apply (they already did in spirit under v3.2.1), but the wording is now explicit. Several controls got the option of a targeted risk analysis (TRA) — you can propose a different control frequency if you can justify it through a documented risk assessment. Useful if you've got a mature security programme; risky if your TRA writing isn't rigorous.

The customised approach is available on both SAQs. You can propose your own controls to meet the underlying objective rather than ticking the prescriptive sub-requirements. More merchants find this useful on A-EP than on A, because A's 22 controls are mostly direct enough that the prescriptive approach works fine.

If you're planning the A-EP → A migration, do the v4.0.1 evidence collection at the same time. Don't migrate first and then update your script inventory — design for v4.0.1 from the start of the project so you're not collecting evidence twice.

The relationship to SAQ D and the wider PCI landscape#

SAQ A-EP sits between SAQ A and SAQ D in control burden, and the boundaries are sharper than the names suggest. The PCI Council's intent with A-EP is to give e-commerce merchants who can't quite get to SAQ A a defined middle ground, rather than punting them straight to SAQ D's 360+ controls.

If you're trying to decide between SAQ A and SAQ A-EP, you've already established that you're not on SAQ D — you've outsourced storage, you're not running your own gateway, you're not card-present. The question is just how much of your origin sits in the payment data flow. The pillar comparison guide on SAQ A vs SAQ D covers the SAQ D side in detail and is worth reading if you're not certain which side of the line your architecture sits on.

For the SAQ A side, the SAQ A guide walks through the 22 controls one at a time. The SAQ A eligibility checklist goes deeper on the eligibility criteria. The SAQ A controls explained piece works through what evidence to gather for each control. And the SAQ A documentation checklist covers the artefacts a QSA wants to see at desk review.

For the underlying technical detail on what "PCI-validated" actually means, the PCI DSS standard itself sits behind all of this. Our what is PCI DSS explainer covers the 12 requirements that the SAQs derive from.

Common questions about the SAQ A vs SAQ A-EP boundary#

A few questions that come up repeatedly when merchants are working through this.

"Can I be on SAQ A for one channel and SAQ A-EP for another?" Yes. PCI DSS allows per-channel SAQ assessment. You might be on SAQ A for phone payments (with DTMF masking) and SAQ A-EP for web checkout (Stripe Elements). Your aggregate posture follows the most restrictive channel, so the operational reality is that you're doing the SAQ A-EP work anyway — but the per-channel breakdown matters for evidence collection.

"Does Apple Pay / Google Pay change the SAQ?" Apple Pay and Google Pay use device-side tokenisation. The merchant never receives a PAN — they get a device-specific token. The integration is usually SAQ A or SAQ A-EP depending on whether the wallet button is rendered by your code or by the PSP. The PSP's drop-in usually handles the wallet button itself, which means the SDK rules above apply.

"What about 3D Secure 2?" 3DS2 is layered on top of whichever capture mechanism you're using. It doesn't change the SAQ. If your capture is Elements-based, 3DS2 fires inside the same SDK and you're still SAQ A-EP. If your capture is a full redirect, 3DS2 fires on the PSP's hosted page and you stay on SAQ A.

"Do mobile apps follow the same rules?" Native mobile apps that integrate a PSP SDK are typically scoped under SAQ A-EP equivalents in the PCI mobile guidance. The PCI Council has a separate mobile payment acceptance guide that overlays the SAQ structure. Generally, if your app loads a PSP SDK that renders form fields inside your app, you're A-EP-like. If your app punts to a web view hosted by the PSP, you're A-like.

"What happens if my acquirer wants A-EP and my QSA says A?" The acquirer has the final call on which SAQ they'll accept. The QSA can advise but the acquirer signs off. If there's a disagreement, escalate to the acquirer's compliance team in writing before you self-certify. Most disagreements resolve through documentation rather than architectural change.

"Is SAQ A-EP going away in a future PCI DSS version?" There's been industry discussion about whether the A vs A-EP split is still meaningful in a world of widespread JavaScript SDK adoption. As of v4.0.1, both SAQs exist and both are actively used. The Council hasn't signalled a near-term plan to consolidate them.

The architectural takeaway#

The single biggest lever in SAQ A vs SAQ A-EP is whether your code runs on the page where the card is entered. Everything else is downstream of that one decision. PSPs make the SDK path easy because it gives them a better UX story, but they're explicit in their documentation that the SDK is SAQ A-EP — most merchants just don't read that part of the documentation until the QSA points it out.

If you're greenfield, design for SAQ A from the start. Pick the hosted-checkout mode of whichever PSP you're using. Accept the design discontinuity of the PSP page. Keep your origin code out of the payment flow. The annual compliance saving compounds across the lifetime of the business.

If you're already on SAQ A-EP and the v4.0.1 transition is adding overhead, the migration to SAQ A is usually small, well-understood, and pays back inside a year. The Pinnacle Group case study on our case studies hub documents a 95% PCI scope reduction from a related architectural shift — the principle is the same: get your code out of the data flow and the questionnaire shrinks.

Next steps#

If you're trying to work out whether you're on SAQ A or SAQ A-EP today, the practical test is the DevTools check in step 1 above — open your payment page, inspect the card input, see whether it's inside a cross-origin iframe (likely SAQ A) or a merchant-rendered field with PSP JavaScript managing it (SAQ A-EP). That tells you where you actually are, independent of what the integration was sold as.

For phone payments specifically, the equivalent check is whether the customer's keypad audio is heard by your agent or split off at the carrier. If your agent hears the digits, you're SAQ D no matter what the vendor sells it as. If channel separation moves the audio direct to a PCI-validated endpoint, you're SAQ A. The DTMF masking solution page walks through the audio architecture.

If you'd rather walk it through with someone who's done the migration on the other side, the contact form reaches our UK team, or you can book a 15-minute call to see the architecture wired against your actual phone or web setup. For background on the standard itself, the what is PCI DSS explainer covers the 12 requirements the SAQs derive from, and the related SAQ glossary entry and PCI DSS 4.0.1 glossary entry cover the technical terms.

The structural point: SAQ A-EP isn't a permanent fate. It's a snapshot of where your code sits relative to the payment flow. Move the code out of the flow and the questionnaire follows.

Related reading#

• What is SAQ A? PCI compliance levels explained
• SAQ A vs SAQ D: which do you need?
• SAQ A eligibility checklist
• SAQ A controls explained
• SAQ A documentation checklist
• What is PCI DSS? The full explainer