How does iframe, redirect or direct post change PCI DSS for e-commerce?
A customer, contract or acquirer request to validate PCI DSS for online payments usually starts with one question: how does the checkout collect card data? The checkout method determines the SAQ. Redirect and iframe pages generally fall under SAQ A, direct post and JavaScript forms fall under SAQ A-EP, and accepting card data on your own site falls under SAQ D. Each step up the list brings more requirements you must meet and more evidence an assessor will ask for. Confirm the method with your payment provider in writing, because the provider's integration documentation describes exactly which elements your pages serve and which come from the provider.
The organization owns its controls. An implementation partner can prepare systems, script inventories, network diagrams and evidence, but a partner's work does not validate anything. Only the attestation process does: a Qualified Security Assessor issues a Report on Compliance for larger assessments, and for SAQ-based validation the merchant completes the questionnaire and its Attestation of Compliance. The PCI SSC FAQ on SAQ A-EP and SAQ A sets out how the iframe, redirect and direct post cases are separated, which is the first document to bring into a scoping discussion.
Two things change the workload even when the SAQ stays the same. First, an iframe or redirect page that embeds a provider's form is subject to the script-attack eligibility criterion, which the PCI SSC FAQ on SAQ A script eligibility explains applies to merchants whose page embeds a provider's form but not to those who fully redirect. Second, quarterly external scans by an Approved Scanning Vendor apply to SAQ A merchants whose pages redirect to or embed a provider's iframe. Ask your provider which of these applies to your integration and whether your own site, plugins or tag managers can change the payment page. Those answers, not the checkout label alone, decide the evidence you will need.
Which checkout model puts your site in which SAQ?
With a redirect, the customer leaves your site at checkout and lands on a payment page that the processor generates and hosts. Your site builds none of the payment page and does not receive the card data, so the payment page elements come directly from a third party. This is the most fully outsourced model covered on this page.
- Page generation: The provider's hosted page collects the account data. Your site sends the order and receives the result.
- SAQ: SAQ A applies under FAQ 1291 when every payment page element comes only and directly from PCI DSS validated third-party service providers.
- Script-attack criterion: FAQ 1588 states that this criterion does not apply to merchants that redirect customers to the provider or fully outsource payment.
- ASV scans: FAQ 1604 requires quarterly external vulnerability scans by an ASV for merchant webpages that redirect to a payment provider.
- Page changes: Adding a third-party analytics or marketing script to the pages that lead into the redirect can change your eligibility, so review those pages before each release.
Confirm the provider's validation status and the exact elements on your pages before you select SAQ A for this model.
With an iframe, the processor generates the payment form and your page displays it inside an embedded frame. The customer stays on your domain, but the card fields come from the provider. Your page still hosts the surrounding checkout and carries the risk that a script on it could alter the payment form. FAQ 1291 places an iframe under SAQ A when the same third-party requirement is met.
- Page generation: The provider's form sits inside an iframe on your page, so the card fields come from the provider while the frame sits on your site.
- SAQ: SAQ A applies under FAQ 1291 when all payment page elements come only and directly from validated providers.
- Script-attack criterion: Since 30 January 2025, SAQ A requires you to confirm your site is not susceptible to script attacks that could affect your e-commerce systems. FAQ 1588 says this applies to iframe embedding.
- ASV scans: FAQ 1604 requires quarterly ASV scans for merchant webpages that embed a payment provider's iframe.
- Own scripts: Every script on the checkout page, including tag managers, needs review against the criterion, and your assessor will expect that review to be documented.
Record how you confirm the script criterion each time the checkout page changes, since one new script can make your attestation inaccurate.
With direct post, your website builds all or part of the payment page and sends the account data straight to the processor. Your site shapes the payment transaction and the integrity of the page that accepts it, but it does not store, process or transmit the account data itself. FAQ 1291 places direct post under SAQ A-EP, and a JavaScript form that your site builds follows the same logic.
- Page generation: Your site builds the form or part of it, and the browser posts the card data to the processor.
- SAQ: SAQ A-EP applies under FAQ 1291. SAQ A-EP covers e-commerce merchants whose website does not receive account data but affects the security of the transaction.
- Script criterion: The SAQ A criterion in FAQ 1588 does not apply here. Requirements 6.4.3 and 11.6.1 have applied to entities outside SAQ A since 31 March 2025, covering script authorization, script integrity and script inventory.
- Scanning: The sources used for this page do not settle whether ASV scans apply to SAQ A-EP, so confirm this with your acquirer and assessor.
- Guidance: The Payment Page Security and Preventing E-Skimming information supplement, published 10 March 2025, explains how to meet 6.4.3 and 11.6.1 on a payment page.
Check which parts of the form your code builds, because each part you control moves the answer toward the controls on your own page.
With self-hosted card fields, your own front end or application renders the card inputs and receives the account data before it reaches the processor. Your web servers, code and any logs that touch the data are now part of the environment that handles cardholder data. The SAQ A and SAQ A-EP routes do not fit this model because your site receives the account data. SAQ D for Merchants covers e-commerce merchants that accept cardholder data on their own website.
- Page generation: Your application renders the card fields and receives the account data before the processor does.
- SAQ: SAQ D for Merchants applies to merchants that accept cardholder data on their own website and do not meet the criteria for another SAQ.
- Scope: Systems that store, process or transmit the data, and systems that could affect them, fall in scope, which usually adds requirements to document and test.
- Script and page controls: Requirements 6.4.3 and 11.6.1 apply to entities outside SAQ A, which includes this model.
- Scanning: Confirm with your acquirer whether quarterly ASV scans apply to your external systems under the SAQ you are assigned.
Ask your acquirer which SAQ it expects before you build, because that choice decides how much of the environment you must document and test.
What the script rules in SAQ A and SAQ A-EP ask for
On 30 January 2025 the PCI SSC removed Requirements 6.4.3, 11.6.1 and the related targeted risk analysis from SAQ A, and added an eligibility criterion: the merchant must confirm that its website is not susceptible to script attacks that could affect its e-commerce systems. Whether that criterion applies to you depends on how the payment page reaches the customer. FAQ 1588 says it applies when your webpage embeds a provider's page or form, such as an iframe. It does not apply when customers are redirected to the provider or payment is fully outsourced. In practice, a merchant with an embedded iframe should document why its own pages cannot be altered to capture card data, and should check that the eligibility statement on its SAQ A matches that assessment. Confirm the wording with your acquirer, since the payment brands and acquirers set which validation applies to you.
Requirement 6.4.3 is different. It became mandatory on 31 March 2025 for entities outside SAQ A, which includes SAQ A-EP merchants whose pages run the card form in their own code. It asks for three things. First, a method to confirm that each script on a payment page is authorized. Second, a method to assure each script's integrity, so an unexpected change to a file is detected. Third, an inventory of every script on the payment pages, with a written justification for each one. Start by crawling your checkout pages in a test environment and listing every script, including tag managers, analytics and A/B testing tools, then remove anything that cannot be justified. Your inventory will also drive the authorization and integrity controls, which are usually implemented with a content security policy, subresource integrity hashes or a script monitoring service.
Third-party scripts are where most checkout problems start, and the SSC's Payment Page Security information supplement explains how to approach them. FAQ 1592 covers third-party script providers. Assign an owner for each script, record who can change it, and confirm which changes you approve before they reach production. Ask your implementation partner or developers to show the authorization and integrity evidence for each script. An external assessor will check it, and only that assessor can confirm the validation outcome.
What moves your e-commerce scope and effort up or down
Your checkout design sets the SAQ, but several smaller decisions around it determine how much work the validation takes. The cards below cover the choices that change which questionnaire applies and what you must maintain after you pick it.
Embedded page or redirect
Whether the processor generates the payment page or your site builds it decides the questionnaire. With an iframe or URL redirect, the processor's own page collects card data, and the SAQ A route applies only if every payment page element comes directly from PCI DSS validated third parties. With Direct Post, your website builds all or part of the page, which moves you to SAQ A-EP. Confirm with your processor which model your integration actually uses, because template changes can switch it without anyone noticing.
Card data touching your servers or logs
Any path that lets primary account numbers or card verification codes reach your web servers, application logs, error reports, analytics or load balancers pulls those systems into scope. Check request logging, proxy configuration, client-side error capture and debugging tools on the checkout path. Find out whether a single misconfigured log line would put card data into systems you did not plan to validate, and test that case before you choose the SAQ.
Third-party scripts on payment pages
Every script that loads on a page that carries payment fields is a control point. For SAQ A merchants, the eligibility criterion on script attacks applies when your webpage embeds a provider's iframe or form, so the number and ownership of those scripts matters. Keep an inventory with a written justification for each script, confirm who can change it, and remove tags such as marketing pixels from checkout pages that do not need them. Requirement 6.4.3 applies to merchants outside SAQ A, and the review effort grows with each added script.
Tokenization and hosted fields
Hosted fields and tokenization move card capture to a provider's frame or service and return a token to your system. The approach can keep your servers out of the card data flow, but only if the tokens cannot be reversed inside your environment and the provider's components are the ones loaded on the page. Ask whether the fields sit inside an iframe you do not control, whether your code can read the values before they are tokenized, and whether tokens are returned to the browser or to your back end. Those answers decide whether you keep SAQ A or move to a broader questionnaire.
Checkout domains and environments
Each checkout domain, subdomain, staging site and test environment that renders a payment page is a separate item to inventory, assess and scan. Quarterly external vulnerability scans by an ASV apply to SAQ A merchant webpages that redirect or embed an iframe, so every public checkout hostname needs coverage. Confirm which hosts serve payment pages, retire unused ones, and make sure staging copies do not hold live card data or unrestricted third-party tags.
Stored card data for subscriptions
Storing cards for recurring billing or card-on-file purchases moves you out of the simplest SAQ categories because stored account data falls under the storage requirements. Once you keep a primary account number, even as a token issued by your processor, you need to confirm which party holds the data, whether your environment can retrieve it, and how retention is enforced. Most merchants can avoid this scope by asking the processor to hold stored credentials and reference them by token, so review that option before building your own vault.
Who is paid for what in an e-commerce PCI DSS validation
This table lists each cost component of an e-commerce PCI DSS validation, who gets paid for it, whether it is one-time or recurring, and what drives it up. No fee figures are given here, so use it as a checklist when you request written quotes that split these items separately.
| Cost component | Who is paid | One-time or recurring, and what drives it |
|---|---|---|
| QSA or SAQ process | Qualified Security Assessor (only for a ROC) or your internal team and acquirer (for an SAQ) | A QSA engagement is recurring each year. Drivers include the SAQ type, number of payment pages and systems in scope, and whether a ROC is required by your acquirer. |
| ASV external scanning | Approved Scanning Vendor | Recurring, typically quarterly for SAQ A merchants with redirect or iframe pages (PCI SSC FAQ 1604). Drivers include the number of public IP addresses and webpages scanned. |
| Checkout hardening and script inventory | Implementation partner or internal engineers | Mostly one-time for the initial script inventory, justifications and integrity controls, then recurring upkeep. Drivers include the number of third-party scripts and how often checkout changes. |
| Internal engineering time | Your own staff (paid through payroll, not invoiced) | Recurring. Covers page changes, patching, log review, access reviews and evidence collection. Drivers include team size, change frequency and how much evidence is kept manually. |
| Payment provider fees | Payment service provider or processor | Recurring transaction and platform fees, separate from validation. Ask whether the provider supplies a current Attestation of Compliance for its hosted page or form. |
| Penetration testing | Independent penetration testing firm | Recurring, usually annually or after significant changes. Drivers include the application and infrastructure scope and whether testing covers the checkout page. |
| Dedicated script or payment page monitoring | Monitoring tool vendor or implementation partner | Recurring subscription or service. Needed where scripts run on pages outside SAQ A, since Requirements 6.4.3 and 11.6.1 applied from 31 March 2025 (PCI SSC FAQ 1593). |
How an e-commerce PCI DSS validation runs from scope to attestation
This sequence turns a checkout design into a documented scope decision, the controls and evidence that support it, and a signed Attestation of Compliance that the acquirer or card brand can accept. Each step closes with a artifact you can hand to the next step or to your assessor.
Confirm the checkout model and SAQ eligibility
Document how the payment page reaches the customer: a redirect to the provider's hosted page, a payment iframe embedded in your site, a direct post in which your site builds part of the form, or card fields that collect data on your own site. Your team owns this decision, and your acquirer or the card brand determines which SAQ type applies to that model. The output is a one-page checkout data-flow diagram plus a written SAQ eligibility note that names the SAQ type and the reason for it. Confirm the eligibility criteria against the current SAQ instructions before you proceed.
Confirm the processor's PCI DSS validation status
For redirect and iframe models, every payment page element must come only and directly from PCI DSS validated third-party service providers under SAQ A. Obtain the current Attestation of Compliance from each payment provider and record its validation date and the services it covers. Ask the provider which parts of the payment page it serves, so the diagram matches what the customer sees. The output is a vendor evidence file with one current attestation per provider. Ask your assessor how often they expect these to be refreshed.
Build the script inventory and authorization method
If your site embeds a payment page or form, or if you use direct post or JavaScript forms, list every script that loads on the payment page, including third-party tags, analytics and tag managers. For each script, record its owner, its business justification, the method that authorizes it to run, and the method that checks its integrity. Scripts that the SAQ A eligibility criterion covers need this work when they affect the payment page. The output is a script inventory with a justification for each entry and a signed change-control procedure that governs additions. Confirm with your assessor which controls apply to your SAQ type.
Configure quarterly ASV scans where SAQ A applies
Under SAQ A, merchant webpages that redirect to a payment provider or embed its iframe need quarterly external vulnerability scans by an Approved Scanning Vendor. Engage an ASV, scope the scan to your public-facing checkout and related hosts, and run the first scan before you sign the attestation. Remediate any findings that the ASV reports as failing, then rescan until the report shows a passing result. The output is a set of passing ASV scan reports with dates, which you retain as evidence. Confirm the scanning calendar and scope with your acquirer and ASV, because the timing depends on your assessment cycle.
Complete the SAQ or ROC
Work through the applicable SAQ on the official PCI SSC template, or, if the acquirer requires it, have a Qualified Security Assessor produce a Report on Compliance. Map each question to the evidence you hold, such as policies, configuration records, scan reports, and vendor attestations. Where a control is met by a different method, document the approach and the rationale in the response. Your team owns the answers, and the assessor or reviewer checks them. The output is a completed questionnaire with an evidence reference for each response.
Sign the Attestation of Compliance
An authorized officer of your organization signs the Attestation of Compliance that matches the SAQ or ROC, after confirming that every answer is accurate and that the scope described in the attestation matches the checkout diagram. For a ROC, the QSA also signs the attestation. Keep the signed attestation with the evidence file so you can produce both on request. The output is a signed AOC that matches the scope and the answers. A certificate or badge does not replace this document, because PCI SSC does not recognize certificates as validation.
Hand off to the acquirer or card brand
Submit the signed Attestation of Compliance and any ASV scan reports to your acquirer, following its submission process and deadlines. The payment brands, not PCI SSC, decide which entities must validate and how they enforce it, so confirm the required submission format, the review timeline, and any additional questions with your acquirer. Store the submitted package with its date and the version of the SAQ used. The output is written acknowledgment from the acquirer that the attestation has been received and accepted. Ask for that confirmation in writing before you treat the validation as complete.
Choosing between redirect, iframe, direct post and self-hosted card fields
This table compares four ways to collect card data at checkout by the SAQ they usually fall under, the script and scan duties they add, who controls the payment page, and when each fits. Read it as a starting point: the option you pick sets your scope, but none of them removes every PCI DSS obligation.
| Checkout option | Likely SAQ | Script and scan duties | Who controls the payment page | When it fits |
|---|---|---|---|---|
| Full redirect to the provider's hosted page | SAQ A | Eligibility confirmed for your own site. Quarterly ASV scans of your redirecting webpages under Requirements 11.3.2 and 11.3.2.1 still apply. | Provider generates the payment page. You control only the pages that send the customer there. | Merchants who want the smallest scope and can accept a visible hand-off to the provider. |
| Iframe embedded in your checkout | SAQ A | Script-attack eligibility criterion applies. Script controls for your page, including Requirement 6.4.3 and 11.6.1, must be confirmed as eligibility criteria. ASV scans apply. | Provider generates the payment fields. You control the page that hosts the frame, so its scripts count. | Merchants who want the payment fields inside their own page design and can keep the host page's scripts tightly controlled. |
| Direct post from your site | SAQ A-EP | Your site builds all or part of the payment page, so Requirements 6.4.3 and 11.6.1 apply to your scripts. Validation is larger than SAQ A. | You build part or all of the payment page and control its scripts, while the provider receives the data. | Merchants who need custom page logic and accept a broader set of requirements for the page they build. |
| Self-hosted card fields on your own site | SAQ D for Merchants | Full set of script controls, inventory and justification for every payment page script, plus other applicable requirements. Scope depends on whether card data touches your systems. | You control the page, the fields and the handling of card data within your environment. | Merchants with in-house development capacity who accept cardholder data on their own website and can run a full SAQ D assessment. |
What must be in place before the assessor or acquirer signs off
An e-commerce validation holds up only when the SAQ choice, script controls, processor evidence, scan results, change control and data-flow picture all describe the same checkout. Each card below names one item the assessor or acquirer will ask for and how to check it before submission.
Confirmed SAQ eligibility record
A dated written record that states which SAQ the checkout qualifies for and why, such as SAQ A for a redirect or iframe page or SAQ A-EP for direct post. For SAQ A, it must also record the merchant's confirmation that its site is not susceptible to script attacks that could affect its e-commerce systems. Check that the record names the actual checkout method in use today, since a later change to the payment page can invalidate the eligibility.
Current script inventory with justifications
A complete list of every script loaded on payment pages, with a written reason for each and a method to confirm that each script is authorized and has not changed. This applies to SAQ D merchants and to any SAQ A merchant whose eligibility depends on the script criteria. Check the inventory against the live page, including scripts loaded by tag managers and third-party widgets, not only the scripts in the source code.
Processor PCI DSS validation evidence
The current Attestation of Compliance from each third-party service provider that builds or hosts any part of the payment page, such as the processor or hosted field provider. Your SAQ depends on those providers being PCI DSS validated, so the AOC must cover the service that actually runs your checkout. Check the AOC date, the scope it describes, and whether it lists the payment page service you use, and keep a record of when each one was last reviewed.
ASV scan reports from an approved vendor
Quarterly external vulnerability scan reports performed by an Approved Scanning Vendor for the merchant webpages that redirect to a payment provider or embed its iframe. Scans must be run against the public-facing hosts that serve the checkout, and passing scans must be documented with no open failures. Check that the scanning vendor appears on the PCI SSC list of ASVs, that each scan covers the current domains, and that any rescans after failures are on file.
Payment page change control
A documented process for every change to the checkout, including code releases, tag manager edits, script updates and changes made by a hosted payment provider. The record should show who approved each change, what was tested, and how unauthorized changes are detected and reverted. Check a sample of recent releases against the change log, and confirm that tag manager edits go through the same approval path as application code.
Data-flow diagram of card data
A diagram that traces where card data enters the browser, which systems and third parties receive it, and where it never goes, including logs, analytics and error reporting. It should match the SAQ eligibility record and show whether your servers ever receive card data. Check it by following a test transaction through the browser developer tools and your server logs, then comparing what you find with the diagram.
Who owns each part of an e-commerce PCI DSS program
Your organization owns its PCI DSS compliance, its payment pages and the decision about which checkout design to use. Responsibility for the controls does not move to a provider or partner because the work was outsourced. Your engineering and compliance staff decide the checkout method, approve script changes, keep the inventory of what runs on payment pages, and answer assessor questions about how the controls operate day to day.
- Checkout decision: choose redirect, iframe, direct post or on-site card entry, and record why, since that choice sets the SAQ.
- Script governance: approve each script on payment pages, justify it in writing and keep the inventory current for the requirements that apply to your SAQ.
- Change control: run and document releases, reviews and rollback for the website and any tag manager.
- Policies and roles: maintain the security policy, named owners and training records.
- Attestation: sign the Attestation of Compliance and confirm the scope statement is accurate.
Before engaging anyone, confirm internally who signs off on the SAQ type and who receives vulnerability scan results.
The payment provider or processor runs the systems that receive and process card data on its side. Under a redirect or iframe design, the provider generates the payment page elements that collect card data, which is why SAQ A depends on those elements coming only and directly from a PCI DSS validated third party. The provider's own PCI DSS validation covers its infrastructure, but it does not cover your website, your scripts or your scans.
- Page generation: the provider hosts the card entry fields in a redirect or iframe, so card data does not touch your servers.
- Validation evidence: request the provider's current Attestation of Compliance and the responsibility matrix that shows which controls it covers.
- Integration documentation: ask which scripts or parameters you must load and which are fixed by the provider.
- Third-party scripts: confirm whether the provider requires any additional scripts on your page, since those scripts fall into your scope.
- Change notices: agree how the provider notifies you of page changes that could affect your SAQ eligibility.
Check that the provider's validation covers the exact payment method and integration you use, not only its general service.
An implementation partner such as DeployOpen can prepare systems, scripts, configurations and evidence for your team and assessor. Work is typically scoped in writing before it starts, and the deliverables are documents, configurations and technical changes that your organization then owns. A partner does not issue the Attestation of Compliance, the Report on Compliance or any scan validation. Those outputs come only from the QSA or ASV, and a partner that prepares evidence for an assessment must stay separate from the assessment itself.
- Script hardening: review and reduce third-party scripts on payment pages, and document authorization and integrity checks.
- Scan setup: prepare the external scan targets, configuration and remediation tracking for the ASV.
- Evidence packs: assemble configuration records, logs, change tickets and inventories in the format your assessor requests.
- Testing support: arrange application and external testing as part of the program, with findings owned by your team.
- Ongoing support: run recurring tasks such as script reviews and scan follow-up under a retainer, if you choose that model.
Ask the partner to state in writing which deliverables it produces and confirm that it will not act as your QSA or ASV.
A Qualified Security Assessor (QSA) performs the on-site or remote assessment and writes the Report on Compliance where one is required. An Approved Scanning Vendor (ASV) runs the external vulnerability scans that SAQ A requires for merchant webpages that redirect to a provider or embed its iframe. These independent parties decide whether a control is in place, and they are the only parties whose output counts as validation for the payment brands.
- Scope confirmation: the QSA or your validation process tests whether the payment page design matches the SAQ you selected.
- Control testing: the assessor examines configuration, samples evidence and interviews staff.
- Scan output: the ASV issues the passing or failing scan reports that your quarterly scans depend on.
- Independence: the assessor cannot design the controls it is testing for the same engagement in a way that removes its independence.
- Attestation: the QSA or the validation process produces the documents you submit to your acquirer.
Confirm early which assessor your acquirer accepts, what it will need from you and whether the assessment is an SAQ review or a full ROC.
Common questions about PCI DSS for e-commerce checkouts
Can an iframe checkout still need SAQ A-EP?
Usually not. An iframe or URL redirect checkout generally points to SAQ A, because the payment page elements come only and directly from PCI DSS validated third parties. SAQ A-EP applies when your own website builds all or part of the payment page and sends the data to the processor, as with direct post and many JavaScript forms. Your checkout code is the deciding factor, so ask your QSA or acquirer to confirm the SAQ against how the page is actually built. If your team edits the embedded form, adds scripts around it, or changes how card fields load, the eligibility answer may change. Confirm the final choice in writing before you complete the questionnaire.
Does a redirect checkout still need ASV scans?
Yes, in many cases. Under SAQ A for v4.x, merchant webpages that redirect to a payment provider or embed its iframe must have quarterly external vulnerability scans performed by an Approved Scanning Vendor (ASV), covered by Requirements 11.3.2 and 11.3.2.1. Redirect-only sites that fully outsource the payment page have a narrower script-related obligation, so the scan question still depends on how your pages are built. Ask your acquirer whether they require ASV scans for your channel, and ask your ASV to confirm that the scan scope covers the public-facing hosts that serve your checkout.
What does a payment page script inventory require?
It requires three things for each script on the payment page. You need a method to confirm that each script is authorized, a method to assure that each script has not been altered, and an inventory of every script with a written justification for why it is there. This applies to merchants on SAQ D and other entities outside SAQ A, where Requirement 6.4.3 has been mandatory since 31 March 2025. The inventory must be kept current, so tag managers, analytics tags and chat widgets count. Reviewing the inventory on each release is what keeps it accurate. The PCI SSC's guidance on payment page security explains how assessors look at this area.
Can we complete e-commerce PCI DSS ourselves?
A merchant can complete a self-assessment internally, provided its staff understand the SAQ, the payment flow and the controls it relies on. Many teams handle the questionnaire, the policies and the evidence in-house and bring in outside help for specific gaps, such as script controls, server hardening or a technical review of the checkout. A Report on Compliance must be completed by a Qualified Security Assessor, and only the assessor issues that report. Your acquirer decides which validation you must complete, so confirm the requirement with them before you decide how much work to keep in-house.
What does e-commerce PCI DSS cost and how long does it take?
The PCI SSC does not publish fees, and no supplied figure sets a price or duration for this work, so get written quotes rather than relying on estimates. Costs fall into a few groups: your internal staff time, the checkout and script changes, the ASV scan fees, and any assessor fees if a QSA report or independent review is required. One-time work includes the initial scope and script inventory, while scans and reviews recur. Costs rise with the number of third-party scripts, custom checkout code and the SAQ type. Ask each provider to itemize scope, deliverables, timeline and what is recurring.
What should we ask a QSA or consultant before signing?
Ask first how they will confirm your SAQ eligibility and whether they can issue the Attestation of Compliance or Report on Compliance for your validation level. Ask whether the same firm will prepare your systems and also assess them, because consulting and assessment work should stay independent. Request a written scope that names the checkout pages, third-party scripts, hosts and scan targets, and ask who will perform each task. Confirm the deliverables, the timeline, the evidence you must supply and the recurring work after the first year. Ask about the assessor's PCI SSC qualification and references you can verify.
Does a self-hosted open-source checkout change the SAQ?
Hosting the checkout yourself does not automatically change the SAQ. What matters is who builds the payment page and who receives the card data. If you run an open-source checkout and collect card fields on your own page, you may fall under SAQ A-EP or SAQ D, even if the software is free. If you use a validated hosted payment page from a processor inside an iframe or redirect, the SAQ A criteria apply. DeployOpen can plan, implement, harden and document a self-hosted platform in your own infrastructure and prepare evidence for your assessor, but it does not issue reports or attestations. Your assessor decides the final SAQ or ROC.
What usually delays e-commerce PCI DSS projects
Most delays in e-commerce PCI DSS work come from decisions made late or assumptions left unchecked. The cards below cover the checkout model, the scripts running on payment pages, the processor's evidence, scan readiness and the duties that remain after a redirect.
Changing the checkout model late
Moving from a redirect to an iframe, or from an iframe to direct post, changes the SAQ, the script duties and the evidence set. Decide the checkout model before the build starts, and write it into the scope document. If the team must switch later, re-confirm the SAQ eligibility and the list of payment page elements before the next validation cycle. Ask the processor which integration patterns it supports for your site.
Unmanaged marketing and analytics tags
Advertising pixels, chat widgets and analytics tags often load on checkout pages without a formal review. Each script on a payment page needs an authorization method, an integrity check and a written justification. Build a complete script inventory from the live page, not from the development repository, and tie each tag to an owner. Remove any tag that no one can justify.
Missing processor AOCs
Your SAQ depends on every third party in the payment flow being PCI DSS validated, so the processor's current Attestation of Compliance is a required document. Obtain it before scoping, check its date and the services it covers, and file it with your evidence. Confirm whether your hosting provider, tag manager and payment page host are covered by their own validations. Gaps here stall the assessment late in the cycle.
Unplanned ASV scan failures
Merchants whose webpages redirect to a provider or embed its iframe must run quarterly external vulnerability scans by an Approved Scanning Vendor. A scan can fail on an outdated component, a misconfigured server or an open service that nobody expected. Schedule a pre-scan run with your own tools, fix findings, and leave time for a rescan before the validation deadline. Confirm the scan frequency and scope with your ASV and acquirer.
Assuming a redirect removes all script duties
A redirect to a provider's hosted page removes many page-level script obligations, but it does not remove every duty. Your own site still has pages, links and any scripts that load before the customer leaves. Review the pages that lead to the redirect and confirm that none of them handle card data or embed provider code. Document that reasoning in your scope file so the assessor can follow it.
How do we scope a checkout before we commit to an SAQ?
A written scope fixes three things before anyone chooses a self-assessment questionnaire: the checkout model, the sources of every payment page element, and the systems that touch card data. Start by mapping each path a card can take, from the product page through the payment page to the processor's response. For each element on the payment page, record whether it is generated by the processor, served from your own server, or loaded from a third-party script. That single inventory decides whether the payment page sources come only and directly from PCI DSS validated providers, which is the condition that keeps a redirect or iframe checkout on SAQ A, or whether your own code touches the data and points you toward SAQ A-EP or SAQ D.
The scope document should also name the systems that sit beside the checkout: web servers, content management plugins, tag managers, analytics and chat widgets, logging pipelines, and the staff accounts that can change page code. Record who owns each one and how changes are approved. An engagement scoped in writing usually produces an evidence pack that includes the scope statement and data-flow diagram, a script inventory with the business reason for each script, the list of payment page elements and their sources, the external scan results and their remediation records, and the change and access records for the checkout servers. Confirm with your provider exactly which of these items are included, who signs off the scope, and what happens if the processor changes its page model later.
DeployOpen plans, implements, hardens and documents the systems and evidence described above, but it does not issue Reports on Compliance, Attestations of Compliance or certificates, and it does not guarantee a validation outcome. Those decisions belong to your acquirer or payment brand, and the questionnaire itself must be completed and attested by you or an independent assessor. Ask any provider to confirm in writing which deliverables are theirs, which belong to your team, and which require a qualified assessor, before you commit to a checkout design on the strength of a planned SAQ.
