Question 1

Why Medusa POS instead of ERPNext POS or standalone POS apps (Petpooja, Ginesys, etc.)?

Accepted Answer

**ERPNext POS** (frappe.io/erpnext/open-source-pos-software) is excellent — Mithtech deploys it routinely for ERP-only retailers who don't have an online store. Upstream marketed as *"Simple and user-friendly POS to manage your retail business"* with the headline claim *"generate invoices up to five times faster"*. Concrete ERPNext POS feature inventory: **store-based Item Pricing** (different rates per outlet on the same SKU), **batch + expiration date tracking** for perishables, **dedicated POS user per billing counter** with pre-configured customer / warehouse / payment defaults, **barcode-scan item retrieval**, **promotional-scheme auto-discount**, **loyalty-point redemption at billing**, **automatic change calculation across multiple payment modes**, **predefined POS print format optimised for thermal printers**, **shift-open/close consolidated invoice** (all transactions in a shift roll up to a single accounting entry while individual transactions are retained for audit), and a **dedicated Warehouse per store** with role-based permissions and per-store profitability tracking.

ERPNext POS is the right choice when the client's commerce model is *'physical retail only'* and the priority is tight ERPNext integration without omnichannel complexity. Native Frappe stack alignment, simple to operate, no engineering overhead.

**Standalone POS apps (Petpooja, Ginesys, GoFrugal, Posist, etc.)** — solid for single-vertical retail (Petpooja for restaurants, Ginesys for fashion) with minimal customisation needs. Trade-offs: per-outlet/per-month SaaS fees that compound at scale, limited integration depth with custom ERPs, vendor lock-in, and a bolt-on architecture if/when the client also wants an online store (which means running two parallel systems with reconciliation pain).

**Medusa POS (Mithtech-implemented per the upstream recipe at docs.medusajs.com/resources/recipes/pos)** — the right choice when the client's commerce model is **omnichannel**: physical stores + online store + mobile app + B2B portal + marketplace from a single inventory and customer database. The website-and-POS-on-the-same-Medusa pattern unlocks: **real-time stock accuracy at the till**, **customer recognition across channels** (online order history visible at point-of-sale per the recipe's Customer Module guidance), **"endless aisle"** (the till sells SKUs not physically in-store with auto-routing to online fulfillment — this is the Medusa POS recipe's headline pattern), **unified loyalty + promotions + gift cards**, **single source of truth for finance reconciliation**, and **zero per-till SaaS fees**. Trade-off: more upfront engineering (4–10 weeks for pilot vs 1–2 weeks to plug in Petpooja or 2–3 weeks to enable ERPNext POS) but produces a platform the client fully owns and can extend in any direction.

**Mithtech's decision rule:** 
- **Single-channel retail with no online ambitions** → ERPNext POS (free, fast to deploy, ledger-tight).
- **Single-vertical operator (restaurant, fashion boutique)** with no engineering team → Petpooja-class SaaS.
- **Omnichannel brands or multi-outlet retailers planning online expansion** → Medusa POS.
- **Combined retail + B2B portal + marketplace** under one roof → Medusa POS (only viable choice; ERPNext POS doesn't reach this scope).

We walk every retail client through this decision matrix during scoping. We deploy whichever option fits — Mithtech is not philosophically committed to Medusa-only; we deploy ERPNext POS frequently when it's the right call.

Question 2

How does the offline-first POS handle network outages and reconciliation?

Accepted Answer

Indian retail conditions demand it — the till **must keep selling** when the internet drops. Mithtech's offline-first POS pattern uses Medusa's API-first architecture combined with a PWA-based UI:

1. **Local catalogue cache** — at shift-start (or on a schedule) the POS UI pre-loads the full active catalogue (products, prices, taxes, promotions, customer-group rules) into IndexedDB. The cache refreshes automatically when online and on demand from the manager screen. Selling stays valid even with zero network.
2. **Local transaction queue** — every sale, refund, layaway, or shift event written first to IndexedDB; a sync worker uploads to the Medusa backend the moment connectivity returns. Sales never block on the network.
3. **Idempotency keys** — each transaction carries a client-generated UUID; the Medusa side de-duplicates on sync. No double-billing if the network flickers mid-checkout.
4. **Inventory reservation strategy** — for high-velocity SKUs (where running out at the till is unacceptable), Mithtech configures **reserved-stock allocation per outlet** so the local store has guaranteed inventory even without real-time backend confirmation. For low-velocity items the till can optimistically sell with backend reconciliation.
5. **Z-report & shift close** — at shift end, the till computes its own Z-report (cash drawer expected vs actual, payment-mode breakdown) from the local queue. Manager closes the shift; the queue uploads as a single batch.
6. **Reconciliation safety net** — nightly Mithtech-built reconciliation Workflow compares till-side computed totals to backend-received totals, flags any drift to the store manager + ERPNext finance team. Drift over a configurable threshold blocks the next-day shift open until resolved.
7. **Multi-day offline tolerance** — for rural or unstable-network outlets, the till is built to tolerate 48–72 hours offline before requiring sync. Manager dashboard flags outlets approaching the threshold.

Production-tested across multi-outlet Indian retail deployments with intermittent connectivity.

Question 3

What's the Indian payment stack — UPI, cards, wallets, mPOS — and how does it integrate?

Accepted Answer

Mithtech's standard Indian POS payment stack, all integrated as Mithtech-owned Modules:

**UPI:**
- **Razorpay UPI Collect / Cashfree UPI / PayU UPI** — dynamic QR generated per transaction, displayed on customer-facing screen, auto-confirmation via webhook in 2–8 seconds. Zero MDR for QR payments under government rules.
- **Bharat QR / NPCI Static QR** — for outlets with low-volume contactless preference; transaction confirmation via SMS-poll fallback.

**Cards:**
- **Pine Labs / Mosambee / Innoviti / Mswipe / Ezetap** — integrated via the vendor's mPOS API; the till sends amount → terminal prompts customer for card + PIN → terminal returns success/failure → till finalises invoice. MDR negotiated separately by client.
- **mPOS-less option** — Razorpay / PayU card-on-file with QR fallback for outlets that prefer not to manage terminals.

**Wallets:**
- **Paytm / PhonePe / GPay** — via UPI deep-link or wallet-specific API depending on volume.
- **Amazon Pay / MobiKwik / Freecharge** — covered by aggregator integration (Razorpay / Cashfree handle these as wallet rails behind UPI Collect).

**Cash + alternative:**
- Cash with cash-drawer trigger (ESC/POS via USB / serial) and denomination-tracking for shift-close.
- **Gift cards / Store credit / Loyalty points** — Mithtech-built Module with balance tracking, redemption gating, partial-use, expiry, GL posting (gift-card liability account).
- **Split payment** — single transaction with mixed payment modes (e.g., ₹500 UPI + ₹300 cash + ₹200 store credit). Tax allocation across modes computed correctly.

**Reconciliation:**
- Daily payment-aggregator reconciliation report (Razorpay / Cashfree settlement file) auto-imported and matched to till transactions; drift flagged for finance review.
- ERPNext Payment Entry per transaction with the correct payment-mode tagging for downstream reconciliation.

Mithtech configures the payment stack per client based on volume (negotiated MDR), outlet hardware (mPOS terminal model), and customer demographic (UPI-heavy vs card-heavy).

Question 4

Can this scale from a single pilot store to 100+ outlets?

Accepted Answer

Yes — Medusa.js is deliberately built for this; the upstream marketing quotes **500+ store locations across quick commerce** as a production reference. Mithtech's scaling pattern across pilot → multi-outlet → enterprise:

**Pilot (1 outlet, 2–4 weeks):** Single Medusa instance + single till. Validates: catalogue accuracy, GST treatment correctness, payment-stack reliability, staff workflow, offline-sync behavior, ERPNext posting accuracy. Produces operational playbook + staff training collateral.

**Multi-outlet rollout (5–50 outlets, 8–16 weeks):** Same Medusa backend, additional Sales Channels (one per outlet or one per region depending on inventory model), per-outlet user accounts and permissions, per-outlet receipt templates and outlet-specific GST registration handling, per-outlet shift management. Hardware procurement coordinated by Mithtech (ruggedised Android tablets / iPads / Windows terminals + receipt printers + cash drawers + barcode scanners). Staff training delivered by region with train-the-trainer model.

**Enterprise scale (50+ outlets):** Database tuning — PostgreSQL connection pooling (PgBouncer), read replicas for catalogue browsing, partitioned tables for high-volume order/transaction data; Redis cluster for catalogue cache; CDN for receipt images and product photos; Bull queue scaling for background workflows; horizontal scaling of the Medusa server behind a load balancer; observability dashboards (Frappe Insights or Grafana) showing per-outlet sales velocity, till uptime, sync lag, payment-mode mix, alert thresholds for till downtime.

**Multi-region / multi-country (international):** Medusa's Multi-Regional by default — multi-currency, region-specific tax rules, region-specific shipping/payment/discounts. Mithtech extends with per-region GST + VAT + GAAP compliance modules ([GST Compliance](/products/gst-compliance) for India, [VAT/GAAP Setup](/products/vat-gaap-setup) for UAE/GCC/UK/US).

We scope explicitly during the pilot — clients with 50+ outlet ambitions are walked through the scaling cost curve upfront. No surprises at month 12.

Question 5

What does Mithtech actually build and modify on top of Medusa for a POS deployment?

Accepted Answer

Mithtech is an expert POS-on-Medusa implementor — we **modify, develop, and deploy** the open-source platform. POS is the most operationally-sensitive Medusa configuration we deliver (the till must work every minute it's open). Concrete scope from production deployments:

1. **Custom POS Module** (Medusa SDK conventions, TypeScript) — Cash Register doctype, Shift management, Cash Drawer reconciliation, Z-Report generation, Tax-Inclusive/Exclusive display, Receipt template engine (per-outlet, GST-compliant), Layaway/Hold-Bill/Park-Ticket workflows, Discount-Approval gates with manager-override audit log.
2. **Touch-optimised POS UI** — Mithtech-built React PWA (Next.js or TanStack Start), sub-3-second checkout target, barcode-scanner integration, weighing-scale integration (for kg-billed SKUs), customer-display screen mirroring, ESC/POS receipt-printer driver, cash-drawer trigger, mPOS terminal integration. Runs in any modern browser; deploys to Android tablets, iPads, or Windows touch terminals.
3. **Offline-first PWA architecture** — IndexedDB transaction queue, local catalogue cache with auto-refresh, idempotent sync worker, manager-controlled cache reload, multi-day offline tolerance for rural/unstable-network outlets.
4. **Payment Module integrations** — UPI (Razorpay / Cashfree / PayU dynamic QR), cards (Pine Labs / Mosambee / Innoviti / Mswipe / Ezetap mPOS APIs), wallets (Paytm / PhonePe / GPay), cash with cash-drawer denomination tracking, gift cards / store credit / loyalty points (Mithtech-built Module), split-payment with correct tax allocation.
5. **Custom Workflows** — every till sale fires a sequence: inventory reservation → tax computation (CGST/SGST/IGST per customer-outlet location pair) → payment capture → ERPNext Sales Invoice creation → Stock update → GL posting → loyalty point accrual → receipt generation → printer trigger.
6. **ERPNext integration bridge** — Sales Invoice creation with correct GST treatment, Payment Entry per payment mode, Stock Entry on inventory movement, GL postings to outlet-specific accounts, Cash Closure on shift end, Daily Sales Summary report.
7. **Indian compliance Modules** — [GST Compliance](/products/gst-compliance) integration for IRN generation on B2B above-threshold sales, GSTR-1 / GSTR-3B prep, composition-scheme support for small retailers, e-invoicing exemption rules for B2C.
8. **Polygin Integration bridge** — WhatsApp templated receipts to customers (alternative to paper print), abandoned-cart recovery for online side, post-sale CSAT surveys.
9. **Smartflo Integration** — click-to-call from the POS or store-manager dashboard for customer support; CCaaS recordings attached to Customer records for dispute resolution.
10. **Store-Operations Dashboard** — Mithtech-built React UI for store managers + area managers showing today's sales, hour-by-hour trend, top SKUs, employee performance, current cash drawer balance, pending layaways, shift-close status. Mobile-responsive for managers visiting multiple outlets.
11. **Ruggedised hardware setup** — Mithtech procures (or guides client procurement of) Android tablets / iPads / Windows touch terminals, ESC/POS receipt printers, cash drawers, barcode scanners, weighing scales; delivers store-by-store hardware kit with pre-configured POS UI and on-site setup support during go-live.
12. **Staff training** — Mithtech's train-the-trainer model: Mithtech trains 2–3 client-side master trainers per region; master trainers cascade to outlet staff with Mithtech's training collateral; on-call Mithtech support during the first week of each outlet's go-live.
13. **Deployment & scaling** — Docker Compose for operator, Kubernetes Helm for enterprise scale; PostgreSQL tuning on high-volume Order / Transaction / Stock-Entry tables; Redis cache for catalogue browsing; CDN for product images.

All work delivered as a Mithtech-owned Git repository — TypeScript source, hardware-setup guide, store-staff training playbook, runbook, 90-day on-call support window during go-live. Client owns IP.

POS & Retail Billing on Medusa.js

What can POS & Retail Billing on Medusa.js do?

Built on Medusa.js v2.14.1 (MIT, 32.8k+ stars) — full source-code ownership, no per-till licence fees, no GMV tax

How does POS & Retail Billing on Medusa.js work?

Audit & scope

Deploy on your infrastructure

Customise & integrate

Train & roll out

Operate & evolve