Can a credit card machine work without internet?

How offline terminal payments generally work

Current documentation from Square, Stripe Terminal, Adyen, and Clover shows a common pattern: supported equipment can retain payment information during a connection interruption and forward the transaction after service returns. The details differ substantially by provider, integration, reader, payment method, and account settings, so this pattern does not establish that a particular terminal can work offline.

1. The terminal detects a connection problem. A supported application may display an offline status or offer a provider-approved offline workflow.
2. The device checks its configured rules. Transaction amount, payment method, device state, and provider limits can determine whether the attempt is eligible.
3. The customer completes the supported terminal prompts. The merchant should follow the normal approved interface and should not bypass a warning or invent a manual workaround.
4. The transaction remains pending. The terminal stores the payment for later submission rather than confirming a real-time issuer authorization.
5. The terminal reconnects and uploads the transaction. The payment service then attempts to process it, and the merchant reviews the final result.

For background on the normal connected transaction path, read how a credit card terminal works.

Why an offline payment can still fail

With a normal online authorization, the terminal communicates through the merchant's payment path and receives a transaction response while the customer is present. During many offline workflows, that real-time check is unavailable. The device may accept the transaction locally, but the later submission can fail because the issuer declines it, the stored transaction expires, the upload deadline is missed, the device loses pending records, or the attempted payment method was not eligible.

Official provider documentation consistently warns that the merchant bears additional exposure when goods or services are released before a pending offline payment is successfully processed. An on-screen offline acceptance message should therefore be treated as a pending operational result, not a guarantee of payment. Staff need a documented way to recognize pending transactions, reconnect the device, confirm the final status, and reconcile any unsuccessful attempts.

Provider limits and deadlines can change and are not universal. Do not copy a time window, amount limit, or supported-method list from another provider or device. Use current instructions for the exact terminal, software version, merchant account, and processing configuration.

What staff should do during an outage

First, determine whether the problem affects one terminal, the local network, the internet provider, or the payment service. Follow the provider's status and troubleshooting path before changing settings. If the approved application offers offline mode, read the device prompts carefully and apply the business's documented transaction limits. If offline mode is unavailable, do not force the terminal to imitate it.

Protect pending records. Avoid signing out, deleting the payment application, factory-resetting the device, switching configurations, or taking other actions that the provider says could remove stored transactions. Restore the approved connection as soon as practical, allow pending payments to upload, and check each final result in the normal transaction record. Match the processed results to orders before closing the incident.

For connection-specific troubleshooting, see what to do when a terminal cannot connect. Use a verified provider support channel for account-specific instructions.