How Do Marketplace Payments Work?

Between the click on "pay" and the transfer landing in the seller's account, the money passes through several pairs of hands, and each of them runs on different timings, fees, and risks. Companies that did not draw this route before building learn it later, in the worst possible way: at the first refund that lands after a payout, at the first card dispute, or at the first seller who got a different amount from the one they saw in their panel.

A marketplace payment is one payment from a buyer that has to end up divided between several parties: the sellers, and you. Between the buyer's card and the seller's bank account that money makes seven stops. At each one it sits somewhere specific and somebody specific can decide about it. Which stops your setup has is what settles your payout cycle, your balance model, and whether you need a payment licence at all.

This article breaks down:

• Which 7 stops does a marketplace payment make?
• Whose account does the money land in?
• What happens when it travels back?
• Who controls it at each stop?

Key insights

• A marketplace payment does not flow. It stops seven times, and at each stop somebody different controls it.
• A seller balance is an accounting entry rather than money. The funds may still be at the payment provider.
• Less arrives than the buyer paid, because the provider takes its fee on the way. Who absorbs that is a separate decision.
• The route back is not the route forward reversed: a refund needs the original rail, and a card dispute takes the money before the argument starts.

Where does the money stop between the buyer and the seller?

"Money flow" is a misleading phrase, because it suggests a continuous stream from the buyer to the seller. In reality, the money stops several times, and at every stop somebody else controls it. That somebody decides when it moves on.

On top of that, two separate routes run here: the route of the money and the route of the information about the money. The balance a seller sees in your panel is an entry on the information route.

At that same moment, the funds themselves are sitting somewhere else, under somebody else's control. Most settlement disputes start exactly there: somebody treats an entry as money.

One example runs through this whole article: a €1,000 cart and your 12% commission.

Which 7 stops does a marketplace payment make?

1. The bank's consent, before any money moves

The buyer clicks "pay". Their bank checks the funds and puts a hold on €1,000 without passing it on.

That is authorization: consent to a charge rather than the charge itself.

Nobody has received anything yet. The seller sees an order, your system has calculated a €120 commission, and the money is still in the buyer's account.

The hold has an expiry date, and once it passes, the hold falls away.

This is where the route forks for the first time: do you charge straight away, or only once the shipment is confirmed? With several sellers in a single cart, that is a decision with real consequences.

A separate article on the moment of capture settles it.

2. Capture when the money leaves the buyer

Capture turns the hold into an actual transaction. Only now does the €1,000 leave the buyer's account.

And it goes neither to you nor to the seller. It goes into the card settlement system.

This is where intuition at board level most often goes wrong: the order is paid, the report shows €1,000, and the money is in no account you control.

3. Settlement at the payment provider

Transactions are collected into batches, pass through the card organization, and come back to the acquirer, who deducts their own fees and transfers only the net amount. Two consequences, and both matter for planning.

The first: the money arrives late, with the delay counted in business days from the capture. Exactly how late depends on the contract, the market, and the risk profile.

Get that number from the vendor in writing, because it is a direct charge on your working capital.

The second, and more often missed: less arrives than the buyer paid. Suppose the transaction fees come to €15.

Then €985 lands in the account. You calculate the €120 commission on the price the customer sees, so the arithmetic does not close on its own: the seller is "owed" €880, and €985 came in.

Who covers that €15 is a separate decision and a separate article. It can fall to you, the seller, or both.

What matters here is that the difference exists and somebody will carry it. Whoever does not settle this before launch settles it in an emergency, and usually to their own disadvantage.

4. Somebody's account and the fork that decides the rest

Here the route splits in two, and this is the one fork that no later refactor can undo.

Option one: the money lands in the seller's settlement account at your payment provider. The seller is registered there as a separate entity and verified by them, and all you send is an instruction: how much to release and to whom.

Your commission comes off along the way, into your account. You never touch anyone else's money.

Option two: the whole amount lands in your account, and you pay the sellers out in cycles. It is more convenient operationally, and it gets picked more often.

Very often without anyone realizing it. From that moment on, you hold money that is not yours for a while, and in most jurisdictions that is payment activity.

This article does not settle it. The next one is given over to it.

Note one thing: the consequences of this choice are regulatory, so the decision belongs to the board and the lawyer rather than to the integration team.

5. The balance is an entry

Whichever option you pick, your system keeps a balance for the seller. The market has settled around three states.

It is worth knowing what they mean, because every vendor names them slightly differently:

• pending: the sale has already happened, but the amount owed has not matured yet;
• available: it has matured, and it goes into the next payout;
• paid out: the money has gone.

The move from the first state to the second is triggered by a maturing event: usually confirmation of delivery, sometimes the passing of an agreed number of days after it. The delay exists for one reason.

It gives the buyer time to return the goods and raise a complaint before the money leaves your reach. Market practice sits between a few days after delivery and a few weeks, and new or risky sellers get longer periods than proven ones.

That is not the operator being difficult. It is the price of risk.

And one thing has to be said plainly: the balance in the panel is your liability toward the seller rather than the seller's money. Until the funds sit in segregated accounts at a licensed entity, the seller holds a claim against you, which carries all the risk that implies.

Better that the board hears that sentence calmly, and not from a lawyer in emergency mode.

6. The payout

A transfer to the seller's bank account. This is the only moment on the whole route where money genuinely changes owner.

Everything before it was a promise, a hold, or an entry. That is why the status "paid out" should mean "transfer confirmed" and not "transfer instruction created".

Those are two different things, and the difference surfaces at exactly the moment a transfer fails to arrive. Cycles, holds, and reserves are the subject of a separate article.

7. Reconciliation

The last stop does not move any money. It checks whether the route closed.

Three independent sources have to agree: your own ledger, the payment provider's report, and the bank statement. In finance, this is called three-way reconciliation, and it is ordinary practice everywhere payments run through an intermediary.

In a marketplace, it is harder than in an ordinary store, for three reasons at once: settlements arrive already reduced by fees, a single order can settle in several installments on different days, and refunds come back by a different path from payments. If nobody has this in their job description with a stated cadence, reconciliation simply does not happen.

The gap then grows for months, until an auditor notices it.

What happens when the money travels back?

The most expensive assumption in this layer goes like this: "the money came this way, so it will go back the same way." It will not.

A refund has to go back to the original payment method, and the ability to refund to a card expires after a certain time. At that point, you need a fallback rail.

It is usually a bank transfer, which comes with a different accounting path and a different document. This is not an edge case.

It is the ordinary fate of a refund when the returns window is long.

A card dispute behaves even less intuitively. The buyer can challenge the transaction with their bank many months after the purchase, and in some situations much later.

The money then leaves almost immediately, out of the account of whichever entity answers for the transaction toward the payment provider. That is when you find out whether you got around to settling who that is.

And the third: the money is no longer where it was. In our example, the €880 went out to the seller three weeks ago, and the customer has just returned the goods.

Where do you find €1,000 for the customer? From a reserve, a deduction against future payouts, or a demand for payment.

Each of those paths is a different process and a different clause in the seller contract. All three have to be written down before you launch.

Which payments never take the 7-stop route?

Cash on delivery (COD) is the cleanest example: the money goes from the buyer through the courier straight to the seller and never enters your route at all. The €120 commission has nothing to be deducted from, so it turns into a receivable.

Either you charge it against the seller's balance from other orders, or you invoice them separately and chase the payment.

Gift cards, store credit, and deferred payments behave the same way: to the buyer it is one transaction, and on the money side it is a different flow. You do not have to support all of them from day one.

You do have to know which ones you are not supporting, and tell your sellers before it surprises them.

Comparison: Who controls the money at each stop?

What does the payment route decide?

1. Stop 4 settles the rest

The choice between a seller account at the payment provider and your own account determines your regulatory exposure, the cost of changing vendors, and who pays for card disputes. That is the first question in the first meeting.

2. The seller's working capital is your recruiting tool

The delays at stops 3, 5, and 6 add up to the number of days a seller finances your platform. A shorter cycle attracts sellers, a longer one protects you against refunds.

That is a genuine commercial trade.

3. The seller contract is a financial document

Payout cadence, the maturing period, the rules for deductions, and what happens when a balance goes negative. If that is not in the contract, it is nowhere, and the system will do something regardless.

4. Reconciliation needs a job rather than a tool

A named person, a named frequency, named classes of discrepancy. Without those, you are buying software that produces reports nobody reads.

How do you trace your own payment route? Questions for the vendor

Take one real order and walk it stop by stop. Seven questions that have to get a specific answer rather than "that is configurable":

1. How many business days pass between the charge to the customer and the money landing in an account? And whose account is it?
2. By how much does the amount that lands differ from the amount the customer paid? And who carries that difference?
3. What event moves a seller's receivable from "pending" to "available"? And who can trigger it by hand?
4. Can you produce today a statement for a month that closed two months ago, including a later refund relating to that month's sale? That single question reveals whether the system records events or only recalculates balances.
5. What exactly does the status "paid out" mean? A transfer instruction, or confirmation that the money arrived?
6. What does a refund look like once the window for refunding to a card has closed, and how is the fallback rail booked?
7. What happens when a seller's balance goes below zero? Who tells them, who collects, and after how long?

Write the answers down. Not because the vendor is lying, but because in a year you will be reading them in a completely different mood.

5 mistakes operators make about the payment route

1. Treating the balance as money

A balance is an entry recording a liability. The sentence "we have €400,000 owed to sellers" means something different in each of the two options from stop 4.

In only one of them is it harmless.

2. Shortening the payout cycle to attract sellers

It works, and it is sometimes sensible, but paying out before the window for returns and disputes closes moves the risk onto you. Do it deliberately, and price it.

3. Confusing commission calculated with commission collected

€120 in a report is not €120 in the account. With cash on delivery, refunds, and cancellations after capture, those two numbers drift apart.

You have to be able to show the difference as well as explain it.

4. Assuming one route for every payment

One unsupported flow is enough to stop reconciliation from closing.

5. Putting reconciliation off until "after launch"

A discrepancy caught in the third month is an hour of work. The same discrepancy at the year-end close is a project.

What do you still have to settle yourself about marketplace payments?

This is a map of mechanisms. It is neither legal or tax advice nor a vendor recommendation.

Confirm with a lawyer, for the specific country and model, whether the option you pick at stop 4 requires a payment license or a licensed partner, before you start building. This article deliberately gives no thresholds and no deadlines that come out of regulation, because they change faster than this text does.

It also does not settle which option is right for you, or how to pick the length of your payout cycle. That depends on the category, the structure of your seller base, and your appetite for risk.

Every interval here is given as an order of magnitude and as market practice rather than as a measurement.

The articles that follow go down into each fork in turn: the regulatory perimeter, the moment of capture, the payment split and the cost of handling it, payout cycles, and the ledger that has to agree with the bank transfer. This one had a single job: to give you a route on which you can point with your finger to where your money is standing.

Summary: Which stop should you settle first?

Settle stop 4 before anything else, because it decides whether you are holding other people's money. Then the payout cycle, the balance model, and reconciliation follow from it.

Trace one real order through all seven stops with your provider and your platform vendor in the room. Talk to a marketplace expert if you want a second pair of eyes on the route.

Frequently asked questions on marketplace payments

How do payments work on a marketplace?

The buyer pays once, and the money makes seven stops before it reaches the seller. Authorization, capture, settlement at the payment provider, arrival in somebody's account, the balance entry, the payout, and reconciliation.

The fourth stop is the one that decides your regulatory exposure.

Does the seller get paid directly or through the marketplace?

Both models exist, and the choice is yours to make once. The payment provider can split the payment and settle the seller directly, which keeps you out of the flow of funds.

Or the whole amount can land in your account, and you pay out in cycles, which gives you control over timing and makes you responsible for money that is not yours.

Why is a seller balance not the same as money?

Because a balance is an entry in your ledger, not funds in an account. The money can still be sitting at the payment provider while your panel already shows the seller what they are owed.

The number in the panel and the transfer that arrives have to be reconcilable, which is a separate piece of work.