Marketplace payments and payouts: who holds the money?

What does “who holds the money” mean in a marketplace?

It means whose account a customer’s payment lands in first: the platform’s or the provider’s. Almost everything else about payments follows from that one answer.

When a customer pays for a job, a delivery or a prescription, the money has to go somewhere before the provider is paid. If it passes through the platform, you control when the provider gets paid, how refunds happen and how your commission is taken. If it goes straight to the provider, you control far less, and you have to collect your share some other way.

It is the third of the five questions we ask before we quote: which payment rails, and who holds the money? We ask it early because the answer changes three things at once: what we build, how much regulation applies to you, and how the platform earns. If we cannot answer it, we quote a phase, not a platform. How we work explains the phases.

What are the ways a marketplace can take payment?

There are three common models: the platform collects through a payment gateway and splits the money, the platform keeps a wallet balance for its users, or the customer pays the provider directly. Escrow, or milestone payments, is a way of timing the first two.

A payment gateway is the company that takes card or mobile payments on your behalf. “Rails” are the payment networks available in a country, such as cards, bank transfers or mobile money.

The platform collects and splits the payment

The customer pays the platform through a gateway. The gateway splits the payment: the provider’s share goes to the provider, and your commission stays with you. The provider has an account with the gateway, connected to your platform, so that money can reach them. Their share never sits in your own bank account.

The platform keeps a wallet balance

The customer tops up a balance inside the app, or the provider’s earnings build up there. Money moves between balances inside the platform and leaves when someone withdraws it. Help24, the health marketplace we built for Côte d’Ivoire, has a wallet.

The customer pays the provider directly

The customer pays in cash, by bank transfer or through the provider’s own payment link. The platform records the order but never touches the money. Your commission is invoiced to the provider separately, or replaced with a subscription.

Escrow and milestone payments

The customer pays up front, but the provider is only paid when the work, or a stage of it, is confirmed. “Escrow” here means what it usually means in an app: the platform holds the payment until a condition is met. It sits on top of the first two models. It cannot work with direct payment, because there is nothing to hold.

What is the difference between a split payment and a wallet?

A split payment is divided at the moment it is taken and passed on. A wallet is a running balance for each user, and money can stay inside the platform for days or months.

That difference matters more than it sounds. A split payment is a series of single events, and the gateway does most of the accounting and the regulated work. A wallet is a ledger you run. Every top-up, purchase, refund, fee and withdrawal has to balance, for as long as the platform exists, and someone has to be able to prove it.

A wallet makes sense in three cases:

The country’s rails make repeated small payments awkward.
Customers are already used to stored balances.
The business model depends on credits or prepaid value.

Without one of those reasons, split payments are simpler, cheaper to build and easier to keep correct.

How does each model change the build?

Holding the money adds screens, rules and console work. Paying providers directly removes most of it. The more you control, the more there is to build and test.

Split payments: provider onboarding with the gateway’s identity checks, a payout status the provider can see in their app, commission rules, refunds that reverse the split, and a console view of every payment.
Wallet: everything above, plus the ledger itself, top-ups, withdrawals, a balance history for each user, limits, and reconciliation. Reconciliation means checking that the platform’s records match the money that actually moved.
Escrow or milestones: a held state for each payment, the rules for releasing it, what happens when the customer never confirms, and a dispute path that can stop a release.
Direct payment: order records and, if you take commission, invoices to providers and a way to chase the unpaid ones. Almost no payment code, but a weaker grip on the business.

Payouts need their own decision. Where the rail supports payouts, providers can be paid automatically. Where it does not, the console handles manual payout runs, with a full record of who was paid, when and for what.

These parts sit inside every marketplace we scope, alongside the customer app, the provider app and the admin console. The full list is on marketplace app development.

Does holding the money bring regulation?

Usually, yes. The closer your platform gets to holding other people’s money, the more compliance work sits in the scope.

With split payments, the gateway carries most of that load. It checks providers, holds the funds and moves them under its own permissions. You still have obligations: clear terms, accurate records, and following the gateway’s rules on who can be paid and for what.

A wallet adds compliance scope. Keeping a balance for someone can look, to a regulator, like taking deposits or issuing electronic money. Depending on the country, that can mean working through a licensed partner, limits on balances, or identity checks before a withdrawal. We tell you before a wallet goes into the plan, not after it is built. We are not lawyers, and for a wallet you should take local legal advice as well.

Direct payment keeps the platform furthest from the money, and so furthest from this work. That is its main attraction.

How does the platform make money under each model?

Commission is easy to take when the money passes through you and hard when it does not. If the platform holds the money, commission is deducted before the provider is paid. If the provider is paid directly, you have to bill them and wait.

Commission can be a percentage, a fixed amount per order, or different for each category. It is set in the admin console, not written into code, so you can change it without releasing a new version of the app. The admin console is the web dashboard your team uses to run the marketplace. Some marketplaces also charge customers a service fee or charge providers a subscription. These follow the same pattern: rules in the console, shown clearly in both apps.

Direct payment is not always wrong. If providers already take cash and will not change, a subscription may be the only revenue that works. But be honest about it at the start. A marketplace that plans to add commission later has to move every provider onto a new way of being paid, and some of them will leave rather than switch.

Which payment gateway should a marketplace use?

We choose the gateway by country and by whether payouts are needed. There is no single right answer, and the best-known name is often not available where your customers are.

Three things narrow the choice:

Where your customers and providers are. Gateways differ by country in what they accept: cards, bank transfers, mobile money.
Whether providers are paid out through the platform. Many gateways take payments well. Fewer can pay out to many providers.
Whether you need a wallet or held payments. Not every gateway supports split or held funds.

The gateway’s own fees are a third-party cost. They sit outside the build price, and you pay them to the gateway. A second payment rail, or an integration nobody planned for, is extra scope, and we say so before it is built.

How should refunds and disputes work?

Write the refund and dispute policy in phase one, and build it as a flow in the apps and the console. Do not plan to handle it by email.

A flow means the customer raises a problem inside the app, the provider sees it and can respond, the payment is held or reversed by a rule, and your team decides in the console with the whole order history in front of them. Every step leaves a record. When disputes run through email, the record lives in someone’s inbox, refunds are done by hand in the gateway, and the platform’s figures stop matching the money.

The policy has to answer a short list of questions before any code exists:

Who can cancel, and until when?
What happens if the provider does not show up?
Is a refund full, partial, or a credit?
Who pays the gateway fee on a refund?
How long does the provider have to respond to a dispute?

Each answer becomes a rule we build. Shorter answers on refunds, payouts and commission are in payments and payouts.

Worked example: how does the money move on FindWorker?

FindWorker is our own home services marketplace in Pakistan, and we operate it. Workers set their own price, customers choose, and payment is by milestone, which means the platform holds the money until the work is confirmed.

Here is how the questions in this guide read on a platform like it.

Who holds the money? The platform, for the length of the job. That is the escrow model: a held payment on top of the platform collecting it.

Why milestones for home services? A customer booking a worker wants to know they will not pay for work that did not happen. A worker wants to know the money exists before they turn up. A held payment answers both at once.

What does the payment design touch? More than the payment screen. FindWorker has category-driven provider selection with skills and rates, geolocation matching, booking with calendar sync, a live proximity map, and order tracking. The order’s status decides when money can move, so the payment rules and the order rules have to be designed together.

What changes when something goes wrong? With a held payment, a dispute is about whether to release money that is still held, not about recovering money a provider already has. That is a far easier position to run a marketplace from.

What did running it teach us? FindWorker has real workers, real customers, real disputes and real payouts. Everything that goes wrong in a marketplace has gone wrong to us, with our own money. Running it is why refunds, disputes and payouts are designed in phase one on every build we take on, and not left until after launch.

What this means for your estimate

Who holds the money is one of the largest single drivers of scope in a marketplace. Direct payment is the smallest build. Split payments add provider onboarding, payouts and refund flows. Milestones add held states and release rules. A wallet adds a ledger and compliance work.

Before you use the planner, have a view on three things:

Does money pass through your platform, or straight to providers?
Do providers need paying out, automatically or in manual runs?
Do you need a wallet, or only payments?

The estimate planner asks these as guided questions and turns your answers into a brief. We reply with a tailored quote, usually within one business day. If you are not sure yet, say so. Phase one, scope and price, is where this gets decided and written down, along with a named list of what we are not building. Pricing shows what every price includes and what costs extra, including third-party gateway fees.