From Batch Payouts to Self-Serve: Giving Merchants Instant Access to Their Own Money

A customer taps their card at a restaurant, the sale clears in seconds, but the money the restaurant just earned won’t be theirs to touch for days; it lands with the POS operator first, pooled with every other merchant’s takings, and gets paid out in a batch once or twice a week. So when payroll comes due, or a supplier needs paying, or any bill lands before the next batch, the owner is in the strange position of watching money they’ve already earned sit just out of reach.

This is one of the most common frictions in platform payments, and it shows up the same way in Riyadh, São Paulo, Jakarta, and London. It isn’t a staffing problem on the operator’s side or a discipline problem on the merchant’s. It’s an architecture problem, and as instant, account-to-account payment rails go live in market after market, it’s an increasingly hard one to justify.

A growing number of POS, marketplace, and vertical SaaS platforms are making exactly this shift by embedding banking infrastructure directly into their product. This is how it works, why it matters more to the platform than you might expect, and what it looks like in a market where it’s already playing out.

Why This Problem Is Worth Solving

The pain is universal because two things are true in almost every market at once: small merchants live close to the edge of their cash, and the infrastructure to pay them instantly now exists.

On the merchant side, delayed access to their own money is not a minor annoyance, it collides with obligations that don’t wait. Payroll runs on a fixed date. Suppliers expect to be paid on terms. Tax and social-contribution deadlines are calendar-bound. A profitable business can still miss any of these simply because its cash is temporarily locked with an intermediary. This is why cash-flow timing, not profitability, is repeatedly identified as a leading cause of small-business distress across markets.

On the infrastructure side, the ground has shifted fast. Instant, 24/7 account-to-account payment rails are no longer a novelty confined to one or two countries:

266 billion real-time payment transactions were processed globally in 2023, up more than 40% year on year, and the trajectory has only accelerated since^[1].
Live in most major markets. Saudi Arabia’s sarie, India’s UPI, Brazil’s Pix, the US’s FedNow and RTP, the UK’s Faster Payments, and the eurozone’s SEPA Instant all move money bank-to-bank in seconds. Africa alone has 36 instant-payment systems across 31 countries^[2].
Increasingly mandated. The EU’s Instant Payments Regulation required eurozone banks to offer instant euro transfers, at the price of a standard transfer, from late 2025, a signal that “instant” is becoming the baseline, not a premium^[3].

Put those together and the batched-payout model looks increasingly out of step: the merchant needs their money now, and the rail to deliver it now already exists. The only thing in the way is how the platform holds and releases funds.

A Market Where This Is Already Playing Out: Saudi Arabia

It helps to look at one market where both forces (merchant cash-flow pressure and instant-payment infrastructure) are especially visible, because it previews where many others are heading.

The Saudi picture isn’t exceptional, it’s a concentrated version of the same dynamic emerging elsewhere: fast rails, tight merchant cash cycles, and hard deadlines. A platform that solves the payout gap here has effectively built a template it can carry into any market with a comparable instant rail.

The Model Today: Batched Payouts and a Manual Bottleneck

Most platforms that collect card payments on behalf of many smaller merchants (a cloud POS serving independent restaurants, a marketplace paying out sellers) default to the same architecture:

A customer pays at the point of sale.
The transaction settles into the operator’s own bank account: one pooled account collecting funds from every merchant.
The operator’s finance team reconciles who is owed what, and pushes payouts to each merchant in a batch, usually once or twice a week.

Notice where the work sits: the operator actively pushes money out to merchants. This works at small scale and breaks down as the platform grows, in three specific, expensive ways:

Linear headcount growth. Reconciliation and payout effort scales with merchant count, not with engineering leverage; doubling merchants roughly doubles the manual workload.
Support cost. “Where’s my money, I have salaries due” is one of the most common, most avoidable categories of merchant support ticket, and it’s pure overhead.
Merchant churn risk. When a merchant can’t reach their own money to meet a payroll run or a supplier bill, and a competing platform offers faster access, the slow payout experience becomes a reason to leave.

The Shift: From Operator-Push to Merchant-Pull

The fix flips the direction of the last step. Instead of the operator pushing batched payouts out, each merchant sees their own balance and withdraws from it on demand. It doesn’t require the platform to become a bank; it requires one omnibus account with a licensed banking partner, and the ability to issue a Virtual IBAN (VIBAN) to every merchant programmatically:

One omnibus account is opened for the platform itself, held with a licensed banking partner; the only bank relationship the platform needs to manage.
A VIBAN is issued per merchant via API, in the same flow as merchant onboarding. No manual account-opening, no waiting on the bank, a new merchant gets a dedicated virtual account the moment they join.
Card settlement routes directly to the merchant’s own VIBAN, so funds are earmarked and trackable at the individual merchant level from the moment they land, not commingled in an undifferentiated pool.
The merchant sees their real balance in real time, inside the same terminal or dashboard they already use every day.
The merchant withdraws their own money instantly, on their own schedule, via the local instant rail, straight from that same interface, 24/7, no ticket, no batch, no call to support. If payroll is due today, they move what they need today.

Is it still the operator’s money, legally, until it’s withdrawn? No, and this is the detail worth being precise about. Each VIBAN gives the funds sitting inside the omnibus account sub-ledger-level traceability back to a specific merchant. The omnibus structure is an operational convenience for the banking partner; it doesn’t blur who the funds belong to. That’s what makes the model both auditable for the bank and safe for the platform to build on; the platform is never commingling merchant funds without a clear, per-merchant record.

“We Already Have a Payments Provider, Isn’t This Scope Creep?”

This is usually the first objection from a product leader, and it rests on a misread of what the model replaces. It doesn’t replace your payment acceptance: the terminal, the card processing, the checkout flow all stay exactly as they are. This sits on top of the money you’re already collecting, changing only where settled funds land and how merchants access them.

In other words, this isn’t a decision to “become a fintech.” It’s a decision about the account structure and payout experience behind a payment flow you already own. The licensing, the bank relationship, and the compliance surface sit with the Banking-as-a-Service (BaaS) partner and the licensed bank, not on your balance sheet and not on your roadmap. Your team integrates an API; it doesn’t take on a banking charter.

Why This Matters More to the Platform Than to the Merchant

It’s tempting to pitch this purely as a merchant-facing convenience: faster access to your own money, nicer UI. That’s real, but it undersells the case. The bigger win sits with the product and finance leadership of the platform itself:

Finance stops being a scaling bottleneck. Manual reconciliation and batch-payout work is exactly the kind of process that should scale with automation, not headcount. Removing it isn’t a nice-to-have; it’s the difference between finance capacity being a constraint on growth or not.
Support volume drops. “Where’s my money” tickets all but disappear when merchants can see a live balance and move funds themselves.
It becomes a product differentiator, not a back-office fix. Instant, self-serve withdrawals are a feature you can market to prospective merchants; especially against operators still batching once or twice a week.
It ships in weeks, not quarters. Building this directly (securing a bank relationship, meeting each market’s licensing and safeguarding requirements, and integrating settlement rails) typically runs into multiple quarters of work before any product is built on top. A BaaS partner absorbs that undifferentiated heavy lifting, so a product team can ship the merchant-facing feature in a fraction of the time and, crucially, can repeat it market by market instead of rebuilding from scratch each time.

What This Looks Like in Practice

Picture a cloud-based POS platform serving independent restaurants and cafés. Historically, every card transaction across every merchant location settled into the operator’s own account, and its finance team pushed proceeds out to each restaurant in a batch once or twice a week.

After making the shift to self-serve, the operator:

Opened a single omnibus account with its banking partner: one relationship to manage, not thousands.
Used a VIBAN issuance API to generate a dedicated virtual account for every restaurant automatically, as part of onboarding, zero manual setup per merchant.
Routed card settlement directly to each restaurant’s VIBAN, giving every merchant a real, trackable balance from the moment a sale settles.
Exposed balance visibility and on-demand withdrawals directly inside the existing POS terminal, no new app, no new login.

The result: when a restaurant needs to cover payroll or an urgent supplier payment, it withdraws what it needs instantly, 24/7, without waiting for the operator’s next batch. The operator’s finance team is no longer in the loop on day-to-day payouts at all. And the operator now has a self-serve feature it can point to in every sales conversation with prospective merchants, in every market it operates.

The same shape works well beyond F&B. A services marketplace can issue a VIBAN per provider and let them draw down earnings on demand; a vertical SaaS platform with embedded payments can give every sub-merchant a live balance inside the dashboard they already log into. The vertical changes, the market changes, but the shift is the same: from the operator pushing money out to the merchant pulling it in.

The Broader Pattern

Anywhere a platform collects money on behalf of many smaller sub-merchants or partners (marketplaces, gig platforms, booking systems, vertical SaaS with embedded payments) the same three building blocks apply, regardless of geography:

An omnibus account with a licensed banking partner aggregates all incoming funds.
A VIBAN issued per end customer gives every sub-merchant a trackable, auditable balance, without separate bank onboarding.
Balance visibility and instant, self-serve withdrawals are exposed via APIs directly inside the product the end customer already uses, over whichever real-time rail the local market provides.

Together they replace a manual, operator-driven payout process with a self-serve one, the platform’s core product becomes the front door to financial services its merchants didn’t previously have, and the team that used to move that money by hand is free to work on something that actually requires a human. Build it once, and it travels with you into the next market you enter.

Thinking about where payout ops sit on your roadmap?

If manual reconciliation and batch payouts are quietly consuming your finance team’s time (or if instant, self-serve withdrawals are becoming table stakes in your market) it’s worth seeing what the omnibus + VIBAN architecture looks like for your specific product. Staq’s team can walk you through a reference architecture and a one-page integration overview mapped to your platform and the markets you operate in. Reach out for a technical walkthrough.