Most ISVs think PCI compliance doesn't apply to them.

They've partnered with a gateway or processor who provides some shiny iFrame or drop-in JavaScript that handles the card entry experience. As far as they're concerned, they're out of scope. No card data touches their servers. No worries, right?

Wrong — and potentially very expensive.

Let's Talk About What PCI Actually Says

Straight from the PCI DSS glossary:

"PCI DSS is intended for all entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) or could impact the security of the cardholder data and/or sensitive authentication data. This includes all entities involved in payment account processing — including merchants, processors, acquirers, issuers, and other service providers."

That “could impact” part? That's the kicker — and it absolutely includes ISVs.

Why? Because Software Isn't Static

When your platform embeds someone else's PCI-compliant payment capture solution — be it a hosted iFrame or JavaScript SDK — it's true that the default behavior doesn't expose card data to your systems.

But what if:

• Your web application is compromised?
• A developer introduces rogue code?
• A dependency brings in a malicious update?
• An XSS vulnerability opens up script injection?
• Your CDN serves the wrong JavaScript version?

Suddenly, your “safe” payment capture becomes a trap, funneling full cardholder data off to an attacker — and your platform is the source of the breach.

Service Providers Have Stricter Requirements

ISVs that provide payment-related services to other merchants are classified under PCI and Visa rules as Service Providers, not just merchants.

That means:

• You have a broader obligation to protect downstream merchants
• Your PCI responsibilities aren't magically absorbed by your processor
• You're subject to stricter validation requirements — especially around change management and frontend integrity

Which PCI Requirements Apply?

Even if your architecture is designed to avoid cardholder data exposure, you're still responsible for a meaningful subset of PCI DSS requirements:

• Requirement 6: Secure Development

  • Validate and sanitize all inputs
  • Conduct secure code reviews and change control
  • Vet and monitor all third-party dependencies

• Requirement 11: Vulnerability Management

  • Regular vulnerability scanning and pen testing
  • Simulate tampering and injection scenarios

• Requirement 12: Security Policy and Vendor Management

  • Define clear internal roles and responsibilities
  • Train staff on secure coding and operational practices
  • Maintain an inventory of third-party service providers
  • Require service provider contracts to include PCI DSS responsibilities
  • Collect and assess their Attestation of Compliance (AOC) annually
  • Vet new vendors before integration

Scope May Be Reduced — But It's Not Zero

Yes, using hosted fields and tokenization can reduce your PCI scope dramatically. That's smart architecture.

But reduced scope ≠ no scope.

You still need to:

• Document and review what's in scope and what isn't
• Validate inherited vs. implemented controls
• Monitor any component that can influence the security of cardholder data

Do It Right From the Start

If you wait until Visa or your acquirer says you're out of compliance — or worse, your platform is linked to a breach — it's already too late.

Building PCI into your platform early is faster, cheaper, and smarter. You'll protect your customers, de-risk your business, and gain credibility with partners and processors.

Where Payments Therapist Comes In

We specialize in helping ISVs and SaaS platforms define their PCI scope, document controls, and navigate their obligations as Service Providers — without turning compliance into a six-month distraction.

Every PCI engagement starts with scope:

• What's in or out?
• What controls are yours vs. inherited?
• Which vendors matter — and how are they being managed?

We help you build a right-sized compliance program that fits your actual architecture — and makes sure you stay off the card brands' naughty list.

If you're building payments into your product, you're in scope. Let's make sure you're in control too.