Key takeaways
- Hosted fields are provider-owned iframes embedded in your checkout, so card data goes to the provider, not your servers.
- Because scope follows the card data, keeping it off your systems can move you from SAQ-D toward SAQ-A.
- The benefit disappears if your code ever touches the raw card number, so avoid capturing or proxying it.
- Hosted fields cover capture only; you still own access control, patching, logging, and policy.
- Flux serves origin-isolated fields from payments.fluxpayments.com and tokenizes the card so you never store the number.
What it means to reduce PCI scope with hosted fields
Scope is the part of your business that PCI DSS applies to. Reduce the scope and you reduce the number of systems you have to secure, document, and prove safe every year. The phrase reduce PCI scope with hosted fields describes one of the cleanest ways to do that: instead of collecting card numbers in your own form, you embed input fields that are owned and served by a compliant payment provider.
The card data goes straight from the shopper's browser to the provider. Your servers never receive it, so they fall out of the sensitive part of your environment.
How do hosted fields work?
A hosted field looks like a normal input box for the card number, expiry, and security code. Under the hood, each of those boxes is a small iframe loaded from the provider's domain rather than yours. Visually it sits inside your checkout. Technically it belongs to the provider.
When the shopper types their card number, the keystrokes land inside that iframe, which is on a different origin from your page. Your JavaScript cannot read into it, and neither can anything else running on your domain. The provider tokenizes the data and hands your page back a token, a safe stand-in you can store and use to complete the charge.
Why this shrinks your audit
PCI scope follows the card data. If a system can see, store, or transmit a real card number, it is in scope and every relevant requirement applies to it. Hosted fields cut that data off before it reaches your systems, so most of your stack has nothing sensitive to protect.
In practice this is often the difference between the long SAQ-D questionnaire and the much shorter SAQ-A. You are still responsible for your checkout page and how you load the fields, but the encryption, storage, and key-management questions that dominate SAQ-D largely fall away because you are not holding the data those questions are about.
The setup mistakes that quietly add scope back
Hosted fields only help if the card data truly never touches your page. A few missteps undo the benefit. The first is capturing the card number in your own input and then passing it to the provider, which puts the raw value back through your code. The second is loading the provider's script from a location you control or proxying it, which can pull your server back into the data path.
Others include logging full form contents for debugging, letting third-party scripts run unrestricted on the checkout page where they could skim the fields, and mixing test and live integrations so a misconfiguration sends real cards to the wrong place. The rule of thumb: if any system of yours can read the card number, even briefly, it is back in scope.
What hosted fields do not cover
Hosted fields handle capture. They do not, on their own, secure the rest of your environment. You still need access controls, patching, logging, and a written security policy. If you store tokens, you need to protect the systems that can use them, since a token plus your API credentials can move money.
Think of hosted fields as removing the single most dangerous piece of data from your walls, not as removing the walls.
How Flux implements hosted fields
Flux serves its hosted fields as origin-isolated iframes from payments.fluxpayments.com. Because the fields live on a separate origin, the card number never reaches your servers or your domain, and browser isolation keeps your own scripts from reaching in. Flux tokenizes the card so you can charge, save, and rebill using the token instead of the number, and it is SAQ-D Level 2 PCI DSS certified on the infrastructure that receives the data.
For most merchants the goal is not to become a security company. It is to keep card data out of the building while still owning the checkout experience. Hosted fields, used correctly, are how you get both.
Frequently asked questions
Can I style hosted fields to match my checkout?
Yes. Hosted fields render inside your page and can be styled to fit your design, while the actual input still lives in the provider's iframe. You control the look; the provider controls the data.
Do hosted fields work for saved cards and recurring billing?
Yes, through tokenization. The provider returns a token that stands in for the card, and you charge or rebill against that token so you never store the real number.
Will hosted fields alone make me PCI compliant?
They remove card data from your environment, which is the biggest step, but you still must secure the rest of your systems and complete the appropriate self-assessment.
Ready to get set up with Flux?
Cards, ACH, and stablecoins in one platform, with volume-based pricing. No setup fees or contracts.
Get Started