PCI Compliance for Web Developers: Who's Liable for Client Checkouts
PCI compliance for web developers explained: where agency responsibility ends, how build choices shift scope, and contract terms that limit liability.
Photo: Pixabay
On this page 7 sections
- PCI Compliance for Web Developers: Does It Apply If You Don't Take Payments?
- How Build Choices Change Your Client's SAQ
- Hosting Client Sites: When You Become a Service Provider
- Script Management and Security Controls for Payment Pages
- Contract Clauses That Limit Developer Liability for a Card Data Breach
- A Pre-Launch PCI Checklist for Client Checkouts
- Next Steps for Your Agency
Key takeaways
- Your client is the merchant and owns PCI validation, but your build, hosting and maintenance work can pull you into scope.
- How the payment form loads, whether by redirect, embedded fields or direct post, largely decides how much compliance work the client faces.
- Hosting or administering a site with a checkout can put your agency in the client's chain of security responsibility.
- Written scope, a responsibility matrix, liability caps, indemnity terms and insurance are your main protections if a client checkout is breached.
Most agencies never see a card number, so many assume PCI is the client's problem. That is only partly true. PCI compliance for web developers depends on what you build, where it runs and who can change the checkout page after launch. This guide covers where your responsibility starts and ends, how your technical choices affect the client's compliance work, when hosting puts you in the client's chain of responsibility, and which contract terms limit your exposure if a client's checkout is compromised.
This article is general information, not legal advice. PCI DSS requirements, self-assessment questionnaires and eligibility criteria are revised over time. Before you rely on anything here, confirm current requirements with the PCI Security Standards Council, your client's acquirer or processor, and a qualified attorney.
PCI Compliance for Web Developers: Does It Apply If You Don't Take Payments?
PCI DSS is the industry security standard backed by the major card brands for protecting cardholder data. It is mainly aimed at businesses that handle card data. Its reach can also extend to anyone whose systems or access could affect how that data is protected.
That second point is what catches agencies. You may never touch a card number. If you can edit the page where shoppers type one, though, your work can still affect the security of that data.
Roles usually break down like this:
- The client is the merchant. The client signed the merchant agreement, validates compliance with its acquirer and takes the first hit after a breach. That can mean fees or assessments passed down by the acquirer, forensic investigation costs and possibly losing the ability to accept cards.
- The agency is a contractor or vendor. You have no direct contract with the card brands. If your work contributed to a breach, the client may still try to recover its losses from you under your contract or through a negligence claim.
In practice, PCI shapes your work even when it doesn't apply to your business directly. Your actual exposure depends on your contracts and on what you control.
A related trap: some agencies run client sales through the agency's own merchant account to make a launch easier. That creates separate underwriting and card network problems, which we cover in whose merchant account a client's checkout should use.
How Build Choices Change Your Client's SAQ
Many small and mid-size merchants validate compliance with a self-assessment questionnaire (SAQ). The questionnaire a client qualifies for, and how much work it involves, depends largely on how card data moves through the site you built. For website builders, the integration method is the decision that matters most under PCI DSS.
The table compares common approaches in relative terms. It does not assign specific questionnaires. Only the client's acquirer or processor can confirm which one applies.
| Build Approach | Who Handles Card Data | Relative Scope for the Client |
|---|---|---|
| Full redirect to a processor-hosted payment page | Processor only | Lowest |
| Embedded hosted fields or iframe served by the processor | Processor, but your page delivers the frame | Low, though the page around the frame still matters |
| Direct post or a custom JavaScript form on your page that sends data to the processor | Your page controls the form | Moderate to high |
| Card data passes through or is stored on the client's server | Client's systems | Highest |
Some practical points:
- Don't promise a specific questionnaire. Eligibility criteria change, and the acquirer makes the final call. Get its confirmation for your exact integration before you tell the client how light its compliance work will be.
- Fewer custom pieces usually means less scope. Hosted payment pages and processor-hosted fields keep card data off infrastructure you and the client manage.
- 3-D Secure reduces fraud, not scope. 3D Secure authentication helps with card-not-present fraud and chargebacks. Don't assume it reduces the client's compliance scope.
When you evaluate a gateway, ask the provider which integration methods it supports and how each one affects the merchant's PCI scope. MannyPay works with gateways and integrations including Authorize.Net and NMI. You can compare options on the payment gateways page.
PCI Compliance for WordPress Developers
WordPress and WooCommerce builds have their own risks. The payment plugin may be well built. The problem is usually everything else that loads on the same site:
- Too many plugins and themes. Any plugin with admin-level code can inject scripts on the checkout page if it is compromised.
- Shared admin accounts. When several people use one "agency" login, you can't trace who changed what.
- Form plugins used as payment forms. Clients sometimes ask for a "quick form" that sends card numbers by email or saves them to the database. Refuse. It puts raw card data on systems you manage and pushes the client into the heaviest compliance scope.
- Gateway plugin mode. Many gateway plugins offer more than one mode, such as hosted fields or a direct integration. The mode you pick changes the client's scope.
For the store owner's side of these decisions, see our WooCommerce payment gateway checklist and the WooCommerce integration page.
Hosting Client Sites: When You Become a Service Provider
Your role changes once you host or administer the site. In general terms, a service provider in the PCI context is a third party that handles card data for another business or can affect its security. An agency that hosts a client's checkout site, manages its server or holds admin credentials may be treated as one. Check the PCI SSC's current definitions and your client's acquirer for how your role is classified.
Here is what that typically means:
- The client will need to account for you. Merchants are generally expected to know which vendors can affect their card data security, what each vendor is responsible for, and whether those vendors keep up their security practices. Clients or their acquirers may ask you for a written statement of responsibilities or evidence of your security practices.
- You may be asked to validate. Depending on your role and the client's acquirer, you may be asked for formal evidence of your own compliance. Requirements vary, so ask what is expected.
- Reselling hosting doesn't remove your role. If you resell a managed host's servers, the host covers its infrastructure. Your configuration, plugins and access controls are still your responsibility.
Illustrative scenario: An agency builds a WooCommerce store with embedded hosted fields, hosts it on a server the agency manages and runs monthly plugin updates under a maintenance plan. An abandoned plugin is compromised, and an attacker adds a skimming script to the checkout page. The processor's fields are never breached, but the script captures card data as shoppers type. Who pays depends on the contract. Did the maintenance plan include security monitoring? Who approved the plugin? Was there a liability cap?
If you sell retainers like this, define security duties as clearly as the billing terms in your website maintenance plan billing setup.
Script Management and Security Controls for Payment Pages
E-commerce skimming attacks inject malicious JavaScript into the page that hosts or loads the payment form. They go after the code agencies manage: tag managers, analytics snippets, chat widgets and plugin assets.
PCI DSS guidance on payment pages has evolved. Check the PCI Security Standards Council's current documents and your client's acquirer for what the standard requires for your client's integration. Whatever the exact wording, the following controls are sound security practice for any checkout you build or maintain:
- Strip the checkout page. Remove marketing pixels, heatmaps and chat widgets from payment pages unless the client documents a business need for them.
- Keep a script inventory. List every script that runs on payment pages, who owns it and why it is needed.
- Use a Content Security Policy to limit which domains can serve scripts on checkout pages.
- Use Subresource Integrity for third-party scripts where the vendor supports it, so tampered files fail to load.
- Set up change detection. A monitoring service or file integrity tool should alert on changes to checkout templates, scripts and security-related HTTP headers.
- Send alerts to a person. An alert that lands in an unmonitored inbox protects no one. Name the person who responds, and include that name in the contract.
Contract Clauses That Limit Developer Liability for a Card Data Breach
Your contracts are your main protection against developer liability for a card data breach. Have an attorney draft or review these terms. The clauses below are common starting points, not a substitute for legal advice.
| Clause | What It Does |
|---|---|
| Scope of work | States exactly what you build, host and maintain, and what you don't |
| Security responsibility matrix | Assigns each security duty to a party: updates, monitoring, access, incident response |
| Merchant acknowledgment | Confirms the client is the merchant of record and responsible for its own PCI validation |
| Limitation of liability | Caps your exposure, often tied to fees paid, and may exclude certain indirect damages |
| Indemnification | Sets who covers which losses, including those from client-installed plugins and client-requested scripts |
| Client change controls | Shifts responsibility when the client or another vendor changes code or adds plugins |
| Insurance | Commits you to carry appropriate coverage, such as cyber or professional liability, and may require the client to carry its own |
| Incident cooperation | Sets notification timelines and your role in any forensic investigation |
| Termination and handover | Defines how credentials transfer and when your access and responsibility end |
Some drafting notes:
- Liability caps aren't absolute. Whether a cap holds can depend on state law and the facts, for example when gross negligence is alleged. Ask your attorney what is likely enforceable where you operate.
- Put declined advice in writing. If a client insists on a risky integration, document your recommendation and the client's decision.
- End your access cleanly. A defined end to your access protects you after offboarding, including when a relationship ends over unpaid invoices. That situation is covered in whether you can take down a non-paying client's website.
A Pre-Launch PCI Checklist for Client Checkouts
Before any client checkout goes live, confirm that:
- The client has its own merchant account and is the merchant of record
- The integration method is chosen, and the client's acquirer or processor has confirmed the applicable questionnaire
- No card data is collected through forms, email, chat or logs
- Unnecessary third-party scripts are removed from the checkout page
- A script inventory is documented, with a reason for each script
- A Content Security Policy and integrity checks are in place
- Change detection is configured, with alerts going to a named person
- Each admin has an individual account with multi-factor authentication, and shared logins are removed
- Core, theme and plugin updates are current, and abandoned plugins are removed
- TLS is configured correctly across the whole site, not only the checkout
- The client has signed the responsibility matrix
- Both parties have reviewed their insurance coverage
- The client has a shared incident contact list
Next Steps for Your Agency
Your web agency PCI responsibility comes down to three questions: what you control, what you agreed to in writing, and whether your build kept card data off systems you manage. Choose integrations that minimize scope, control the scripts on payment pages, and put every security duty in a signed contract.
If you're scoping a client checkout and want to compare gateway and integration options, see how MannyPay supports web design agencies and their clients, or request a free quote. A MannyPay specialist responds to quote requests within one business day.
This article is for general educational purposes and is not legal, tax or financial advice. Card network rules and state laws change; confirm current requirements for your business.
