Noon Clone Features: One Catalog, Several Markets
Selling into a second state multiplies the things that have to agree. The same product needs a price in another currency, a VAT treatment that differs, a delivery promise that only holds for some destinations, and a settlement path for a buyer who pays cash at the door days later. All four are modelled in the schema here rather than left to operator discipline. Here is what ships, grouped by who touches it.
Request a Live Demo →See PricingFeature Set by Role
Six surfaces run against one REST API, so the grouping that matters is not web against mobile - it is who is holding the screen. Four identities, four sets of permissions, four wallets.
Customer
- Prices quoted in the currency of their own market
- Category tree of unlimited depth, brand directory, autocomplete search
- Product pages carrying the variant matrix and photo reviews
- One cart spanning several sellers at once
- Guest cart tracked by session and merged on login
- Coupon, wallet credit and loyalty points stacked on one order
- Tax shown inclusive or exclusive per market, itemized on the invoice
- Return opened with a reason and evidence, refunded to wallet or gateway
Seller
- Registers with KYC, approved and suspendable by an operator
- Product CRUD with the variant matrix, stock and bulk import
- Per-locale content on a listing, not one shared description
- AI-assisted descriptions, SEO titles and image alt text
- Order queue with accept and reject, plus refund responses
- Commission visible on the wallet, not reconciled after the fact
- Sales analytics and a withdrawal request flow
- Web panel or Android app against the same API
Delivery Agent
- First-class identity with KYC, approval and zone assignment
- Assignment feed with accept and reject
- Navigation to the seller for pickup, then to the buyer
- Live location broadcast while in transit
- One-time code verified at the door before handover
- Earnings held separately from cash collected
- Cash balance carried per agent, settled to the operator
- Payout request flow from the app
Operator
- Currencies, tax zones, delivery countries and languages in one tab
- Catalog moderation queue with approve, reject and bulk actions
- Cross-seller orders with a full status timeline
- Refund, payout and withdrawal queues
- Agent cash settled against the operator wallet
- Commission set globally, per category, per seller or per product
- Every module behind its own permission
- Reports over any date range, exported to Excel, CSV or PDF
The operator console is treated as a role rather than an afterthought because running several markets from one deployment makes the configuration surface as busy as the daily queues. A new state is opened from a settings tab, not from a migration.
Noon vs Miracuves Clone vs Building From Scratch
The same capability, three different paths. The rows that separate them are all multi-market rows - the places where a single-country commerce script quietly assumes there is only one answer.
| Capability | Original Noon | Miracuves Clone | Single-market commerce script |
|---|---|---|---|
| Currency per market | Yes, several GCC states | A currency catalog with operator-set rates; the default drives what each buyer is quoted at checkout | One base currency, display conversion at best |
| VAT that differs by state | Yes, handled centrally | Tax classes bound per zone with per-product rules through a polymorphic binding, inclusive or exclusive per market | One tax rate, or a plugin bolted on later |
| Where you can actually ship | Yes, mature logistics | Delivery country codes and zip allowlists deciding whether checkout is offered at all, plus per-category shipping overrides | Flat shipping zones, no serviceability gate |
| Catalog in more than one language | Yes, Arabic and English | Entity-level translation, so a listing carries its own content per locale rather than one shared description | Interface strings translated, catalog not |
| Cash on delivery | Yes, in several markets | A settlement path: code verified at handover, cash balance per agent, operator-set handling fee, reconciliation to the operator wallet | A payment method flag with no accounting behind it |
| Money held per actor | Internal | Four wallets - buyer, seller, agent, operator - each with an append-only history written inside the same transaction as the balance move | One balance field, updated in place |
| Delivery fleet | Own and partner fleets | Agent identity with KYC, approval, zone assignment, assignment feed, live location and verified handover | Usually absent, or a courier webhook |
| Source code | Not available | Complete Laravel 12 backend and all three Flutter projects, unobfuscated, no licence callback | Often encrypted files or a licence check |
| Time to live | Not applicable | Six working days, markets configured with you at deployment | Weeks, then months on the multi-market gaps |
The last four rows are the ones that decide a rebuild. A script that treats currency as a display filter and tax as a single percentage will carry your first market perfectly well and then quietly fail your second.
How It Works, End to End
One order, traced across four identities and two currencies, with every state change and every wallet movement written down.
The market decides what is possible
Before a price is shown, the buyer market sets three things: which currency the catalog is quoted in, which tax class applies to each line, and whether the destination zip is served at all. A zip outside the allowlist does not get a shipping quote and a checkout to abandon - it does not get a checkout.
The cart spans several sellers
One cart can hold items from several sellers at once, each with its own shipping estimated before checkout. A guest cart is tracked by session and merged into the account on login, so the basket built before signing in is not lost.
Checkout stacks the discounts and applies the zone
A coupon, wallet credit and loyalty points can all apply to the same order. Tax comes from the zone rules with per-product overrides, and it is displayed inclusive or exclusive according to the market. Placement is guarded by an idempotency check, so a double submit does not become two orders.
The seller works a queue, not an inbox
The order lands in a seller queue with accept and reject, from either the web panel or the Android app. Stock moves, commission is visible on the seller wallet from the outset, and a rejection walks its own path rather than being handled by email.
The agent carries the parcel and, often, the cash
An assignment appears in the agent feed with accept and reject. Navigation runs to the seller for pickup, then to the buyer. Location broadcasts while in transit, checkpoints record picked up through to delivered, and a one-time code is verified at the door before the parcel changes hands.
Four balances move, and each move is written down
On completion the commission splits, the seller balance credits, the agent earning credits, and on a cash order the collected amount lands on the agent cash balance rather than being mixed with earnings. Every one of those movements pairs with an append-only history row written in the same database transaction, so any balance can be re-derived rather than trusted.
Settlement closes the loop
The agent settles collected cash against the operator wallet. Seller and agent payout requests queue for approval, denial or mark-processed. Settlement records are held per gateway and per currency, which is what makes a second market reconcilable rather than merely functional.
Nine order statuses carry an order from pending payment through to delivered, with cancelled, returned and failed ending it. Every move is stamped into a status history with the actor, a note and a timestamp, and any operator edit leaves a field-level record.
Every Feature Earns Its Place
Feature lists are cheap. These are the ones that exist because a specific thing goes wrong in a multi-market marketplace without them.
| Capability | Why it is not optional |
|---|---|
| Operator-set exchange rates | Rates are set by the operator rather than pulled from a live feed. A feed that moves overnight reprices a whole catalog without anyone deciding to, and both sellers and buyers find out at checkout. A dirham price and a riyal price are both meant to be deliberate. |
| Polymorphic tax binding | Tax classes bind per zone, and a per-product rule can override the class. That is what lets five percent in one state and fifteen in another be a configuration change rather than two deployments - and what puts a defensible tax line on every invoice. |
| Zip allowlists ahead of checkout | Serviceability is decided before a checkout is offered, not after the order is taken. The alternative is an order you accept and then cancel, which costs you the customer and the seller their committed stock. |
| Per-category shipping overrides | A cross-border route and a dense city route do not cost the same to serve, and a single flat rate makes one of them subsidise the other. Shipping methods carry per-category cost overrides so both can be priced honestly. |
| Entity-level translation | A listing carries its own content per locale rather than sharing one description across markets. Interface translation is table stakes; catalog translation is what decides whether the second market converts. |
| Cash separated from earnings | An agent wallet keeps money earned apart from money collected. Merge them and the first reconciliation gap is unrecoverable, because there is no longer a record of which was which. |
| Idempotency on order placement | A guarded placement means a slow network and an impatient tap do not become two orders, two commission splits and one very awkward refund conversation. |
| Field-level edit history | When an operator changes an expected delivery date or overrides a status, the change is recorded with the actor and a reason. Weeks later, when a dispute lands, that record is the difference between a defensible position and a guess. |
| Settlement per gateway and per currency | Settlement records are held per gateway and per currency rather than pooled. Pooling works until the day a payout in one currency has to be traced against takings in another. |
None of these are exotic. They are the nine places where a marketplace that was only ever going to serve one country stops being extendable.
The Technology Behind the Features
Deliberately ordinary choices, because the developers who maintain this after handover should already know all of it.
Why the schema size is the number that matters
A hundred and thirty-one tables is not a boast, it is a consequence. Currencies, tax classes, zone bindings, delivery country codes, zip allowlists, translation entries, four wallet histories, nine order statuses with a status history and a field-level edit log all need somewhere to live. A marketplace that models the same business in forty tables has made four of those someone else's problem.
Everything above transfers into your repository. There are no encrypted files and no licence callback of any kind.
What Is Not Included in the Base Package
Everything above is in the base build and demonstrable in the live demo. These are not, and the hub labels them configuration-required or integration-required rather than implying them away.
Yours to own, or scoped separately
- Right-to-left layoutNamed on the hub as a scoped customization, not implied anywhere as included. In a Gulf-market platform this is the caveat worth reading twice - budget it explicitly rather than discovering it in week two.
- iOS applicationsThree Android builds ship. The Flutter projects compile for iOS, quoted as an add-on with signing and store submission.
- Additional markets beyond the ones configured at deploymentYour markets are set up with you during the six days. Further states, VAT export and processor-side verification are scoped and quoted separately, typically two to eight weeks.
- Gateway credentialsEleven gateways are integrated; each needs your own merchant account and its own approval in each market you take payments in.
- SMS and email providerIntegration-required - your accounts, your sender reputation, your deliverability.
- Firebase projectPush notifications across all three Android apps run through your own Firebase project.
- OpenAI keyThe AI module generates descriptions, SEO copy and alt text against your key, with per-feature token quotas and a log recording tokens and cost per call.
- Catalog data and translated copyThe translation store is ready and empty. Products, imagery, seller recruitment and the translated product copy are the business, and they are yours.
- VAT rates per stateTax classes bind per zone, but the rates for your jurisdictions are yours to set, and yours to keep current.
- ISO 27001 and SOC 2Neither certificate is held and neither is claimed. The platform is ready for the evidence gathering; the certification is a separate programme.
Exchange rates being operator-set is listed here as a design decision rather than a gap. A marketplace that silently reprices a catalog against a live feed surprises sellers and buyers at the same moment, and in a multi-currency book that surprise is expensive.
See how Miracuves compares to agencies and freelancers
The deployment process, two modelled reference deployments, and what to check on currency, tax and cash integrity before you hire anyone - on the Development Company page.
Frequently Asked Questions
Can one deployment really serve several countries?
How are exchange rates handled?
How does VAT work when it differs by state?
Is cash on delivery properly accounted for?
Is right-to-left layout included?
Are iOS apps included?
See a second market opened live, not described
Ask for the demo and we will add a currency, bind a tax zone and open a delivery country in front of you, then place an order through it.
Explore the Noon Clone
Ready to run several markets from one deployment?
Deploy in six days with the storefront, seller panel, delivery fleet and operator console included, your currencies, tax zones and delivery countries configured with you, and full Laravel 12 source on infrastructure you own.
Talk to Us →