Transaction ingestion
Sales, refunds, voids, discounts, tax lines and tender types pulled per location and normalised into one model, including offline transactions posted late.
Solution
POS Integration
We connect point of sale to the rest of your business so sales, stock, customers and loyalty stay consistent across the counter, the website and the back office.
Overview
What the system does
A point of sale system records the transaction at the counter. Everything else you want to do with that transaction happens somewhere else: stock, accounting, loyalty, marketing and reporting.
Without integration, each of those runs on a partial view. Online stock does not match the shelf, a customer who buys in store is invisible to the loyalty programme, and the month end reconciliation is manual.
POS integration joins the counter to the rest of the estate, in the direction each piece of data should flow.
Who needs this
Retail and hospitality operators connecting POS locations with ecommerce, stock or reporting.
What we build
Model menu or catalog identifiers, modifiers, taxes, locations and tender references. A sale, refund and stock adjustment are different events. Integration design must account for terminals that go offline and upload events later.
Modules
Core modules
Catalogue synchronisation
Products, variants, barcodes, prices and modifiers kept aligned between the POS, the website and the inventory system, with one owner per field.
Inventory reconciliation
Stock movements from sales, returns, receipts, transfers and counts applied to a single ledger, so online availability reflects the shelf.
Customer unification
In store and online customers matched into one profile, so history and loyalty follow the person rather than the channel.
Loyalty and promotions
Points, tiers, vouchers and offers applied consistently at the counter and at online checkout, with one balance.
Accounting export
Daily journals by location with tender breakdown, tax summary and discount treatment, in the shape your accounting system expects.
Multi location handling
Location aware pricing, stock and reporting, with transfers and inter location visibility.
Reporting
Sales by product, hour, staff member and location, margin where cost is available, and comparison against prior periods.
Architecture
How it fits together
A typical implementation flow, with explicit responsibilities at each boundary.
Integrations
- Point of sale platforms with an available API or export
- Ecommerce storefronts
- Inventory and order management systems
- Accounting software
- Payment processors and terminals
- Loyalty and messaging platforms
- 01
Receive
Verify POS events and retain provider event identifiers.
- 02
Apply
Map sale lines and inventory effects to the owning systems.
- 03
Balance
Reconcile refunds, settlements and delayed offline transactions.
Security and controls
Design for the exceptions, not just the happy path.
Keep PAN and sensitive authentication data out of the integration. Terminal and processor APIs should expose references, not raw card details. Protect refund permissions and store credentials per location.
Technology options
We select the final stack after reviewing your existing systems and operating requirements.
Security and IP practicesFit
Industries that use this
FAQ
Questions people actually ask
Can online and in store stock be the same number?
Yes, once one ledger owns the position and both channels post movements to it. The practical limit is how quickly your POS reports a sale, which sets how tight the buffer needs to be on fast moving lines.
What happens to sales rung up while the POS is offline?
They arrive late, out of order, and sometimes duplicated. Ingestion is idempotent on the transaction identifier and the ledger applies movements by event time, so a late batch settles correctly.
Can we match a walk in customer to an online account?
Where there is a shared identifier such as an email address, phone number or loyalty card, yes. Without one, matching is a guess and we do not do it silently.
Does this work across several locations?
Yes. Pricing, stock and reporting are location aware, and transfers between locations are modelled as movements rather than adjustments.
Do you handle the card payment itself?
No. Card processing stays with your processor and terminals. We read the transaction record. Sawhorse is not a payment processor and does not build card processing infrastructure.
What if our POS has no API?
We work with scheduled exports or a supported reporting feed. Freshness is lower and we say so before you commit.
Let’s talk about the system you need.
Tell us where the current process breaks down. We can map the workflow, examine the integration requirements and define a practical scope for the build.
- A mutual NDA is signed before project details are shared.
- Scope is fixed in writing before any build starts.
- You own the source code, the IP and the documentation at delivery.
- Support plans are available and tailored on a discovery or technical call.