Case notes: solving Real-time disbursements for a real merchant

How to read these case notes

These are case notes, not a trophy. We are not going to tell you we saved a named client a specific sum, because that is exactly the kind of tidy story that is usually invented.

Instead, this is how we approach real-time disbursements when a merchant comes to us with the problem, written so you can apply the thinking yourself. The merchant here is a composite, unnamed on purpose, and the numbers are deliberately absent. What is real is the method.

The situation we are called into

Picture a merchant that collects money from customers and then has to pay a set of recipients out of that flow: a marketplace paying sellers, a platform paying providers, an operator paying a network of contractors. The complaint is almost always the same. Money comes in fine, but paying it back out is slow, manual, and generating complaints.

Recipients want their money sooner, the finance team is reconciling payouts by hand, and a batch process that runs once a week has become the thing everyone is unhappy about. The merchant asks for real-time disbursements, meaning they want to pay recipients close to the moment the obligation is created rather than on a slow cycle.

How we approach the diagnosis

Before we design anything, we map the flow. We ask where the money that funds disbursements comes from and when it is actually available, because you cannot pay in real time from funds you do not yet have. We ask who the recipients are and what they can receive, since push-to-card needs an eligible debit card and some recipients will need ACH.

We ask what currently happens when a payout fails, because a manual process often hides the fact that failures are being handled by someone noticing later. And we ask how payouts are reconciled today, since real-time money movement with batch-era bookkeeping just moves the pain. The diagnosis usually reveals that the slowness is not one problem but three: funding timing, rail choice, and reconciliation.

The design we reach for

With the flow mapped, the design tends to follow a pattern. Route disbursements that need speed to push-to-card through Visa Direct, so recipients with a debit card get funds quickly, and keep ACH as the fallback for everyone else. Make payout requests idempotent so a retry during a network blip does not pay someone twice.

Wire the merchant's system to consume webhooks, so a disbursement is marked complete only when the platform confirms it, not when the request is sent. Verify recipients once at onboarding and reserve extra review for unusual payouts. And sync cleared transactions to the books, using a QuickBooks integration where it fits, so finance stops reconciling by hand. Because Flux handles acceptance and disbursement in one platform, this is usually an extension of an existing integration rather than a new vendor.

What we watch for after it goes live

Launching is not the end of the method. We keep the first phase narrow, sending real-time disbursements to a subset of recipients while confirming that funding holds and reconciliation balances. We watch for fraud patterns, because a faster rail is more attractive to abuse, and we make sure the failure path actually works by testing a failed payout on purpose.

We treat the presence of a fallback rail as non-negotiable, so no recipient is stranded without an eligible card. Only when those hold do we widen the rollout. The goal is not to be fast once, but to be fast reliably.

Real-time disbursements as a method, not a switch

If there is a lesson in these case notes, it is that real-time disbursements are rarely a single feature you switch on. They are the result of fixing funding timing, choosing the right rail per recipient, and bringing reconciliation into the same era as the payments.

We approach every merchant this way because the tidy version, the one with a big number attached, tends to skip the parts that actually determine whether it works. Get the method right and the speed follows.