How we approach origin-isolated payment fields at Flux

What origin-isolated payment fields are

When we talk about origin-isolated payment fields, we mean input boxes for card data that run on a different web origin from the merchant's site. An origin is the combination of scheme, domain, and port that browsers use as a security boundary. Two pages on different origins cannot freely read each other's contents. We build payment fields on top of that boundary on purpose, so the card number lives somewhere the merchant's own code cannot reach.

This post is about how we approach the problem, not a claim about any particular customer. The design goal is simple to state: the card number should be usable for a payment and invisible to everyone else, including the merchant.

Why we start from the browser's own boundary

We could try to protect card data with rules and promises, telling merchants what not to log and hoping their scripts behave. We prefer to lean on a boundary the browser already enforces. The same-origin policy is old, well understood, and applied consistently across browsers. By serving payment fields from payments.fluxpayments.com rather than the merchant's domain, we get isolation that does not depend on anyone remembering to be careful.

Building on an existing, enforced boundary tends to fail safe. If a merchant's script misbehaves, the browser still will not let it read across origins into our field.

How we keep the card off your domain

In practice, the merchant embeds our fields as iframes. The shopper types their card number into a frame that is ours, loaded from our origin. The keystrokes never enter the merchant's page context, so the merchant's JavaScript cannot observe them and the merchant's servers never receive them. When we need the data, it travels from the browser to Flux directly, not through the merchant's backend.

We serve the controlling script from our own domain as well, so the whole capture path stays on our side of the boundary. That is a deliberate constraint we design around, even though it means the merchant gives up the ability to touch the raw value.

What we hand back to your application

The merchant does not need the card number to run their business. They need to charge it, sometimes save it, and sometimes rebill it. So after capture we tokenize the card and return a token: a reference that stands in for the number and is safe to store. The merchant uses that token with our API to complete the payment, save the card, or charge it again later.

From the application's point of view, the checkout still feels native. The fields sit inside the merchant's design, and the result is a token their code can hold without inheriting the risk of holding a card.

What this does for your PCI scope

The reason we take this approach is scope. PCI DSS applies to any system that can see, store, or transmit cardholder data. Because origin isolation keeps the card off the merchant's servers and domain, most of the merchant's environment has no card data to protect, which is what makes the shorter SAQ-A path reachable for many of them. On our side, the infrastructure that does receive the card is SAQ-D Level 2 PCI DSS certified.

We think of it as moving the hardest, highest-stakes part of compliance to the place best equipped to carry it, and leaving the merchant with a smaller, more manageable surface.

Where the boundary ends and your job begins

Origin isolation is powerful, and it is not everything. It protects capture. It does not secure the merchant's accounts, servers, or API credentials, and a token plus those credentials can still move money. So we are clear with merchants that our boundary handles the card data, while they still own access control, patching, monitoring, and their own policies.

Good security is layered. Our layer is keeping the card number somewhere the merchant's code cannot reach. The rest of the layers are a shared responsibility, and we would rather be honest about that line than blur it.