How Instant Payouts actually works, from application to settlement
In Part 1, we covered why the weekend and holiday liquidity gap has become a real retention risk for payment companies. This post is about mechanics: what a merchant actually experiences, and what has to happen behind the scenes for that experience to work without creating risk or operational overhead for you.
Who's eligible, and how enrollment starts
Eligibility criteria for instant payouts are intentionally light, which is part of what makes the product broadly adoptable. A typical bar is: 30 days of processing history, a minimum of $1,000 in volume during that window, and a chargeback rate under 3%. Most merchant portfolios see the large majority of their base qualify.
Eligible merchants receive an invitation to enroll and complete a short application covering owner details, business details, and a bank account for funding. If you already hold that data, the application can be pre-filled to remove friction. Clean applications are reviewed and decisioned automatically, so a merchant can go from invitation to active in minutes.
The application itself can live in your own merchant portal (embedded via a lightweight integration) or in a white-labeled hosted experience, so you're not forced to choose between owning the experience and shipping it quickly.
The available balance and payout request
Once enrolled, a merchant sees an available balance that grows throughout the day as they process transactions. It's calculated off gross authorizations rather than a single transaction, which is what allows a merchant to draw down a portion or all of it at once, rather than being limited to payout-per-sale.
When a merchant requests a payout, they see the amount, the destination account, the fee, and the net amount they'll receive. Funds typically arrive within 30 minutes of initiating a transfer.
Payouts can be scheduled in advance of a known holiday or payroll date.
Merchants select their preferred day and time to receive Instant Payouts, and funds are sent automatically for the full available amount.
Repayment, without disrupting the merchant's normal funding
This is the part worth understanding closely, because it's the piece that determines whether instant payouts creates operational drag for you or runs invisibly in the background.
All settled funds are first deposited into an intermediary settlement account rather than going straight to the merchant's primary bank account. From that settlement account, whatever amount was paid out the prior day as an instant payout gets withheld to make the payout provider whole. The remainder is swept immediately to the merchant's primary account over the fastest available rail (RTP, FedNow, or same-day ACH, depending on what the receiving bank supports).
The practical effect: a merchant sees no change to their normal funding timing. If they're on next-day funding, they stay on next-day funding, even with the settlement account sitting in between. All of that activity, what was received, what was withheld, and what was pushed out, is itemized for the merchant so they can easily reconcile it against their bank statement, and the same visibility is available to you as the partner through a dashboard.
How risk is managed
A few guardrails keep the product safe for both the merchant and the payment company:
Seasoning and volume checks establish a baseline before a merchant is offered the product, so an available balance can be sized against a realistic pattern of authorizations versus settlement.
Payout caps (typically up to 95% of authorization volume, with per-transaction and daily maximums) leave room for voids, refunds, or chargebacks without over-extending.
A small set of MCC restrictions apply, generally tied to categories where a settlement account can't legally be opened in the merchant's name.
Anomaly flags catch transactions that break a merchant's typical pattern (an unusually large ticket size, for example) before a payout against it is approved.
Capital and risk for a standard implementation sit with the instant payouts provider, not the payment company, so eligibility, decisioning, and loss exposure aren't new operational burdens on your team.
Coming up in Part 3
Mechanics only matter if the economics work. In the final post of this series, we'll break down the revenue model, what drives adoption and usage within a portfolio, and what a realistic build-to-launch timeline looks like.
To learn more about partnering with Jaris, contact us.