Building on the Flux API: hosted fields, tokens, and webhooks

What a payment API should give a developer

A payment API is judged by how little it forces you to worry about. The ideal is that you can take money, charge a saved customer later, and know reliably what happened, all without your servers ever holding a raw card number. The Flux payment API is organized around exactly those three jobs: hosted fields for capturing input safely, tokens for reusing payment methods, and webhooks for knowing the truth about every transaction.

This is a developer-oriented tour of how those pieces fit together, and why the design keeps the risky parts of payments off your infrastructure. Underneath it all is a full REST API, so the same operations are available programmatically.

Hosted fields: capture without touching card data

The first problem in accepting a card is capturing the number without your application ever seeing it. Flux solves this with drop-in hosted fields: the input elements where a customer types their card are served inside origin-isolated iframes on payments.fluxpayments.com and embedded in your page.

Because those fields live on a separate origin, your page renders them and positions them but cannot read what is typed into them. The customer sees a seamless form; your code sees a controlled component that hands back a token, never the raw digits. This is what lets you build a native-feeling checkout while the card data goes straight into Flux's SAQ-D Level 2 environment instead of yours.

Tokens: charge again without storing the card

Once a card is captured, you often need to use it again: a repeat purchase, a subscription, a saved payment method for a returning customer. Storing the actual card number to do that would be a liability you do not want. Tokenization removes the need.

Flux returns a token that stands in for the payment method. You store the token, which is useless to an attacker on its own, and reference it when you want to charge. The sensitive data stays inside Flux; your database holds only the reference. For any product with recurring or repeat payments, this is the difference between holding a vault of card numbers and holding a list of harmless tokens.

How do webhooks keep your system in sync?

The final piece is knowing what actually happened. Payments are asynchronous: a charge can settle, fail, or a dispute can arrive long after the initial request returns. Polling the API on a loop to find out is wasteful and slow. Webhooks invert the flow, so Flux notifies your system when an event occurs.

You expose an endpoint, and Flux sends it events as they happen. Your application reacts, updating an order, provisioning access, flagging a failure, driven by the authoritative record rather than an optimistic assumption from the client. Treat the webhook as the source of truth: the browser can lie or lose connection, but the webhook tells you what the platform actually recorded.

Putting the three together

A typical integration uses all three in sequence. Hosted fields capture the card and return a token. You charge the token through the REST API. A webhook confirms the outcome and keeps your system in sync. At no point does a raw card number pass through your servers.

And because the same platform accepts cards, ACH, and stablecoins, the integration you build extends across payment types rather than locking you into cards alone. Pricing is a flat 2.9 percent plus 30 cents per transaction with no setup fees, monthly fees, minimums, or contracts, so you can build against it without a standing cost. To get API access, reach the Flux team at sales@fluxpayments.com or (813) 402-8244, or apply at /apply.html.