One API for every way money moves

Most payment stacks aren't designed. They accumulate. A provider for accepting funds, another for issuing cards, a third for gift cards, a fourth for payouts. Each one solved a real problem, and together they left you with money spread across systems that don't talk to each other, stitched together in vendor reports.

Fluz collapses that stack into one integration: a single GraphQL API and a centralized ledger that every capability posts to. Funding, balances, transfers, cards, gift cards, payouts. One system of record for all of it.

Key takeaways

• Fluz covers the full money movement lifecycle through one API: funding balances, managing them across accounts, sending money, issuing open-loop cards, and purchasing closed-loop gift cards.
• Every event posts to one centralized ledger in real time, so you avoid reconciling these capabilities across separate vendors.
• Controls and approval workflows operate against the same underlying account and transaction data, from spend limits to authorized user permissions.
• Adding another supported capability builds on infrastructure you already integrated, rather than starting another vendor integration.

One API, one ledger

Every action in the Fluz API writes to the same ledger. A deposit, a card authorization, a gift card purchase, a transfer, a payout: different events, one system of record, updated in real time. Query it once and you have the complete flow of funds, without stitching together exports from separate providers.

That shared foundation is what makes controls dependable. Spend limits, card locks, approval workflows for transfers and purchases, and authorized user permissions all operate against the same account and transaction data. Because supported controls and workflows live within the same platform, they don't have to be recreated across separate providers.

What that looks like in practice

Consider a platform serving its own customers. It can fund a customer balance, separate that balance by purpose, issue a virtual card against it, send a gift card as a reward, and let the customer withdraw what's left, all through the same integration, with every event reflected in the same transaction history. That's the difference a shared foundation makes: these capabilities behaving like one connected system instead of six adjacent products.

The rest of this post walks through those capabilities, and what each one adds to that system.

Fund a balance

Everything starts with money coming in. Link eligible bank accounts through Plaid, add debit and credit cards, and deposit into a Fluz balance through the API. Accounts can also use configured primary and backup funding methods, helping eligible transactions continue when ACH funding fails.

The moment funds arrive, they're on the ledger and available to everything downstream: cards, gift cards, transfers, payouts. Funding isn't a separate system your balance syncs from. It's the first entry in the same record everything else writes to.

Manage balances

A single balance works until the first time two teams share it. Create multiple spend accounts to separate money by team, project, or purpose, then transfer between them instantly. Check any balance in real time, close accounts you no longer need, and withdraw to external bank accounts when funds need to leave.

Because spend accounts share one ledger, internal transfers are instant bookkeeping entries rather than settlement events, and one query shows every balance across every account. That's the single control layer at work: budgets, permissions, and visibility organized around one structure instead of scattered across tools.

Send money

Fluz moves money in every direction. Transfer from your application's balance to a user, or from one user to another. Send someone a virtual card through a hosted link, no app download required. Push withdrawals to external bank accounts, or to wallets like Venmo and PayPal through built-in connectors. Disburse to one recipient or thousands through the same integration.

Every payout posts alongside your deposits and spending, so outbound money carries the same visibility as inbound. Adding disbursements to your product didn't require a payout vendor. It was already in the API you integrated.

Open-loop cards

Fluz issues open-loop virtual cards for spending online and in store wherever the card network is accepted. Set a PIN and push cards to Apple Pay or Google Pay. Each card can be issued with a cardholder name and card-specific billing address, providing the data merchants use for AVS verification.

Card activity posts to the ledger as it happens: authorizations, settlements, declines. Your card program's transaction history and your system of record are the same thing.

Card issuing at scale

Creating a card is a single API call. So is editing limits, locking and unlocking, and pulling transaction history down to the individual card. Bulk orders issue cards by the thousands. Authorized users get their own cards with their own spending rules, while you keep full visibility into every transaction.

A thousand cards still operate within the same ledger and control foundation, so visibility doesn't fragment as the program grows. Expanding the card program doesn't mean adding another system to manage.

Closed-loop gift cards

The same API opens a broad catalog of closed-loop gift cards. Query the catalog, pull the best available offer, purchase one card or buy in bulk, and reveal redemption details programmatically. For rewards programs, incentives, and disbursements, that's an additional payout option without another catalog integration: purchased from the same balance that funds everything else, tracked in the same transaction history.

One decision, not five

Fund it, manage it, send it, spend it. Every capability above runs through one API and shares the same account, permission, and transaction foundation. Launching your next money movement capability means extending an integration you already have, not onboarding another vendor.

One API for every way money moves. Explore the documentation at docs.fluz.app/overview and make your first call in staging in about five minutes.