Card terminals

A card terminal lets a customer pay by card at the outlet — tapping at a kiosk, or handing a card to a member of staff at the register. The card is read by the terminal, never by the app.

Where to find it

Dashboard → Settings → Configuration → Feature (/settings/settings/feature-settings) — Admin, Co-Admin

Terminal payments are enabled separately for the kiosk and the register. Bind a reader to a device at Dashboard → Operations → Devices (/configuration/devices/list).

Setting one up

1. Have a reader supported by your payment gateway. Terminal support is gateway-agnostic: whichever gateway your account uses, its own card-present readers are the ones that work. Your gateway supplies and registers the hardware.

2. Record the reader against your payment configuration, so the platform knows which reader belongs to your account.

3. Bind a reader to a device in Devices if you have more than one — otherwise a kiosk in the lobby could send its payment to the reader at the counter.

4. Enable terminal payments in Feature Settings, separately for kiosk and register.

5. Take one live test payment on each device, then refund it.

Taking a payment

The amount goes to the reader, the customer taps or inserts, and the result comes back to the device — approved, declined or cancelled. A payment can be cancelled from the device while it is waiting.

The wait before a payment is given up on is configurable per surface. The kiosk default is longer than the register’s, because a customer alone at a kiosk takes longer to find their card than one being served.

Tipping on the reader

The register can ask for a tip on the terminal itself, which is the pattern customers expect from a card machine. When it is on:

• The reader prompts for the tip, and the customer chooses on the reader.
• The tip is confirmed by the gateway rather than entered by staff.
• The tip is not added to the order total — it rides alongside it, so your order figures stay clean and tips are still reported.

The kiosk asks for tips on screen instead, before payment, using the presets you configure.

When a reader is offline

A reader that is definitively unreachable fails fast and says so, rather than leaving a customer watching a spinner. The kiosk offers pay-at-counter instead; the register can take cash or another method.

Common causes, in the order worth checking: the reader has lost Wi-Fi, the reader is powered off or asleep, the reader is bound to a different device, or the gateway is having an incident.

A captured payment is always honoured

If a card is charged but something fails afterwards, the money is not lost and the customer is not charged twice — the order is completed with the payment that succeeded, and a reconciliation sweep catches anything left in between. Never re-run a payment because a screen looked stuck; check the order first.

Refunds

Card-present refunds are completed at the terminal or in your gateway’s dashboard, not from the device. The register records the refund against the order so your reporting is right, but the money is moved on the gateway side.

Plan for it: whoever handles refunds needs access to the gateway dashboard, or a process for handing the refund to someone who does. See Refunds & disputes.

Troubleshooting

Symptom	Try this
“Terminal offline”	Check the reader’s power and network first; it is nearly always one of those
Payments go to the wrong reader	Bind the reader to the device in Devices
The terminal option is missing	Terminal payments are enabled per surface in Feature Settings
A payment took the card but the order did not appear	Check the order before retrying — a captured payment is always attached to its order
Declines with no obvious cause	Declines come from the card issuer; ask the customer to try another card
Tips are not appearing	Reader tipping is a register setting; the kiosk asks on screen instead
A refund is not reaching the card	Card-present refunds are completed at the terminal or in the gateway dashboard

Related: POS register · Self-order kiosk · Gateway setup · Refunds & disputes