What iRetail PRO does

One product in four places: the register, the store's back office, the chain's hub and its console, and the API your own systems call. Here is what each role gets.

Cashier

A sale is scan, scan, scan, pay — with the keyboard alone if you like.

  • A scan field that finds items by barcode, PLU, SKU, name or meaning; 3* before a scan sells three.
  • Cash, card, EBT and split tenders through the terminal on the counter; tips on the terminal or typed in.
  • Returns and voids refunded to the same card; a senior's approval wherever a limit asks for one.
  • Several cashiers on one register's shift, each with an X report; a simplified mode with larger targets.
  • Variants by a grid, a serial number per unit, age checks from the ID's barcode.

Store manager

The back office runs the store from its node, on a desktop or in a browser.

  • Catalog, groups, taxes, prices and promotions; import from CSV, Excel or a Google Sheet.
  • Stock with lots and expiry, FIFO and FEFO; receiving, write-offs, price changes and inventory counted from several devices at once.
  • Purchase orders, supplier returns, re-grades, kits and production from a recipe.
  • Loyalty cards and points, vouchers, gift cards, stamp cards, partner codes and employee bonuses.
  • Sales, stock, tax and restaurant reports, exported as CSV or XLSX; shelf tags and labels.

Chain manager

The hub is the chain's center; the same back office is its console.

  • The catalog and prices owned centrally, with stores asking for changes and you approving them.
  • Dashboards over sales and stock, written as YAML, with drill-downs and currencies converted at each day's rate.
  • Transfers between stores, each store's sync state, health and alerts, encrypted backups kept by the hub.
  • Releases rolled out store by store in waves, each wave only after the last is healthy.
  • A private WireGuard network between the hub, the stores and their devices, inside the product.

Integrator

Everything the apps do goes through the same API, checked against published contracts.

  • REST, GraphQL and WebSocket from one domain layer and one permission layer.
  • An MCP server for external agents; every write it proposes waits for a person.
  • Docker Compose for a store and a small hub, a Helm chart for Kubernetes, Terraform for AWS, GCP and your own servers.
  • Prometheus metrics, OpenTelemetry traces and Grafana dashboards for the nodes.
  • Card terminals by Stripe, Adyen, Clover, Worldpay and Fiserv through a device gateway on the store's PC.

Offline is a state, not an error

A store keeps working without its hub for as long as it takes; a register keeps selling without its node until the end of the shift, from its own copy of the catalog, and sends its queued receipts once the node is back, each exactly once.

Weighed goods

Live weight from Mettler 8217 and NCI scales through the gateway, added only on a steady reading above zero, never typed. Scale labels with price or weight are read at the register; tare, PLU lists and shelf labels come with the grocery pack.

Modules are switches in one build

Every module ships in the same image and the same apps; the license key turns it on. A store without a module never downloads anything extra, and the US pack (sales tax by category, SNAP, deposits, the pseudoephedrine logbook) is the first country pack.

The assistant and MCP

The assistant in the back office runs on your organization's own model key — OpenAI, Anthropic, Gemini or any OpenAI-compatible server — with no proxy of ours. It reads through the same permissions as a person, masks cards and phones, and every change it proposes is shown in full and approved by someone with the right role.

Payment terminals, scales and printers are tested against emulators written from their public documentation; certification with real hardware is listed on Changes.