Spark's Eftpos fault: test your payment backups for routing failures

On Monday 2 November, some Spark-connected Eftpos terminals in Invercargill and Dunedin were caught in a connectivity failure with Paymark's network. Supermarkets and pharmacies were hit, and Invercargill City Council could take only cash at its main office and facilities, or payments through its online portal. FreshChoice said about 12 of its South Island stores were affected. Spark has since said services are fully restored, although it's still working out why the fault happened.

The outage was regional and was fixed the same day, so most businesses will move on quickly. The way the fault behaved deserves a closer look, because a backup designed for a dead line might not have helped.

What went wrong

Paymark called the problem a widespread connectivity issue between Spark and Paymark. A first fix went in early on Monday, but reports of trouble kept arriving, and a different fix followed that afternoon. Spark's explanation is that some Eftpos connections were incorrectly directed inside its network and couldn't reach Paymark, and that resetting the affected connections restored payments. Eftpos New Zealand said customers on its own network weren't affected. The reports we've read give no firm start time, no count of affected businesses and no mention of compensation.

Why routing faults catch backups out

Spark's description points to a routing fault, which behaves differently from a cut cable or a failed modem. The reports we've read don't say whether general internet access stayed up at affected sites. If access did stay up, a router or terminal watching only for a lost line would've seen a healthy connection and stayed on the broken path. Vendor material doesn't settle the question. Eftpos NZ's backup SIM page says the terminal switches when the primary connection is disrupted, without explaining how the terminal detects a disruption. Anyone buying failover should ask the supplier that exact question.

Carrier choice carries a similar doubt. Telstra's advice to Australian merchants rests on fixed and mobile services rarely failing together. That advice holds when the two services are truly separate, but a fixed line and a backup SIM from one carrier may still share parts of that carrier's network. Nothing we've read says whether Spark's mobile-connected terminals were caught on Monday. A backup on a second carrier removes the doubt.

Offline mode is the other common safety net, and its limits matter. Eftpos NZ includes offline mode with every Verifone terminal but describes the service as working in a limited capacity. One Paymark terminal manual sets out what that can mean on older hardware. Only purchases are accepted, pre-set limits apply per card and per amount, the merchant needs bank approval, and the cardholder must sign the receipt. Stored transactions that get declined only show up when the terminal uploads them, by which time the customer has left with the goods. The manual doesn't say who carries that loss, so merchants should get the answer from their bank.

Where payments fit in transformation planning

We think Monday's fault belongs on the transformation agenda as well as the IT support list. New point-of-sale systems and self-service kiosks add steps between a customer and a completed sale. A digital transformation plan should record who owns each step and what the business does when one fails. Invercargill City Council shows the value of a separate channel, because its online portal stayed available while its counters were limited to cash.

Pay-by-bank could become another separate channel. The Commerce Commission estimates merchants could avoid about $180 million of the roughly $340 million a year they pay to accept Visa and Mastercard debit, although actual savings will vary. MBIE data in the same report shows over 556,000 payment requests worth more than $158 million in August. The options include payment links, invoices and in-person QR codes. A QR payment runs through the customer's phone and banking app, so it shouldn't depend on the shop's Eftpos path, although the merchant still needs a way to confirm the money has arrived. Uptake at everyday checkouts is unproven, which makes invoices and payment links the sensible place to start a pilot.

Cash still covers the failures that take everything else down. B2B News reports that 56.6% of people still use cash alongside other methods, citing the Reserve Bank's survey. The same article recalls the Reserve Bank flying in $41 million in cash after Cyclone Gabrielle cut connectivity across Tairāwhiti and Wairoa.

What the fixes cost

Basic protection is cheap compared with an afternoon of lost card sales. Eftpos NZ lists a backup SIM at $5 plus GST per terminal per month and a preconfigured spare terminal at $25 plus GST per box per month. Backup SIMs for a site with 10 terminals would come to $600 plus GST a year. Other suppliers will price these options differently, so get quotes from yours.

Larger retailers can protect a whole site at the router. Briscoe Group's case study describes cloud-managed LTE failover across 83 stores, run by a seven-person IT team, replacing a GPRS backup that was unreliable and couldn't be monitored. The 99.99% uptime figure is vendor-published and the page is undated, so treat the number with caution. Monitoring is the useful lesson, because a backup nobody can see may already be broken when it's needed.

Next steps

• Map every payment point. Record the terminal, the connection, the carrier, the payment network and the acquiring bank for each one. Include unattended machines, which have no staff on hand to fall back to cash.
• Test a bad route as well as a dead line. Ask your supplier to help you block the terminal's path to the payment network while the internet connection stays up, then watch what the terminal does. Unplugging the router only proves the easy case.
• Check that your backup is independent. Confirm which carrier your backup SIM or router uses, and check mobile coverage at each site.
• Get offline terms in writing. Ask your bank whether offline mode is enabled, what limits apply and who carries the loss on a stored transaction that's later declined.
• Write a one-page outage procedure. Name who decides to switch to fallback, how staff handle signed receipts, and how much float each site holds.
• Add a channel that doesn't use your terminals. Payment links or an online portal can keep invoices moving during a counter outage, and they make a low-risk pay-by-bank pilot.
• Ask for the root cause if you're a Spark customer. Spark says it's reviewing its systems and processes. Its findings should tell you whether your failover design would've worked, and your contract will show whether any service credits apply.