Case study · Retail & eCommerce
Three hundred makers, one basket, correct payouts
A curated marketplace wanted customers to buy from several makers in one order, and each maker to be paid correctly without anybody doing arithmetic. That is the whole problem with marketplaces.
Engagement · Product build & launch
A marketplace, where the money movement is the hard part.
- Industry
- Craft & artisan retail
- Solution
- Multi-vendor marketplace
- Platform
- Shopify
- Engagement model
- Dedicated product team
- Scope
- Onboarding, catalogue, payouts, shipping, disputes
- Vendors
- 340 makers at launch
- Constraint
- Curation must not become a bottleneck
- Target
- Automatic settlement
Outcomes
What automated settlement made possible
A marketplace that settles by spreadsheet cannot grow past about fifty vendors.
-
340
Makers onboarded in the first year
Self-service onboarding with curation as a review step rather than a data-entry step means the team approves makers instead of typing their catalogues.
Measured across approved vendors in the first 12 months
-
0
Manual payout calculations
Commission, shipping attribution and refunds are computed per line and settled automatically, so nobody reconciles a spreadsheet at month end.
By design: settlement computed per order line
-
2.1
Vendors per order on average
Customers buy from multiple makers in one basket, which is the entire reason a marketplace exists rather than a directory of separate shops.
Measured across completed orders after launch
Context
A directory that wanted to be a marketplace
Customers could find makers. They could not buy from two of them at once.
The business
A curated marketplace for independent makers, with a strong editorial brand and a growing audience.
The starting point
Each maker had their own storefront linked from the marketplace, so a customer wanting three items paid three times and paid shipping three times.
The trigger
Basket analysis showed customers repeatedly trying to buy from multiple makers and giving up at the second checkout.
What they wanted
One basket across makers, correct automatic payouts, per-vendor shipping that is fair to both sides, and onboarding that does not consume the curation team.
Constraints
Curation is the brand and must stay human · makers ship themselves, at different rates, from different places · refunds and disputes must attribute correctly · payouts must be right, because a maker's livelihood depends on them.
System
What it runs at today
The marketplace as it runs today.
-
340
Makers
Onboarded in year one
-
2.1
Vendors per order
One basket, several makers
-
0
Manual payouts
Settled automatically
-
Human
Curation
Review, not data entry
The engineering problem
Four problems every marketplace hits
The storefront is the easy part.
-
Money that has to split correctly
One payment from a customer becomes payouts to several makers less commission, adjusted for refunds, shipping and returns. Done by hand, it stops scaling almost immediately.
What we did
Per-line settlement: commission, shipping attribution and adjustments computed at line level and settled automatically on a schedule.
-
Shipping from several places at once
Makers ship themselves from different locations at different rates. Charging one shipping fee is unfair to somebody; charging three is unfair to the customer.
What we did
Per-vendor shipping calculated per basket with a customer-facing total that is fair, and attribution back to each maker that is accurate.
-
Onboarding that consumes the curation team
If the marketplace team enters each maker's catalogue, growth is capped by their typing speed.
What we did
Self-service vendor onboarding with bulk catalogue import, where curation is a review and approval step rather than a data-entry one.
-
Refunds that have to unwind correctly
A refund on one line of a multi-vendor order has to claw back the right commission from the right maker, or the marketplace is quietly losing money.
What we did
Refunds and disputes attributed per line, adjusting settlement automatically in the period they occur.
Architecture
How it fits together
Simplified — the shape of the system rather than every service in it.
-
Vendors
- Onboarding
- Catalogue import
- Curation review
Makers manage themselves; the team curates rather than types.
-
Catalogue
- Per-vendor products
- Unified browsing
- Editorial curation
One catalogue to the customer, many owners behind it.
-
Settlement
- Per-line commission
- Shipping attribution
- Adjustments
Money split at line level and settled on a schedule.
-
Fulfilment
- Per-vendor shipping
- Split dispatch
- Tracking
One order, several parcels, one customer experience.
Settlement is computed at line level, not order level. Order-level settlement looks simpler until the first partial refund on a multi-vendor basket.
Solutions
What we built
A marketplace that scales past the team's typing speed.
-
Vendor onboarding
Self-service application and catalogue import.
-
Curation workflow
Human review and approval as the gate.
-
Unified basket
Multi-vendor checkout in one payment.
-
Per-vendor shipping
Fair combined totals with accurate attribution.
-
Settlement engine
Per-line commission, shipping and adjustments.
-
Vendor portal
Orders, statements and payout transparency.
Key capabilities
What it does day to day
Six capabilities across the marketplace.
| Capability | Runs | Refresh | What it does |
|---|---|---|---|
| Vendor onboarding | Vendors | Self-service | Application, catalogue import and setup without the team typing |
| Curation | Marketplace team | Per application | Human review and approval, which is the brand |
| Unified basket | Customer | Per order | Products from several makers in one checkout |
| Shipping | Automatic | Per basket | Per-vendor rates combined into a fair customer total |
| Settlement | Automatic | Per period | Commission, shipping and adjustments computed per line |
| Disputes & refunds | Marketplace team | Per case | Attributed per line, adjusting settlement automatically |
Integrations
How the moving parts plug in
One basket in, correct money out.
Customer basket
- Several makersOne checkout
- Shipping combinedFair total
- One payment
Order split
- Each maker notifiedTheir lines only
- Dispatch separately
- Tracking unifiedFor the customer
Settlement
- CommissionPer line
- Shipping attributedTo the right maker
- Refunds adjustedIn period
The customer sees one order and one tracking view even though three parcels arrive on different days from different places — which is what separates a marketplace from a directory.
Security & data
What protects the makers
These are small businesses whose cash flow depends on being paid correctly and on time.
-
Settlement accuracy
Computed per line with a full statement, so a maker can check every penny.
-
Payout transparency
Each maker sees their orders, commission and adjustments rather than a single net figure.
-
Data isolation
A vendor sees only their own orders and customer data, enforced server-side.
-
Dispute handling
Refunds and disputes attributed per line with a recorded decision.
The brief
A marketplace is a payments product with a shop attached
The marketplace team framed this as a storefront project. The storefront was the least of it — the reason their old model could not scale was that every additional maker added manual reconciliation.
We built settlement first, at line level, and the customer experience on top of it.
- Settlement computed per order line
- Self-service onboarding with human curation
- Per-vendor shipping with a fair customer total
- Refunds attributed and adjusted automatically
What the build had to respect
- 01Curation as the brand, which must stay human
- 02Makers shipping themselves at different rates
- 03Payouts that must be exactly right
- 04Refunds that unwind across several vendors
Process
We modelled the money before the storefront
Marketplaces that build the shop first end up rebuilding it when settlement arrives.
-
Settlement model
Commission, shipping attribution and refund handling modelled and validated against a year of historical orders.
-
Vendor onboarding
Built next, because vendor supply gates everything else in a marketplace.
-
Unified basket
Multi-vendor checkout built once settlement could account for it correctly.
-
Shipping
Per-vendor rates combined with customer-facing fairness tested against real basket compositions.
-
Pilot cohort
Launched with fifty makers and full manual verification of every payout before scaling.
Technology
Shopify with a marketplace layer
Commerce on Shopify, vendor and settlement logic purpose-built.
Commerce
- Shopify
- Storefront API
- Admin API
Marketplace
- Vendor onboarding
- Catalogue import
- Curation workflow
Settlement
- Per-line commission
- Payout scheduling
- Statements
Fulfilment
- Per-vendor shipping
- Split dispatch
- Unified tracking
Business impact
What changed for the marketplace
Three outcomes in the first year.
-
340 makers onboarded
Because onboarding stopped being the team's job.
-
2.1 vendors per order
Customers buying across makers, which the old model made impossible.
-
Settlement stopped being work
Computed per line, settled on schedule, with no spreadsheet.
The result
Customers buy across makers, makers get paid correctly
340 makers onboarded in the first year, with an average of 2.1 vendors per order — customers are genuinely shopping across the marketplace rather than from one maker at a time.
Nobody calculates a payout. Settlement runs per line, and each maker gets a statement they can check.
- 340 makers onboarded in year one
- 2.1 vendors per order on average
- Zero manual payout calculations
- Curation still human, and not a bottleneck
What we hold to in marketplace builds
- 01Model settlement before you model the storefront
- 02Settle at line level or partial refunds will break you
- 03Vendor onboarding must not consume the team
- 04Give vendors a statement, not a net figure
Free discovery call
Have an idea? Let's turn it into AI-powered software.
Book a free discovery call with our experts. Share your idea and we will help you shape the scope, timeline and budget, under NDA.
- Free consultation
- NDA before we talk
- Transparent estimate