PCI SAQ Types Explained: A, A-EP, D — Which One Are You Stuck With?

You've probably heard someone mention "we're SAQ D" with a grimace. That reaction is well-founded. SAQ types aren't just categories — they're a direct measure of how much PCI DSS work you're signing up for, and most PMS and channel manager companies don't realise they're in the most demanding one until an auditor shows up.

Your SAQ type is determined by how much card data touches your systems. The more it touches, the more the PCI DSS applies to you. The difference between a manageable compliance burden and a significant ongoing cost is often a single architectural decision made years ago.

What's an SAQ, and Why Should You Care?

SAQ stands for Self-Assessment Questionnaire. It's how merchants and service providers prove they're following PCI DSS rules. The PCI Council publishes the questions, and based on how you answer, you fall into one of three categories that'll define your compliance life for the next 12 months.

Your SAQ type directly determines:

• How many PCI DSS requirements you must follow (anywhere from 12 to 300+)
• Whether you need an external auditor (some do, some don't)
• How much of your engineering team's time goes to compliance instead of features
• Your annual audit costs and ongoing security spending

The stakes are real. In breach scenarios, card brand fines vary based on scope and number of records compromised — but the financial exposure can be significant, alongside mandatory forensics costs, customer notification obligations, and potential card network penalties. Some acquiring banks and processors have also become more selective about merchants with large PCI scope, as it increases their own risk exposure.

SAQ A: The Dream (If You Can Achieve It)

SAQ A applies if: You accept card payments through a fully hosted payment page on your payment processor's domain — the customer leaves your application to enter their card details. Card data never touches your servers, networks, or systems.

How it works: Customer lands on your checkout. You hand them off to Stripe, Square, or another processor. They enter their card on the processor's page. Data never comes through your servers.

Requirements: Around 12 core PCI requirements. You don't manage card data, so you don't need encryption, tokenization, secure databases, intrusion detection, or most of the heavy lifting.

The catch: If your integration is anything but fully hosted, you're not SAQ A. Many companies think they are SAQ A, then realize during audit that their custom integration scripts, hidden form fields, or API calls mean they're actually handling card data. One mistake and you drop straight to SAQ D.

SAQ A-EP: The Compromise (Partial Card Handling)

SAQ A-EP applies if: Your website can affect the security of a payment transaction — for example, by hosting or delivering payment form elements, iframes, or scripts — even if your servers don't directly receive card data. The key test: if your page influences how card data is collected or transmitted, you're likely SAQ A-EP.

How it works: Your booking form includes a payment iframe hosted by your payment processor. The cardholder enters their card in that iframe. Your server never receives the raw card number — instead it receives a token or confirmation. But because your page delivers the payment form elements, your systems are still in scope.

Requirements: Around 80-100 PCI requirements. More than SAQ A, but nowhere near SAQ D. You need basic encryption, network segmentation, some audit logging, and vendor management.

The reality: This is where most mid-market PMS and channel manager companies live. You're not fully hosted (the customer experience demands a seamless checkout on your page), but you're smart enough to avoid storing the card data itself. It's a workable middle ground, but it still requires serious security infrastructure.

The gap: The difference between SAQ A and SAQ A-EP is significant. You're responsible for securing the iframes, validating the tokens, preventing man-in-the-middle attacks on the iframe calls, and proving that your system never stores the card data. One misconfiguration (storing the card "just for a second" in a session variable, logging it to debug, passing it through an unencrypted API) and you're SAQ D.

SAQ D: The Nightmare You Didn't Choose

SAQ D applies if: You store, process, or transmit card data in any way that doesn't fit SAQ A or SAQ A-EP. This includes:

• Storing card data in your database (even encrypted)
• Passing card data through your APIs
• Logging card data, even accidentally
• Handling card data in batch processes, chargebacks, or refunds
• Storing cards for recurring billing or retries

How it works: Your system touches the card data directly. You're responsible for end-to-end security of that data. Everything in PCI DSS applies to you.

Requirements: 300+ PCI DSS requirements. Full scope audits by Qualified Security Assessors. External penetration testing. Annual compliance certification. Continuous monitoring, incident response planning, vendor risk management, encryption key management, and more.

The cost: For a representative mid-market travel tech company, SAQ D compliance can run well into six figures per year in combined audit fees, testing, tooling, and engineering time. The engineering burden — implementing encryption, managing keys, building intrusion detection, maintaining audit logs, segmenting networks — is significant and ongoing. (See our cost breakdown post for illustrative estimates.)

Why companies end up here: Most didn't make an intentional choice. They built their PMS or channel manager years ago, before they fully understood card handling. They stored cards for retry logic, or kept them in a batch system for manual reconciliation, or logged them for debugging. By the time they realized, thousands of merchants were depending on the system. Migration to SAQ A or A-EP would require rewriting core payment logic.

That's where most travel tech companies find themselves: trapped in SAQ D not because they're reckless, but because the architectural debt is too expensive to fix.

The Real Difference: Not Just Compliance, But Viability

The jump from SAQ D to SAQ A-EP or SAQ A isn't just a paperwork change. It's transformative:

• Engineering time: From substantial ongoing developer time on PCI compliance to a much lighter integration maintenance burden
• Third-party risk: From managing all the card data security yourself to delegating that to a specialised payments provider
• Audit burden: From full external audits (with months of prep, weeks of testing, findings to remediate) to self-assessment or lighter validation
• Liability: From broad exposure to breach-related fines and incident response costs to a significantly reduced risk profile (exact liability allocation depends on your contractual arrangements)
• Growth constraints: SAQ D merchants can face increasing friction as they grow — more scrutiny from processors and card networks, rising compliance costs, and more expensive breach insurance. A smaller PCI footprint removes many of these scaling barriers.

How to Move From D to A or A-EP

The path depends on your current architecture:

If you're SAQ A-EP: You're already handling card data in a controlled way. You can stay here indefinitely, or migrate to SAQ A by moving to fully hosted payment pages. This works if your user experience can tolerate redirect-based checkout instead of embedded forms.

If you're SAQ D: The migration requires architectural change. You need to:

1. Implement tokenization — card data is replaced with a token managed by a payment processor
2. Ensure your system works with tokens, not raw cards
3. Eliminate card storage, logging, and batch processes that touch raw data
4. Validate with your payment processor that you've truly achieved SAQ A or A-EP status

This isn't a quick fix. But it's foundational to scaling safely.

The Best SAQ Is the Shortest One

Here's the uncomfortable truth that payments processors don't emphasize: PCI DSS compliance is not a competitive advantage. It's a cost center. The best PCI strategy is to do as little of it yourself as possible.

The companies in travel tech that are growing fastest aren't the ones that mastered PCI DSS. They're the ones that removed card data from their own systems entirely. They implemented a payments architecture where a specialized provider handles the compliance burden, and they focused their engineering on what matters: building great hotel tech.

With Vaultera's tokenization and orchestration platform, you move your card data off your servers into our PCI Level 1 certified infrastructure. Vaultera manages the encryption, the keys, the audits, the compliance burden. You integrate via API, work with tokens, and your SAQ surface can shrink from SAQ D to SAQ A-EP or SAQ A, depending on your architecture.

That's not a compliance detail. It's the difference between significant ongoing security and audit spend, and a fraction of that on a proven payments platform. It's the difference between your developers building payment infrastructure and building your actual product.

The question isn't whether you can handle PCI DSS. The question is whether you should. And for almost every travel tech company, the answer is no.

A note on service providers: These SAQ categories apply to merchants. If you operate as a service provider — processing card data on behalf of other businesses, as many PMS companies and channel managers do — your validation path is different. Service providers typically undergo a full external QSA audit rather than completing an SAQ. Speak with your acquiring bank or a Qualified Security Assessor to understand your specific obligations.

Vaultera Vault handles the card data. You handle your business. [Learn how tokenisation can reduce your SAQ footprint.](https://vaultera.co/contact)