Only show a counter or terminal payment when the order context matches the physical location. Use an explicit branch or collection choice, rather than just the IP address, user or a generally available payment method. This prevents someone ordering from home from choosing a payment option that can only be completed beside a terminal.
Availability is a business rule. The method can depend on the shipping method, selected collection location, staff member’s role and configured terminal. All these conditions must be checked again on the server, even if JavaScript has already hidden the option from view.
Define one source for location context
Choose which data determines where payment takes place. For click-and-collect, this is usually the selected collection location. For an order created by staff, it may be an explicitly selected branch. A staff account can provide an extra check, but someone may temporarily work in another store; a role or profile alone is therefore not always enough.
Associate each location with a recognisable list of terminals. Show staff a clear name and, where useful, a position rather than a technical ID. If exactly one device is available, it can be preselected. With several devices, a deliberate choice is safer.
| Condition | Show terminal payment? | Reason |
|---|---|---|
| Collection at a location with an active device | Yes | The customer and terminal are physically together |
| Home delivery through the normal checkout | No | The customer cannot reach the terminal |
| Collection location without configuration | No | No reliable device selected |
| Unauthorised staff member | No | Starting a counter payment is restricted |
| Location changes during checkout | Reassess | The previous terminal choice is no longer valid |
Check again when payment starts
A visible payment method is not permission in itself. Between displaying it and clicking, the shipping method may change or a terminal may be disabled. Have the server validate the order, location, terminal and permissions again when payment starts. If rejected, offer an understandable route: choose another method or ask an authorised staff member.
Remove a previous terminal choice when the customer switches from collection to delivery or changes branch. Otherwise, hidden session data may reappear later. The same applies to a copied order or returning through browser history. The current order context must always take precedence.
Define behaviour during a temporary outage separately from configuration issues. ‘Terminal does not exist for this location’ requires administration; ‘device currently unreachable’ may call for a temporary operational choice. Do not show customers internal device statuses. Counter staff may see more context, but even there a concrete next step matters more than a raw provider message.
Fictional example: three stores, five terminals
Outdoor store Kompas has three branches. Rotterdam has two terminals, Delft one and Leiden temporarily none. A customer chooses collection in Delft. Checkout shows counter payment as an option, but does not start payment yet; that only happens when the customer is at the counter and a staff member opens the order.
A day later, the customer changes the collection location to Leiden by phone. The previous terminal choice is removed and the method disappears because that branch has no active device. The staff member offers another supported payment route. The system makes no assumptions based on the original selection.
For each terminal, Kompas records only the identification and location needed operationally. The public checkout never receives a list of all devices or internal labels. In administration, an authorised user can deactivate a terminal without deleting historical order references. This keeps old transactions explainable while new payments respect the changed configuration.
When location, order and stock are also managed in other systems, define the source for each data item. The explanation of reliably integrating an online store and ERP shows why explicit ownership prevents errors.
Location-specific acceptance test
- Test each branch with an active, inactive and missing terminal.
- Switch between delivery and collection after checkout has loaded.
- Change the collection location and check that old session data disappears.
- Try starting payment with a customer account and an unauthorised staff member.
- Disable a terminal while the order page is open.
- Check mobile, desktop and the actual counter device.
- Make error messages specific without exposing technical configuration.
- Document who manages terminals at each branch.
Keep location management central and small. Free-text fields for branch names quickly produce variations that can no longer be linked to a terminal. Use stable internal identifiers and show users recognisable labels. For further integration of order and branch context, Yindle Connect can make the process boundaries explicit.
Also schedule a periodic check with the people on site. A technically active terminal may have been physically moved, replaced or taken away from the intended counter. Have branch managers confirm the recognisable names and remove unused configurations in a controlled way. This keeps the software’s map aligned with reality.
Let Yindle work out the availability rules for your counter payments.