How Hosted payment fields API actually works, explained simply

What a hosted payment fields API is

A hosted payment fields API lets you drop individual card inputs, the number, expiry, and security code, into your own checkout, except those fields are not really yours. Each one is a small iframe served from the payment provider's domain. With Flux, they render from payments.fluxpayments.com. Your page controls the layout and styling, but the actual input where the customer types their card number belongs to Flux, not to you.

That single design choice is what makes the whole model work. You get a checkout that looks and feels like part of your product, while the most sensitive input in the entire flow lives somewhere your code cannot reach.

The problem it solves

Before hosted fields, a custom checkout meant putting a plain card input on your own page. The moment a customer typed their number into an element your JavaScript could read, that data was in your environment, and your servers, logs, and error trackers were all in PCI scope. One careless log line could capture a card number.

Hosted fields exist to remove that entire class of risk by making sure the sensitive input never lives in a DOM your code can touch. You cannot leak what you never had.

How does a hosted payment fields API keep data off your server?

The fields are iframes, and iframes from a different origin are isolated by the browser. Your page cannot read what the customer types into a cross-origin iframe, and neither can a malicious script that sneaks onto your page. When the customer submits, the card data travels directly from the iframe to Flux, not through your server. Flux returns a token, a stand-in reference, which is the only thing your code ever sees.

The isolation is enforced by the browser's same-origin policy, not by a promise. That is why origin isolation is the load-bearing part: the security comes from the field living on a different origin, payments.fluxpayments.com, than your site.

You still own the look and feel

A common worry is that hosted fields mean an ugly, generic checkout. They do not. You place the field elements wherever you want in your layout, size them, and style them to match your brand. To the customer, it looks like one seamless form.

The only difference, invisible to them, is that a few of the inputs are tiny iframes doing the secure work. The customer experience you design and the security boundary you rely on are not in tension.

From field to token to charge

The flow is worth memorizing because it is the same on almost every integration. The customer types into the hosted fields. Your code asks the provider to tokenize what is in those fields. The provider returns a token. Your server creates a charge against that token through the REST API. From there you handle the response and listen for webhooks to confirm settlement.

Because the token, not the card, is what you store, you can charge the same customer again later without ever having held their number. Repeat billing and one-click checkout become possible without your database ever becoming a card vault.

What it means for your PCI scope

This is where the model pays off. Because the card number renders and submits inside Flux's origin-isolated iframes and never reaches your servers or domain, the number of systems you have to secure and audit shrinks dramatically. Flux carries SAQ-D Level 2 PCI DSS certification for the part it handles.

You still have obligations, but they are far smaller than they would be if raw card data flowed through your stack. That reduction is the real product a hosted payment fields API delivers.