Token equipment
Token Dispenser Offline Payments: Check Network Loss and Recovery
Review connectivity dependencies and recovery separately for local control, cash validation, cashless payments and reporting.
Define what offline means in the proposed setup
Token dispenser offline behavior depends on which service loses its connection and at which transaction stage. Review payment authorization, token delivery and report synchronization separately, then test recovery.
The reference kiosk sheets do not specify network-loss behavior. Any continued offline payment needs the chosen provider’s authorization and the exact device/controller/software configuration.
Use a stage-specific loss-of-network worksheet
Identify the connection being interrupted and agree the supplier/provider-supported test procedure. Record screen messages, payment state and counted output during the transition.
Start with a connected baseline, then cover the authorized stages and payment methods. Write the expected behavior before the trial so differences are easy to locate.
- Before selection: available packages and whether payment options are disabled.
- Before authorization: customer message and permitted next action.
- During an in-progress transaction: payment status and commanded output.
- After authorization or delivery: locally retained record and final-state evidence.
- Reconnection: synchronization, duplicate control and unresolved event handling.
- Each mode: cash, token, voucher or cashless tested separately where applicable.
Check provider-specific conditions
Offline payment is a provider configuration. For example, Nayax’s guide requires support activation and describes EMV contactless/NFC scope for its feature. Ask the chosen provider for the terms applicable to the proposed device, account and destination.
Record supported methods, activation, limits and settlement conditions alongside the equipment’s local buffering or reporting behavior. These answers define what the venue can continue offering.
Review customer support and reconciliation
For an interrupted transaction, distinguish not authorized, authorized but not delivered, delivered but not synchronized, and the final payment state using the provider’s definitions. Match payment and kiosk identifiers.
In a hypothetical test, tokens are delivered before the reporting connection fails. On reconnection, trace the same event through synchronization and verify that recovery does not create another dispense.
Check reconnecting before restarting sales
Define the recovery checks staff use before reopening the affected service. Include pending events and payment-provider state as well as the network connection.
If the kiosk and payment device reconnect at different times, record the transition and permitted restart actions. This gives staff an explicit sequence to follow.
Plan a supportable fallback
Plan the venue response when an affected payment method stops: customer message, approved staffed alternative where available, recovery owner and review of unresolved transactions.
Send the stage worksheet, destination and provider with the enquiry. The resulting configuration should name the services available during each loss condition and the responsibilities for reconnecting them.
CHECK THE REFERENCES
Sources
- 32-Inch Touchscreen Token Exchange Kiosk reference configuration
Supplier reference specifications and supplied model images.
- 21.5-Inch Compact Token Vending Kiosk reference configuration
Supplier reference specifications and supplied model images.
- Nayax Offline Payments Configurations
Payment provider offline configuration guide.
PUT THE GUIDE TO WORK
Review network loss for each payment mode
Name the proposed provider and connection. Request function dependencies, authorized test stages and the synchronization and restart procedure.
Build my equipment brief
