In-store payments overview

The in-store channel takes a card-present payment on a physical terminal in one of your stores. It is built for a billing application — a point-of-sale system, a kiosk, a back-office app — that rings up a bill and needs the customer to pay at a device.

The model

An in-store payment is always taken somewhere specific, so the channel adds a small hierarchy under your business:

Your business
└── Store            a physical location
    └── Terminal     a payment device at that location

You register each store and each terminal with Boundless once, using your own identifiers for them. Every payment then names the store and terminal it is being taken at.

Synchronous request, asynchronous outcome

An online payment is decided while your request waits. An in-store payment is not: the bill goes to a device and is decided by whoever is standing at it. So the flow has two parts.

Part one — you ask Boundless to take the payment, and it returns immediately with the payment in a waiting state and an id you can track it by. Nothing has been charged yet.

Part two — the customer pays at the device, and Boundless resolves the payment. You learn the outcome two ways:

• a webhook to an endpoint you register (recommended), or
• a status call you make yourself, at any time (a reliable fallback, and useful for a check-status button on your point of sale).

Both give the same answer, and asking for the status while a webhook is also arriving is safe.

What you never handle

The card is read by the terminal and the acquirer, never by your application. Boundless returns only masked display data — the last four digits, the card brand, an approval code. Your integration never sees, stores, or transmits a card number.

What you build

The rest of these guides walk the integration in order: authenticate, register your stores and terminals, take a payment, and receive its outcome.