At a counter, in a queue, on a route, or at a pop-up, the payment endpoint has to be ready before the buyer is. A powered terminal is not enough: the app, keys, parameters, connectivity, and spare rule all decide whether the transaction can happen, and the queue is the first to find out when one of them is missing.
We scope that operating stack around each pay point—the terminal, terminal management system (TMS), keys, fleet visibility, and the spare drawer—then write the acquirer and support boundaries into the proposal so nothing important sits between two owners.
Stack used here
| Layer | Piece |
|---|---|
| Hardware | Payment and point-of-sale handhelds |
| Software | Terminal management, fleet insights, mobile device management (MDM) if operating-system lock is required |
| Power | S2000 Pro or S1000 Pro for shops on unreliable grids |
Your acquirer relationship remains with you. We make the endpoint operable and define who owns each interface around it.
Related: Hardware and software · Payment handhelds
FAQ
What is a “pay point” in this stack?
Any place a payment is taken: counter, queue-bust, delivery handoff, temporary stall. Each pay point needs a terminal class, a TMS profile, and a spare rule.