Named for what they sell
Goods become Products and Product Orders. Services gain Appointments and Calendar. Events get Tickets, Attendees and Check-ins. A merchant selling in more than one way gets each relevant group.
One console.
Made for every merchant.
Your staff and your merchants run the whole business from one admin app. What each merchant sees is generated from what they sell, what their products can do, and what your deployment includes.
The app fits the trade
Their business, already in place
There is one route tree in the codebase. Intent gives its shared routes the names a merchant expects, product behaviours narrow what appears, and installed capability removes anything the engine cannot serve.
Only useful tools appear
Shipping appears when something is shippable. Availability and resources appear for bookable products. A route whose backing package was never installed is absent, not disabled.
One app at every size
The same console works on a phone behind the counter and a laptop in the back office, on your domain and carrying your institution’s brand.
A day in the console
From today view to final report.
Start with what needs attention.
Orders awaiting action, recent payments, and current business activity appear before the catalogue of every possible platform feature.
Move one record forward.
A counter sale, website order, or invoice opens with its customer, lines, payment state, and fulfilment work attached.
Change how the business trades.
Managers maintain products, prices, stock, locations, and staff access. Installed packages decide which fields and routes exist.
Support without borrowing a login.
An institution support role can open the same merchant and operational context while merchant only and institution only controls stay separate.
Finish with numbers that already agree.
Reporting reads the Commerce Engine directly, so the team does not compare separate counter and online totals before closing.
One record, every channel
A complete view of the business, without a sync
A web sale, a counter sale and a payment link resolve to the same order against the same customer. The console is a surface on the Commerce Engine API, so there is no second database to reconcile.
- Orders and fulfilmentPicking and shipping for goods, a calendar for services, and a door list for events.
- Customers and locationsEvery sale builds the merchant’s own customer history, while locations, stock and staff remain together.
- Returns and refundsA return stays attached to the original order and clears through the rails that took the payment.
“The merchant sees a console shaped around their trade. Our support team sees the same thing, with the right access, and works from the same records.”
Built for institutions that own the merchant relationship
Staff and access
Everyone works in context
Merchant staff
A merchant adds their own people and assigns roles against the routes their business actually generated.
Your support team
Institution-side roles work in the same console, so field and support teams can help without a second tool or copy of the data.
Cashier sessions
Each till session joins the staff member, enrolled device, location, and sales completed while that person was signed in.
Connected by design
More capability, without another back office
Connect flows, the merchant website and Retail Rails all read and write the same engine records. Merchants can automate follow-up, sell online and take payment at the counter without learning another system.
Explore Connect Explore in person payments