Marketplace Payments: Commissions, Split Payouts and Refunds

A payment in an ordinary store has two parties. Marketplace payments have at least three, the buyer, the vendor and you, and every order has to answer who received the money, who is owed which share, and who pays when it is refunded or disputed. Teams that leave those answers vague tend to find them out during the first chargeback.

This explains the models in general terms. It is not tax or legal advice, and the points where you need your accountant or lawyer are marked.

Three ways marketplace payments can flow

Model	The buyer pays	The vendor is paid	Refunds and disputes hit	Fits
You collect, then pay out by hand	You	By bank transfer, on your schedule	You	A handful of vendors at the very start
The provider splits the payment, you are the merchant	You. Your name is on the card statement	The provider moves the vendor's share to the vendor's own account with it	Your balance first. You recover the vendor's share	Marketplaces where the buyer deals with your brand
The vendor is the merchant, you take a fee	The vendor	Directly. Your fee is deducted on the way	The vendor's balance	Platforms that give sellers tools and stay in the background

The first model is the easiest to build and the one to be careful with. You are holding money that belongs to other people, which can bring regulatory duties depending on the country, and a standard merchant account may not permit it. Ask your payment provider and your lawyer before relying on it.

The other two are what gateway marketplace products are for. Stripe's is called Connect, and its documentation on charge types maps onto the table: destination charges, or separate charges and transfers, when the platform is the merchant, and direct charges with an application fee when the vendor is. PayPal has a comparable multiparty product in which the platform earns a partner fee on each transaction.

One practical consequence: a cart containing items from several vendors needs the platform to take one payment and split it several ways. In Stripe's terms that is separate charges and transfers, the most involved of the integrations. If you can launch with one vendor per order, the payment work gets noticeably smaller.

Identity checks belong to the payment provider

Before a vendor can receive money, someone has to establish who they are. These checks, usually called KYC, are an obligation on the payment provider, and carrying them is a large part of what a marketplace product does. Stripe describes how it verifies connected accounts: it collects details about the person or company, may ask for an identity document or proof of address, and can pause charges or payouts until its requirements are met. PayPal likewise screens the sellers a platform onboards.

Your part is small and should stay small:

• send the vendor into the provider's hosted onboarding and store the account identifier that comes back,
• listen for status updates and keep the vendor's listings or payouts on hold until the provider reports the account ready,
• show the vendor plainly what the provider is still waiting for.

Do not build your own passport upload. You would be storing sensitive documents and still not satisfying the provider's checks. Stripe also notes that its verification does not discharge any legal duties a platform has of its own, so ask counsel whether you have any.

Define the commission on paper before anyone codes it

"We take a commission" hides half a dozen decisions. Take a concrete order, with an item price, a shipping charge, tax and a coupon, and write down the answer to each of these:

• What is the base? Commonly the item price only, with shipping passed through to the vendor untouched.
• Who absorbs the processing fee? You, out of the commission, or the vendor, or both in proportion.
• Who funds a discount? If the platform issued the coupon, the vendor usually expects to be paid on the full price, and you cover the difference.
• How do you round? Calculate in the smallest currency unit as whole numbers, round once per order line, and decide who gets the odd cent.
• Do rates vary by category, by vendor or by sales tier?

Then store the rate and the calculated amounts on each order line at the moment of purchase. A rate change next quarter must never rewrite what last quarter's orders earned.

When vendors get paid

Paying the vendor the instant the buyer pays is simple and leaves you exposed when the order is canceled or returned. A common pattern is to release the vendor's share after a trigger: delivery confirmed, a service completed, or a return window closed.

The payout itself, the transfer from the vendor's balance to their bank account, is made by the payment provider. A platform can influence its timing, within limits the provider sets. Stripe, for example, lets a platform switch connected accounts to manual payouts, caps how long funds can be held by country, and states that it does not provide escrow. That word has a legal meaning, so keep it out of your own marketing unless your lawyer has agreed to it.

Decide who carries refunds and chargebacks

Refunds

Every refund raises the same four questions, and the answers belong in your vendor terms and in the code.

• Is the commission returned? On a full refund the usual choice is to return it. Some marketplaces keep it when the vendor was at fault.
• What about a partial refund? The usual rule is to reduce the commission in the same proportion.
• Who absorbs the original processing fee? Check whether your provider gives it back on a refund. If it does not, someone carries that cost on every return.
• What if the vendor has already been paid? The vendor's share has to come back out of their balance or their next payouts. If that balance stays negative, the loss may fall on the platform, depending on how the accounts are configured.

Decide as well who may issue a refund: vendors for their own orders, perhaps, with your approval above a threshold or after a time limit.

Disputes

A dispute is the buyer's bank pulling the money back. The disputed amount is taken from whoever was the merchant: the vendor's balance in the vendor-as-merchant model, your platform balance when you are the merchant. In the second case you can try to recover the vendor's share by reversing the transfer, which only works if the vendor still has funds with the provider. The provider also charges a dispute fee, and its documentation says which account pays it.

The evidence, such as proof of delivery or the conversation with the buyer, is normally in the vendor's hands, and the bank sets a deadline. Build the path for it: notify the vendor the same day, collect the documents through the vendor dashboard, and state in your terms that vendors bear disputes on their own orders.

Keep your own ledger and reconcile it

The provider's dashboard is not your accounting. Record every money event yourself as a new row that is never edited afterward: the charge, each transfer, each fee, refunds, reversals, disputes and payouts, each tied to an order line and a vendor. Vendor statements, your revenue report and support answers should all come from this ledger.

Events reach you through webhooks, which can arrive twice or out of order. Store the event identifier and ignore one you have already processed. Once a day, compare your ledger with the provider's transaction report and flag any difference. This is the part of the build where careful payment API integration pays for itself, because a silent mismatch grows with every order.

What to ask your accountant about tax and invoices

We cannot tell you what you owe, but we can tell you what to ask. Who is the seller of record on each sale? Do marketplace facilitator rules in the places you sell make the platform responsible for collecting sales tax or VAT on vendors' sales? Is your commission a service to the vendor that needs its own invoice? Are you required to report vendor earnings to a tax authority? Providers sell tools for some of this. Setting them up correctly remains your responsibility.

Plugin, provider features or custom code

For a product marketplace on WooCommerce, the marketplace plugins offer gateway add-ons that handle split payments, and that is enough for a standard commission with one vendor per order. Custom work starts where the model does: payouts held until delivery, mixed carts, platform-funded coupons, tiered rates, or a ledger your finance team can audit. We build that on both stacks for online marketplaces, as WordPress marketplace development or a Laravel marketplace build. The step before any of it is getting vendors through verification, covered in vendor onboarding and quality control.

Frequently asked questions

Do I need a special payment account to run a marketplace?

Usually, yes. Collecting money for third parties through a standard merchant account may breach the provider's terms. Marketplace products exist for this, so tell your provider what you are building before you launch.

Who pays the card processing fee on a marketplace order?

It depends on the model. When the platform is the merchant, the provider normally bills the platform, and you decide whether the commission covers it. When the vendor is the merchant, the fee can come out of the vendor's side.

Can vendors in other countries be paid?

Only where your provider supports it for your platform's country and the vendor's. Cross-border payouts have their own eligibility rules and currency conversion costs, so check the provider's country list before recruiting vendors abroad.