Payments are the layer where a marketplace stops being a catalog and starts being a business that moves money. One customer pays once; several vendors must eventually be paid; some of those orders will be refunded, disputed or silently stuck in a pending state at the provider. This is a practical guide to choosing a payment setup for a marketplace, moving money to vendors, and running the reconciliation loop that stops small discrepancies from becoming an accounting nightmare.
Choosing a payment provider for a marketplace
A single-store checkout needs a provider that can take a card payment. A marketplace needs more: it takes one payment for a basket that belongs to several sellers, so the money has to be attributable and, eventually, divisible. When you evaluate providers, weigh them on the questions a marketplace actually hits.
| Question to ask a provider | Why it matters for a marketplace |
|---|---|
| Local payment methods in your market | Bank-link and wallet coverage decides conversion far more than card fees |
| Webhook reliability and retries | Your order state is driven by their events; missed or duplicated webhooks corrupt orders |
| Refund and partial-refund API | Marketplace refunds are usually one vendor's parcel, not the whole basket |
| An authoritative order-status endpoint | You need a source of truth to reconcile against, not just fire-and-forget webhooks |
| Payout / split model | Determines whether you can pay vendors through the provider or must settle out of band |
Do not over-index on the headline transaction fee. A slightly cheaper provider that lacks the local bank-link method your customers expect will cost you far more in abandoned checkouts than it saves per transaction.
Who is the merchant of record?
The single most consequential decision is who is the merchant of record — the legal seller who takes the customer's money and owes the tax on it. There are two broad shapes, and they change your compliance surface completely.
In a facilitator model, each vendor is the merchant of record for its own goods and the platform merely facilitates. In a merchant-of-record (reseller) model, the platform takes the money as the seller and pays vendors as suppliers. The choice drives who invoices the customer, who owes VAT, who handles chargebacks and who carries fraud liability. It is as much a legal and tax question as an engineering one, so decide it with an accountant and a lawyer before you write the payout code — the VAT consequences are covered in VAT for online marketplaces. Treat the specifics as advice to confirm professionally, not as settled fact from a blog post.
Payouts and settlement
However you take the money, each vendor eventually needs to be paid for what it shipped, minus the platform's commission and minus anything refunded. Because we split every basket into per-vendor sub-orders at payment time, settlement has a clean unit to work from: the sub-order already knows its vendor, its items, its shipping and its VAT. Payout is then a matter of aggregating settled sub-orders per vendor over a period and subtracting commission and refunds.
Two rules keep payouts trustworthy. First, only pay for settled money — a sub-order whose payment has actually cleared at the provider, not one that is merely marked paid in your database. Second, never pay out a period until reconciliation (below) has run, so refunds and disputes that landed after the sale are already netted out. A payout is easy to send and painful to claw back, so the whole flow is worth building conservatively. Each payout should also produce a statement the vendor and your accountant can both read, which is where settlement meets marketplace invoicing: the commission you deduct is itself an invoiceable, VAT-bearing service, not just a number subtracted in a spreadsheet.
Reconcile against provider status — always
Webhooks lie by omission. They get missed, delivered twice, or arrive out of order, and a payment can sit in a pending or authorised-but-not-captured limbo that your order table never hears about. The fix is a reconciliation sweep: periodically re-read each order's real status from the provider's authoritative endpoint and correct your own record to match. Treat the provider as the source of truth for money and your database as a cache of it.
Our monthly bookkeeping report — orders, VAT, refunds, an invoice register and per-vendor totals — runs a reconciliation pass against the payment provider's own status so a payment stuck in an in-between state surfaces in the report rather than silently skewing a vendor's payout. Reconciliation is not a nice-to-have; it is the difference between books you can trust and books you hope are right.
Refunds, chargebacks and fraud basics
Refunds on a marketplace are almost always partial — one vendor's item came back, not the whole order — so your refund flow has to target a sub-order and reverse both the money and the VAT booked against it. Chargebacks add a wrinkle: the customer disputes the single payment they made, but the goods may span several vendors, so you need to know which sub-orders a disputed charge covers.
On fraud, the boring controls earn their keep: rely on the provider's risk scoring and strong-customer-authentication where it applies, watch for mismatches between billing and the parcel-locker destination, and flag unusual velocity from one account. You do not need a bespoke fraud model to start; you need to not switch off the protections your provider already offers. Reconciliation and clean per-vendor records also make the rare fraudulent order far easier to unwind after the fact.
One marketplace-specific wrinkle is worth planning for: a chargeback hits the single payment, but the goods may already have shipped from several vendors on their own timelines. Decide up front who absorbs that loss — platform or vendor — and encode it in your settlement terms, because discovering the answer during your first dispute is an expensive way to learn it. Clean sub-order records at least tell you exactly which vendors' goods a disputed charge covered, so the conversation starts from facts rather than guesswork.
Key takeaways
- Pick a provider on marketplace fit — local methods, reliable webhooks, partial refunds and an authoritative status endpoint — not on the headline per-transaction fee.
- Decide merchant of record deliberately; facilitator versus reseller changes who invoices, who owes VAT and who carries chargeback and fraud risk.
- Settle from per-vendor sub-orders, aggregating settled orders per vendor and subtracting commission and refunds.
- Reconcile every order against the provider's real status on a schedule — treat the provider as the source of truth and your database as a cache.
- Reverse VAT with every refund and target refunds and chargebacks at the specific sub-order, since marketplace returns are usually partial.
- Get the merchant-of-record and payout structure reviewed by an accountant and a lawyer before writing settlement code.
Frequently asked questions
Who is the merchant of record on a marketplace?
Why reconcile orders against the payment provider?
How are vendors paid on a marketplace?
Do I need a custom fraud system for a marketplace?
Payments, payouts and reconciliation, handled.
We run the payment flow, per-vendor settlement and monthly reconciliation on a marketplace that lives on your domain.
Request early access See the live marketplace →