What happens when EFTPOS goes down at an event?

“EFTPOS is down” can mean four different things. One terminal has lost coverage. A local access point has failed. The card processor is unavailable. Or the venue network is carrying traffic but cannot reach the payment service.

Those failures look identical to the person at the till. They need different responses from the control room.

Name the boundary first

Record the first affected device, location and time. Check a second device in the same zone, then a device on another network path. That tells the team whether it is dealing with one terminal, one area or the whole site.

Do not start changing every terminal configuration while the boundary is still unknown. That turns one failure into several different configurations that must be untangled later.

Keep the visitor path open

Move visitors to a working lane, kiosk or staffed top-up point. Put a person at the queue before the queue finds the problem for you. A clear sentence at the front of the line is worth more than a technical explanation over the radio.

Regular card payments, event-wallet payments and scans do not always share the same rail. One can remain available while another is affected. The operating plan should name the fallback for each payment method before opening day.

Offline is a controlled operating mode

Where the event configuration permits it, Ludo devices can keep approved transactions and scans on the device, then post them when connectivity returns. Limits and allowed transaction types must be agreed before the show.

That is different from promising that every card payment always works offline. Card behaviour depends on the terminal, processor, transaction type and configured risk rules. The runbook must describe the real rail, not a generic offline claim.

Preserve the record during the outage

Keep the affected device identifiers, lane, operator and outage window together. Do not manually re-key queued sales into a second system. Duplicate entry creates a harder finance problem than the original network failure.

When coverage returns, let the devices post their queued records. Watch the queue clear. Then compare the device record, the central ledger and the vendor view before declaring recovery complete.

Recovery finishes with reconciliation

A green network light is not the end of the incident. Confirm that queued transactions arrived once, refunds and voids still point to the original sale, and each vendor ledger reflects the correct location.

Write down what failed, how long it lasted, which fallback carried trade and what the next shift should change. The useful incident report is short enough to read before tomorrow’s gates open.

Questions to settle before opening day

Which rails can continue during a coverage loss? What limits apply? Who can enable or stop the fallback? Where do visitors move? What evidence proves every queued record posted once?

If those answers are not written down, the outage plan is still a hope.