Retail and POS
Stores, online channels and the ERP behind them, in step
POS integration, stock and price sync, card payments, loyalty and e-commerce for retailers with many sites.
Overview
Retailers run on many systems that must agree: tills, web shops, warehouses, payment providers and the ERP. When they drift apart, stock is wrong, prices differ between channels and finance spends days reconciling.
We connect those systems so that sales, stock, prices and payments move between them reliably, and we build the customer apps and back-office tools around them. Stores keep selling when the network fails, and catch up when it returns.
Where we work
StoresShops, restaurants and outlets with tills, payment terminals and local stock.
What we build
- POS extensions, back-office apps and store dashboards
- Offline-safe sync between store servers and head office
Typical integrations
- POS platforms, payment terminals and the ERP
Online and marketplacesWeb shops, apps and marketplaces that sell the same stock as the stores.
What we build
- E-commerce front ends and order services
- Click and collect, returns and order tracking
Typical integrations
- E-commerce platforms, marketplaces, carriers and the ERP
What we build
POS and ERP integration
Sales, returns and end-of-day totals posted to the ERP, with prices, promotions and items sent back to every store.
Stock visibility
One view of stock across stores, warehouses and online, updated as sales and deliveries happen.
Online and mobile commerce
Web shops and apps that share products, prices and stock with the stores.
Loyalty and promotions
Loyalty programmes, vouchers and promotion rules that work the same way in every channel.
Store operations tools
Apps for stock counts, transfers, deliveries and staff tasks, built for use on the shop floor.
How it connects
Scroll sideways to see the whole drawing.
POS to ERP: every sale posted once
Sales flow from the tills to the ERP as events, and prices and stock flow back. A store that goes offline keeps selling and catches up. A posting that fails is retried, then handed to a person.
- Primary flow
- Asynchronous
- Exception path
The flow, step by step
- From POS terminals to Store or POS cloud server: Sales, returns and voids (primary flow).
- From Store or POS cloud server to Integration layer: Sales events and end-of-day totals, through an event queue, over REST/JSON (asynchronous).
- From Integration layer to ERP: Sales and stock movements posted, over OData · REST/JSON (primary flow).
- From ERP to Integration layer: Prices, promotions and item data, by API or file export, over REST/JSON (primary flow).
- From Integration layer to Store or POS cloud server: Price and stock updates, over REST/JSON (primary flow).
- From Integration layer to Retry queue: Posting failed (exception path).
- From Retry queue to Integration layer: Retried (exception path).
- From Retry queue to Store operations team: Still failing: alert with the details (exception path).
Scroll sideways to see the whole drawing.
Card payments: authorised at the till, settled later, reconciled in the ERP
The terminal or checkout asks the gateway, the gateway asks the acquirer, and the acquirer routes to the card scheme and issuer. Settlement files arrive later and are matched to sales and fees in the ERP. A timeout triggers a reversal so the customer is never charged twice.
- Primary flow
- Asynchronous
- Exception path
The flow, step by step
- From EMV terminal or online checkout to Payment gateway: Authorisation request, over EMV · REST/JSON (primary flow).
- From Payment gateway to Acquirer: Authorisation, over ISO 8583 (primary flow).
- From Acquirer to Card scheme and issuer: Routed to the issuer, over ISO 8583 (primary flow).
- From Acquirer to Payment gateway: Approved or declined, over ISO 8583 (asynchronous).
- From Acquirer to Integration layer: Settlement and fee files, over SFTP (asynchronous).
- From Integration layer to ERP: Settled sales, fees and payouts, over REST/JSON (primary flow).
- From Payment gateway to EMV terminal or online checkout: No response in time: automatic reversal, over ISO 8583 0400 (exception path).
- From Integration layer to Payments operations team: Settlement mismatch or chargeback (exception path).
Typical integrations
POS platforms
Tills and POS cloud services, through their APIs, export files or store servers.
Card payments
Terminals, gateways and acquirers, with settlement files matched to sales.
ERP
SAP S/4HANA, Microsoft Dynamics 365, Oracle NetSuite, Odoo and others, for items, stock and finance.
Warehouses and carriers
Warehouse systems and carrier APIs for fulfilment, deliveries and returns.
Engineering for the rules
Card data out of scope
We keep card data with the payment provider, through tokenisation and point-to-point encrypted terminals where they are available, which keeps PCI DSS scope small.
Customer data
Loyalty and order data is collected with consent, kept only as long as it is needed, and handled under GDPR and the local laws that apply.
Fiscal and tax rules
Where a country requires fiscal receipts or e-invoicing, we connect the certified devices or platforms it mandates and keep the records it asks for.
Questions and answers
What happens when a store loses its connection?
The store keeps selling. Sales are stored locally and sent when the connection returns, each with a unique identifier so that nothing is posted twice. Price and stock updates queue up in the same way. Operations can see which stores are behind and by how much, so a long outage is noticed straight away, not discovered at month end.
Link to this questionWhich POS systems can you integrate?
We integrate POS platforms through whatever they offer: cloud APIs, store servers, database exports or files. Before we estimate, we review the POS documentation and a sample of its data, because that decides the approach. Naming a POS platform or an ERP on this site does not mean a partnership with its vendor.
Link to this questionWhy does stock never match between the ERP and the stores?
Usually because the systems disagree on timing, units or what counts as a movement. Returns, transfers, damaged goods and sales during a stock count are common causes. We trace the differences, agree one rule for each kind of movement, and build the sync so it records every change with its source. Remaining mismatches go to a review list instead of building up.
Link to this questionWhat drives the cost of a retail integration?
The number of systems, stores and channels, how well the POS and the ERP expose their data, and how many exceptions need rules, such as returns across channels or split payments. Rolling out store by store adds testing effort too. We estimate after reviewing the systems and a sample of real transactions.
Link to this questionCan you roll out without closing stores?
Yes. We go live in stages, starting with a pilot store, and run the new integration alongside the current process until the totals agree. Changes in stores are scheduled outside trading hours where possible, and each stage has a way back if something does not work as planned.
Link to this questionWho supports the integration after go-live?
We can monitor and support it under a support agreement, or hand it over to your team with documentation, alerts and a runbook. Either way, a failed message lands in a queue with its reason, so it can be fixed and replayed rather than lost.
Link to this questionTell us what you need to build or connect.
Describe the systems, the timeline and the constraints. The right engineers take it from there.
- Our team will call you within 24 hours during your preferred time slot
- Our team is available 24/7