E-commerce systems

In short

An e-commerce system is the complete set of software, data stores and third-party services that lets a buyer discover a product online, place an order, pay for it, and receive and return it, while the seller manages catalogue, inventory, fulfilment, settlement and taxes. It is a *systems* topic: catalogue and cart design, order and payment state machines, security and trust, plus Indian legal and tax compliance. Indian university syllabi (AICTE "E-Commerce / E-Business", UGC CBCS IT electives) examine business models, EDI and EPS (electronic payment systems), security mechanisms and cyber law; placement rounds at Flipkart, Amazon India, Myntra, Nykaa, Meesho, Zomato, Paytm, PhonePe, Razorpay and Infosys/TCS retail practices ask the same material as design questions. India's scale — UPI, ONDC, COD, GST — makes the local variants (not textbook US flows) the ones actually asked.

Explained

What an e-commerce system is, and its business models

• Definition: buying and selling of goods, services and information over electronic networks, together with the supporting processes — marketing, payment, fulfilment, after-sales and record-keeping.
• E-commerce vs e-business: e-commerce is the commercial transaction layer; e-business includes all internal electronic processes (procurement, HR, production planning) of which e-commerce is one part.
• Classification by parties:
  • B2C — business to consumer: Amazon.in, Flipkart, Nykaa. High volume, low ticket size, heavy UI and marketing emphasis.
  • B2B — business to business: IndiaMART, Udaan, Zetwerk. Negotiated price lists, credit terms, purchase orders, bulk logistics, GST invoice matching.
  • C2C — consumer to consumer, platform-mediated: OLX, Quikr, Meesho resellers. Platform supplies trust (ratings, escrow), not inventory.
  • C2B — consumers sell to business: freelancers on Upwork, stock-photo and influencer marketplaces.
  • B2G / G2C / G2B — e-procurement (GeM — Government e Marketplace), e-tendering, GST and IRCTC portals.
  • D2C — brand sells direct from its own storefront (boAt, Mamaearth), bypassing marketplaces to own data and margin.
• Classification by operating model:
  • Inventory (first-party) model: platform buys, stocks and sells. Better control, working-capital heavy. India's FDI policy bars 100% FDI-funded marketplaces from holding inventory for B2C, which is why Amazon/Flipkart use seller networks.
  • Marketplace (third-party) model: platform is an intermediary; sellers list and ship; platform earns commission, fulfilment and ad revenue.
  • Hybrid / managed marketplace, aggregator (Ola, Swiggy — platform sets price and quality), subscription (Netflix), drop-ship, and open-network (ONDC — the government-backed open protocol that decouples buyer apps from seller apps so a buyer on one app can order from a seller on another).

Architecture of an e-commerce platform

• Classic three-tier: presentation (web/mobile client) → application/business logic → data tier (RDBMS + caches + search index + object store for images).
• Typical modern decomposition into services: catalogue, search, pricing and promotions, cart, checkout, order, payment, inventory, warehouse/logistics, user and auth, notification, reviews, recommendations, reporting.
• Why microservices here: load is wildly uneven (search and catalogue reads vastly exceed order writes), and each service scales and releases independently; cost is distributed transactions and operational complexity.
• Read path optimisation: CDN for images and static assets; Redis/Memcached for product pages and sessions; Elasticsearch/OpenSearch (or Solr) for faceted product search; database read replicas.
• Write path integrity: orders, payments and inventory need ACID guarantees or carefully designed compensating transactions (the saga pattern: reserve inventory → capture payment → confirm order, with a compensating "release/refund" step for each failure).
• Headless commerce: a catalogue/cart/order backend exposed only through APIs, with web, Android, iOS and WhatsApp front-ends consuming it — the standard choice when channels multiply.
• Idempotency: every externally retriable operation (payment capture, order create) carries an idempotency key so a network retry does not create a second order or a second charge.
• Event-driven glue: Kafka/RabbitMQ carries "order placed", "payment captured", "shipment dispatched" events to notification, analytics, warehouse and accounting consumers.

Catalogue, cart and the order lifecycle

• Catalogue data model: Category → Product (title, description, brand, images, attributes) → Variant/SKU (the actual stockable unit: size, colour, pack). Price and stock hang off the SKU, never the product.
• Attributes and taxonomy drive faceted navigation; enrichment/PIM (product information management) keeps attributes consistent across thousands of sellers.
• Cart: a short-lived, mutable collection of (SKU, quantity, price-at-add). Guest carts live in a cookie/localStorage or a server-side session keyed by an anonymous token, then merge into the user cart on login. Prices and stock are re-validated at checkout — the cart is not a reservation.
• Checkout steps: address → delivery option and serviceability (pincode check) → coupon/loyalty → tax and shipping computation → payment method → place order.
• Inventory reservation: stock is decremented or soft-reserved with a TTL at order placement; oversell is prevented by atomic conditional updates (UPDATE stock SET qty=qty-1 WHERE sku=? AND qty>=1) or optimistic locking, not by read-then-write.
• Order state machine: Created → Payment Pending → Confirmed → Packed → Shipped → Out for Delivery → Delivered → (Return Requested → Picked Up → Refunded) ; plus Cancelled and Failed. Each transition is an immutable event row, so the order's history is auditable.
• Split orders: one customer order becomes several shipments from different sellers/warehouses, each with its own status and tracking — the usual reason a student's single-table order design fails an interview.
• Reverse logistics: returns, exchange, refund to original instrument, restocking or scrapping. COD refunds go to a bank account/UPI handle, which requires extra verification.

Electronic payment systems (Indian practice)

• Instruments: UPI (dominant by volume in India), debit/credit cards, net banking, wallets/PPIs (Paytm, PhonePe, Amazon Pay), EMI and pay-later/BNPL, gift cards and store credit, and COD — cash on delivery, still a large share of Indian orders and a major source of RTO (return to origin) losses.
• Actors in a card payment: customer → merchant → payment gateway (Razorpay, PayU, CCAvenue, Cashfree — collects and encrypts credentials, routes the request) → acquiring bank / PA-PG → card network (RuPay, Visa, Mastercard) → issuing bank (authorises against balance/limit) → response back. UPI instead routes through NPCI: the PSP app resolves the VPA and debits the payer's bank account account-to-account.
• Authorisation vs capture vs settlement: authorisation blocks the amount; capture requests the money (often at shipment for marketplaces); settlement is the acquirer paying the merchant's nodal/escrow account, typically T+1 to T+3 less MDR; refund and chargeback reverse it.
• Payment flow in code: server creates an order with the gateway → client completes payment on the gateway's hosted page/SDK → gateway returns a signed response → server verifies the signature → gateway also posts an asynchronous webhook, which is the authoritative, retriable confirmation. Never mark an order paid from a client-side redirect alone.
• Reconciliation: daily three-way matching of platform orders, gateway settlement reports and bank statements; mismatches are "money-in-transit", double refunds or failed-but-debited cases.
• RBI rules that shape Indian implementations: card-on-file tokenisation (merchants may not store actual card numbers; a network token is stored instead), Additional Factor of Authentication for most domestic transactions (2FA/OTP, with carve-outs such as small-value e-mandates and contactless limits), and the e-mandate framework for recurring payments with pre-debit notification. Exact thresholds and exemptions change by circular — check the current RBI master direction before quoting figures.

Security, trust and standards

• Requirements: confidentiality, integrity, authentication, non-repudiation, availability, and privacy of personal data.
• Transport security: TLS (HTTPS) with a CA-issued certificate; HSTS. SSL is obsolete; the correct current answer is TLS 1.2/1.3.
• How HTTPS works, exam version: asymmetric keys (RSA/ECDHE) authenticate the server and establish a shared secret; a symmetric cipher (AES-GCM) then encrypts the bulk traffic because it is far faster.
• Digital signature: hash the message (SHA-256), encrypt the hash with the sender's private key; the receiver decrypts with the public key and compares hashes — gives integrity + authentication + non-repudiation. Legally recognised in India under the Information Technology Act, 2000 (electronic and digital signatures, Certifying Authorities under the CCA).
• PCI DSS governs anyone handling card data; the standard risk-reduction move is to never touch the PAN — use the gateway's hosted checkout or iframe so the merchant stays in a reduced scope.
• Application-layer threats and defences: SQL injection (parameterised queries), XSS (output encoding, CSP), CSRF (anti-CSRF tokens, SameSite cookies), broken access control/IDOR (server-side authorisation on every object), price tampering (never trust a client-posted price — recompute server-side), coupon abuse (server-side usage limits), credential stuffing (rate limits, MFA, bot defence), and payment-response forgery (signature verification).
• Fraud controls: device fingerprinting, velocity checks, address-risk and RTO scoring, 3-D Secure, and COD confirmation calls or OTP.
• Legal and regulatory frame in India:
  • IT Act, 2000 and its rules — legal validity of electronic records and contracts, intermediary liability and due-diligence obligations, cybercrime offences.
  • Consumer Protection Act, 2019 with the Consumer Protection (E-Commerce) Rules, 2020 — mandatory seller identity and contact details, country of origin, no unfair trade practice or manipulated search ranking, published return/refund/grievance policy, a grievance officer with time-bound redressal, and no cancellation charges levied one-sidedly.
  • Legal Metrology (Packaged Commodities) Rules, 2011 — mandatory declarations on the listing: MRP, net quantity, manufacturer/importer, consumer-care details, country of origin.
  • Digital Personal Data Protection Act, 2023 — consent-based processing, notice, purpose limitation, data-principal rights, breach notification; operational obligations commence with its rules, so treat specific timelines as subject to the notified rules.
  • GST: e-commerce operators must collect TCS at 0.5% (0.25% CGST + 0.25% SGST intra-state; reduced from 1% with effect from 10 July 2024) on the net taxable value of supplies made through the platform and file GSTR-8; GST slabs since 22 September 2025 are 5%, 18% and 40% (with nil and special rates for some goods); the operator is liable to pay tax on certain notified services (such as passenger transport and restaurant service) supplied through it. Rate applicability per product should be read off the current notification.

Marketing, analytics and operations

• Funnel: impression → product view → add-to-cart → checkout start → payment → delivered. Each step has a drop-off; the metric set follows the funnel.
• Core metrics: conversion rate, average order value (AOV), cart-abandonment rate, customer acquisition cost (CAC), customer lifetime value (CLV/LTV), repeat rate, RTO %, gross merchandise value (GMV) vs net revenue, contribution margin per order.
• SEO and performance: server-side rendering or static generation for product pages, canonical URLs, structured product data, image optimisation; page latency directly moves conversion, which is why CDN and caching are commercial decisions, not just technical ones.
• Personalisation and recommendations: collaborative filtering ("users who bought X also bought Y"), content/attribute-based similarity, and "frequently bought together" from association rules; cold-start handled with popularity and category defaults.
• A/B testing for layout, pricing and copy; cohort analysis for retention.
• Supply side: seller onboarding and KYC, catalogue ingestion, pricing/buy-box logic, warehouse and 3PL integration (Delhivery, Ekart, Shadowfax), serviceability and pincode masters, invoice and e-way bill generation.
• EDI (syllabus item): Electronic Data Interchange — exchange of structured business documents (purchase order, invoice, dispatch advice) in agreed formats (ANSI X12, UN/EDIFACT) between trading partners, historically over VANs; now largely superseded by XML/JSON APIs but still used in large B2B retail and logistics.

Key points

• E-commerce vs e-business — e-commerce is the transaction; e-business includes all internal electronic processes.
• B2B / B2C / C2C / C2B / B2G / D2C — classification by who the two transacting parties are.
• Marketplace vs inventory model — intermediary earning commission vs platform owning the stock; Indian FDI rules push large platforms to the marketplace model.
• ONDC — open protocol unbundling buyer apps from seller apps so orders cross platform boundaries.
• SKU — the stockable unit; price and inventory attach to the SKU, not the product.
• Cart is not a reservation — price and stock must be re-validated at checkout.
• Order state machine — explicit states with immutable transition events; split shipments are normal.
• Oversell prevention — atomic conditional decrement or optimistic locking, never read-then-write.
• Payment gateway vs payment processor/acquirer — the gateway captures and routes the request; the acquirer moves and settles the money.
• Authorisation ≠ capture ≠ settlement — blocking, charging and receiving funds are three separate events.
• Webhook is authoritative — server-side signature verification and the webhook, not the browser redirect, confirm payment.
• Idempotency key — stops retries from creating duplicate orders or charges.
• Tokenisation and PCI DSS — do not store PANs; keep card data out of your scope using hosted checkout.
• Digital signature — hash + private-key encryption gives integrity, authentication and non-repudiation; valid under the IT Act, 2000.
• Price tampering — all prices, taxes and discounts recomputed server-side from trusted data.
• E-Commerce Rules, 2020 — seller identity, country of origin, return/refund policy, grievance officer, no manipulated ranking.
• GST TCS 0.5% by the operator on net taxable supplies, reported in GSTR-8; slabs are 5/18/40% from 22 September 2025.
• COD and RTO — India-specific cost driver; refunds and fraud controls must handle it.

Formulas and examples

Example 1 — Funnel, conversion and AOV. A D2C store had 4,00,000 sessions in a month, 9,000 orders and revenue of ₹1,62,00,000. Carts created: 36,000.

• CR = 9,000 ÷ 4,00,000 × 100 = 2.25%
• AOV = ₹1,62,00,000 ÷ 9,000 = ₹1,800
• Cart abandonment = (1 − 9,000 ÷ 36,000) × 100 = 75%
• If a faster checkout lifts CR to 2.70% at the same AOV and sessions: orders = 0.0270 × 4,00,000 = 10,800; revenue = 10,800 × 1,800 = ₹1,94,40,000, a gain of ₹32,40,000 (+20%).

Example 2 — GST split and TCS on a marketplace order. A kitchen appliance is listed at ₹2,360 inclusive of 18% GST; the marketplace charges 12% commission on the taxable value, and shipping of ₹90 is borne by the seller. One unit is sold; one more unit worth ₹2,360 was returned in the same month.

• Taxable value = 2,360 ÷ 1.18 = ₹2,000; GST = ₹360 (₹180 CGST + ₹180 SGST if intra-state).
• Commission = 12% × 2,000 = ₹240; GST on commission at 18% = ₹43.20 → total fee ₹283.20.
• Seller's net = 2,360 − 283.20 − 90 = ₹1,986.80 before TCS.
• TCS for the month: net taxable value = 2,000 (sold) − 2,000 (returned) = ₹0 → TCS = ₹0. Had there been no return, TCS = 0.5% × 2,000 = ₹10, credited to the seller's electronic cash ledger.

Example 3 — Payment-method mix and MDR cost. 10,000 orders of AOV ₹1,500 → GMV ₹1.5 crore. Mix and MDR:

• Blended payment cost = 93,650 ÷ 1,50,00,000 = 0.62% of GMV.
• If a UPI-first nudge moves 5 percentage points from credit card to UPI: credit-card value falls to ₹10,50,000, cost 1.8% = ₹18,900; new total = ₹80,150, i.e. 0.53% of GMV — a saving of ₹13,500/month. (UPI merchant-discount rate is zero for normal merchant transactions under the current zero-MDR policy for RuPay debit and UPI; PA fees on other instruments vary by contract.)

Example 4 — Oversell and reservation TTL. 40 units of an SKU; a flash sale brings 500 add-to-cart events in 60 seconds, each holding stock for a 15-minute TTL.

• With reservation-on-add-to-cart: 40 reservations succeed, 460 fail, and stock is frozen for 15 minutes even though only, say, 60% of carts convert → 16 units idle for a quarter of an hour.
• With reservation-on-order-placement and an atomic decrement: carts are unlimited, 40 of the placement attempts succeed; the remaining users see "out of stock" at checkout. Expected sold = 40 either way, but held-but-unsold inventory = 0 units versus 16, which is why large platforms reserve at placement, not at add-to-cart.

Example 5 — Reorder point. An SKU sells 120 units/day on average, supplier lead time is 7 days, safety stock 300 units.

• ROP = 120 × 7 + 300 = 1,140 units. At 1,140 on hand the purchase order goes out; expected stock at receipt = 1,140 − 840 = 300 units (the safety stock), consumed only if demand or lead time overruns.

Where it is used

• Horizontal marketplaces and verticals: Amazon India, Flipkart, Meesho, Myntra, Nykaa, Ajio — roles in catalogue, search relevance, pricing, order management and fulfilment engineering.
• Payments and fintech: Razorpay, PayU, Cashfree, Paytm, PhonePe, BillDesk — gateway integration, webhook and reconciliation systems, PCI-scoped services, chargeback tooling.
• D2C and SaaS commerce: Shopify/WooCommerce/Magento-based storefronts for Indian brands, with custom plugins for GST invoices, pincode serviceability and COD; agencies and in-house teams hire for exactly this.
• Logistics tech: Delhivery, Ekart, Shadowfax, Shiprocket — serviceability, route and RTO-prediction systems that plug into the order pipeline.
• Government and B2B: GeM e-procurement, IRCTC, ONDC seller/buyer app builders, IndiaMART and Udaan B2B flows with credit and GST invoice matching.
• Job roles: full-stack/backend developer, SDE in order or payments platform, solution architect, business analyst, category/catalogue ops, growth and marketing analytics, QA for payment flows, and security/compliance (PCI DSS, DPDP).

Interview questions

• Q: Difference between a payment gateway and a payment aggregator/acquirer? A: The gateway is the technical channel that collects and routes payment credentials and returns an authorisation result; the aggregator/acquirer holds the merchant relationship and actually settles funds into the merchant's account after deducting MDR.
• Q: Why must payment confirmation come from a webhook rather than the browser redirect? A: The redirect can be lost, tampered with or replayed by the client; the server-to-server webhook (with signature verification and retries) is authoritative and survives the user closing the tab.
• Q: How do you prevent two customers buying the last unit? A: Decrement stock with a single atomic conditional update or optimistic version check inside the order transaction, so exactly one request succeeds; never read stock, decide in application code, then write.
• Q: Where do you store the price — cart or order? A: The cart holds a display price only; the order stores the immutable price, tax and discount computed server-side at placement, because catalogue prices change and the order is a legal record.
• Q: How would you design the order status model? A: A state machine with explicit allowed transitions plus an append-only event log per order (and per shipment, since one order can split), so status is derivable and auditable rather than overwritten.
• Q: What is idempotency and where does it matter in e-commerce? A: The property that repeating a request has the same effect as doing it once; it is enforced with a client-supplied key on order creation, payment capture and refunds to stop duplicates from retries.
• Q: Why should a merchant not store card numbers, and what replaces them? A: Storing PANs brings full PCI DSS scope and breach liability; RBI's card-on-file rules require network tokens instead, so the merchant keeps a token usable only for that merchant.
• Q: How does a digital signature give non-repudiation? A: Only the holder of the private key could have produced a signature that verifies against the matching public key, so the signer cannot credibly deny the message — recognised under the IT Act, 2000.
• Q: What does the Consumer Protection (E-Commerce) Rules, 2020 require of a platform? A: Disclose seller identity and contact details and country of origin, publish return/refund/grievance policies, appoint a grievance officer with time-bound redressal, and avoid unfair trade practices such as manipulated search ranking.
• Q: What is TCS under GST for an e-commerce operator? A: The operator collects 0.5% of the net taxable value of supplies made through it (net of returns), deposits it and files GSTR-8; the amount credits the seller's electronic cash ledger.
• Q: Why is COD both valuable and expensive in India? A: It converts customers who distrust prepaid or lack cards, but it raises RTO, ties up cash in transit, adds collection fees, and makes refunds harder since money must go to a bank account or UPI handle.
• Q: Tricky — a customer was debited but the order shows failed. What is your design response? A: Treat it as a reconciliation case: match the gateway transaction to the order by idempotency key, and either auto-confirm the order if inventory allows or auto-refund, driven by the settlement report rather than manual intervention.
• Q: How do you keep a product page fast under heavy load? A: Serve images and static assets from a CDN, cache rendered product data in Redis with event-based invalidation, use a search index for listings, and keep only cart/checkout calls hitting the primary database.

Common mistakes

• Trusting client-posted prices, totals, discounts or quantities instead of recomputing them server-side — the classic price-tampering flaw caught in security reviews.
• Marking an order paid on the front-end callback, with no signature verification and no webhook handling, so failed or forged payments become confirmed orders.
• Attaching price and inventory to the product rather than the SKU/variant, which breaks the moment sizes or colours differ in stock.
• Reading stock then decrementing in application code, and overselling under concurrency; or reserving at add-to-cart and freezing saleable inventory.
• Treating an order as a single row with one status field and one shipment — real orders split, partially cancel and partially return.
• Writing "SSL" and "the gateway stores my card data" in exams; the current answers are TLS 1.2/1.3 and network tokenisation under PCI DSS/RBI rules.
• Quoting stale compliance facts — old GST slabs, or ignoring the E-Commerce Rules, 2020, Legal Metrology declarations and the DPDP Act, 2023 in a system design answer.
• Mixing GST-inclusive and exclusive amounts: dividing by 1 + rate is required to get the taxable value, and commission is charged on the taxable value, not the MRP.

Related topics

REST APIs · API integration and middleware · Enterprise systems: ERP and CRM · Server-side web development · Back-end development with Node.js · Web fundamentals: HTML, CSS and JavaScript