Multi vendor marketplace development built around the money flows
Building the software is the part everybody plans for. Getting sellers to show up, moving other people's money safely and settling disputes fairly are the parts that decide whether the platform survives its first year.
What is marketplace development?
Marketplace Development is building a multi vendor platform where independent sellers list, transact and get paid: vendor onboarding, commission rules, split payments, payout scheduling, ratings and dispute handling. It suits Australian operators connecting supply and demand in a defined category, where the platform earns a fee rather than holding stock itself.
Get a fixed written quote- Typical timeline
- 14 to 26 weeks
- What drives cost
- How many sides the marketplace serves, how complex the payout and commission rules are, and what verification the launch needs.
- Best for
- Operators with a credible route to supply, not only an idea
- You own
- The platform, the source code and the vendor and buyer data
- Built with
- Multi vendor architecture, split payments, escrow style holds, payout automation
Your handover
The software is the easy part
Every marketplace has the same opening problem. Buyers will not come to a platform with fifty listings, and sellers will not maintain listings on a platform with no buyers. Software does not solve that. Supply usually has to be manufactured by hand, one relationship at a time, before the product is worth building at scale.
- 01Vendor onboarding with verification and agreement acceptance
- 02Listing and catalogue management for sellers
- 03Search, discovery and category structure
- 04Commission engine with configurable rules
- 05Split payments, held funds and payout automation
- 06Dispute, refund and chargeback workflows
- Ratings, reviews and moderation tooling
- Administration console with financial reporting
- Vendor and buyer analytics dashboards
More on the software is the easy part
So the first question we ask a founder is not what features they want. It is whether they can name twenty sellers who will list on day one, and what those sellers are doing today instead. If the answer is a spreadsheet and a phone, you have a real business to improve. If the answer is that nobody has been asked yet, the honest advice is to spend six weeks and very little money finding out before committing to a fourteen to twenty six week build. We have talked several people out of starting, and none of them regretted it.
Match the model to how the category already behaves rather than to how you would prefer it behaved.
How money moves through an Australian marketplace
This is where marketplace development stops resembling a normal store build. A single checkout may need to split across several vendors, hold funds until delivery is confirmed, release a payout on a schedule, reverse a commission when a refund is issued and handle a chargeback that arrives weeks later. Each of those states has to exist in your data model from the beginning, because retrofitting them is close to a rebuild.
The rest of the answer
There are Australian specifics that shape the design. Vendors need identity and bank verification before they can be paid, and collecting an ABN at onboarding matters for how invoicing works. Whether your platform sells as principal or acts as an agent for the seller affects who issues the tax invoice and how GST is treated, which is a question for your accountant and not for us, but the answer changes what we build. We design the ledger so every cent is traceable from the buyer's card to the vendor's account, because the first time a seller queries a payout you will want an answer within minutes rather than a reconciliation project.
How the engagement runs
How we sequence a marketplace build
Marketplace development works in one order: the transaction loop before anything decorative. A platform that can list, discover, transact, fulfil, pay out and review is a business. A platform with beautiful vendor profiles and no payout logic is a directory with ambitions.
- 01Stage 1Prove demand manually first, even if that means matching buyers and sellers by phone for a month
- 02Define the transactionWhat is bought, who sets the price, who carries the risk and when money is released
- 03Design vendor onboardingVerification, banking details, agreement acceptance and the minimum a listing must contain
- 04Build the core loopList, discover, transact, fulfil, pay out, review
- 05Wire paymentsSplit settlement, held funds, refunds, chargebacks and payout scheduling
- 06Add trust and safetyVerification signals, reporting, dispute queues and the admin console
- 07Stage 7Launch in one category or one city, measure liquidity honestly, then expand deliberately
Two decisions on your side that keep the project moving
Launching narrow is the other discipline that matters. One category, or one city, gives you enough density that a buyer arriving finds real choice. Spreading the same number of sellers across eleven categories produces eleven empty shops. We would rather ship a working slice in month four and expand from evidence than deliver everything in month nine and discover the model needs changing.
Choose the right level
Which marketplace model actually fits your category
The revenue model is not a pricing decision made at the end. It determines what the platform must do, what data it must hold and where the operational cost lands, so we settle it during discovery.
Model
01
Commission on transaction
How it earns
A share of each completed sale processed on platform
Watch for
Buyers and sellers taking the relationship offline once trust exists
02
Listing or subscription fee
How it earns
Predictable revenue independent of transaction volume
Watch for
Sellers churning fast whenever buyer demand thins out
03
Lead fee or directory
How it earns
Buyers enquire and you charge for the introduction
Watch for
Arguments about lead quality and attribution that consume support time
04
Managed marketplace
How it earns
You control fulfilment, quality and service, and charge accordingly
Watch for
Operating cost closer to running a retailer than a platform
05
B2B procurement platform
How it earns
Supplier fees or a platform licence paid by the buying organisation
Watch for
Long sales cycles and integration work with buyer side systems
How we work this out during scoping
The commonest mistake is choosing commission because that is what the well known marketplaces do, in a category where the transaction happens offline and nobody will process payment through your platform. If you cannot see the money, you cannot charge a percentage of it, and every enforcement mechanism you invent will annoy the sellers you need. Match the model to how the category already behaves rather than to how you would prefer it behaved.
Trust, safety and the disputes that decide your reputation
A marketplace is a promise that a stranger will do what they said. Everything that supports that promise is product work: verification at onboarding, ratings that cannot be manufactured, clear cancellation rules, a refund path that works without an email thread, and a moderation console your team can operate at speed.
The full list
Disputes deserve particular attention because they are where goodwill is won or lost, and because your obligations under Australian Consumer Law depend on the role your platform plays in the transaction. We build the mechanisms, you and your legal adviser set the policy. In practice that means defined dispute states with timers, an evidence trail neither party can edit after the fact, partial refund handling that reverses commission correctly, and reporting that shows which vendors generate a disproportionate share of problems before those vendors damage your brand.
- Identity, ABN and bank account verification before a vendor can transact
- Written vendor agreement accepted in product and versioned so you can prove what was agreed
- Ratings tied to completed transactions rather than open submission
- A dispute queue with defined states, timers and an evidence trail
- Refund and partial refund handling that reverses commission correctly
- An internal console for moderation, payouts and vendor support
When a marketplace is the wrong shape for the problem
Plenty of projects that arrive described as a marketplace are something simpler and cheaper. If you control the supply, you do not have a marketplace, you have a store with several warehouses, and a commerce build will get you trading months earlier. If the platform exists so approved suppliers can quote, invoice and track deliveries against your purchase orders, that is a supplier portal and it does not need payments infrastructure at all.
The rest of the answer
If you plan to charge sellers a monthly fee for software rather than take a slice of transactions, you are building software as a service and the roadmap looks different, so read our SaaS work first. And if the real value is connecting your platform to systems other businesses already run, the centre of gravity is the API rather than the interface. We would rather name the thing correctly at the start than deliver marketplace machinery you never switch on. Two categories where this comes up constantly are property and professional services, where a directory with good booking flow usually beats a full transactional platform.
How we scope it
Four ways to scope your Marketplace Development project
We do not publish package prices, because the same brief can be a short build or a long one. These are the shapes the work usually takes. Tell us which one sounds like you and you will get a fixed written quote that spells out exactly what it covers.
Store launch
A first real store, set up for Australian selling
Fixed written quote, agreed before work starts
- Vendor onboarding with verification and agreement acceptance
- Listing and catalogue management for sellers
- Search, discovery and category structure
Store growth
A store with catalogue, integration or margin problems to solve
Fixed written quote, agreed before work starts
- Everything in Store launch
- Commission engine with configurable rules
- Split payments, held funds and payout automation
- Dispute, refund and chargeback workflows
Commerce platform
Multi store, multi channel or a custom commerce build
Fixed written quote, agreed before work starts
- Everything in Store growth
- Ratings, reviews and moderation tooling
- Administration console with financial reporting
- Vendor and buyer analytics dashboards
Marketplace Store care
Merchandising, speed and conversion, month to month
Rolling monthly, quoted in writing
- Hosting, patching, backups and uptime monitoring
- Merchandising, campaign and catalogue changes
- Checkout and payment paths tested after every update
- Rolling, cancel with 30 days notice
These are shapes, not menus. Most quotes end up somewhere between two of them, and we will say so when the honest answer is the smallest one. Describe the problem and we will tell you which it is.
Questions buyers usually ask
Frequently asked questions
Scope and timeline
What is a realistic timeline to the first live transaction?
For a focused first release, 14 to 26 weeks. The transaction loop and payments account for most of it, and payment provider onboarding and verification can add several weeks of waiting that no amount of development speed removes. Marketplaces that try to launch every category and every feature at once take considerably longer and usually learn less for the money.
Can we start smaller than a full marketplace?
Almost always, and we usually recommend it. A single category, manual vendor approval, weekly payouts run by a human and no automated dispute engine is a legitimate first version. It tests whether the model works while you still have budget to change direction. Automation is then added where volume proves the manual step has become the bottleneck.
Cost and quoting
Why do marketplace quotes vary so wildly between agencies?
Because the word covers everything from a directory with a contact form to a platform moving money between thousands of parties. Payment complexity, verification requirements, dispute handling and admin tooling are where the effort really sits, and cheap quotes frequently omit all four. We scope those explicitly and put them in a fixed written quote so you can compare like with like.
Who holds the money between purchase and payout?
Your payment provider does, under arrangements you enter into directly. We design the platform so funds are held against a defined release condition, such as delivery confirmation or a cooling off window, and so every movement is recorded in a ledger you can audit. Handling other people's money brings obligations, so we build to what your provider and your adviser require.
Detail and edge cases
Do we own the vendor and buyer data?
Yes. The application code, the database and every service account sit with your entity. Because you will hold personal information about both sides of the market, we build to the Australian Privacy Principles from the start: role-based access, retention rules, an export path for individuals who ask, and logging so you can answer questions about who saw what.
How do we get the first hundred sellers on board?
Manually, and that is not a failure of the product. Early sellers join because a person convinced them, so we build onboarding that a member of your team can complete on a vendor's behalf during a phone call, along with bulk import for anyone arriving with an existing catalogue. self-service onboarding matters later, once demand does the persuading for you.
Related services
Tell us about the two sides of your market
Who supplies, who buys, and what they do today instead. We reply within one business day with an honest view of the model and a fixed written quote for a first release.