How we reached PCI DSS SAQ-D Level 2 and what it means for you

The acronym that decides who guards the cards

PCI DSS is the security standard the card networks require of anyone who touches cardholder data. SAQ-D is the most comprehensive self-assessment questionnaire within it, the one that applies to organizations handling card data most directly, and the levels describe validation tiers based on transaction volume and risk. So PCI DSS SAQ-D compliance is not a vanity badge; it is a statement about how seriously an organization guards the most sensitive data in a transaction.

Flux is certified to PCI DSS SAQ-D Level 2. This post explains what that means in plain terms and, more importantly, what it means for a business that processes through Flux.

What SAQ-D actually asks for

SAQ-D is the demanding end of PCI self-assessment because it covers the full breadth of the standard: how card data is stored, transmitted, and access-controlled, how systems are hardened and monitored, how vulnerabilities are managed, and how policies hold it all together. It is the questionnaire for organizations that are directly in the path of cardholder data rather than fully outsourcing it.

Meeting it is not a one-time form. It reflects ongoing controls and practices around protecting card data, which is why it carries weight. When a platform is SAQ-D certified, it has taken on the version of PCI responsibility that assumes it handles the sensitive data itself.

Why does Flux's compliance reduce yours?

Here is the part that matters for a merchant. Every business that accepts cards has some PCI obligation, but the scope of that obligation depends on how much card data the business itself touches. If card numbers flow through your servers, your PCI scope is large. If they never touch your systems at all, your scope shrinks dramatically.

Flux captures card data inside origin-isolated iframes hosted on payments.fluxpayments.com. When a customer types their card, that data goes into a frame Flux controls, on a Flux domain, and never reaches the merchant's servers or domain. The sensitive part of the transaction happens inside Flux's SAQ-D Level 2 environment, not yours. The practical effect is that the merchant offloads the heaviest part of the compliance burden onto infrastructure built and certified for it.

What origin isolation buys you

The origin-isolated iframe is the technical mechanism that makes this real. Because the field lives on a separate origin, payments.fluxpayments.com, the merchant's own page cannot read what the customer types into it, and neither can anything running on the merchant's site. The card data is walled off by the browser's own security boundary.

That isolation is what lets a merchant honestly say card numbers never touch their systems. It is not a policy promise; it is enforced by how the browser separates origins. Combined with tokenization, the merchant works with tokens that stand in for card data rather than the data itself.

What it means for you in practice

For a business choosing a processor, the takeaway is concrete. Processing through Flux means the most dangerous data to hold, raw card numbers, is something you never hold. That lowers your breach exposure, shrinks your PCI scope, and keeps you out of the business of running an audited card environment.

Two honest caveats. Every merchant still has its own PCI responsibilities appropriate to how it operates; using a compliant processor reduces scope, it does not erase every obligation. And the certification stated here is specifically SAQ-D Level 2, no more and no less. To understand how this maps to your setup, reach the Flux team at sales@fluxpayments.com or (813) 402-8244, or apply at /apply.html.