An online store order can be paid at a physical payment terminal when the order, terminal and provider payment are explicitly linked. The employee starts payment from the order, the customer pays on the device and the online store applies the payment transition only after the provider confirms the correct payment and amount.
This differs from a standalone card transaction alongside WooCommerce. Without an integration, the order does not know whether payment succeeded, staff may open the wrong order and reconciliation becomes manual work. Design the terminal as one channel within the order process, including failure, cancellation and retries.
Link four identifiers
A robust workflow identifies at least the WooCommerce order, chosen branch, physical terminal and provider payment. Store provider references against the order, but show staff only what they need in administration. A terminal name such as “Utrecht counter left” is more useful than a technical device code.
Before starting, the employee must see the order number, amount due and terminal. Have the server check that the order is still payable and the terminal is available for that location. Then start one specific payment attempt. Do not silently reuse an ongoing attempt for another order, and make clear when retrying is safe.
Design statuses for the counter
| Situation | What the employee sees | What the system does |
|---|---|---|
| Awaiting customer | Terminal and amount, with cancellation | Order remains unpaid |
| Payment confirmed | Succeeded, with provider reference | Checks the amount and processes payment once |
| Declined or cancelled | Understandable outcome | Allows a controlled retry |
| Status unknown | Do not request another payment | Retrieves the current provider status |
| Terminal unreachable | Device unavailable | Retains the order and offers an appropriate alternative |
Do not rely only on a spinning indicator. State what the customer or employee should do now. A transaction may be complete on the device while the browser has not received an update. The online store must therefore be able to retrieve the current status from the provider and process a later provider confirmation too.
Make cancellation work on both sides. Closing the browser alone may not end the terminal request; cancelling only on the terminal may leave the online store waiting. Send cancellation to the provider where possible, then retrieve the final status. A timeout means “outcome still unknown”, not automatically “failed”. Keep the order out of fulfilment in that state until its status is reliably established.
Fictional example: showroom collection
Interior shop Vormkracht lets customers order online and pay in its showroom. Employee Inez opens order 1842, sees the outstanding total and selects “Ground-floor showroom”. The terminal displays the amount. While the customer pays by card, the tablet connection briefly freezes. Inez does not press start again; the screen reports that the outcome is being checked.
After recovery, the online store retrieves the current payment status. The provider confirms the same order reference and amount. Payment is processed once, and WooCommerce moves the order to the appropriate paid status according to product and process configuration. For physical products, “Processing” generally does not yet mean fulfilment is complete; warehousing and delivery follow. If the amount does not match, the order remains under review.
If sales, stock and administration must also be updated afterwards, design the complete data flow. A WooCommerce–AFAS integration is more than a single export, for example; errors and recovery actions need an owner too.
Vormkracht also restricts terminal buttons to employees at the relevant branch. An online store administrator can configure devices, while counter staff may only start payment for an open order. The system records who began the action without showing complete payment details in ordinary order notes. Logging supports investigation without creating a new privacy or security risk.
Terminal acceptance checklist
- Staff see the order, amount, branch and terminal before starting.
- Only authorised roles can begin or cancel a payment attempt.
- Two terminal actions cannot complete the order simultaneously.
- Browser polling and provider messages lead to the same final status.
- The server checks the provider reference, currency and amount.
- An unknown status requires a check, not a second payment.
- The interface works on the device actually used at the counter.
- Logs contain references and outcomes, not unnecessary payment details.
Also prepare a short counter procedure for power failure, a faulty device and a customer leaving during payment. Technology can record status reliably; staff also need a clear course of action. Read more about reliable workflows between online stores and ERP.
Discuss with Yindle how terminal payments fit your order process.
For a WooCommerce terminal flow with authorized orders, provider verification and showroom access, see Yindle Terminal Payments and the guide to preparing Mollie POS terminal payments.