How an agricultural marketplace serves 30,000+ farms on Mercur

Challenge

Agricultural trade runs on trust between parties who have often never met. A buyer sends money for a crop they have not inspected, and a seller ships produce before the payment clears.

Certification carries the same weight. A buyer paying a premium for protected-origin produce needs the claim to hold, and the claim has to travel with the listing.

Both sides also trade as businesses. A farm has employees who buy and employees who sell, and approvals sit between them.

4 things a standard commerce platform couldn't do

1. Holding a payment until delivery conditions are met

A commerce platform charges the buyer and credits the seller in one step. Escrow splits that into a sequence that stays open for days.

Funds are held from the moment of payment until both sides agree the terms are met. The order status and the payment status have to change together, with a record at every step. A dispute or a partial delivery sends the transaction down its own path, and holding funds brings financial and KYC compliance requirements with it.

2. Letting a farming business act as one account with many people

A standard marketplace account belongs to a person. A farm trades as a company, with procurement and sales handled by different employees.

That calls for roles with scoped permissions inside one organization, and a boundary that keeps one organization from reading another's orders or prices.

3. Selling at a price the two sides negotiate

Catalogue commerce assumes the price is set before the buyer arrives. Agricultural trade often settles it per deal, in conversation between the two sides.

A buyer has to be able to request a quotation, a seller to answer with their own figure, and both to keep talking until they agree. The agreed amount then carries into the order itself.

4. Proving a product is what the listing claims

The premium on certified produce depends on buyers being able to verify the certification. A listing has to show its traceability identifier and protected-origin status, and the origin behind them has to be verified.

A claim typed into a free-text description cannot be validated, and it reads differently on every listing.

Why Mercur

The marketplace layer came with the platform

Starting from an empty repository would have meant building the seller model, the catalogue, the order flow, and the commission engine before any agricultural logic could begin.

Those parts came with the platform, so development time went into the escrow engine, the organization model, sales channel management, the quotation workflow, and certification on listings.

The operator owns the platform

There are no licence fees, and no share of any settled deal goes to a platform vendor. A commission on each deal would grow with every tonne traded. Here the licence cost stays at zero at any volume.

Owning the platform also removes lock-in to a single vendor.

Industry logic is added as extensions on the core

Escrow, organizations, sales channels, certification, and quotations are extensions on top of the Mercur core. Each holds its own data model and reaches the marketplace through the engine's own interfaces. No engine code was changed to add them, so the marketplace takes new Mercur versions without redoing the custom work, and new capabilities arrive without rebuilding the underlying system.

One core behind several storefronts

The same core carries several sales channels, and end customers manage their own storefronts. Each new storefront reuses the vendor model and commission rules already in place, and its own sales channel controls which products it shows.

How Mercur was used

Multi-vendor logic

Each farm or supplier sells as its own vendor, with its own listings. A buyer browsing a category sees produce from several vendors in one catalogue.

Commission management

Mercur calculates the marketplace's commission on each vendor's orders. Without it, every vendor's commission would have to be worked out outside the system.

Cart and checkout

One cart can hold produce from several vendors, and the buyer checks out once. The escrow logic extends this flow with additional order statuses.

Customers

Customer accounts and order history come with the platform, so a buyer can return to what they have ordered.

Products and inventory

Products carry their own stock levels, so each listing reflects the products a vendor has available.

Price lists

Price lists hold prices separately from the product, so a vendor can set special prices for a group of buyers or a period without editing every listing.

Discounts

Discounts and promotion codes are available from the start, so the operator can run a campaign without a developer.

Vendor and customer messaging

Buyers and vendors message each other inside the platform. The same messaging carries the negotiation in the RFQ engine.

Vendor onboarding

Suppliers register and set up their own selling profile. Supply arrives one business at a time, and onboarding that needed a staff member for each of them would cap how large the seller base can get.

Admin panel

Vendor management, product management, order management, and commission management are available in the panel from the start. The operator runs the marketplace from one place, and none of that panel was built for this project.

Vendor panel

Each vendor manages its own products, orders, and shipping in a dedicated panel. Product data can be imported and exported, so a farm with many listings can load them without entering each one by hand. The operator does not enter products or process orders on their behalf.

Storefront

Mercur provides the storefront for buyers with category pages, search and filtering, product pages, cart, and vendor profiles. The marketplace was opened to buyers without a storefront being designed from scratch, thanks to Mercur's B2C marketplace storefront template.

How Mercur was customized

Escrow transaction management system

The platform holds the buyer's payment in escrow and pays the seller after delivery. Each step of an order decides what happens to the money.

1. When the buyer pays, the money goes into escrow.
2. When the seller ships, the order becomes ready for payout.
3. When the buyer confirms delivery, or the order is marked as fulfilled, the money is paid out to the seller.
4. If a dispute is opened, the money stays in escrow until the dispute is settled.

The platform and the escrow provider always show the same status for an order, and a change on one side is passed to the other. If a notification from the escrow provider does not arrive, the platform asks for it again.

Safeguards stop an order from showing as complete while the money is still held. Without them, someone would have to compare orders and payments manually.

Multi-organization governance system

Farming businesses operate as organizations. Role-based access control inside each organization gives staff in roles such as procurement and sales their own permissions, and a farm adds its employees through invitations and joining workflows.

The data of each organization is kept apart at the boundary, so a farm sees only its own orders and prices.

Sales channel management extension

Mercur's sales channels are extended so that each organization is tied to its own channel. The channel controls which products the organization sees, which keeps segments of the marketplace apart and lets the operator address each segment separately.

RFQ and negotiation engine

Buyers submit requests for quotation (RFQ), and sellers answer with their own pricing. Negotiation runs through the platform's vendor and customer messaging, and the history of what was offered stays attached to it.

An accepted quotation converts into a finalized order, with the agreed amount carried through to the order record. The negotiation and the order it ends in sit in one place.

Certification and traceability layer

Each listing shows its GS1 traceability identifier and Geographical Indication (GI) status, and the product's origin is verified. A buyer checks authenticity and supply-chain provenance on the listing itself.

This supports compliance with the agricultural certification frameworks the marketplace trades under.

What Mercur integrates with

• TradeSafe – South African escrow provider that holds funds between buyer and seller, with conditional release and dispute handling, synchronized with order state in both directions.
• Odoo – ERP system behind vendor onboarding and the synchronization of organizational data between systems.
• Railway – hosts the backend services and handles their deployment and scaling.
• Vercel – hosts the frontend application, with edge delivery and CI/CD.
• Resend – transactional email, from order notifications to escrow status updates.

Results

The marketplace has a stable foundation to serve a growing network of 30,000+ farms without disruption. Listings, negotiation, payment, and farm accounts run in one system, and the operator controls transactions and listings centrally.

Deals where delivery, logistics, or product checks happen before the final payment carry less risk for both sides, because the buyer's payment is held in escrow until the delivery conditions are met.

The operator can add new agricultural categories and further certification standards faster and at lower cost than on a SaaS marketplace platform, where workflows are limited to predefined patterns. Each addition is a module on top of the Mercur core, so the core does not have to be rebuilt.

The operator also receives Mercur updates without redoing its own work. Each agricultural module holds its own data model, so a release that improves the commerce layer leaves the modules on top as they are.

Implemented by Rigby.