PCI Compliance Is an Architecture Decision, Not Just a Checkbox

Ask a payment vendor if they are PCI compliant and you will almost always get the same answer: yes. Ask which SAQ their architecture puts your business on, and the conversation gets a lot more interesting, sometimes uncomfortably so. Most vendors never get asked that second question, which is exactly why so many Business Central teams end up on a wider, more expensive assessment than their actual card volume should require.

That gap exists because PCI compliance gets treated as a form to fill out instead of a decision that already got made, months or years earlier, when nobody in the room was thinking of it as a compliance decision at all. A gateway got added. A subsidiary came in through an acquisition, carrying its own checkout page. A terminal showed up at a counter somewhere. Each one of those quietly decided how wide the cardholder data environment would be, long before anyone opened a questionnaire to find out.

Why the Scope Question Got Harder to Ignore

PCI DSS 4.0 raised the floor on what "compliant" even means. As of March 2025, controls that used to sit in the optional best-practice column, expanded authentication requirements and stricter encryption among them, became mandatory for anyone who stores, processes, or transmits cardholder data. That landed at an inconvenient time for a lot of Business Central users, who were already carrying more payment complexity than their systems were built for: card-present terminals running alongside online invoicing, legal entities added through acquisition, and processors bolted on one at a time as the business grew.

Every one of those additions was a decision about where card data flows, whether anyone treated it that way or not. A new gateway connection is a decision. A subsidiary going live is a decision about whether its payment environment inherits the parent company's controls or starts from scratch. Most of these calls get made by whoever is closest to the immediate problem, an IT admin standing up a new integration, a controller onboarding an acquisition, and nobody steps back to ask what it does to the compliance picture as a whole. Nobody budgets time for that question until the questionnaire shows up.

Where the Real Cost Hides

Break "PCI compliance" into what it actually validates and the picture gets clearer. The PCI Security Standards Council organizes its requirements around network security, cardholder data protection, vulnerability management, access control, monitoring, and information security policy, six objectives that sound reasonable until you realize almost no merchant answers all of them directly. Compliance gets validated through a Self-Assessment Questionnaire, and which SAQ applies depends entirely on how much of that cardholder data environment a business actually touches.

When a merchant never sees a raw card number, because a hosted payment page or iframe handles it before the number reaches their servers, they can land on a questionnaire that runs to roughly thirty questions. A merchant storing card data on its own systems, or running a checkout with any influence over how that data moves, ends up on one that runs into the hundreds. That is not a rounding difference. It is the difference between an audit a controller closes out before lunch and one that pulls in IT, legal, and a security assessor for weeks.

Plenty of businesses misjudge which SAQ they actually need, usually because nobody mapped how card data moves through the environment before the architecture got built. By the time that becomes obvious, redesigning the payment flow to qualify for a lighter questionnaire is expensive and disruptive in a way it never had to be. Most vendor conversations skip past this part entirely and lead with certifications and encryption specs instead. Those matter, but neither one decides what SAQ a merchant lands on. Scope does, and scope gets decided long before anyone opens the form.

What Architecture-First Changes

Scoping down a cardholder data environment works a lot like clearing out a garage. Get rid of anything that does not need to be in there, and there is simply less to protect, track, or explain the next time someone asks what's inside.

For a Business Central user, that looks like this. Card data gets captured through a hosted iframe field or payment page that lives outside the merchant's own servers, so a raw card number is never actually sitting inside Business Central to begin with. The first time a customer's card gets used, it is replaced with a token, a reference that means nothing outside the vaulting system that issued it, and that token is what BC stores and reuses for recurring billing or repeat purchases. Spreedly's Level 1 PCI-compliant vault handles that piece for USTPay specifically, but the underlying pattern matters more than any one vendor's version of it.

The same logic extends to gateway architecture. A gateway-agnostic connector that works across more than a hundred processors means a business is not locked into whichever gateway happened to get integrated first, which is worth something for redundancy and negotiating leverage on its own. It also means the payment architecture does not get rebuilt every time a business adds a subsidiary or starts accepting a new currency, since the same tokenization and scoping logic extends instead of resetting. Card-present locations need the same discipline.

A Dejavoo terminal that talks straight to the processor keeps swiped and inserted card data off the internal network entirely, rather than routing it through a POS system that now has to be secured to the same standard as everything else, the same principle behind independent card vaulting: keep the sensitive data in one purpose-built place, and everything connected to it inherits a smaller footprint.

None of this makes PCI obligations disappear. A business still needs policies, access controls, and an annual attestation no matter how tightly it scopes its cardholder data environment. What changes is the size of that environment, and size is what decides whether recertification is a quarterly non-event or an annual fire drill.

What This Means for Your Next Vendor Conversations

For a controller managing recertification across three subsidiaries, or an AP lead who inherited "the PCI thing" along with a dozen other responsibilities, the useful question is not whether a payment vendor is PCI compliant. Every legitimate one will say yes, and none of them are lying. The useful question is which SAQ their architecture puts a business on, and why.

That means asking where card data actually lands before it reaches the ERP, whether it gets tokenized on first use or ever sits in the clear anywhere along the way, and whether adding a new entity or currency means touching the payment architecture at all or just extending a configuration. It also means asking what happens to that scope the day a business adds a card-present location or starts accepting a new currency, since that is usually the moment an architecture built for one simple use case starts to strain. One architecture turns that moment into a configuration change. The other turns it into a project.

Where to Start

Building a compliance program well is still its own discipline, gap assessments, documentation, ongoing monitoring, and it matters no matter how the architecture underneath it is built. But that work gets considerably lighter when the architecture was designed to keep card data out of scope from the start. The most useful first step is not shopping for a new vendor.

It is mapping how card data actually moves through your current environment today, gateway by gateway, entity by entity, and marking every point where a raw card number touches a system it does not need to. That map will tell you more about your real audit burden than any certification badge, and it costs nothing but an afternoon.

Ready to See What This Looks Like Inside Your BC Instance?

If you want a second set of eyes on where cardholder data actually sits in your own environment, the USTPay team works specifically with Business Central users on exactly this question. Connect with a payments expert to walk through what a smaller, architecture-first PCI scope would look like inside your instance of Business Central today.