What PSPs Aren’t Telling Merchants About Client-Side Risk

Payment service providers play a critical role in modern commerce. They help merchants accept payments, reduce infrastructure complexity, and shift sensitive parts of payment processing to specialized providers. For many merchants, that relationship creates a comforting assumption: “Our PSP handles payment security.” That assumption is only partly true.

A PSP may secure the payment form, hosted checkout, iframe, tokenization process, or transaction processing environment. But that does not automatically secure everything happening in the customer’s browser before payment data is submitted. 

It does not automatically control every script running on the merchant’s site. It does not automatically protect the broader payment flow from eSkimming, formjacking, fake overlays, malicious redirects, or compromised third-party JavaScript. That is the client-side risk gap. And it is the part of shared responsibility that too often gets under-explained.

The Uncomfortable Truth: PSP Coverage Has Limits

Most PSPs are very clear about what they process. They are often less clear about what they do not control. A merchant’s checkout experience is rarely just a payment form. It can include a product page, cart, shipping page, login page, account creation flow, promotional code field, tag manager, analytics tools, chat widgets, advertising pixels, personalization scripts, consent tools, fraud tools, and one or more embedded payment components.

Many of those scripts run in the customer’s browser. Many come from third parties. Some call fourth parties or other downstream dependencies. Some can read page content, interact with forms, change what users see, or transmit data.

A PSP cannot protect what it cannot see or govern. If malicious JavaScript modifies the payment flow before the customer reaches the PSP-controlled step, overlays a fake payment form, captures credentials on an account page, or manipulates the browser session around an iframe, the merchant can still face security, compliance, and reputational exposure. The payment may be outsourced but the customer experience is not.

The Browser Is Now Part of the Payment Risk Surface

Traditional payment security focused heavily on data at rest, data in transit, and server-side systems. Attackers adapted. They increasingly target data at the point of input: the moment a customer types payment information, credentials, or personal information into a web form.

This is why client-side attacks are so dangerous. The page may look legitimate. The PSP may be legitimate. The transaction path may appear normal. But malicious or compromised JavaScript can steal data before it is protected by downstream payment controls.

This is also why the “we use an iframe” answer is not always enough. Iframes can reduce certain types of payment processing exposure, but they do not automatically eliminate the risk created by the parent page, surrounding scripts, tag managers, overlays, redirects, or malicious behavior elsewhere in the payment flow.

For merchants, the question is no longer just, “Is my PSP PCI compliant?” It is also, “Can scripts running in my customers’ browsers interfere with the payment experience, access sensitive data, or create a path to eSkimming?”

What PCI DSS 4.0.1 Changed

PCI DSS 4.0.1 brought client-side payment security into sharper focus through requirements 6.4.3 and 11.6.1. At a practical level, these requirements push organizations to maintain visibility and control over scripts on payment pages. They require processes to authorize scripts, justify why they are needed, assure script integrity, and monitor for unauthorized changes or tampering.

PCI SSC guidance also makes clear that these topics matter to merchants and third-party service providers involved in eCommerce payment flows. For SAQ-A merchants using embedded payment forms, PCI SSC FAQ 1588 clarified that merchants may need to confirm their webpage is not susceptible to script attacks by using techniques such as those in 6.4.3 and 11.6.1, or by obtaining confirmation from a PCI DSS-compliant TPSP/payment processor that its embedded payment solution includes techniques to protect the merchant’s payment page from script attacks.

That clarification matters because it moves the conversation beyond “Who processes the card?” and toward “Who is protecting the browser experience that leads to payment?”

The Shared Responsibility Gap Between PSPs and Merchants

Shared responsibility is easy to say and hard to operationalize.

A PSP may be responsible for the payment pages, forms, iframes, or hosted checkout infrastructure it controls. A merchant may be responsible for the eCommerce site, parent pages, scripts, vendors, tag manager, user journey, and implementation choices it controls. In between those responsibilities is a gray area where attackers thrive.

That gray area creates several practical questions:

• What exactly is the PSP protecting?
• What evidence can the PSP provide?
• What remains the merchant’s responsibility?
• Does the PSP’s protection cover only its own iframe or the broader page context?
• Can the merchant prove its site is not susceptible to script attacks that affect the eCommerce system?
• Who monitors third-party and fourth-party scripts?
• Who responds when a new script appears or changes behavior?

Merchants need clear answers. PSPs that provide those answers can turn security and compliance into a competitive advantage.

Where PSP Communication Often Falls Short

The issue is not that PSPs are doing nothing. Many PSPs invest heavily in platform security, fraud controls, payment infrastructure, compliance, and availability. Many merchants do not understand the boundary. PSP communication often falls short in four places.

First, PSPs may emphasize their own PCI compliance without clearly explaining what that compliance does and does not cover for the merchant.

Second, PSPs may explain hosted fields or iframe models as scope-reducing controls without clearly explaining the client-side risks that can remain on the parent page or elsewhere in the payment flow.

Third, PSPs may provide limited practical evidence merchants can use for their own compliance workflows, such as script inventories, tamper monitoring outputs, or clear statements about protection against script-based attacks.

Fourth, PSPs may underestimate how much merchants want simplicity. Merchants do not want to become JavaScript security experts. They want to know what is covered, what is not covered, and what they need to do next.

What Merchants Should Ask Their PSP

Merchants should not settle for “we are PCI compliant” as the full answer. They should ask more specific questions:

• Do your eSkimming controls cover only PSP-hosted payment components, or do they also protect the merchant page where the component is embedded?
• Can you provide written confirmation that your embedded payment solution includes techniques to protect the merchant’s payment page from script attacks when implemented according to your instructions?
• What evidence do you provide to support PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1?
• How do you monitor scripts, HTTP headers, and unauthorized changes?
• How do you detect or prevent double-entry attacks, fake payment overlays, malicious redirects, or script behavior that manipulates the checkout flow?
• What responsibilities remain with the merchant?

Those questions are the foundation of a mature shared responsibility model.

What PSPs Should Provide Merchants

For PSPs and eCommerce platforms, the opportunity is bigger than compliance. Merchants are looking for partners that reduce risk, simplify audits, and help them maintain customer trust.

A stronger PSP client-side security posture should include clear responsibility documentation, merchant-facing implementation guidance, evidence that supports PCI DSS 4.0.1 workflows, and a practical path for merchants that do not have the resources to manage script risk themselves.

The best PSPs will go further. They will help merchants understand their exposure, provide security and compliance features as part of the payment relationship, and make client-side protection visible without making it burdensome. That is how shared responsibility becomes a value-added service instead of a source of confusion.

Why Static Controls Are Not Enough

Some organizations try to address client-side risk with static controls such as Content Security Policy or Subresource Integrity. CSP policies can be complex to configure, can break legitimate functionality, and often require continuous tuning. SRI is impossible to apply effectively to dynamic third-party scripts that change frequently.

The deeper problem is that attackers do not limit themselves to simple, predictable script changes. Modern eSkimming techniques include double-entry overlays, silent skimming, compromised tag managers, first-party script injection, WebSocket-based delivery, abuse of trusted services, and attacks that target pages before the final payment step.

A static allowlist does not answer the most important runtime question: what is this script actually doing in the customer’s browser right now?

A Better Model: Behavior-Based Client-Side Protection

Client-side security needs to focus on script behavior, not just script presence.

A behavior-based model monitors what scripts are doing in the browser, controls whether they can read or write sensitive fields, detects unauthorized behavior, and prevents malicious actions before data is exfiltrated. This approach is better aligned to the way modern attacks operate because it protects data at the point of input.

For PSPs, behavior-based protection can become part of a scalable merchant support strategy. It can help provide visibility into third-party and fourth-party scripts, support PCI DSS 4.0.1 evidence workflows, and reduce the operational burden of manually reviewing every script change.

For merchants, it can close the gap between “my PSP processes payments” and “my customer’s browser session is protected.”

Source Defense was built for this problem: client-side security, eSkimming protection, script visibility, behavior-based control, and PCI DSS 4.0.1 support for requirements 6.4.3 and 11.6.1. The goal is not to replace PSP security. It is to strengthen the shared responsibility model by protecting the part of the payment journey attackers increasingly target: the browser.

Conclusion: Shared Responsibility Should Become Shared Visibility

PSPs are essential to secure digital commerce. But merchants need to understand that outsourcing payment processing does not automatically outsource every client-side risk. The browser is now a critical part of the payment security conversation. Scripts running on payment pages and across payment flows can create exposure before data ever reaches the PSP. PCI DSS 4.0.1 has made that reality harder to ignore.

For merchants, the next step is to ask sharper questions and validate what is actually protected.For PSPs, the opportunity is to lead with transparency, provide clear evidence, and offer stronger client-side protection as part of the merchant relationship. The PSPs that win will not be the ones that tell merchants, “Don’t worry, we handle payments.”

They will be the ones that can say, “Here is exactly what we protect, here is what you control, and here is how we help you close the gap.”

FAQ

Does using a PSP eliminate client-side risk?

No. A PSP can reduce payment processing complexity and secure the payment components it controls, but merchants may still have client-side exposure from scripts running on their own pages, parent pages, tag managers, and broader payment flows.

Are iframes enough to stop eSkimming?

Iframes can reduce certain risks, but they do not automatically protect the entire customer journey. Attackers may target the parent page, inject fake payment overlays, manipulate the flow before the iframe loads, or capture other sensitive data outside the PSP-controlled component.

What should merchants ask their PSP about PCI DSS 4.0.1?

Merchants should ask what protections the PSP provides for script-based attacks, what evidence is available for requirements 6.4.3 and 11.6.1, what written confirmation is available for embedded payment implementations, and what responsibilities remain with the merchant.

Why does behavior-based protection matter?

Behavior-based protection focuses on what scripts actually do in the browser. That matters because modern eSkimming attacks often abuse trusted scripts, tag managers, dynamic dependencies, and legitimate services in ways static controls may not reliably catch.

How can PSPs turn this into a competitive advantage?

PSPs can differentiate by helping merchants reduce compliance effort, maintain clearer SAQ-A support where applicable, provide merchant-facing evidence, and offer built-in client-side security that protects the payment experience without adding operational burden.

Close the Client-Side Risk Gap

Your PSP protects the payment infrastructure it controls. Source Defense helps you see and control what scripts are doing across the browser-side payment journey, strengthening eSkimming defenses and supporting PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1. Learn more by downloading The Payment Service Provider & eCommerce Platform Playbook.