Flipkart Clone Features: Cash, Serviceability and the Last Mile
Marketplaces built for card-first, metro-first markets do not fit the way a large part of India actually buys. Cash here is a full accounting path, serviceability is decided down to the zip, and the storefront reads in the buyer’s language. Here is what ships, grouped by who touches it.
Request a Live Demo →See PricingFeature Set by Role
Every capability grouped by who actually touches it - the customer buying, the vendor selling and getting paid, and the delivery agent closing the loop at the door.
Customer
- Keyword search with autocomplete, filters and sorting
- Featured, most-demanded and best-selling rails
- Deal of the day, time-boxed flash deals, clearance storefront
- One cart spanning several vendors at once
- Guest cart tracked by session and merged on login
- Coupon, wallet and loyalty applied together at checkout
- Refund request with reason and evidence
- Restock subscriptions, wallet, loyalty and referral
Vendor
- Register with KYC, approved by an operator
- Product CRUD with variants, stock and bulk import
- SKU-level rows with their own price and quantity
- Stock thresholds with low-stock alerts
- AI-assisted descriptions, SEO titles and alt text
- Order queue and refund responses
- Sales analytics and withdrawal requests
- Web panel or Android app, same data
Delivery Agent
- First-class identity with KYC and admin approval
- Assignment feed with accept and reject
- Navigation to vendor and to customer
- Live location broadcast and status checkpoints
- One-time-code verification at the door
- Cash collected written to their own balance
- Reconciled to the operator wallet on settlement
- Earnings view and withdrawal request flow
A delivery agent is an identity with its own KYC, wallet and approval state, not a flag on a customer account. That distinction is what makes cash reconciliation possible at all.
Flipkart vs Miracuves Clone vs Building From Scratch
The same capability, three different paths - and one row where a general commerce script simply has nothing to offer.
| Capability | Original Flipkart | Miracuves Clone | Generic commerce script |
|---|---|---|---|
| Cash on delivery | Yes, in many categories | A settlement path with its own accounting: OTP, agent float, handling fee, reconciliation | Where general commerce scripts quietly give up |
| Serviceability control | Postcode-level, built in-house | Delivery countries, zones and zip allowlists decide where checkout is offered at all | Usually a shipping-rate table, not a gate |
| Route economics | Optimised at enormous scale | Per-category shipping overrides so a city route and a rural one differ | One flat rate, then margin bleeds on the long routes |
| Tax by state and category | Yes | Tax classes bound per zone with per-product rates and a line on every invoice | A single tax rate, then an accounting problem |
| Regional language | Extensive | Per-entity translation across storefront, apps and console | Interface strings only, catalog left in English |
| Vendor onboarding | Seller portal | KYC, admin approval, own panel and Android app, per-vendor commission | A registration form and a spreadsheet |
| Money model | Internal | Four wallets - customer, vendor, agent, operator - append-only | One balance column and a reconciliation problem |
| Source ownership | N/A | Full Laravel 12 and all three Flutter projects, no licence callback | Full ownership (you are building it) |
| Price | N/A | $2,499 one-time | An 18 - 30 month programme with a senior team |
The iOS row is stated plainly because it is the thing buyers most often assume. Three Android builds are in the base price; the Flutter projects compile for iOS, and App Store builds, signing and submission are quoted separately because the review cycle and developer account are separate work.
How It Works, End to End
One cash order, followed from a serviceability check to reconciled money - the path a card-first platform never has to think about.
Is this address even serviceable?
Before anything else, the zip allowlist decides whether checkout is offered at this address at all. Delivery countries and zones sit above it, and per-category shipping overrides mean a dense city route and a town two hours out do not carry the same economics. Offering checkout where no route exists is how a sale becomes a refund and a wasted trip.
Order placed, stock and commission committed
One cart can span several vendors, so the order splits, stock decrements at SKU level and each line carries its own delivery status. Placement is guarded by an idempotency check. On a cash order, all of this is committed days before any money exists - which is precisely why the accounting has to be right.
The agent carries the float
A delivery agent is a first-class identity with KYC and approval, not a flag on an account. They take the job from an assignment feed, navigate to the vendor and then the buyer, and broadcast location through the checkpoints. Until settlement, whatever they collect is their balance, not yours.
OTP at the door, not a tap
A server-verified one-time code closes the handover. In a cash market this is the difference between a record and a claim, and it is the single most disputed moment in the whole order. The cash collected is written to that agent's balance and into a dedicated transaction table.
Reconciliation closes the loop
Cash settles from the agent balance into the operator wallet, with an operator-set handling fee covering the cost of collecting by hand. Commission is deducted from the vendor wallet on completion and reversed automatically on refund. Every movement writes an append-only row, so any figure can be re-derived.
Step five is the one to interrogate in any platform you evaluate. A refund that reverses the payment but not the commission, or cash that never reconciles, leaves a balance nobody can explain - and you will find it at year end, not at launch.
Every Feature Earns Its Place
Nothing here is on the list because it demos well. Each capability exists because leaving it out breaks something specific and expensive.
| Capability | Why it is not optional |
|---|---|
| Cash in its own transaction table | Because a cash order is not a payment that happened - it is a promise that closes days later, at a door, with stock and commission already committed. |
| A float carried per agent | Because until settlement the money is the agent's liability, not yours. Without a per-agent balance you cannot say who is holding what. |
| Server-verified code at handover | Because in a cash market “marked delivered” is the single most expensive unverified claim on the platform. |
| Operator-set handling fee | Because collecting notes by hand has a real cost, and recovering it should not mean quietly inflating the product price. |
| Zip allowlists | Because offering checkout where no route exists turns a sale into a refund, a bad review and a wasted agent trip. |
| Per-category shipping overrides | Because a dense city route and a town two hours away cannot carry the same delivery economics without one subsidising the other. |
| Tax classes bound per zone | Because rates differ by product category and by state, and every invoice needs the line to be right. |
| Per-entity translation | Because a buyer who does not shop in English converts badly against an English storefront, however good the catalog is. |
| Four separate wallets | Because customer refunds, vendor payouts, agent cash and your commission are four different liabilities on one order. |
The Technology Behind the Features
A conventional, hireable stack, deliberately: PHP 8.2 on Laravel 12 with nWidart modules, running controller to service to repository to model with transactions at the service boundary. That is 114 Eloquent models over 131 normalized MySQL tables, with modules for AI, Blog and Tax that enable and disable without touching core, and observers, events and listeners driving notifications and ledger writes. REST API v1, v2 and v3 serve every client. Mobile is Flutter with Dio and Provider over GetIt - customer, vendor and deliveryman builds from one shared architecture, Sanctum bearer tokens carrying role claims, Firebase Cloud Messaging per app and Google Maps in the deliveryman build. Data sits on MySQL 8.x and Redis 7.x with InnoDB and utf8mb4 throughout, soft deletes on customer, vendor, agent and product rows, composite indexes on the hot paths, and append-only wallet histories.
Nothing here is exotic, and that is the point: the developers who maintain this after handover should already know it.
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, not ours to supply
- iOS applicationsThree Android builds ship. The Flutter projects compile for iOS, quoted as an add-on with signing and submission.
- Gateway credentialsEleven gateways are integrated; each needs your own merchant account and approval.
- SMS and email providerIntegration-required - your accounts, your sender reputation.
- Firebase projectPush notifications 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.
- Catalog dataProducts, imagery and vendor recruitment are the business, and they are yours.
- Tax ratesTax classes bind per zone, but the rates for your jurisdictions are yours to set.
- ISO 27001 and SOC 2Neither certificate is held and neither is claimed. The platform is ready for the evidence gathering.
Currency exchange rates are operator-set rather than fetched automatically, which is deliberate - a marketplace that silently reprices a catalog against a live feed surprises vendors and customers at the same time.
See how Miracuves compares to agencies and freelancers
The deployment process, two modelled reference deployments, and what to check before you hire anyone - on the Development Company page.
Frequently Asked Questions
How does the delivery fleet work?
Is cash on delivery properly handled?
Can vendors manage everything themselves?
Which payment gateways are supported?
Are iOS apps included?
What does the AI module actually do?
See exactly what you are getting - before you commit
Request a working demo of the storefront, the vendor panel, the delivery app and the operator console, or check exact pricing.
Explore the Flipkart Clone
Ready to launch a marketplace that owns its last mile?
Deploy in 6 days with the storefront, vendor panel, delivery fleet and operator console included, full Laravel 12 source on infrastructure you own.
Talk to Us →Miracuves is an independent software development company. We are not affiliated with, connected to, sponsored by, or endorsed by Flipkart.
“Flipkart Clone” is used descriptively. It is how the software industry refers to building a platform with functionality similar to Flipkart, and how clients search for it.
The entire design and codebase is built by our own team. The product contains no code, design, graphics, or content originating from the Flipkart website or applications.
Flipkart and all other third-party names and marks are the property of their respective owners, referenced here solely to describe the category of software offered.
