Your Card Reader Can't Connect. Here's How to Keep Taking Payments — and the Three Fixes That Delete Them.

It is a Saturday, there are six people at the counter, and the card reader says it cannot connect. Somebody has already suggested restarting it. Somebody else has already suggested logging out and back in.

There are actually two separate questions tangled together here, and they have different answers. The first is "can I still take cards?" — and the answer is usually yes, more easily than you would think. The second is "will I actually get the money?" — and that one is a real question with a real risk attached, which almost nobody explains to the person standing at the till, because almost everybody explaining it has a terminal to sell you.

Here is the whole thing in plain English: what to check in the first five minutes, what your terminal is quietly doing on your behalf, and the three ordinary troubleshooting moves that will permanently destroy money you have already taken.

Five minutes first: is it the internet, or is it your shop?

"No internet" on a card reader is a symptom, not a diagnosis. Four different faults produce that exact message, and three of them you can fix in the next few minutes.

Take a phone off Wi-Fi — turn Wi-Fi off entirely so it is on cellular — and load any website. If the site loads, the outside world is fine. Now put the phone back on the shop Wi-Fi and try again. If it works on cellular and fails on your Wi-Fi, the problem is inside your four walls: your router, your access point, or the cable between them. That is a completely different afternoon from an outage at the provider.

Then check whether it is only the terminal. If the back-office computer is online and the reader is not, nothing is down at all — the reader has lost its own connection. The most common cause we see is the least dramatic one: the terminal is sitting on a Wi-Fi name that is no longer the right one. A router got replaced, a network got renamed, an access point got added, someone joined the terminal to the guest network months ago and nobody noticed until the guest network was changed. A device that connects to the wrong network behaves exactly like a device with no internet.

And check the obvious one last, because it is embarrassing and it is real: if your reader talks to the till over Bluetooth or over your local network rather than over the internet directly, a reader that has drifted out of range or dropped its pairing will report a connection problem that has nothing to do with your line at all.

Before you touch anything: three fixes that delete money

This is the part to read before the rest, because it is the part with a deadline on it.

When your terminal cannot reach the payment processor, it does not throw the sale away. It captures the card and stores the transaction on the device, waiting for a connection so it can send it off to be authorised. Those stored sales are money you have taken and not yet been approved for, and they live in one place only: on that piece of hardware, in that app.

Which means the three moves every one of us reaches for first will destroy them. Square's own support page lists what not to do while offline payments are pending — sign out of the Square POS apps, delete the Square POS apps, switch modes, switch locations, or factory reset your device or Square hardware — and states the consequence flatly: "Pending offline payments will be permanently lost and the funds won't be captured." Toast says the same about its own devices: deleting the POS device's memory or uninstalling the app "can result in losing pending payments. Lost payments cannot be recovered."

Read those two lists again and notice what they are. They are the standard tech-support script. Log out and back in. Reinstall the app. Reset it and set it up fresh. Every one of those is a sensible thing to try on a device that will not connect, and every one of them is a shredder for uncaptured payments. This is genuinely the single most useful thing we can tell a shop owner about an outage, and it is not on any of the pages that come up when you search for the problem.

So the rule for the duration of the outage is: restart, yes — sign out, uninstall or reset, no. A restart is safe on the major platforms; Square explicitly says you can restart or power off the device, as long as you power it back on in time to upload. Anything that logs you out or wipes the app is off the table until the queue is empty.

What offline mode actually does

Under normal conditions a card sale is a conversation. The terminal asks the customer's bank, in real time, whether that card is good for that amount, and the bank answers before your customer has put their coat back on. That answer is the approval.

Offline mode removes the conversation. The card details are read, encrypted and stored on the terminal, the screen says approved, the receipt prints, the customer leaves — and the bank has not been asked anything yet. Stripe describes the sequence exactly: "payment information is collected at the time of sale, and authorization is only attempted after connectivity is restored and the payment is forwarded."

That is not a criticism of the feature. For most small shops it is the difference between trading and closing the doors, and the overwhelming majority of those stored sales go through fine when the line comes back. But it is worth being clear-eyed about what the word "approved" on that screen means during an outage: it means "recorded", not "paid".

Who is carrying the risk — and it is not the bank

When a stored sale finally reaches the card network and the answer comes back "declined" — the card was over its limit, cancelled, reported stolen, or simply never any good — somebody eats that sale. It is you.

This is not a fringe interpretation. It is stated in the same words by every platform and by a neutral referee. Square: "You're responsible for any expired, declined, or disputed payments accepted while taking offline payments." Toast: "you are responsible for any declined, expired, or disputed payments while operating in offline mode." Stripe is the bluntest of the three: "You, as the user, assume all decline and tamper-related risks associated with an offline transaction... there's no way to recover the funds, and you might not receive payment from the customer for goods or services already provided."

And because those are all companies with an interest in the feature, here is the referee. The Federal Reserve published a research note on offline payments on 16 August 2024 which puts it in one sentence: "The merchant bears the risk of transaction declines associated with the offline payment." The same note adds the case that actually bites — "In instances where the payer has insufficient funds or of prolonged internet inaccessibility, the payee assumes the loss."

None of that means turn the feature off. It means you should know it is a business decision and not a technical setting. You are choosing to extend a few hours of unsecured credit to whoever walks in, in exchange for staying open. For a café selling nine-dollar sandwiches that is an easy yes. For a shop where the average sale is eleven hundred dollars, it is a genuinely different calculation, and it deserves five minutes of thought on a quiet Tuesday rather than a shrug on a busy Saturday.

You are probably already switched on, and you probably did not choose it

Here is the fact that surprises nearly every owner we say it to. On Square, this is on unless you went and turned it off. Square's own words: "Offline payments will be automatically allowed on all your devices unless you opt out."

So if you run a Square counter, you have very likely been carrying decline risk on outage days for as long as you have had the hardware, and nobody ever asked you. It is not a trap — the default exists because most merchants would rather trade than not — but it is a decision that was made for you, and it is worth knowing you made it.

Other platforms differ, and that is the point: go and look at yours rather than assuming. On Square it is under Settings, then Device management, then Modes, then Checkout, then Offline payments; in the POS app it is under More, Settings, Checkout, Offline payments. Stripe-based systems are the other way round — offline has to be deliberately enabled on the account before a reader will do it at all. Clover terminals have the setting on the device itself, under Setup and then Payments. Whichever you run, the useful exercise is the same: open the screen, read what it currently says, and decide whether that is what you want.

The clock starts at the first sale, not at each one

Stored payments do not wait forever. They expire, and an expired payment is not a payment.

The window is short and it varies by platform. The Federal Reserve note puts the general range at "commonly 24 to 72 hours", after which terminals "will delete pending transactions if internet connectivity is not restored within that period." Square gives the specific number for its own hardware — "Pending offline payments will expire after 72 hours if you don't reconnect to the internet and upload them."

Now the detail that catches people, and it is the reason to write this on a card and tape it inside the till. Square's instruction is to "upload offline payments within 72 hours of taking your first payment." Of your first payment. Not of each one. The clock started with the first card you took on Friday afternoon, not with the last one you took on Sunday — so the sale you took two hours before the line came back does not get its own fresh three days. Everything in that queue lives or dies on the same deadline, set by the oldest item in it.

The practical consequence is that a long outage is far more dangerous than a short one, and a long outage over a weekend — when nobody is going to notice the line is back until Monday — is the worst case there is. If you take offline payments on a Friday night and the shop is shut until Monday morning, that queue may already be gone.

What stops working, whatever brand you run

Offline mode keeps the core sale alive and quietly drops a surprising amount of everything else. The lists differ slightly between platforms but they rhyme, and it is better to find out now than at the counter.

Gift cards generally do not work. Toast's list of what cannot be used offline is long and specific — "Gift cards, loyalty redemptions, Tender API payments, text to pay, customer credits, comp cards and house accounts" — and Square likewise does not support its own gift cards offline, with loyalty needing to be linked up by hand afterwards. If a regular tries to redeem points or settle a house account during an outage, the answer is a polite "not today".

Refunds are out, and this one causes arguments. A stored sale has not been sent anywhere yet, so there is nothing to reverse. Square: "Offline payments can't be canceled or refunded while they're still processing." Stripe: "You can't cancel or refund a PaymentIntent that was created and confirmed offline until it's forwarded to Stripe." If a customer changes their mind fifteen minutes later, you are either giving cash back out of the drawer or asking them to come back — and you need to have decided which before it happens.

Swiping may be out too, and for a good reason. Stripe simply refuses magnetic-stripe cards while offline: "Because magnetic stripe data is easy to spoof, Stripe disallows this option while operating offline." Square goes the other way and asks for chip or contactless whenever possible, supporting the swipe only on certain hardware. Either way, the old instinct — "the chip reader is being funny, let me swipe it" — is precisely the wrong instinct during an outage, because the swipe is the entry method with the least protection behind it at the moment you have the least protection available.

And receipts change shape. Emailed and texted receipts generally are not sent until the payment actually goes through, so the paper receipt is the only proof the customer walks out with. Print it, even for the people who normally wave it away.

Set the limit before Saturday, not during it

Every serious platform lets you cap what it will accept offline, and this is where the risk conversation turns into a number you actually control.

There are usually two caps and they do different jobs. The first is a ceiling on any single sale — Square allows anything from $1 to $50,000, and Stripe enforces its own hard ceiling on top of whatever you choose, "the Stripe-enforced offline maximum of 10,000 USD". The second, where it exists, is a ceiling on the total value sitting unsent in the queue, which is the one that actually protects you, because ten unauthorised sales at two hundred dollars is the same exposure as one at two thousand.

A sensible way to pick the per-sale number: set it a little above your normal ticket, not near your biggest one. The point of the cap is not to squeeze every possible sale through the outage — it is to make sure that the transactions you cannot verify are the routine ones. An unusually large purchase, from someone you do not know, on a day when you cannot check the card, is the exact shape of the loss you are trying to avoid. Toast handles this by letting a manager approve anything over the threshold, which is a good pattern to copy even if your system does not enforce it: over the line, get a second person involved and take a phone number.

The restart order, and the one thing that goes wrong on the terminal

If the fault is inside the shop, restart in the direction the connection travels: modem first, then router, then access points and switches, then the terminal — and wait for each one to settle before starting the next. Restarting the terminal first is the most common wasted five minutes in this whole business, because the terminal is downstream of everything else. Square's own troubleshooting for its Register puts the modem and router step ahead of the "restart your Square Register" step for exactly this reason.

Give the modem a real wait. Two minutes on a cable modem, and rather longer on some fibre installations, before you judge whether it came back. Then let the router come up fully before you look at the reader.

The thing to watch on the terminal is that it comes back onto the same network it was on before. On Stripe smart readers this is not a preference, it is a hard rule: "Your reader and POS device must be on the same local network used to connect online. You can't switch networks while offline." There are two other conditions on that platform worth knowing about before you find them the hard way — the reader has to have connected to your till while online within the last 24 hours, and its software has to have been updated within the last 30 days, or it will refuse to work offline at all. A backup terminal that has been in a drawer since spring is not the emergency plan you think it is. Take it out once a month, put it on the network, and let it update.

Do not put the register on your phone's hotspot

This is the single most popular improvisation during an outage and it is usually a mistake, sometimes an expensive one.

If the terminal has already gone offline and started storing payments, moving it onto a hotspot means moving it onto a different network. On Stripe hardware that breaks the pairing outright — it cannot switch networks mid-outage, and the connection will simply fail. On other systems it may work, but you are performing a network change on a device that is currently holding money, which is the wrong moment for an experiment.

There is also a quieter problem. A hotspot gets you connected but not necessarily connected properly: your till may reach the internet while the reader cannot reach the till, because they are now on separate networks entirely. You end up with half a system, in a queue, under pressure.

The time for a hotspot is before anything has been stored — if you catch the outage in the first minute and nothing is queued yet, switching to a cellular connection cleanly is a reasonable move. Once the queue is building, leave the terminal where it is and let it do its job.

The register should be on a cable, and not on the guest Wi-Fi

Two changes make outage days dramatically rarer, and neither is a purchase from your payment company.

First: wire it. Wi-Fi in a shop is genuinely hostile — a microwave behind the counter, a neighbouring café's access point, a card reader placed in the one spot on the floor where the signal from the back office does not reach. A cable does not care about any of it. Most counter-top hardware supports this even where it is not obvious: Square Register takes Ethernet through its accessory hub and, in Square's own words, "will default to using Ethernet connection over Wi-Fi if both are available." If the register is more than a few metres from the router and there is no cable there today, that is a job worth doing once — and if a wall is in the way, the coax already running to the shop will often carry Ethernet without opening anything up.

Second: get the register off the network your customers use. A guest Wi-Fi network exists so visitors can browse without touching anything of yours, and it is frequently configured with client isolation, which stops devices on it from talking to each other — which is exactly what breaks a till and a reader that need to see one another. Beyond the practical breakage, a payment terminal sharing a network with every phone that walks through the door is not a configuration anyone would choose on purpose. The register, the back-office computer and the receipt printer on one network; customers, and anything that streams music or drives a menu screen, on the other.

A backup line: what it buys you and what it does not

Once a shop has had two or three outage days, the question becomes whether to pay for a second connection. It is a reasonable thing to buy, and it is worth being precise about what it does.

The usual form is a router that can fall back to a cellular connection when the main line dies, either built in or as a small add-on box with its own SIM. The reason it works is that it fails independently: the cellular network is not carried on the cable or fibre in your street, so the digger that cut your line has no effect on it. A backup line will not match your main connection for speed and does not need to — card authorisations are tiny.

What it will not do is help with a power cut. If the lights are off, your modem, your router and your access points are off too, and a cellular backup device is off with them unless it is on a battery. That is a separate piece of planning, and we have written it up separately for Southern California, where the planned shutoffs make it a real annual question rather than a hypothetical one.

It also will not help if the failure is your own equipment. A backup connection plugged into a router that has died is a backup to nothing. If the shop runs on one ageing all-in-one box from the provider, the first upgrade is not a second line — it is not having a single point of failure that also happens to be the thing most likely to fail.

When it comes back: the ten minutes that decide whether you got paid

The outage ending is not the end of the job. The queue has to actually drain, and this is where money quietly goes missing.

Leave everything on and connected. Do not close up, do not power down the terminal, do not put the reader back in the drawer, and do not let anyone log out of the app until you have confirmed the queue is empty. Stripe warns about precisely this — "If you disconnect or power off your smart reader too soon, your payments might not be forwarded." On Square you can watch it happen: pending offline payments appear in the transactions list with a circling arrows icon next to them, and when the icon is gone, they are gone from the queue.

Then reconcile, the same day. Some of those sales will have declined, and you need to know which. Toast tags them on the payment — a "Declined" tag means the card used offline was refused once the device reconnected, and a "Backgrounded" tag reopens the closed check. Square and Stripe surface theirs in the transaction record and the dashboard. Whatever the system, the question is the same: how many stored payments went in, how many came out approved, and what is the gap.

For anything in the gap, act while it is fresh. A card that declined an hour after the sale is often perfectly good the next morning — the customer moved money, or the bank was blocking a card it did not expect to see used offline. A phone call the same day, with the receipt in front of you, recovers a good proportion of these. A week later, with a name you did not write down, recovers none of them. Which is the real argument for taking a phone number on anything above your everyday ticket during an outage: not paranoia, just the ability to ring someone.

Write the outage page before you need it

All of the above compresses into one sheet of paper taped inside a cupboard by the till, and the whole point is that it has to be readable by whoever is on shift, not by you.

It needs: which network the terminal belongs on and its password; the restart order, modem then router then terminal; the sentence "do not sign out, do not reinstall, do not reset"; the offline ceiling you have set and what to do above it; what to tell a customer who wants a refund on an offline sale; the deadline, counted from the first offline sale, not the last; and two phone numbers — the provider's and ours.

Everything on that list is free. It takes twenty minutes on a quiet afternoon, and the day it matters, the person holding it is a part-timer who has never seen the register do this before and has a queue watching them.

Where we come in

We do small-business network work across the San Gabriel Valley, Orange County, the Inland Empire and the desert — the independent shops, cafés, salons, studios and clinics that run a till and a reader and do not have anyone on a service contract to ring. It is the same customer base as the one-of-a-kind main streets we work on all over Southern California, where the person who owns the shop is also the IT department by default.

The useful visit is the boring one, before anything breaks: wiring the register instead of leaving it on Wi-Fi, splitting the till and the back office off the network the customers use, checking what your offline setting actually says and whether the ceiling on it is a number you would have chosen, making sure the spare terminal in the drawer is current enough to work, and putting a backup line in if the maths supports one. None of that is dramatic and all of it is cheaper than a bad Saturday.

The other call is the urgent one, and if you are reading this with a queue in front of you, the short version is at the top of this page: restart things in order, do not sign out of anything, do not reinstall anything, do not reset anything, print the paper receipts, and get the line back before the clock runs out. What we will not do is tell you which payment company to use. We do not sell terminals and we do not take a cut of your processing — we just make the network under it behave, and tell you honestly what the setting you have already got is doing.