Service · POS integration

Till and online shop: assess first, then connect.

If you work with a point-of-sale system (POS) in your shop, the question is how stock, prices and orders reach the online shop. We assess, coordinate and – where it holds up – build an integration. Provider by provider.

Important upfront

There is no integration that “just works” with every POS system. Whether and how your system can be connected, we assess for each vendor, product and version individually. Until then we promise nothing.

Sound familiar?

Typical starting points

  • You have a POS system in the shop and want to sell online without maintaining stock twice.
  • Your stock does not match between online and in store.
  • You want prices or promotions maintained in one place.
  • Your POS vendor offers an interface, but nobody knows what is possible with it.

What we clarify

Questions about your POS system

We clarify these points in the feasibility assessment before promising anything:

  • Which vendor, product, version and licence tier?
  • How many locations or tills are affected?
  • Is there a documented interface (API) or export function? What does it cost?
  • Is vendor approval or involvement required?
  • Is there a sandbox and are there test credentials?
  • Who owns the access credentials, and who is responsible for changes to the POS?
  • Which other systems are involved, such as inventory management or accounting?

Data flows

What could flow between till and shop

For each kind of data we clarify where it is maintained as the “source of truth”, which way it flows and how often.

  • Products and variants

    Item numbers, names, variants, tax rates. Where is master data maintained, and how are changes carried over?

  • Prices and promotions

    Regular prices, discounts and promotions. Can they be mapped through the interface, or only partly?

  • Stock per location

    How current does stock need to be, and what happens when items are sold in store and online at the same time?

  • Customer data

    Only if necessary and agreed from a privacy perspective. It is often sensible to keep customer data separate.

  • Orders

    Should online orders appear in the POS system, and if so in what form and with what payment status?

  • Returns and gift cards

    How are returns, refunds and gift cards handled consistently across both channels?

Phases

Step by step, with decision points

After each phase you decide whether to continue.

  1. Feasibility

    Review documentation, interfaces, permissions and costs. Result: a written assessment of whether and in what form an integration makes sense.

  2. Prototype in the test system

    Try the most important data flow with test credentials. Result: evidence instead of assumptions.

  3. Pilot and reconciliation

    Limited, controlled live operation: does the data match? What happens on errors?

  4. Operation and monitoring

    Failed syncs become visible, and there is an overview for checking data states.

Diligence

What we watch on the technical side

  • Error handling and retries

    Interfaces are sometimes unreachable. Syncs are retried without booking stock twice.

  • Reconciliation and conflict rules

    It is defined in advance what applies when till and shop show different states, and an overview is provided for checking.

  • Security

    Credentials are kept server-side only and never in source code. Permissions are limited to what is needed.

  • Logs without personal data

    We log so that errors can be found without storing unnecessary personal data.

When it does not work directly

Honest alternatives

Sometimes there is no usable interface. Then we talk about simpler routes.

Possible routes (feasibility open)

  • Middleware approved by the vendor, or a third-party connector
  • Controlled import and export (e.g. CSV), scheduled or manual
  • One-way or delayed sync only, e.g. stock only
  • A separate online range with its own stock maintenance

What we will tell you then

  • Whether the effort justifies the benefit
  • Where the risks to data quality and stock lie
  • That switching POS vendor is sometimes the better solution – but not always
  • No promise that an alternative works before it has been tested

Till and tax law

A shop connection does not certify a till

A shop connection does not certify a till

Obligations around tills, receipts, records and tax (e.g. tamper protection and data exports) concern your POS system and your processes. An online shop integration neither fulfils nor certifies them. Clarify questions on this with your POS vendor and your tax adviser.

Outcome

What you have in hand at the end

Typical scope – we agree the exact scope in writing beforehand.

  • A written feasibility assessment for your vendor
  • If sensible: a tested prototype in the test system
  • Description of data flows, responsibilities and conflict rules
  • If implemented: a documented integration with monitoring and a reconciliation overview

Questions

Frequently asked questions

Which POS systems do you support?

We do not publish a list, because a promise without assessment would not be credible. Tell us vendor, product and, if known, version. If you do not know, we help find out.

What does the feasibility assessment cost?

The scope depends on how well the system is documented and whether test access exists. We agree the scope with you before any costs arise. Interface or licence fees from your POS vendor may come on top.

Do I need my POS vendor’s approval?

Often yes, for example for API access or changes to your licence. We clarify that in the first phase together with you.

What if my vendor has no interface?

Then we discuss alternatives such as controlled import and export. Whether they hold up in daily use only shows in testing.

You will find more answers in the general questions.

Want to know whether your till fits an online shop?

A short description is enough. We reply by email and suggest a time for a first conversation.