CS-Cart Multi-Vendor Vendor Payouts
Every marketplace operator hits this eventually. A vendor emails to say their payout is wrong. You open the admin accounting screen, open the vendor panel, and the two don't agree. Or they do agree, and the vendor still thinks it's wrong, because they expected shipping to be theirs and it went to you.
This comes up on the CS-Cart forum constantly, phrased a dozen different ways: does the payout include shipping, how do I change the payout formula, why don't admin and vendor accounting match, should commission come off before or after tax, what about discounts, why is this vendor's balance negative.
They're all the same question. Here's the whole picture in one place.
The two models
Before any of the detail, know which model you're running. Everything else follows from it.
Model 1: the marketplace collects everything. The customer pays you. All of it lands in your account. You then owe each vendor their share, and you pay it out on a schedule.
Model 2: the gateway splits at the point of payment. The customer pays once, and the payment processor divides it between you and the vendors automatically. Stripe Connect and PayPal's multiparty products work this way.
Many CS-Cart marketplaces run model 1, because model 2 depends on the split product being available in every country your vendors are in, not just yours. That's the constraint people miss.
Model 1 means you are holding other people's money between the sale and the payout. Depending on where you operate, there may be rules about doing that. Worth an hour with an accountant before you scale.
How the share is calculated
Strip away the interface and there are four steps.
- Work out the commission base: the amount commission is charged on
- Apply the commission rate to it
- Add anything else the vendor is owed, or charged
- That's the vendor's share of that order
Almost every dispute is an argument about step 1. Not the rate. The base.
A worked example
An order:
- One product, sold for $100.00
- Shipping charged to the customer: $10.00
- Tax at 20%: $20.00
- A 10% discount off the product: −$10.00
- Customer pays: $120.00
- Your commission rate: 15%
Now: what is 15% charged on?
| Commission base | Base | Commission | Vendor gets |
|---|---|---|---|
| Everything the customer paid | $120.00 | $18.00 | $102.00 |
| Product only, before discount | $100.00 | $15.00 | $95.00 (+ shipping?) |
| Product only, after discount | $90.00 | $13.50 | $96.50 (+ shipping?) |
| Product after discount, excluding tax and shipping | $90.00 | $13.50 | $76.50 + $10.00 shipping |
Same order, same rate, four different answers, and a spread of more than $25 on a single $120 sale.
This is why "what's your commission rate?" is a much less useful question than vendors think. Agree the base in writing when you onboard a vendor, with a worked example like the one above. It prevents most disputes before they happen.
Shipping: the argument that never ends
The most common vendor complaint on any marketplace.
The vendor's view: "I packed it, I paid the courier, the shipping money is mine."
The marketplace's view: "It was collected through my checkout, it's part of the order value."
Both are reasonable. Pick one, write it down, and make the system match.
Things that make it genuinely complicated:
Free shipping promotions. You run a "free delivery over $50" campaign. The customer pays nothing for shipping. The vendor still posts the parcel. Who pays for it? If you don't decide this before running the promotion, you'll decide it during an argument.
Multi-vendor orders. One customer buys from three vendors and pays one shipping charge. (Per-vendor carrier accounts need shipping add-ons that understand vendors.) That has to be divided by weight, by order value, by parcel count, or evenly. Whichever you pick, some vendor will be worse off than shipping separately.
Shipping charged versus shipping cost. You charge the customer $10. The courier charges the vendor $7.50. The difference is margin, and whose it is needs deciding.
Commission on shipping. If shipping is in the commission base, you're taking a cut of postage. Vendors hate this and say so loudly. That's fair enough if your rate allows for it, but be upfront rather than letting them discover it.
Tax and VAT in the commission base
The second most common argument, and it's usually about who is actually selling.
The principle: tax collected on a sale is not revenue. It's money held for a tax authority. Charging commission on it means charging a fee on money nobody gets to keep.
Most marketplaces exclude tax from the commission base for that reason. If yours doesn't, you're putting your rate up by your tax rate without saying so, and a vendor who works this out will not be pleased.
Where it gets harder:
Who is the seller of record? If the vendor sells to the customer and you're a platform, the vendor accounts for the tax and you charge tax on your commission as a service. If you're the seller of record, you account for the whole thing. These are very different arrangements and it affects invoicing, not just arithmetic.
Marketplace tax rules. A number of countries now make the marketplace liable for collecting and remitting tax on sales through it, regardless of who "sold" it. If you operate anywhere with rules like this, your payout model needs to reflect it.
Vendors in different tax jurisdictions. Cross-border marketplaces have vendors with different registrations, thresholds and rates. Whatever you build has to handle a vendor who isn't tax-registered next to one who is.
This is the section to take to an accountant who knows your markets. We can build whatever rule you need. We can't tell you which rule is legal where you operate.
Discounts and promotions: whose margin?
A customer uses a 10% code. Ten percent of what, taken from whom?
Three options:
- The marketplace funds it. The discount comes off your commission. Vendor gets their full share. Good for vendor relations, and it can wipe out your margin on a heavily discounted order, occasionally taking it negative
- The vendor funds it. Comes off their share. They should have agreed to the promotion first, or you'll have a row
- Split it. Proportionally, or by an agreed ratio
The rule that saves you: vendors opt in to promotions. A marketplace-wide sale that automatically discounts every vendor's products without asking is the fastest way to lose good sellers.
Watch the edge case: stacked discounts (a marketplace promotion plus a vendor's own) can push an order's commission to zero or below. Put a floor in.
Payment processing fees
The cost everyone forgets to account for.
Your gateway takes, say, 2.5% plus a fixed fee. Someone pays that. Options:
- The marketplace pays it out of commission. Simplest, and it means your real margin is lower than your rate suggests
- Passed to the vendor, deducted from their share. Common, and needs to be in the vendor agreement
- Split
The fixed fee hurts small orders far more than you'd expect. A $0.30 fixed fee on a $4.00 sale is 7.5% before anything else. If your marketplace sells a lot of low-value items, model this properly. It may be more than your commission.
Refunds and chargebacks after payout
This is where balances go negative and vendors get upset.
The sequence: order placed, vendor paid out, customer refunded three weeks later. You've now paid out on money you no longer have.
How CS-Cart handles it: the refund creates a negative adjustment against the vendor, which nets off their next payout. If they have no further sales, they carry a negative balance.
The problems:
A vendor with a negative balance and no sales. You're owed money by someone with no incoming revenue. Do you invoice them? Write it off? Hold a reserve against it?
A vendor who leaves owing money. Recovery is difficult and often not worth it.
Chargebacks arriving months later. Card chargebacks can land a long time after the sale. If you've paid out and closed the books, that's your loss unless your vendor agreement says otherwise.
Partial refunds. A refund on part of an order has to recalculate commission on the remainder. If commission was charged on the full amount and half is returned, the vendor is owed some commission back.
What to do about it:
- Hold a reserve. A percentage of each payout retained for a set period, released after your return window closes. Standard practice, and vendors accept it if you explain it upfront
- Delay first payouts for new vendors. Fraud and quality problems show up early
- Put negative balance recovery in the vendor agreement, in writing, at signup
Why admin and vendor accounting drift apart
Both screens claim to show the same money and don't. Usual causes:
They're showing different things. One shows order totals, the other shows what's payable. Both correct, both different.
Timing. One includes orders in a status the other excludes. An order marked complete on the 31st sits in different months depending on which date each screen uses.
Refunds applied to one side only. A refund processed in the gateway but not properly recorded against the order updates the customer's money and not the vendor's balance.
Orders in an in-between status. Payment Pending, Incomplete, Backordered. Different screens make different assumptions about whether those count.
Manual adjustments made in one place and not reflected in the other.
How to find it: don't compare totals. Export both, match order by order, and find the first order where they diverge. The pattern is always visible once you have the list. It'll be a status, a date boundary, or a refund.
Automatic payouts, and what to do when they aren't available
Stripe Connect is the most complete option. Handles split payments, holds balances, does the payouts, deals with vendor onboarding and identity checks. The catch is country coverage: for your vendors, not you.
PayPal multiparty products cover a different and also incomplete set of countries. Widely used, usually easier to sign vendors up to, less flexible.
When neither covers your vendors, which is common for marketplaces in Africa, South Asia, Central Asia and parts of the Middle East, you're doing manual or semi-automatic payouts. Realistically that means:
- The marketplace collects everything
- Vendor balances are tracked in CS-Cart
- Payouts run on a schedule, by bank transfer, mobile money, or a local provider
- Someone exports a payout file and uploads it to a banking portal
That's a normal way to run a marketplace. It just needs building deliberately rather than being discovered in month three. The things that make it survivable: a payout export in the format your bank actually accepts, a payout record against each vendor so they can see what they were paid and for which orders, and a clear statement per period.
We've built exactly this for marketplaces where the standard split products weren't an option: automatic vendor payouts through Stripe where it was available, and custom payout flows where it wasn't.
A checklist before you launch
- Commission base defined in writing, with a worked example in the vendor agreement
- Shipping: who gets it, and what happens on free-shipping promotions and multi-vendor orders
- Tax excluded or included, checked against your local marketplace tax rules
- Discounts: who funds them, and vendors opt in
- Payment fees: who pays, and modelled on your smallest typical order
- Refund and chargeback policy, including negative balances
- Reserve policy, if you're holding one
- Payout schedule and method, matched to your gateway's settlement timing
- A vendor-facing statement showing what they were paid and for which orders
That last one is worth more than it looks. Most vendor payout disputes aren't really disputes about money. They're disputes about not being able to see the working.
If your marketplace needs a payout model your gateway doesn't support, or your admin and vendor accounting have drifted and you need to find out why, that's the kind of work we do. Tell us about your marketplace.
Common questions
It's your call, but decide it before you sign vendors and write it down with a worked example. If shipping is in the commission base you're taking a cut of postage, which vendors object to loudly. It's fair enough if your rate allows for it. Just don't let them discover it from a statement.
Most marketplaces exclude it, because tax collected on a sale isn't revenue. It's money held for a tax authority. Charging commission on it effectively raises your rate by your tax rate. Check your local marketplace tax rules too, since several countries now make the marketplace liable for collecting and remitting.
Prevent it rather than chase it. Hold a reserve (a percentage of each payout retained until your return window closes) and delay first payouts for new vendors, because fraud and quality problems show up early. Put negative balance recovery in the vendor agreement at signup, in writing.
No. Stripe Connect is the most complete option where it's available, but availability depends on your vendors' countries, not yours. Plenty of marketplaces collect everything centrally and pay out on a schedule by bank transfer or a local provider. That's a normal design. It just needs building deliberately.
Usually they're showing different things: one shows order totals and the other shows what's payable. Or it's a date boundary, an order status one includes and the other excludes, or a refund recorded on the customer side but not against the vendor balance. Export both and find the first order where they diverge; the pattern is always visible from there.
