Your online checkout may look like a simple card form. Behind that form, several organizations and pieces of software may be involved: your store, the payment provider, an extension, an analytics tag, and the person who maintains the website.

With March 31, 2025 approaching, an owner needs a clear account of those responsibilities. The useful question is not whether someone has installed a security product. It is which validation route applies to your business, what your website actually does, and what evidence supports the answers you will provide.

This is a planning guide, not a compliance determination. Your payment arrangement and the requirements set by the organization enforcing compliance need individual review. Start that conversation before the deadline rather than treating the questionnaire as an administrative task for the final afternoon.

Understand which version and deadline you are discussing

The familiar phrase “PCI DSS v4.0 deadline” can hide an important distinction. PCI Security Standards Council published version 4.0.1 as a limited revision and stated that version 4.0 would retire on December 31, 2024.

Its announcement of PCI DSS v4.0.1 says the revision added or deleted no requirements and did not change the March 31, 2025 effective date for the new requirements. As you prepare in February, make sure your discussion uses the applicable documents rather than an old checklist bearing a familiar version number.

Ask your payment contact to identify the validation documentation and version they expect from your business. Keep that answer with the person responsible for the submission. A developer can explain the website architecture, but should not simply choose your validation route without the appropriate compliance discussion.

Do not infer your obligations from another merchant’s setup. Two stores can look alike to a shopper while using different payment integrations, different administrative processes, and different arrangements with their payment partners.

Read the January SAQ A announcement carefully

On January 30, 2025, PCI SSC announced changes for merchants validating with Self-Assessment Questionnaire A. Its official announcement explains both the reporting changes and their limits.

The revised SAQ A removes requirements 6.4.3 and 11.6.1 for payment-page security, along with requirement 12.3.1 for a targeted risk analysis supporting 11.6.1. It adds an eligibility criterion requiring merchants to confirm that their site is not susceptible to attacks from scripts that could affect their ecommerce systems.

The announcement says the January version is available for review but does not take effect until March 31, 2025. It also says the changes do not remove or diminish the underlying PCI DSS requirements. Removing questionnaire entries is not the same as declaring the website outside the security conversation.

PCI SSC states that compliance validation requirements are set by compliance enforcing entities, such as brands, acquirers, and payment facilitators. It directs organizations to consult their own enforcing entity about validation requirements and eligible tools. That is the conversation to have when someone tells you the change means you can ignore scripts.

Keep the conclusion narrower than the headline

You should not conclude from this article that your business qualifies for SAQ A or that a particular technical control satisfies its eligibility criteria. Ask for a written explanation tied to your payment arrangement. Record who supplied it and which documents they used.

Map the payment journey your customers actually use

Ask your developer and payment provider to describe the journey from the cart to payment confirmation. Identify which pages your business serves, where payment details are entered, and which systems process the resulting order information.

Use a diagram that an owner can understand. It should show the main systems and responsibility boundaries, not every technical component. Keep uncertain areas marked as questions until someone with the relevant knowledge answers them.

Review each payment route you offer. The main card flow, a saved payment method, a wallet, a subscription renewal, or a special invoice payment may follow different paths. These are examples to investigate, not assumptions that every store has all of them.

Include the people who change the website. A payment integration can be understood at launch and then modified by a later marketing, design, or extension update. Ask how those changes are reviewed and how your documentation stays aligned with the live implementation.

For ecommerce development work, this map gives your developer a practical starting point. It also helps you identify which questions belong with the provider or compliance contact instead of being answered by guesswork.

A person holds a blank white card beside an open laptop on a kitchen table.

Make a script inventory useful to the owner

Ask for an inventory of the scripts loaded through the relevant customer journey. For each item, record its purpose, source, business owner, and the person authorized to approve changes. Include a note explaining what would stop working if the script were removed.

Do not limit the review to items someone remembers adding manually. Ask the developer to inspect what the pages actually load and how extensions, embedded services, and tag-management arrangements contribute to that result. Reconcile the observed behavior with the written inventory.

Classify uncertainties rather than silently approving them. If nobody can explain why a script is present, assign someone to investigate. If it supports an important function, identify the person who can confirm that function and approve any proposed change.

An inventory is a management tool, not proof by itself that the site meets a requirement. Its value is making responsibilities and dependencies visible enough to review. Keep the compliance interpretation with the people responsible for making that determination.

Separate necessary functions from convenient extras

Review additions that are useful elsewhere on the site but may not be needed during payment. Ask whether each proposed feature belongs in that journey and how it will be tested. Remove nothing casually: a script with an unclear name may still support a necessary function.

Discuss protective controls without buying a magic answer

One technical topic your developer may raise is Content Security Policy, or CSP. MDN’s explanation of CSP describes instructions from a website to the browser that restrict what site code can do, including which resources a document may load.

That makes CSP relevant to a conversation about script behavior, but it does not make a policy header a compliance certificate. Ask the developer to explain the intended protection, its limitations, and the evidence they will use to check that it behaves as planned.

MDN also describes CSP as complementary protection against cross-site scripting rather than an alternative to sanitizing input. Avoid treating one mechanism as permission to neglect the rest of the application. Ask how controls fit together in the actual implementation.

A policy copied from a tutorial may interfere with legitimate functions or allow more than intended. Request an implementation and testing plan suited to your store. The owner should understand the operational tradeoffs without needing to write the browser policy personally.

Test payments and the surrounding business process

Define a test plan with the developer and provider using appropriate test facilities and fictional information. Include successful payments, unsuccessful attempts, customer corrections, and the confirmation that reaches both the customer and your staff.

Also review the routes used less often. If the store supports a payment option or customer situation, ask how the team will test it. Record which cases were completed, what remains untested, and who accepts any limits before deployment.

Do not judge the work solely by whether the button still responds. Confirm that the intended order is created, the correct customer message appears, and the team can follow the normal operational process. Match the checks to the journey you mapped earlier.

For a WooCommerce implementation, include the actual extension combination and configuration in that review. A statement about the platform in general is not a substitute for understanding the store your business operates.

A man points at code on a desktop monitor while using a mouse at a standing desk.

Assign the work across the right people

Name an internal owner for the preparation process. This person should track questions, decisions, evidence, and due dates, even if the technical work is performed outside your business. A task assigned vaguely to “the website people” is difficult to follow up.

Ask the payment provider what documentation describes its responsibilities and the integration you use. Ask the developer to describe the website’s configuration and ongoing change process. Ask your compliance contact how those facts affect the validation route and evidence expected from your business.

Keep unresolved questions separate from completed tasks. A provider response, a developer’s technical explanation, and an owner’s approval are different records. Store them together without pretending one automatically answers the others.

If advice conflicts, bring the specific disagreement back to the responsible parties. Quote the exact question and the relevant document version. Avoid resolving the conflict by selecting whichever answer requires the least work.

Build an evidence packet, not a collection of assurances

Ask what a reviewer would need to understand the decision without repeating every meeting. A useful packet can include the dated system diagram, the script inventory, provider correspondence, the agreed validation route, and records of the tests performed. Have your compliance contact identify what is actually required rather than assuming this suggested packet is sufficient.

Label records with the configuration and date they describe. If the integration changes afterward, an older test result may no longer answer the current question. Keep superseded records clearly marked so nobody mistakes a previous arrangement for the live one.

Record exceptions and ownership. A test that could not be completed, a question awaiting provider clarification, or a temporary workaround should remain visible with a person responsible for following it up. An unresolved item is not improved by moving it out of the summary before an approval meeting.

Decide how urgent changes will be handled

A checkout problem can demand a quick response. Agree in advance who can authorize an emergency change, how it will be tested, and how the final configuration will be documented afterward. The approval route should be usable when the normal project contact is unavailable.

Make sure support staff know whom to notify if the checkout behaves unexpectedly. Give them a safe way to describe the problem without collecting payment details in an ordinary support message. The goal is a clear escalation with context, not an improvised investigation that introduces another information-handling problem.

Prepare a plan you can maintain after March

Review your ecommerce operating strategy alongside this preparation. Decide how payment-related changes will be requested, reviewed, tested, approved, and documented after the immediate deadline has passed.

Keep a short checklist for new extensions, scripts, payment options, and changes made by outside teams. Specify who must be consulted before a change reaches customers. Revisit the system map and inventory when an approved change alters the journey.

The practical next step is a focused meeting with your developer, payment provider, and compliance contact. Bring the current integration details and the January announcement. Leave with named responsibilities, unresolved questions, and evidence to obtain, rather than a reassuring claim that someone else has handled everything.