Two-sided marketplace app development in India: the 2026 build checklist

Summary. A two-sided marketplace in India is a tax collector, a payment router and a grievance-redressal desk before it is a product. Under section 52 of the CGST Act every electronic commerce operator collects tax at source on the net value of taxable supplies made through it, notified at 0.5% under the CGST Act plus 0.5% under the SGST Act, or 1% under the IGST Act on inter-state supplies. That money reaches the government within 10 days of month end, the GSTR-8 statement is due on the 10th, the annual statement by 31 December, and corrections stop on 30 November following the financial year. The operator registers separately in every state it sells into and appoints a person in each state or union territory liable to pay GST, even without a physical presence there. Split settlements add their own line: Razorpay Route charges 0.25%, currently 0.1% on a limited-time offer, on every transfer as add-on pricing, on top of standard payment gateway pricing plus GST. The Consumer Protection (E-Commerce) Rules, 2020 require a marketplace entity to display seller-provided information prominently, including the name, contact number and designation of the grievance officer. None of that is a post-launch chore. All of it lands in the data model, the ledger and the settlement job in week one, and every one of those obligations is why a marketplace costs more to build than the single-seller store it looks like.

What actually changes versus a single-seller store

Founders usually arrive with a D2C build in mind and a supply side bolted on. The two are different products.

The consequential row is the last one on the money side. A single-seller store can treat payments as a checkout integration. A marketplace has to decide, per order, who gets what, when they get it, and what happens when the buyer wants it back. That decision belongs in the ledger design, not in a payment provider's dashboard.

The money layer, and the one rule that shapes it

Non-bank payment aggregators require authorisation from the Reserve Bank of India under the Payment and Settlement Systems Act. The practical consequence for a marketplace is structural rather than punitive: unless you intend to become an authorised payment aggregator yourself, you do not hold or pool seller funds in your own account. You route the split through an authorised aggregator and keep your own ledger as the record of who is owed what.

That is why split-settlement products exist, and why their pricing belongs in your unit economics from the first model.

Razorpay Route publishes a Standard Plan at 0.25%, marked as a limited-time offer at 0.1%, "charged on every transfer as addon pricing," with a footnote that standard payment gateway pricing applies to the underlying payment and GST is applicable. That is a per-transfer charge, not a per-order one, so an order split three ways costs three transfers.

The mechanics are three objects. Linked accounts onboard each seller without physical paperwork. Transfers split a single captured payment across those accounts with your own logic. Settlements control when the money actually leaves, with three modes: settle on the default schedule, set an explicit settlement date, or hold the transfer until a business condition is met.

            curl https://api.razorpay.com/v1/payments/pay_7o52yYkoL/transfers \
-u {KEY}:{SECRET} \
-d 'transfers[0][account]=acc_7o7C7MnIbGk60l' \
-d 'transfers[0][amount]=10000' \
-d 'transfers[0][currency]=INR' \
-d 'transfers[0][on_hold]=1' \
-d 'transfers[0][on_hold_until]=1531543380'
          

That on_hold_until parameter is the single most useful line in a marketplace payments integration, because it encodes your return window in the payment rail rather than in a cron job you have to babysit. Hold the seller's share until delivery plus the return period, release it automatically, and your refund exposure stops being an accounting problem.

Keep your systems in sync through webhooks rather than polling. Route emits transfer.created and transfer.reversed, each configurable with separate URLs for test and live mode.

"Now we can onboard more hosts on our platform with its easy onboarding process and manage the payouts at a time best suited to our business policy and still be in control of our business with deep view through our dashboard," said Vikram Kumar, Co-Founder and CEO of ExploreLifeTravelling, in a testimonial published on Razorpay's Route page. He credits the API-driven approach with saving his team engineering hours on the split logic itself.

Two engineering notes that experience keeps confirming. First, your ledger is the source of truth, not the payment provider's transfer list; reconcile against it daily rather than trusting it. Second, model the commission as a line item on the order, not as a subtraction at settlement time, or your GST working will not tie out.

The tax obligations that live in the schema

Section 52 is short and it drives more of the build than founders expect.

Two of those rows are the ones that cause rewrites.

The correction window means your order records cannot be mutable. When a seller disputes a line four months later, you need to produce what you filed, what changed and when. Design amendments as append-only events from the start; retro-fitting that into a table of updatable rows is the most expensive refactor in this category.

The information notice means you must be able to answer, on fifteen working days' notice, what a specific seller supplied through you in a given period and what stock they held in warehouses you manage and they declared as additional places of business. If your warehouse data lives only in a third-party logistics system, that question is unanswerable. Failure to furnish the required information attracts a penalty which may extend to twenty-five thousand rupees.

State-wise registration is the other structural one. The GST portal's own guidance is direct: an e-commerce operator supplying to multiple states registers separately in each state and appoints a person in each state or union territory liable to pay GST, and an operator without physical presence in a state names the state in Part A of the application. So every order needs a defensible place-of-supply determination at the moment it is placed, and your reporting has to slice by state before it slices by anything else.

Consumer obligations you have to render, not just document

The Consumer Protection (E-Commerce) Rules, 2020 place display duties on the marketplace entity itself. Every marketplace e-commerce entity must provide, in a clear and accessible manner and displayed prominently to users at the appropriate place on its platform, all information provided to it by sellers, including the name, contact numbers and designation of the grievance officer for consumer grievance redressal.

Read that as a product requirement rather than a legal footnote. It means seller identity and grievance contact are fields on the product detail page, populated from seller-supplied data, and it means your seller onboarding flow has to collect and validate them before a listing can go live. Marketplaces that treat this as a static footer page get it wrong in exactly the way a Central Consumer Protection Authority advisory is designed to catch.

Build your own network, or join one

India has an unbundled alternative to building both sides yourself. The Open Network for Digital Commerce identifies four types of players, and which one you are is a strategy decision that changes your architecture.

A Buyer Network Participant connects buyers via a buyer application and takes buyer-facing responsibilities including customer support and a single checkout experience across categories. A Seller Network Participant connects sellers through a seller application, digitises the seller's catalogue and disperses payments, and trains sellers on ecommerce practice. Within that, a Marketplace Seller Node produces no inventory of its own and offers goods and services provided by sellers, while an Inventory Seller Node is operated by a seller selling only its own inventory. A Gateway forwards search requests from buyer applications to all seller applications and back, which is what makes every seller discoverable. A Technology Service Provider supplies the software so a participant can trade on the network without in-house engineering.

ONDC publishes code frameworks for buyer and seller applications in retail and logistics as white-label implementations, plus a developer guide covering API specifications across retail, mobility and finance from onboarding through production registry integration.

The honest framing is that joining a network solves the supply half of the cold-start problem and gives up some control of the experience. Building your own solves neither half and gives up nothing. Most Indian categories we see are better served by owning the app and treating the network as a distribution channel added in phase three.

What the build actually looks like

Scope creep in marketplaces comes from treating every capability as launch-critical. It is not.

Phase 1 exists to answer one question: will both sides show up in one geography? Onboard supply by hand, pay sellers by bank transfer, and skip the split-settlement integration entirely. If the answer is no, you have spent eight weeks instead of eight months. If the answer is yes, phase 2 pays for itself.

The single biggest cost driver is not the app. It is the number of distinct settlement conditions the business wants. Every extra rule about when a seller gets paid is a state in the ledger, a webhook path, a reconciliation case and a support script. Start with one rule.

Matching is the product, and it is where AI belongs

Once both sides are on the platform, your defensibility is how well you match them. Ranking a seller for a buyer is a genuine machine learning problem with real inputs: distance, fulfilment history, price competitiveness, catalogue completeness, dispute rate, response latency.

Two cautions from doing this work. Start with rules and measure them before reaching for a model, because a well-tuned rule set with honest metrics beats an unmonitored model in most categories. And instrument the counterfactual: log what you showed and what you would have shown under the alternative ranking, or you will never know whether the model helped.

Catalogue quality is the unglamorous prerequisite. Sellers supply inconsistent titles, missing attributes and duplicate listings, and no ranking model recovers from a catalogue where the same product appears eleven times under nine names. Normalising that at ingestion is where language models earn their keep in a marketplace, and it is measurable: dedupe rate, attribute fill rate, search zero-result rate.

India-specific considerations

Rupee pricing and multi-state tax mean your reporting layer is not an afterthought. Build the state dimension into orders, settlements and commissions from the first migration, because adding it later means recomputing history you may be asked to file against.

Prompts, seller documents and buyer contact details are personal data, and the Digital Personal Data Protection Act 2023 governs how you collect, retain and delete them. Design retention deliberately, especially for KYC documents collected during seller onboarding, and keep deletion paths real rather than notional. We design applications aligned with DPDP requirements rather than claiming any certification against them.

App store economics matter more for marketplaces than for D2C, because your take rate is thin. Model your commission net of payment gateway charges, the per-transfer split fee, GST on those fees and app store commission before you decide what to charge sellers. Our India versus US app development cost comparison covers the build-side numbers, and the enterprise mobile app development guide covers the architecture decisions that carry over.

Finally, category density beats national coverage. A marketplace that works in three pin codes is a business. A marketplace that works thinly across India is a demo.

FAQ

How eCorpIT can help

eCorpIT builds marketplace products for founders and enterprises from Gurugram, and we start where the risk is rather than where the screens are: the place-of-supply model, the ledger, the settlement rules and the tax extract, reviewed alongside your accountant before a line of app code is written. Our senior engineering teams then build the buyer and seller applications, wire split settlements with held transfers so refunds never chase money that has already left, and design the data model aligned with DPDP requirements. We are CMMI Level 5, MSME Certified and ISO 27001:2022 certified, and we work with AWS, Microsoft, Google and Shopify. If you are scoping a two-sided marketplace, talk to us and we will pressure-test the model before you commit a budget. Related work: ecommerce app development for single-seller D2C, quick-commerce and dark-store apps for hyperlocal fulfilment, and fintech payments app development when the money movement is the product.

References

1. Section 52, CGST Act 2017, Central Board of Indirect Taxes and Customs — collection at source, payment and statement deadlines, correction window, three-year filing limit and the information-notice penalty.

1. Registration as Tax Collector at Source, GST portal — the notified 0.5% CGST plus 0.5% SGST and 1% IGST rates, and state-wise registration guidance.

1. FAQs on Form GSTR-8, GST portal — who files the TCS statement and when.

1. Supplies made through e-commerce operators, GST portal — reporting supplies through operators.

1. E-commerce FAQ, Central Board of Indirect Taxes and Customs — the department's own e-commerce guidance.

1. Consumer Protection (E-Commerce) Rules, 2020, Department of Consumer Affairs — the rules as notified.

1. CCPA advisory under the Consumer Protection (E-commerce) Rules — display duties including grievance officer details.

1. Guidelines on regulation of payment aggregators and payment gateways, Reserve Bank of India — the authorisation requirement for non-bank payment aggregators.

1. Razorpay Route — Standard Plan pricing, linked accounts, transfers, settlement modes, webhooks and the ExploreLifeTravelling testimonial.

1. Linked Accounts, Razorpay Docs — onboarding sellers as linked accounts.

1. Route, Razorpay Docs — the transfers and settlements API surface.

1. Roles you can play on ONDC — Buyer and Seller Network Participants, Gateway, Technology Service Provider, and the MSN and ISN distinction.

1. ONDC tech resources and developer guide — white-label frameworks and API specifications across retail, mobility and finance.

1. How to join ONDC — the participant onboarding steps.

Last updated: 3 August 2026.