Most software companies meet PCI scope at the worst possible moment. A prospect’s security team sends a questionnaire. An acquirer asks for an Attestation of Compliance. A merchant forwards a notice from their bank and wants to know what it means. The scramble that follows is rarely a sign that nobody cared about security. It is a sign that nobody established, early and in writing, which parts of the payment flow the platform is responsible for and which parts belong to someone else.
That boundary is what PCI scope means. For vertical software companies embedding payments, it is one of the most consequential architectural decisions on the roadmap, and it is usually made by accident, by a developer choosing an integration method during a sprint, long before anyone in the business understands what was decided.
Here is how scope actually works, what determines yours, and what a platform can and cannot pass to its merchants.
Scope Is a Property of Your Architecture, Not Your Company
PCI DSS applies to any system component that stores, processes, or transmits account data, along with any system that is connected to those components or could affect the security of them. Nothing in that definition refers to company size, revenue, funding stage, or industry. It refers to systems.
This is the part teams consistently get backwards. Scope is not assigned to you by a card brand or an acquirer based on who you are. It is determined by where card data flows through the systems you control. Two platforms of identical size, serving the same vertical, with the same merchant count, can carry radically different compliance burdens based on nothing more than how checkout was built.
Which means scope is not something you negotiate. It is something you design.
Are You a Merchant, a Service Provider, or Both?
Before scope, role. PCI DSS treats these differently, and platforms frequently discover they occupy both at once.
- You accept cards for your own goods and services. Your SaaS subscription revenue makes you a merchant, regardless of anything else you do.
- Service provider. You store, process, or transmit account data on behalf of another entity, or you provide services that could affect the security of another entity’s cardholder data environment. That second clause is broad, and it is the one that catches platforms by surprise.
A vertical software company that bills its own customers by card and also enables payments inside its product for those customers is operating in both roles simultaneously. The obligations do not merge. They stack.
Validation levels for each role are set by the individual card brands and are driven largely by annual transaction volume. The thresholds differ by brand and by role, and your acquirer is the authority on which apply to you. The important thing is knowing to ask, because a platform that crosses a service provider threshold without noticing does not get grandfathered.
Integration Architecture Determines Almost Everything
Four patterns cover most embedded payment implementations. They are ordered here from least to most scope, and the distance between the first and the last is measured in engineering quarters, not checkboxes.
- Full redirect to a hosted payment page. The customer leaves your domain entirely to enter card details. Account data never touches your infrastructure. This is the lowest scope option available and typically the shortest validation path.
- Provider iframe embedded in your page. The checkout experience stays on your domain, but the form itself is served by the payment provider. Card data goes directly from the customer’s browser to the provider. Still a low scope pattern, with conditions worth understanding in detail.
- Provider JavaScript or direct post from your own page. Your page renders the fields and hands data off using the provider’s client library. Your systems can now affect the security of the payment page, which pulls you into a substantially larger requirement set covering your web infrastructure, change control, and vulnerability management.
- Card data reaching your servers or API. You are now operating a cardholder data environment. Segmentation, encryption key management, logging, access control, penetration testing, and formal assessment all apply. This is an order of magnitude more expensive than the first option and it never gets cheaper.
The step most platforms underestimate is the third one. Moving from a provider-served form to a self-rendered form feels like a modest front-end decision. It is not. It is the decision that changes which requirements apply to your entire public web presence, and it is frequently made for aesthetic reasons by someone who has never seen a self-assessment questionnaire.
The Self-Assessment Change Most Platforms Missed
The current version of the standard brought a change to the shortest self-assessment questionnaire that has meaningful consequences for anyone embedding a payment form in an iframe, and it has not been widely understood.
The PCI Security Standards Council removed the payment page security requirements covering script authorization and change and tamper detection, along with the targeted risk analysis supporting them, from that questionnaire. On its face this reads as a simplification. It is not.
In their place, the Council added eligibility criteria. To use the shortest questionnaire, a merchant must confirm that every element of the payment page delivered to the customer’s browser originates only and directly from a compliant third-party service provider, and must confirm that its own site is not susceptible to script-based attacks that could affect its e-commerce systems.
That second criterion is the difficult one. Confirming a site is not susceptible to script attacks is a substantive technical claim, and assessors have been direct about the fact that it is hard to make credibly. The Council’s own guidance indicates the confirmation can be satisfied by applying the same script management and tamper detection techniques that were removed, deployed either by the merchant or by a third party, or by obtaining confirmation from the compliant service provider supplying the embedded form.
Read that carefully and the shape of it becomes clear. The requirements did not disappear. Responsibility for them moved, and it moved toward whoever can actually make the confirmation.
For a software platform, this is the whole point. If your payment provider can supply that confirmation, your merchants have a clean path. If it cannot, every one of your merchants is left holding a technical attestation they are not equipped to make, and they will eventually ask you about it. It is also worth noting that these requirements continue to apply in full to the questionnaires covering self-rendered payment pages and to full assessments, so the simplification only reaches one specific architecture.
This is a reasonable question to put to any provider during evaluation, and a reasonable thing to expect documented rather than asserted. The Council publishes its guidance directly at the PCI Security Standards Council.
What Your Merchants Inherit, and What They Do Not
Platforms often tell merchants that payments are handled and compliance is covered. That is a well-intentioned oversimplification, and it creates problems later.
Merchants do not inherit compliance. Compliance is not transferable. What merchants inherit is controls, and the effect of good controls is that the merchant qualifies for a shorter validation path with fewer requirements to answer for themselves. Every merchant accepting cards still validates. Your architecture determines how painful that is.
What a platform genuinely owes its merchants is more specific than reassurance:
- Clarity on which questionnaire applies to their configuration, and why.
- A current Attestation of Compliance from the payment provider, available on request rather than after a three-week search.
- A written responsibility matrix showing which requirements are managed by the provider, which are shared, and which remain with the merchant. Current versions of the standard expect this documentation to exist, and it is the single most useful artifact in any merchant security conversation.
- Plain guidance on the merchant’s own obligations, which typically survive regardless of architecture. Constellation Payments publishes an overview of validation paths and questionnaire types in its frequently asked questions.
The platforms that handle this well treat it as product documentation rather than legal cover. The difference shows up in sales cycles.
What Scope Reduction Is Actually Worth
The value of narrow scope is usually framed as saved audit hours, which undersells it considerably. Four things change.
- Assessment burden. Fewer applicable requirements means less evidence collection, fewer interviews, and a shorter validation cycle for you and for every merchant on your platform.
- Engineering freedom. A large cardholder data environment constrains how you build. Network segmentation, key management, restricted access, and change control obligations shape architecture decisions for years. Keeping card data out keeps those constraints off your roadmap.
- Breach exposure. Data you never hold cannot be taken from you. Narrow scope reduces both the probability and the blast radius of an incident, along with the forensic and notification costs that follow one.
- Sales velocity. Enterprise security reviews are a real stage in the funnel. A platform that can answer scope questions precisely and produce documentation on request moves through that stage in days. One that cannot moves through it in months, if at all.
What scope reduction never does is reach zero. Every platform retains obligations around access control, vendor management, incident response, and its own merchant-facing systems. Any provider suggesting otherwise is describing a product that does not exist.
Designing Scope Instead of Inheriting It
The platforms that stay out of trouble are not the ones with the largest security teams. They are the ones that treated scope as a design decision at the point where the integration method was chosen, understood which role they occupied, and selected payment infrastructure that could produce documentation rather than assurances.
CSIPay is built and maintained at PCI DSS Level 1, the highest validation level in the standard, so partners and their merchants inherit that control environment rather than constructing it.
Want a clear read on where your platform sits today? Talk to the Constellation Payments team about your integration and what it means for your scope.