Medusa.js does not ship a built-in point-of-sale screen the way a traditional retail POS product does. It provides the commerce infrastructure — inventory, stock locations, sales channels, customer profiles — through REST APIs, and the actual checkout interface staff use is a separate application built on top of that infrastructure. This distinction is the single most important thing to understand before evaluating "Medusa POS" for a retail store. This guide on medusa js pos is written for Indian SMEs, with code samples, ERPNext / Medusa recipes, and step-by-step fixes you can copy into a real project.
Retailers searching for "Medusa POS" are often expecting a product they can install and open, similar to Shopify POS or a traditional till system. What Medusa offers is closer to an architecture than a product. It is a headless commerce backend carrying the inventory, stock-location, sales-channel and customer modules a POS needs. On top sits either a community-built starter app or a custom front end that talks to those APIs.
This is not a limitation dressed up as a feature — it is a genuinely different model with real trade-offs, and it's worth understanding both sides before deciding. I am Manoj, an ERPNext and Frappe implementation consultant at MithTech, and my team builds retail POS implementations on Medusa specifically for omnichannel brands.
Does Medusa.js come with a built-in POS system?
Medusa.js does not come with a built-in point-of-sale screen — it provides the commerce backend (inventory, stock locations, sales channels, customer profiles, promotions) through REST APIs, and a separate front-end application is what staff actually use at checkout. This is different from an all-in-one retail POS product where the till software and the backend are the same purchase.
So "getting Medusa POS" means one of two things. Either you start from an existing open-source starter — Agilo, a Medusa Expert Partner, publishes one with barcode scanning, cart management, customer profiles and iOS/Android support. Or you build a custom POS front end tailored to your own store workflow. Both paths are real and used in production; neither is a shortcut around needing a POS application layer.
Skimmable summary: Medusa provides the commerce APIs a POS needs (inventory, sales channels, customers) but not the checkout screen itself — that comes from an open-source starter or a custom-built app on top of Medusa's backend.
What does Medusa actually provide for a POS implementation?
Medusa provides four core building blocks for a POS. Inventory and Stock Location track stock across warehouses and physical stores. Sales Channel distinguishes online from in-store transactions against the same product catalog. Customer looks up buyer profiles so an order can be placed under their account at checkout. And the promotion APIs apply discounts on the fly during an in-store sale.
The practical effect: a customer's online cart, loyalty history and stock availability are the same data the POS reads. There is no sync job reconciling an online store against a disconnected till. Both query the same backend. This is the genuine strength of the model for a brand running more than one sales channel.
Skimmable summary: Medusa's Inventory, Stock Location, Sales Channel and Customer modules give a POS app real-time access to the same data as your online store. The value is unified inventory and customer data, not a pre-built checkout screen.
Should I use Medusa POS or ERPNext's built-in POS?
Choose Medusa POS if you run more than one sales channel alongside physical retail — an online store, a mobile app, a B2B portal, a marketplace — or plan to. Medusa's architecture keeps inventory and customer data unified across all of them. Choose ERPNext's built-in POS module if your business is retail-only with no separate online store. It is offline-first and works without a stable internet connection. It also keeps everything inside one ERP, with no separate commerce backend to run.
These are genuinely two different products solving two different problems, not a "better vs worse" comparison. A single-location shop with no e-commerce ambitions is usually over-engineering by choosing Medusa. A brand running a D2C website, a wholesale B2B portal, and physical retail from shared inventory is under-served by ERPNext's POS alone, because it isn't built for that multi-channel data model.
| Scenario | Better fit |
|---|---|
| Retail-only, no online store, unreliable internet at store locations | ERPNext's built-in POS |
| Online store + physical retail sharing inventory | Medusa POS |
| B2B wholesale portal + retail + online, all from one catalog | Medusa POS |
| Want everything inside one ERP with no separate commerce layer | ERPNext's built-in POS |
Skimmable summary: ERPNext's built-in POS suits single-channel, offline-first retail. Medusa POS suits brands running an online store, B2B and physical retail off shared inventory. The deciding factor is how many channels genuinely need the same stock and customer data.
Not sure which POS model fits your store?
MithTech builds retail POS implementations on Medusa.js — touch UI, offline-first PWA, and ERPNext-connected inventory for Indian payment methods — specifically for omnichannel brands. See the POS billing product page for what a Medusa-based POS implementation includes, or explore Medusa as a platform more broadly.
How to apply this in practice
Step 1
Step 2
Step 3
Step 4
Frequently asked questions
+Does Medusa.js have its own POS app I can just install?
Not a single official one from Medusa itself — but open-source starters exist, including Agilo's Medusa POS Starter, which provides barcode scanning, checkout, cart management, customer profiles, and mobile device support. Using one of these, or building a custom POS front end against Medusa's APIs, is how a Medusa POS implementation is actually delivered.
+What's the difference between Medusa POS and ERPNext's built-in POS?
ERPNext ships its own separate, built-in POS module that's offline-first and designed for retailers who don't need a connected online store. Medusa POS is not a single product — it's a POS application built on Medusa's commerce APIs, and its advantage is unifying inventory and customer data across online, B2B, and in-store channels. They solve different problems and aren't direct substitutes for each other.
+Is Medusa POS a good fit for a single-location retail store with no online presence?
Usually not the simplest choice. A single-location store with no e-commerce ambitions is better served by a traditional retail POS, or by ERPNext's built-in offline-first POS module. Medusa's multi-channel architecture solves a problem a single-channel store does not have.
+Can Medusa POS work offline if store internet goes down?
This depends on which POS application you use on top of Medusa, not on Medusa itself. Some starters and custom builds are offline-first, queuing transactions locally and syncing once connectivity returns. That decision is made at the POS-app layer, not by Medusa itself. Confirm it specifically with whoever builds or configures your front end.
About the author
Manoj is an ERPNext and Frappe implementation consultant at MithTech in Bengaluru, and builds Medusa.js-based POS and omnichannel retail implementations connected to ERPNext inventory for Indian brands.
How does Medusa POS compare to a hosted POS like Shopify or Lightspeed?
Medusa POS is open-source and self-hosted, so you own the data and the customisation layer. Shopify and Lightspeed are SaaS — faster to start, but vendor-locked, with transaction and seat fees that grow with the business. For a retailer that wants to keep data on its own infrastructure, Medusa is the better long-run choice; for a small shop that just needs a working till by next week, Shopify is the better short-run choice.
What hardware do you need to run Medusa POS in a retail store?
A modern tablet or small-form-factor PC, a receipt printer (Epson or Star are the standard picks), a barcode scanner, and a cash drawer that pops on print. The Medusa storefront runs in any modern browser, so the tablet can be iPad, Android, or Windows. For multi-store setups, add a network printer per counter and a small UPS so a power blip does not lock the till mid-transaction.