White Label Marketplace Software Features: What Ships in the Build
A product page is the easy screen. The difficult work sits behind it: one basket split across several sellers, stock counted per variant, four balances that must tie back to one ledger, cash counted at a doorstep, and a refund that unwinds every step. This is the platform underneath the marketplace clones, laid out by the person who touches each part.
Request a Live Demo →See PricingRoles and Their Tools
Sorted by who uses it every day: the buyer shopping, the seller listing and collecting earnings, and the rider who finishes the job at the customer's door.
Buyer
- Autocomplete search with price, brand, rating and seller filters
- Rails for featured, best-selling and top-rated stock
- A daily deal, timed flash offers and a clearance storefront
- A single basket holding goods from many sellers
- Guest basket kept by session, merged into the account at login
- Coupon, wallet balance and loyalty points on one order
- Each refund request arrives with a reason and supporting evidence
- Restock alerts, referral codes and reviews with photos
Seller
- Shop registration with KYC, then operator approval
- Products with a color, size and custom-attribute matrix
- Price and quantity held on every SKU row
- Low-stock alerts once a threshold is crossed
- Bulk import and export of the catalog
- AI-drafted descriptions, SEO copy and image alt text
- Order queue with accept, reject and refund replies
- Sales analytics, wallet and withdrawal requests
Rider
- A verified account of their own, approved by the operator
- Job feed where each assignment is accepted or declined
- Map directions to the seller, then on to the buyer
- Position broadcast while the parcel is moving
- Pickup and drop checkpoints along the route
- Single-use code checked at the doorstep
- Cash taken on delivery held against the rider's balance
- Earnings view with its own payout request flow
A rider here is a full account with KYC, a wallet and an approval status, and not a tick-box on a buyer profile. Only that structure lets cash taken at a door be counted back to a named person.
Rental Platform, One-Time Script or the Miracuves Platform
Three ways to hold a marketplace, set against the features that decide whether it survives its first busy season. Rented and script columns describe patterns, not any single product.
| Feature | Rented or hosted platform | One-time script | Miracuves platform |
|---|---|---|---|
| Multi-seller catalog | Usually included, within plan limits | Often a single-seller storefront with an add-on | Variant matrix, SKU-level stock, categories nested to any depth |
| One basket, many sellers | Commonly supported | Varies by script | Yes, split into one order per seller, shipping estimated per seller |
| Your own delivery fleet | Often left to third-party couriers | Frequently absent | Rider accounts, job feed, live position, one-time-code handover |
| Cash on delivery | Depends on the vendor's regions | Often treated as a plain payment type | Per-rider balance, settled to the operator wallet in its own table |
| Separate wallets | Usually internal to the vendor | Frequently one balance column | Buyer, seller, rider and operator wallets, each with append-only history |
| Commission control | Commonly a plan-level rate | Often one flat rate | Global, per category, per seller or per product, reversed on refund |
| Where the source lives | With the vendor | With you, though some vendors withhold it from every tier | In your repository: the Laravel backend and all three Flutter projects |
| Mobile apps | Depends on the plan | Budget tiers commonly come with web-view apps, not native apps | Three Flutter Android builds; iOS is quoted separately |
| Payment methods | The vendor's supported list | Typically a handful of gateways | Eleven gateways, offline methods and cash on delivery |
| How you pay | A recurring fee that stops the service if unpaid | A one-time purchase, usually well under the platform price | $2,799 once, with hosting and provider fees held on your own accounts |
Read the last row as a difference in shape, not in total. A rented plan often bundles hosting, a CDN and licensing into the monthly fee, whereas here those are separate bills you contract directly. Neither is cheaper by default. The mobile row is worth a look too: three Android builds are inside the price, and iOS compilation, signing and store submission are a separate scope.
One Order From Search to Settlement
Follow a single purchase across every surface, all the way to the doorstep and the ledger behind it.
Find something and fill the basket
The buyer types into a search box that completes as they go, narrows by price, brand, rating or seller, and browses rails for featured, popular and clearance stock. One basket can hold items from several sellers. Delivery is estimated seller by seller before payment, and a guest's basket survives until they sign in.
Pay the way the market pays
A single total can be reduced by a coupon, wallet credit and loyalty points together. The payment then goes through any of eleven gateways, an offline method you define, or cash at the door, and every route ends in the same order record. An idempotency check means a nervous second tap does not create a duplicate.
Divide, accept and dispatch
The order divides by seller and stock drops at the variant level. Each seller accepts or declines their share, and each line keeps its own delivery status, so a partly fulfilled order tells the truth. A rider takes the job from the feed, collects from the seller and drives to the buyer while position updates stream in.
Prove the handover
The rider does not simply tap "delivered". At the door, the buyer's one-time code gets verified. If cash changes hands, that amount is booked to the rider's own balance in a dedicated table, apart from card and gateway money.
Refund or release
When the order completes, your commission comes out of the seller's wallet. If it is refunded later, that commission and any loyalty points reverse on their own. Rider cash reconciles to the operator wallet at settlement, and each movement leaves an append-only row so any balance can be rebuilt from history.
Test step five hardest in any product you are shortlisting. A refund that returns the buyer's money yet leaves commission untouched produces a balance nobody can explain, and it surfaces at year end rather than at launch.
Why Each Feature Made the List
None of these is here for the demo. Every one is in the build because omitting it causes a specific, costly failure later.
| Feature | The failure it prevents |
|---|---|
| Four wallets, not one | A buyer refund, a seller payout, a rider's cash and your commission are four separate obligations. One balance column cannot say who is owed what. |
| History that can only be appended | A figure nobody can trace is a figure nobody can defend. Each movement adds a row, so a total can always be rebuilt from the trail. |
| Cash in a table of its own | Filing doorstep cash as a normal payment hides the space between money in a rider's pocket and money in your account. |
| One-time code at handover | "Marked delivered" proves nothing, and a disputed cash order is the costliest kind to argue. |
| Idempotent order placement | A tap repeated on a weak connection must not bill twice or hold stock twice. |
| Status per order line | Parcels from three sellers will not land together. A single status for the whole order would make the tracking page inaccurate. |
| Commission reversed on refund | Returning the buyer's money while keeping your cut sets up a dispute with the seller. |
| Field-level edit history | When a price or status changes, someone will ask who did it and when. The log already has the answer. |
| Zip allowlists | Offering checkout in places you cannot reach turns a sale into a refund and a poor review. |
The Engineering Under the Feature List
Nothing unusual was selected, on purpose. The backend runs PHP 8.2 and Laravel 12, laid out as models, repositories, services and controllers, with database transactions started in the service layer. About 114 Eloquent models rest on a MySQL schema of 131 tables, while AI, Blog and Tax are modules that can be turned off without touching core code. Notifications and ledger writes go through events and listeners, and the REST API comes in three versions serving every client. The mobile side has three Flutter apps built on one shared architecture, with role-bearing bearer tokens for authentication, Firebase push, and Google Maps inside the rider app. Storage is MySQL 8 and Redis 7, with indexes picked for the busiest queries, soft deletes on products and people, and wallet histories that only ever grow by appending.
Whoever maintains the platform after handover will most likely know these tools already. That was the intention.
Exclusions From the Base Package
Everything shown above ships in the base build and can be opened in the demo. The items below do not, and the hub marks them as configuration-required or integration-required instead of leaving them implied.
Your accounts, your data, your call
- A hosted tenancyWhite label here means a handover of the source, not a reskin rented by the month on someone else's servers.
- iOS applicationsAndroid builds are included. iOS compilation, signing and App Store submission are a separate scope, quoted on request.
- Payment processor accountsEleven gateways are integrated, but every one runs on merchant credentials that you open and hold.
- SMS, email and push servicesIntegration-required. You supply the provider accounts and the Firebase project.
- The OpenAI account keyThe AI module drafts copy against your own key, within per-feature token quotas.
- Catalog, sellers and tax ratesProduct data, seller recruitment and the tax rates for your jurisdictions belong to your business.
- ISO 27001 and SOC 2 position of the platformNeither certificate is held or claimed. The controls exist and the platform is ready for penetration testing and evidence gathering.
- The larger extensionsExternal search, deeper analytics, ERP bridges, paid memberships, wholesale pricing, a sponsored-placement engine and observability tooling are all quoted after scoping.
Exchange rates are typed in by the operator and are not pulled from a live feed. That is deliberate, because a catalog that silently reprices itself catches sellers and buyers off guard together.
Weigh Miracuves against rented platforms, script vendors and agencies
The questions to put to every bidder, the delivery days in order, and two illustrative deployment scenarios, all on the Provider page.
Short Answers
What actually carries my brand?
Is this a hosted tenancy on your platform?
How does the delivery side work?
Which payment gateways are built in?
Do the mobile apps cover iOS?
What does the AI module do?
Open every surface before you decide
Ask for a live walk through the storefront, seller panel, rider app and operator console, or go straight to the price.
Browse White Label Marketplace Software
Ready for a marketplace that runs its own last mile?
Storefront, seller panel, rider app and operator console go live in 6 days, with the full source in a repository you own.
Talk to Us →Miracuves is an independent software development company. We are not affiliated with, connected to, sponsored by, or endorsed by Amazon, Flipkart, Walmart, Etsy, Myntra, Noon or Fancy, or any other marketplace operator.
“White label marketplace software” describes a category of product, not any one company. Brand names appear elsewhere on this site only to describe the kind of platform being built and the terms buyers search for.
The entire design and codebase is built by our own team. The product contains no code, design, graphics, or content originating from any third-party marketplace website or application.
All third-party names and marks are the property of their respective owners, referenced here solely to describe the category of software offered.
