PCI DSS SAQ A-EP for direct post and merchant-hosted payment pages

SAQ A-EP applies when your website builds or controls the payment page while a PCI DSS compliant provider handles the card data. This guide explains the eligibility line, the v4 additions and who does what.

Book a callTalk to us
On this page

Does a direct post merchant that never stores card data still need SAQ A-EP?

If your website builds all or part of the payment page and posts card data directly to your processor, SAQ A-EP applies, even though you never store, process or transmit account data yourself. The payment channel is outsourced, but the page that collects the data is still your website, so you remain answerable for its integrity. Your team has outsourced payment processing, yet the checkout template, its scripts and its form fields are still produced by code you control. That split is what the SAQ A-EP scope is designed to capture. Whether you fall under SAQ A-EP depends on who generates each element of the payment page, not on the fact that you outsource. Where the processor generates the page inside an iframe or through a redirect, the answer changes, and the eligibility conditions in the later sections explain how to test each element. Start by listing every page element and script that loads at checkout and recording its origin. Ownership of that answer stays with your organization. Your acquirer or payment brand confirms the SAQ type you must complete, and a PCI DSS Qualified Security Assessor or Internal Security Assessor can review your reasoning before you attest.

The practical risk is assuming that a hosted payment provider removes responsibility for the page. If a script that your team deploys is altered, the processor's certification does not cover it, and the page you operate is where card data is typed. Before you complete any questionnaire, confirm with your acquirer which SAQ applies to each sales channel, and keep the written record of each element's origin with your evidence. Review the processor's Attestation of Compliance as part of this exercise. The PCI DSS v4.0 SAQ A-EP document sets out the eligibility criteria you will need to test against.

Direct post, iframe and redirect: which SAQ fits each page model

With direct post, the merchant's website builds all or part of the payment page and sends the entered card data to the payment processor. Because the merchant's own code touches the payment fields and the transmission, the merchant's website affects the security of the payment transaction, and SAQ A-EP is the questionnaire that applies. The merchant does not store, process or transmit account data electronically, but the page itself sits inside the assessment boundary.

  • Who builds the form: The merchant's web code, templates or hosting produce the fields that collect card data.
  • Where the data goes: Account data is posted directly to the processor's endpoint, so the merchant's server is part of the payment flow.
  • What the assessor checks: Script controls, page integrity, web-attack protection and the outsourcing arrangements that cover the rest of the channel.
  • Added v4 expectations: Payment page script and tamper-detection controls apply to direct post pages that SAQ A-EP covers.
  • Common mistake: Treating direct post as SAQ A because no card data is stored. Storage is not the test here; who generates the page is.

Before choosing, confirm with your acquirer and the guidance in PCI SSC FAQ 1291 that your integration is classed as direct post.

The SAQ A-EP eligibility criteria, one by one

A merchant qualifies for SAQ A-EP only if every eligibility condition holds at the same time, and a single failure moves the merchant to a different questionnaire. The first condition is that all processing except the payment page is outsourced to a PCI DSS compliant third-party service provider (TPSP). Your own systems may host the page that collects card data, but they must not receive, store, process or transmit account data electronically. Map each system that touches the checkout flow, including order management, fraud tools, tag managers and customer databases, and confirm that none of them carries account data. The second condition is that your site controls how customers or their data are redirected. If a provider or a third-party script can send shoppers elsewhere, you need to show who controls that path and document it.

The third condition concerns the origin of each payment page element. Every element must come from your site or from a PCI DSS compliant TPSP, so an inventory of the scripts, frames and images on the checkout page is the working document for this check. Ask each script provider whether it is validated, and confirm that the payment page scripts you rely on can be authorized and their integrity assured in line with Requirement 6.4.3. The fourth condition covers hosting. If a TPSP hosts your site or the payment page, that host must also be PCI DSS compliant. Where the host is multi-tenant, the SAQ points you to Appendix A, which addresses shared hosting, so confirm that the host's current documentation covers the case that applies to you. The fifth condition is that you have reviewed the Attestation of Compliance (AOC) for each TPSP. Keep those AOCs on file, check their dates and scope, and confirm that the service described in the AOC matches the service you buy.

Treat these conditions as a standing checklist, not a one-time sign-off. A new analytics tag, a change of processor, or a redesign that moves the payment fields into your own template can break a condition without any change to your questionnaire. Before you submit, confirm the final list of eligibility answers with your acquirer, since the payment brands and acquirers decide which SAQ applies to a given merchant. If you find that card data reaches your servers in any form, including encrypted or temporarily cached data, stop relying on SAQ A-EP and move to the questionnaire that matches your actual environment.

What PCI DSS v4 added for A-EP merchants

PCI DSS v4 added several requirements that apply to SAQ A-EP merchants even though their website never receives account data. Each card below names one addition, what the merchant must be able to show an assessor, and where the organization's own ownership ends and an implementation partner's preparation work begins. The merchant owns every control; a partner can prepare systems and evidence, but only an independent assessor validates them.

Payment page script protection

Requirement 6.4.3 asks the merchant to confirm that each script loaded on the payment page is authorized, to assure its integrity, and to keep an inventory of all scripts with a written justification for each. The requirement became mandatory on 31 March 2025. An assessor will expect the script inventory and justifications to match what the browser actually loads, so check tag managers and third-party tags, not only the code in your repository. The organization owns this control; an implementation partner can help build the inventory and integrity-checking method.

Payment page change and tamper detection

Requirement 11.6.1 calls for a mechanism that alerts personnel when security-impacting HTTP headers or payment page contents change in the consumer's browser as received. For an A-EP merchant this is the control that catches e-skimming injected after the page leaves your server. Ask whether alerts reach a staffed queue, how often the monitored elements are reviewed, and whether a tested response procedure exists. The merchant owns the alerting and response; an implementation partner can configure monitoring and document the evidence trail.

Malware and phishing protections

v4 extends anti-malware and anti-phishing expectations to the merchant's web-facing environment, including the staff and systems that administer the payment page. An assessor will ask which controls cover the hosting and administrative workstations, how detections are logged and acted on, and whether the merchant can show current protection. Confirm which systems are in scope for this SAQ, since the A-EP eligibility criteria limit what the merchant itself runs. The organization owns the protections; a partner can document coverage and configuration.

Bespoke software inventory and web-attack protection

The merchant must maintain an inventory of bespoke and custom software on the site and protect public web applications against common attacks. Assessors look for a current list of custom components, their owners and their update path, plus evidence that web-attack protection is active and reviewed. Where the site is built on a platform, confirm which parts are custom code the merchant maintains. The organization owns the inventory and the protection; an implementation partner can help produce the inventory and test the web-facing controls.

MFA for all access to the CDE

v4 requires multi-factor authentication for all access into the cardholder data environment, not only remote or administrative access. For an A-EP merchant, the question is which accounts can reach the payment page configuration, the processor portal, or hosting consoles that touch that page. An assessor will want a list of those access paths and proof that MFA is enforced on each. Confirm with your processor and hosting provider which systems count as the CDE in your setup. The organization owns access management; a partner can implement and evidence MFA.

Automated audit log review

Requirement 10 changes in v4 call for automated mechanisms that review audit logs, with alerts for anomalies, rather than relying only on manual checks. For an A-EP merchant, logs from the payment page host, admin accounts and any tag or script management tool are the most useful to review. The assessor will ask what is logged, who receives alerts, and how reviews are recorded. The organization owns the review process; an implementation partner can set up log collection and review rules and keep the records an assessor will request.

Targeted risk analyses and phishing training

v4 requires targeted risk analyses for requirements that allow flexibility in how often an activity is performed, and it adds phishing awareness training for personnel. A-EP merchants should document why each chosen frequency fits their environment and show that staff who administer the payment page complete phishing training. Ask for the risk analysis template and the training records an assessor will check. The organization owns both; a partner can draft the analyses and deliver training material, but the decisions remain the merchant's.

24/7 incident response personnel

v4 expects an incident response plan with personnel available around the clock to respond to suspected compromise of account data or of the payment page. For an A-EP merchant this means a named on-call rotation, an escalation path to the processor and hosting provider, and a tested procedure for taking the payment page offline or switching to a backup. Assessors will ask for the contact list, the escalation timeline and a record of the last test. The organization owns incident response; an implementation partner can help write and exercise the plan, but cannot provide the on-call staff.

Payment page script controls under Requirements 6.4.3 and 11.6.1

Requirement 6.4.3 and Requirement 11.6.1 are the two controls that protect the payment page itself, even when no card data touches your servers. Under Direct Post, your website builds all or part of the payment page, so the scripts that run in the customer's browser are part of your environment. Requirement 6.4.3 asks for three things: a method to confirm each payment page script is authorized, a method to assure each script's integrity, and an inventory of every script with a written justification for why it is there. This became mandatory on 31 March 2025, so an assessor will expect it in place now, not as a future plan.

Requirement 11.6.1 covers the detection side. You need a change- and tamper-detection mechanism that alerts personnel when security-impacting HTTP headers or payment page contents change in a way that is unauthorized. The key phrase is "as received by the consumer browser": monitoring the server's copy of a page is not enough, because skimming code is usually injected after the page leaves your server. Confirm with your web team and your monitoring vendor exactly which elements are watched, how alerts reach a responder, and how each alert is triaged and closed.

For SAQ A-EP, the same pages also bring in quarterly external vulnerability scans by an Approved Scanning Vendor under Requirements 11.3.2 and 11.3.2.1, as PCI SSC FAQ 1604 explains for SAQ A merchants whose pages redirect to or embed a payment provider. Check with your acquirer whether the scan obligation applies to your configuration. For third-party scripts such as analytics or tag managers, use FAQ 1592 and FAQ 1588 as references to confirm whether each script is eligible for your SAQ, and document the answer in the script inventory.

How to confirm SAQ A-EP eligibility before completing the questionnaire

This sequence establishes, with evidence, whether every payment page element and every outsourced function meets the SAQ A-EP eligibility criteria. It ends with a documented eligibility decision that the acquirer has confirmed before the questionnaire and Attestation of Compliance are signed.

  1. Map every payment page element and its origin

    The merchant's web team lists each page that a customer sees during checkout, then records every element on it: the HTML that builds the page, any iframe, any redirect, and every script or resource loaded by the browser. For each element, record whether it comes from the merchant's own site, from a PCI DSS compliant third-party service provider (TPSP), or from a source that cannot be identified. Direct post pages, where the merchant's site builds all or part of the payment form and posts data to the processor, are flagged at this stage because they point toward SAQ A-EP. The step is complete when the team holds a page-by-page element map that a second person has reviewed and that identifies the origin of every item.

  2. Confirm the payment flow outsources all other processing

    Using the element map, the team traces where each customer data flow goes after the payment page, including order management, fulfillment, analytics, and customer service tools. It confirms that all processing other than the payment page itself runs with a PCI DSS compliant TPSP and that no account data is stored, processed or transmitted electronically by the merchant's own systems. Any system found to handle account data moves the merchant out of SAQ A-EP and must be re-evaluated. The output is a written data-flow summary that names each TPSP and the function it performs.

  3. Verify each TPSP's current AOC and PCI DSS status

    For every TPSP named in the data-flow summary, the merchant requests the current Attestation of Compliance and confirms its validation status with the provider. The review checks that the AOC covers the service actually used, that the assessment is current, and that the scope described in it matches the payment channel the merchant relies on. A certificate or marketing statement does not substitute for the AOC. The output is a dated file of AOCs with a note of the service each one covers and any gap found.

  4. Check hosting and multi-tenant status

    The merchant determines where the website and its payment page are hosted and whether that hosting provider is itself a PCI DSS compliant TPSP. If the host is a multi-tenant provider, the team confirms that the host's assessment addresses the requirements for multi-tenant service providers, including the relevant appendix of the standard. The team also confirms who controls the web server, content management system and any tag manager, since those controls determine who can change the payment page. The output is a hosting record that shows the provider, its validation status, and the people with change access.

  5. Confirm the redirect and script controls with the acquirer

    The merchant asks its acquirer or payment processor to confirm, in writing, the SAQ type that applies to its specific integration, including whether the direct post design falls under SAQ A-EP. The team also confirms which payment page scripts the merchant is responsible for, how the processor expects script authorization and integrity to be handled, and what the processor requires for redirect control. Where the merchant's understanding and the acquirer's answer differ, the acquirer's position and the reasons for it are recorded. The output is a written acquirer confirmation that names the SAQ and the integration reviewed.

  6. Complete the SAQ and sign the Attestation of Compliance

    With the eligibility evidence assembled, the merchant completes SAQ A-EP, answering each requirement on the official template and recording the testing performed for each response. Requirements that the merchant marks as not applicable carry a documented reason. The merchant then completes the Attestation of Compliance for SAQ A-EP and signs it through the authorized process. Where the merchant uses a QSA or ISA for help, that help is recorded, and the answers remain the merchant's own. The output is a completed SAQ and a signed AOC supported by the evidence file.

  7. Keep the evidence file current

    The merchant stores the element map, data-flow summary, TPSP AOCs, hosting record, acquirer confirmation, completed SAQ, and signed AOC in one controlled location with version dates and an owner. The team sets a review trigger for any change to the checkout, redirect, script inventory or TPSP lineup, because any such change can alter eligibility. The output is an evidence index that lets a later assessor or acquirer trace each eligibility decision to its source.

Who owns each part of an A-EP assessment

Your organization owns the outcome. You decide whether your website and your processors meet the SAQ A-EP eligibility criteria, you own the payment page code and the scripts that run on it, and you answer every SAQ question yourself. The Attestation of Compliance is signed by someone at your organization who is accountable for the answers, and that signature rests on evidence your team can produce on request.

  • Eligibility decisions: confirm that all processing except the payment page is outsourced to compliant third parties and that your site controls how customers are redirected.
  • Payment page code: own the direct post or hosted page build, the change process and the script inventory with written justifications.
  • SAQ answers: complete each response and the expected testing evidence, and keep the reasoning behind every answer.
  • Third-party review: collect and review the AOC of each TPSP, including any hosting provider, and track when each one expires.
  • Signed AOC: the authorized signatory attests to the answers, and your process records who approved it.

Before you start, check that each responsibility above has a named owner in your organization.

Questions merchants ask about SAQ A-EP

Is SAQ A-EP cheaper than SAQ D?

Usually the effort is lower, but the answer depends on your environment rather than on the SAQ label. SAQ A-EP applies when your website never receives account data, so the card data environment sits with a PCI DSS compliant third party, and your remaining work centers on the payment page, its scripts, the web server and the outsourcing records. SAQ D covers far more systems, including any storage of account data, which means a larger scope, more requirements to test and a more involved evidence set. The cost drivers for A-EP are the number of payment page elements you control, how many scripts load on checkout, how many hosts and TPSPs you rely on, and whether an outside party performs the assessment work. Ask any quote to itemize each of these, and ask whether the price covers the Attestation of Compliance preparation or only the technical work.

Can a merchant complete SAQ A-EP without a consultant?

Yes, a merchant can complete the questionnaire with its own staff if those staff can read the eligibility criteria, test the requirements and document the results. The harder parts are the v4 additions for A-EP, which include payment page script controls, malware and phishing protections, web-attack protection and automated log review, because they need engineering access to the checkout code and hosting. Staff who must confirm that each script is authorized, has integrity assurance and has a written justification will need developers and web operations involved. Outside help is useful when the team lacks that access or time, but a consultant does not sign the attestation. The merchant owns the answers, and the acquirer decides whether a self-assessment is accepted. Confirm this with your acquirer before you start.

How long does SAQ A-EP readiness take?

No duration is supplied for this page, so treat any number you hear as unverified until it appears in a written plan. Readiness time depends on how many payment pages you run, whether your checkout code is custom or vendor-built, how many scripts load on the page, and how quickly your processor and hosting provider supply their current Attestations of Compliance. Teams that already maintain a script inventory and change records usually move faster than teams starting from nothing. Ask any provider for a scoped plan that lists each task, the owner of each task, the evidence each task produces and the dependencies on third parties. A fixed-scope plan agreed in writing before work starts gives you a timeline you can hold a vendor to.

Does my payment gateway's AOC cover my site?

No. A gateway's Attestation of Compliance covers the gateway's own environment, not your website, your hosting or the scripts you load. SAQ A-EP requires that you review the AOCs of every TPSP involved, confirm that each one is PCI DSS compliant, and confirm that any hosting provider's compliance covers the services you use, including the multi-tenant hosting appendix where it applies. You still own the requirements for your web server, your pages, your change control and your script management. Ask the gateway which responsibilities it accepts under its own responsibility matrix, and record the answer in your evidence file. Keep copies of each AOC with its validity period so an assessor can see what you reviewed and when.

What happens if a third-party script provider changes its code?

A change by a script provider can alter what runs in the checkout page of your site without any change on your side, which is why SAQ A-EP v4 requirements focus on payment page script control. Your controls need to detect the change, confirm whether the new code is authorized, and record the decision. The integrity assurance method you use, such as monitoring of script contents or a change detection mechanism that alerts personnel to unauthorized modifications of the payment page, should flag a changed script before customers pay. Review each provider's terms, ask how it notifies customers of updates, and confirm which of its scripts can run on the page at all. Keep the inventory current, because an unlisted script that appears on checkout is a finding in its own right.

Does the acquirer decide which SAQ I complete?

Your acquirer and the payment brands decide the validation requirements that apply to you, because the PCI Security Standards Council does not enforce compliance or impose penalties. The SAQ you may use depends on how you accept cards, and an acquirer can reject a self-assessment that does not match its records of your payment channel. Confirm your SAQ type in writing with your acquirer before you start work, and ask whether it requires an ASV scan report or another document with the attestation. If your integration changes, such as moving from a redirect to a direct post, your eligibility can change too, so repeat the check. A consultant or assessor can help you prepare, but the acquirer's answer is the one that governs your validation.

How DeployOpen prepares payment page evidence for your assessor

DeployOpen works on the infrastructure and tooling side of SAQ A-EP readiness: the merchant-controlled payment page, its scripts, its hosting and its evidence. Our role is to prepare systems and documentation for your self-assessment, while your organization owns its controls and your acquirer or assessor confirms the outcome.

How we scope

  • Confirm in writing which page elements your site builds and which come from the processor or a compliant third party.
  • Document every hosting provider, script source and redirect path so eligibility can be checked against the SAQ criteria.
  • Agree the fixed scope, deliverables and timeline in writing before any work starts.

How we build

  • Implement and harden the self-hosted platforms and web components inside your own cloud accounts or data centers.
  • Set up a payment page script inventory with an authorization method, an integrity check and a written justification for each script.
  • Configure change and tamper detection for security-impacting HTTP headers and payment page content as delivered to the browser.

How we hand over

  • Deliver the script inventory, configuration records, network and data-flow diagrams and test results your assessor will request.
  • Document the Expected Testing evidence for each applicable requirement, marking any requirement not applicable with the reason.
  • Walk your team through the evidence so they can answer assessor questions and maintain it between assessments.

How we support

  • Offer ongoing support, upgrades and continuous testing of the payment page as a retainer after handover.
  • Review script changes and new third-party providers against the inventory before they go live.
  • Confirm with your acquirer or QSA which SAQ version and approach apply, since DeployOpen does not issue attestations.

Sources and further reading

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com