Skip to main content
KioskCraft
Your enquiry

Software & Management

Integrations with your existing systems

Kiosks, displays and sales software are most useful when they share data with the systems you already run. We scope and build integrations with point-of-sale, payment, booking, CRM and stock systems through documented APIs and webhooks, subject to what each supplier allows.

What integration means, and what it depends on

An integration is an agreed, documented way for two systems to exchange data: a kiosk order appearing in your till, a check-in updating your booking system, an enquiry creating a record in your CRM, a display showing live availability from your stock system.

Every integration has two sides, and we control only one of them. Whether a connection is possible depends on the other system offering a suitable interface, its supplier allowing you to use it, and the quality of the documentation and test facilities they provide. For that reason we never promise compatibility with a named system in advance. We assess each one during discovery, and the scope states what will be connected, how, and what it depends on.

Where integrations sit

  • In the centre:

    Kiosk or display application

    The software your customers and staff use.

    APIs and webhooks

    It exchanges data two ways with each of the systems listed next.
  • POS system

    Orders, products and prices.

  • Payment provider

    Card payments through your provider.

  • Booking system

    Appointments, tables and check-in records.

  • CRM

    Customers, enquiries and follow-up.

  • Stock and product data

    Availability, prices and specifications.

  • Other systems

    Anything with a suitable interface.

Each integration depends on the third party's interfaces and approval process.

Kiosk and display software exchanges data with point-of-sale, payment, booking, CRM and stock systems through an integration layer of APIs and webhooks. Each connection is assessed and agreed individually. Illustrative diagram.

What kiosk and display software typically connects to

  • POS systems

    Sending kiosk orders into the till, reading the products and prices it holds and keeping sales reporting in one place. This depends on your till supplier offering a documented interface.

  • Payment providers

    Connecting the kiosk application to a card terminal so that the amount is passed across and the result comes back. The terminal, the merchant agreement and any certification are your payment provider's, and their process governs what is possible.

  • Booking systems

    Looking up, creating or confirming appointments, reservations and arrivals, so that check-in kiosks and reception staff see the same information.

  • CRM systems

    Creating enquiries and contacts with the right consent recorded, avoiding duplicates and giving sales staff the context captured at the kiosk.

  • Stock and product data

    A single maintained source for product details, prices, images and availability, feeding kiosks, displays and AI-assisted recommendations.

  • APIs and webhooks

    An API lets one system ask another for data or send it an instruction. A webhook lets a system announce that something has happened, such as an order being ready. We use whichever the other system supports and design for delays, retries and failures.

  • Authentication requirements

    How our software proves its identity to the other system — keys, tokens or single sign-on — where credentials are stored, how they are rotated and how access is limited to what the integration needs.

What we need from your other suppliers

Asking for these early is the most useful thing you can do to keep an integration project on track.
  • Current API documentation for the exact product and version you use
  • Sandbox or test-environment access, with test data, that does not touch your live system
  • Written confirmation that your licence or plan includes API access, and any extra charges that apply
  • Confirmation of data ownership: that you are entitled to extract and use your own data through the interface
  • Rate limits and usage quotas, so that the integration is designed to stay within them
  • The authentication method, and how credentials are issued, rotated and revoked
  • A technical contact who can answer questions during build and testing
  • Their policy on changes and withdrawals, so that you know how much notice you will get before an interface changes
  • For payments: the provider's supported terminals, integration method and certification steps for unattended use. Certification is the provider's process and timetable, not ours.

How we approach an integration

  1. Assess

    We read the documentation, confirm access and try the key calls in a sandbox before committing to a design.

  2. Define the contract

    We write down which data moves in which direction, what triggers it, which system is the master for each field and what happens on failure.

  3. Build and test

    We develop against the sandbox, including the awkward cases: timeouts, duplicates, partial failures and items that no longer exist.

  4. Prove it on live systems

    With your supplier's agreement, we run a controlled test against the live system and a pilot device before rollout.

  5. Monitor and maintain

    Integrations break when the other side changes. We agree how failures are detected, who is told and how supplier changes are handled under your support scope.

Decisions to make for every integration

Decisions to make for every integration
DecisionWhy it matters
Which system is the master for each piece of dataPrevents two systems overwriting one another with different prices, stock figures or customer details.
How fresh the data must beLive availability needs a different design from a nightly product update.
What happens offlineWhether the kiosk queues transactions, refuses them or falls back to a manual process.
What personal data crosses the connectionOnly what the process needs should move, for a stated purpose and with an agreed retention period.
Who supports the connectionWhen something fails, it must be clear whether to contact us, your IT team or the other supplier.

Scroll sideways to see the whole table.

What this includes — and what it does not

What is and is not included

Kiosk Craft does not hold a library of ready-made connectors and does not promise compatibility with any named point-of-sale, payment, booking, CRM or stock system. Each integration is assessed, scoped and built for your project, subject to the other supplier's interface, permission and documentation.

Third-party API fees, licences, payment certification and any work charged by your other suppliers are outside our quotation unless it says otherwise. A hardware capability, such as a scanner, an NFC reader or a payment-terminal bracket, does not by itself mean the corresponding software integration exists.

Hardware that fits

Product families that suit the applications on this page. Options are confirmed with your quotation.

Guides to read next

Frequently asked questions

Will your software work with our till system?

We cannot say until we have seen its interface. Integration depends on your till supplier offering a documented API, including it in your plan and giving us test access. Send us the product name and version and we will tell you what we find. If no suitable interface exists, we will explain the alternatives, such as running alongside the till.

Can a kiosk take card payments through our existing provider?

Possibly. Your provider decides which terminals and integration methods they support for unattended use, and any certification is their process. We ask you to involve them early. Card terminals are supplied by your payment provider unless separately agreed.

Does NFC hardware on a kiosk mean it can accept contactless cards?

No. An NFC reader can be used with compatible cards and tags for purposes such as membership or loyalty, subject to software being developed for it. Accepting bank cards requires a payment terminal and a service from a payment provider. The two should not be confused when specifying hardware.

What if our supplier has no API?

Options include a scheduled file export and import, a supported export to a shared database, or keeping the systems separate with a clear manual step. We avoid unsupported methods, such as reading another product's database directly without the supplier's agreement, because they tend to break and can breach licence terms.

Who is responsible when an integration stops working?

That is agreed in advance. The scope sets out how failures are detected and who investigates. If the cause is a change on the other supplier's side, fixing it may be new work. A support arrangement can include monitoring and maintenance of integrations, on the terms set out in your quotation.

Tell us which systems need to connect

List the systems you use, with product names and versions if you have them, and what you want to pass between them. We will reply by email with what we need from each supplier.