One system for showroom and website: an in-store point of sale on Mage-OS

A physical store sells differently from a website. Customers pay with a mix of cash, card and financing, put a large purchase on layaway and pay it off over months, and expect the salesperson who helped them to get the commission. When the register lives in one system and the website in another, every sale has to be keyed twice and the two never quite agree.

We built an in-store point of sale for a multi-location retailer, on the same Mage-OS install that runs their website. Each register sells from the same catalog, at the same store prices, and every sale flows to the retailer's ERP the same way a web order does.

The challenge

The retailer's stores needed a register that understood how big-ticket items are really sold, not a generic till bolted onto the website.

Each store has its own prices: a register in one city has to charge that store's price and clearance price, not the price of whichever store the manager last browsed online.
Big tickets get split: a large order might be paid partly in cash, partly by card and partly through in-store financing, and each part has to reconcile in the cash drawer and in the books.
Layaway is a core program: customers pay a deposit, pay the rest in instalments at the store or online, and sometimes take one piece of a set home before the rest is paid off.
The ERP is the system of record: every register sale has to arrive there as a proper sales order with the right salesperson, location and payment lines, without creating duplicate customers.
Stores need daily discipline: opening float, end-of-day count, manager sign-off, a deposit figure and a report for head office.
People need to be paid correctly: staff hours for payroll, and commission that is taken back when goods are returned.
The register cannot stop when the ERP does: a slow or offline back office must never block a sale on the showroom floor.

What we built

A browser-based register app, served by the store's own Magento, with a set of Mage-OS modules behind it.

Register sign-in: staff pick their store and register from a grouped list. A device on a store's network is offered its own store first, and a returning device remembers its register, so most shifts start by typing a password.
One person per register: only one active session per register, a quick switch-user handover from the lock screen, and an admin page where a manager can sign a register out remotely.
Selling from the real catalog: the register searches the same products the website sells, at the register's own store price, with custom-sale lines for items that are not in the catalog.
Split tender: cash, card on the payment terminal and in-store financing in any combination, with every tender stored on its own so it reconciles everywhere.
Layaway at the register: a configurable minimum deposit, instalments taken at any register, and partial release when a customer has paid enough to take one piece home, with a printable release slip.
Open and close the store: denomination counting, a manager's sign-off at close, a next-day float and bank deposit worked out for the staff, and an end-of-day Z-report that prints and can be emailed.
Returns that respect payment rules: register sales are refunded at the register. Website orders are sent to the admin, so the original card is refunded through the payment gateway instead of cash leaving the drawer.
Commission and time clock: commission by salesperson with rates per category or per product, automatic clawback on returns, and a clock-in and clock-out for every shift.
Manager reports: shift and drawer history with over and short amounts, hours for payroll with a CSV export, and commission, each limited to the stores a manager is responsible for.
ERP export: every register sale becomes a sales order in the retailer's ERP, with the right salesperson, location and one payment line per tender.

How it works

The store opens. A staff member signs into the register and opens the store with the counted float. The register is now tied to that store's prices and stock for every request it makes, whatever the browser did before.
A sale is rung up. The salesperson adds products and attaches the customer. Walk-in customers without an email address still get their own customer record, so the ERP keeps one record per person.
The customer pays. The tender screen collects against the remaining balance: some cash, a card charge for part of the total, a financing amount with its authorization number. If the deposit clears the minimum, the sale can become a layaway instead.
The order is placed. Register orders get their own store view and order number sequence, so the business can always tell a showroom sale from a web order. A paid-in-full sale is invoiced and completed on the spot.
The ERP gets the order. The sale is queued for export right after it is placed, and a scheduled job picks up anything the first attempt missed. If the ERP is unavailable, the sale waits in the queue and the register carries on.
Layaway payments arrive over time. Each instalment, at any register, is posted to the same ERP order in the same shape the online layaway payment page uses, so the balance agrees whether the customer pays in store or online. At a zero balance the order completes on its own.
The store closes. Staff count the drawer by denomination. The count is checked against the total, a manager signs off, and the Z-report shows expected and counted cash, over or short, the deposit and the sales by tender. The registers then lock until the next opening.

Under the hood

Mage-OS (Magento 2 open source): the register's sales, layaway, end-of-day, commission, time clock and reporting logic are custom modules exposed through Magento's REST API, so the register app holds no business rules of its own.
A single-page register app: a fast JavaScript app served from the store itself and built for touch screens and receipt printers, with no separate server to run.
The retailer's ERP (Microsoft Dynamics NAV): sales orders, customers and payment lines are written through its web services by the same export pipeline as web orders. We added small extension points to that pipeline, so web orders behave exactly as before.
The store-pricing layer: the same per-store prices and stock that power the website's store picker, pinned to the register's location on every call.
Payments: a card terminal for card tenders, offline methods for cash and in-store financing, and the website's own gateway for refunds of online orders.
Queues and cron: an export queue with a scheduled safety net, and scheduled reports.
Store-scoped admin: every POS admin page uses the same access model as the rest of the retailer's admin. A manager sees only their own stores, and a user with no stores assigned sees nothing.
Tests: the point-of-sale modules carry more than 140 automated unit tests, and every flow above was walked through end to end against a test copy of the ERP.

What it changed

The register is in the retailer's staging environment, where each flow above was tested end to end against a test copy of their ERP. The store-by-store rollout is still to come, so we have no sales figures to report. This is what the retailer can now do:

One catalog, one set of prices: showroom and website sell the same products at the same store prices, from one admin.
No double keying: a register sale reaches the ERP as a complete sales order, with salesperson, location and every payment line, without anyone re-typing it.
Layaway that agrees everywhere: a deposit taken at the register can be paid off online, and an instalment taken today reconciles in today's drawer, even when the layaway was opened months ago.
Daily cash discipline: every store opens with a counted float and closes with a manager-approved count, a deposit figure and a Z-report.
Fair pay data: hours for payroll and commission that is taken back automatically on returns, in reports each manager can only see for their own stores.
Safer refunds: a card-paid website order can no longer be refunded in cash at a register by mistake.

Could this work for you?

A point of sale on the same platform as your website makes sense when your stores and your website sell the same things:

retailers with showrooms and big-ticket sales;
retailers that offer layaway, deposits or in-store financing;
chains that pay commission on the sales floor;
any business that already keeps its books in an ERP and wants every in-store sale to land there without re-keying.

We build these systems on Mage-OS and Hyvä, connected to the ERP and payment providers you already use. If your store is still on Magento 1 or an older Magento 2, we can move it first: see our Magento 1 to Mage-OS and Hyvä migration, our Magento 2 to Mage-OS and Hyvä upgrade, or all migration options.

See everything we offer on our services page, or tell us how your stores sell and we will tell you how we would approach it.