When an ISV adds payments, the upside is obvious: new revenue, stickier product, happier merchants. The part teams underestimate is PCI DSS scope. The moment your systems touch a card number, the rules apply to those systems, and "those systems" can quietly grow to mean your whole platform. The good news is that scope is largely an architecture decision. With the right patterns, you can add payments and keep almost everything out of scope.
To be clear up front: OutsideHire builds PCI-aware software. We are not a QSA, and we do not issue certifications or sign off on your compliance. What we do is build payment features the right way, so that when your assessor looks, the card data is already where it should be (and is not where it should not be).
Why PCI scope matters for ISVs
Scope is the set of systems, people, and processes that store, process, or transmit cardholder data, plus anything connected to them. The wider your scope, the more controls you have to implement, the more you have to document, and the longer and more expensive your assessment becomes. For an ISV, an out-of-control scope can mean your entire application, build pipeline, and support tooling all fall under PCI. That is a tax on every future release.
The strategic move is not to "pass PCI." It is to design so that very little of your system is ever in scope in the first place.
Scope-reduction techniques
These are the levers, roughly in order of how often they apply to ISVs.
- Hosted fields and iframes. The card input fields are served from your payment provider inside an iframe, so the keystrokes go to the provider, not your page. Your application orchestrates the checkout but never sees the PAN. This keeps a smooth, embedded experience while pulling card data out of your DOM.
- Redirect. Send the cardholder to a fully hosted payment page to enter card details, then bring them back with a result. This is the strongest reduction because your servers and pages never handle card data at all. For how to build that page well, see how to build a hosted payment page.
- Tokenization and vaulting. The provider stores the card and returns a token. Your systems work with the token for refunds, repeat charges, and reporting, and the real card number lives in the provider's vault, not your database.
- Point-to-point encryption (P2PE). For card-present flows, a validated P2PE solution encrypts card data at the reader so it is unreadable by the time it reaches your software. This can dramatically cut card-present scope.
- Network tokenization. Card networks issue a network token that replaces the PAN for transactions. It improves authorization rates and security and reduces the value of any data that does pass through.
SAQ A vs A-EP vs D, in plain English
Self-Assessment Questionnaires describe how a merchant validates compliance, and the type depends on how card data flows. The same logic helps you reason about your customers' burden.
- SAQ A is the lightest. It is for merchants who fully outsource card handling, typically via a redirect or fully hosted page, so they never touch card data. This is the target you want to design your merchants toward.
- SAQ A-EP applies when the merchant's site does not receive card data but does influence how it is captured, for example with hosted fields embedded in a page the merchant controls. More controls apply than SAQ A because the merchant's page is part of the flow.
- SAQ D is the heavy one. It applies when card data actually flows through the merchant's systems. It has the most requirements by a wide margin, and it is the outcome good architecture exists to avoid.
The plain-English takeaway: the closer your design gets your merchants to SAQ A, the less work everyone has to do, forever.
Architecture patterns to keep card data out of your systems
A few patterns do most of the work:
- Capture card data in an isolated context. Hosted fields or a redirect mean the PAN is entered into your provider's domain, not yours.
- Pass tokens, never PANs, across your services. Once you have a token, treat the raw card number as something you never want to see again.
- Keep secrets server-side. API keys and gateway credentials live on the server, never in the browser bundle.
- Segment what little scope remains. If any component must touch card data, isolate it on its own network segment so it does not pull the rest of your platform into scope.
Common pitfalls
The classic mistakes: logging full card numbers (often by accident, in a request dump or an error trace), letting card data transit a server that did not strictly need it, and embedding a card form directly in your own page instead of using hosted fields. Each of these can silently expand your scope from "almost nothing" to "everything." Build with the assumption that any system that sees a PAN is now your problem, and design so almost none of them do.
Where we fit
This is the kind of work we do for ISVs and platforms: integrating payments into your product in a way that is PCI-aware from the first commit, so card data stays out of your systems and your scope stays small. See our PCI compliance service and how we build for ISVs and platforms.
If you are adding payments and want it architected so scope is a non-event, start a conversation. The discovery call is free, and we will be candid about what stays in scope and what does not.