Nothing Happens When the Phone Taps the Card Reader, and the Wallet Looks Fine

A contactless payment that fails at a shop counter almost always fails on the phone's side of the radio field, before the terminal has anything to answer. Three symptoms turn up, and they point in different directions: the wallet never appears at all, the wallet appears but the reader keeps asking for a card, or the card sits on screen and no confirmation mark ever arrives. Each of the three has documented causes, and each can be settled at the counter in under a minute once the checks run in the right order.

The scope here is the device side only — the NFC radio, the wallet app, screen-lock and verification state, and which app currently owns contactless transactions on that handset. What happens inside the terminal, how the reader selects an application, how the request is routed onward, and what rules a card issuer applies to a particular purchase all sit on the far side of the field. None of it is observable from a phone, so none of it is guessed at here. Every menu path, threshold and behaviour below comes from Apple or Google documentation checked on 23 August 2026, and where those two publish nothing, the gap is stated instead of filled.

Four Gates Sit Between a Tap and an Approved Payment

A tap has to clear four separate conditions on the handset before a terminal ever sees a response. They fail independently and they fail silently — none of the four produces a distinct message on the phone, which is why a failed tap feels like one undifferentiated problem instead of four. Separating them is the whole diagnosis.

Gate four is the one most often blamed and least often at fault. Apple's instruction is to hold the top of the iPhone near the contactless reader until Done and a checkmark appear on the display; on Apple Watch, the display goes near the reader until there is a gentle tap and a beep. Google's guidance is looser because Android hardware varies: the NFC antenna may sit at the top or the middle of the phone, so the position on the terminal is worth changing before anything else is. A successful Google Wallet payment shows a blue check mark on screen.

The Checks Worth Running While Still Standing at the Counter

Four things can be tested in the time it takes a cashier to void a transaction, and they cover most single-terminal failures.

1. Unlock the phone first, then tap. Google documents that a phone can be tapped against the terminal when it is unlocked, even with the Google Wallet app closed. Apple's flow is a double-click of the side button followed by Face ID, Touch ID or the passcode. A locked handset held against a reader is a normal, expected non-event.
2. Move the phone. Both companies list reader positioning as a first-line cause. Hold it closer, and slide it along the terminal face until it lands over the antenna.
3. Open the wallet and look for the card. If the card is not listed, no amount of tapping will help, and the reason is almost certainly in the removal list further down this article.
4. Check whether some other app opens instead. On iPhone this is a specific, documented setting with a specific consequence, covered in its own section below.

What is deliberately not on that list is restarting the phone, reinstalling the wallet, or removing and re-adding a card at the counter. Re-adding a card can require issuer verification, which is a poor thing to start in a queue.

Express Mode Explains Taps That Go Through With No Authentication At All

A frequent report is the opposite of a failure: one card or pass pays instantly on a locked phone while every other card demands a face scan. That is Express Mode, and it is documented behaviour rather than a fault. Apple's description is direct — an item set to Express Mode can be used "without waking or unlocking your device, authenticating, or opening an app." It applies to transit cards, payment cards in some regions, student IDs, car keys, hotel keys and other passes.

The setting lives in the Wallet app rather than in Settings: select the item, tap the More button, then Card Details, then Express Transit Settings or Express Mode. For an Apple Watch, the equivalent is the Apple Watch app on the paired iPhone, under Wallet & Apple Pay. The switch matters in both directions: it explains a charge on a locked phone, and it explains why one item still works when the rest of the wallet has stopped.

Google Wallet has a narrower version of the same idea. Verification is mandatory in general — Google states that a screen lock must be set up and that identity must be verified for security — but verification can be switched off for transit payments specifically, under Security and then Verification settings in the wallet's own settings. Google is explicit that screen lock verification is still required for other payments.

A second Google behaviour explains why verification is demanded on one visit and not the next. Google documents that a verification performed in the past few minutes may carry over, so the following transaction is not challenged; once it times out, the next transaction must be verified. The rule is time-based in Google's own description.

Power Reserve Keeps Express Mode Alive on a Phone That Will Not Wake

Apple documents that Express Mode items can keep working when an iPhone needs to be charged, for up to five hours with some cards, passes and keys. Two conditions are attached and both matter at a gate or a counter. Pressing the side button or the Home button to see what is available is possible, but doing it often may significantly reduce the reserve. And the reserve does not exist at all if the iPhone has been switched off deliberately rather than running out of charge.

Another App May Have Taken the NFC Radio

This is the single most under-diagnosed cause of an iPhone that suddenly stops paying, because nothing about it looks like a fault. Recent iOS releases allow a third-party app to be set as the default contactless app. Apple's documented consequence is unambiguous: the selected app launches automatically after the iPhone is unlocked, and the cards saved in Apple Wallet "will no longer be presented."

Apple documents the path as Settings, then Apps, then Default Apps at the top of the list, then the feature to change — the contactless entry is listed as iPhone only, and available in some countries and regions. Two details make this diagnosable at the counter. First, Apple Wallet cards can still be used while another app holds the default: open the Wallet app, select the card, then double-click the side button to authenticate. Second, Express Mode continues to work even when Apple Wallet is not the default app, which is exactly why a transit card keeps working while every payment card appears to have vanished.

Android has the same concept and Google publishes the path for it: Settings, Connected devices, Connection preferences, NFC, then Contactless payments, where Google Wallet is selected as the payment app. The NFC radio itself is one level up, at Settings, Connected devices, Connection preferences, NFC. Manufacturer skins rename and reorder these menus, so treat the path as Google's reference layout rather than a guarantee.

When the Right Card Is There but the Wrong One Pays

A payment that goes through on the wrong card is a default-card problem, not a failure. On iPhone, Apple's method for changing the default is to drag a card to the front in the Wallet app; the broader Apple Pay settings sit under Settings, then Wallet & Apple Pay. During a payment, the default card can be overridden without leaving the flow: tap the default card to see the others, tap a new card, and authenticate. On Apple Watch, double-click the side button and scroll down to another card.

Google Wallet uses the selected default card automatically for a tap. If a specific card is needed, it is chosen in the app before the phone goes near the terminal.

Three Android Gates With Published Values

Android adds requirements that iOS does not, and each has a published value attached, which makes it checkable.

Gate	Published requirement	Where it is checked
Operating system version	Android 9 or higher on a phone, Wear OS 2.18 or higher on a watch, stated as of 10 June 2024. Google's reason is that security updates are not available for Android versions below 9.	The phone's About or System settings
Screen lock type	PIN, pattern, password or a Class 3 biometric unlock. Class 1 and Class 2 biometric unlocks are not accepted, and neither are Smart Unlock or Knock to Unlock. Google notes Face Unlock is not supported for tap to pay on Pixel 7 and Pixel 7 Pro.	Settings, Security & privacy, Device unlock, Screen lock
Software integrity	A rooted device, a custom ROM, an unlocked bootloader or uncertified software each fail Google's security standard for contactless payments.	Play Store, profile icon, Settings, About — the Play Protect certification line

The Class 3 requirement is the one that catches people out, because a face or fingerprint unlock that works perfectly for opening the phone can still be the wrong class for a payment. Google's own troubleshooting advice for repeated verification failures is to confirm the lock type is a supported one, and to set a new screen lock if it is not.

When the Card Has Quietly Left the Wallet

Cards are removed by design in several situations, and the phone gives no warning at the time. Google publishes the list, which is unusually specific and worth reading before assuming a fault.

The 90-day entry deserves emphasis because it produces a failure with no triggering event at all. A card added for a trip and left untouched can simply not be there on the next attempt. The Play services entry is similar in effect: clearing that data is standard advice for unrelated Android problems, and the payment consequence is rarely mentioned alongside it.

Google also publishes the error strings that appear when a card cannot be added in the first place, which is a different problem from a card that stops working. Couldn't finish card setup for tap to pay indicates the bank declined the request; Google's advice is to contact the card issuer and to check that name, CVC and billing address match the bank's records. Phone can't be set up for tap and pay points at the device rather than the card — no NFC, or a failure of the security standards above. Card isn't ready to pay online is narrower than it looks: that card may still work for an in-store tap.

What Neither Company Publishes

Four things are commonly asserted about contactless payments and are not documented by Apple or Google in the pages checked. Stating them as facts would be guesswork.

• A transaction amount above which verification is required. Google's published rule is time-based, not amount-based: a recent verification may carry over until it times out. No monetary threshold appears in Google's verification documentation.
• The length of that verification window. Google's own wording is "the past few minutes." No number is given, so no number should be quoted.
• What happens to iPhone cards if the passcode is switched off. Apple documents that a passcode must be set to use Apple Pay, and that a remote erase through Find My removes the ability to pay with the cards on that device. Apple's security overview does not, in the pages checked, spell out the consequence of simply disabling the passcode. Google documents this behaviour for Android; Apple's position is best treated as unknown rather than assumed to match.
• Why a tap fails at one shop and succeeds at the next. That difference lives in the terminal and in the authorisation path behind it. It is not visible from the handset, and no phone-side setting explains it.

When This Doesn't Apply

This frame covers device-side causes, and there are clear signals that the cause is somewhere else.

• The terminal displays a decline message. If a response reaches the reader and comes back refused, the four gates above were all cleared. The phone did its job; the answer came from elsewhere.
• The physical card fails too. A card that is refused when inserted or swiped is not a wallet problem, and re-adding it to the phone will not change the outcome.
• The terminal does not take contactless payments at all. Nothing on the phone reveals this. It is a property of the reader.
• Every card fails on one phone and all of them work on another, including after a fresh setup. Once software state has been ruled out, an NFC antenna that has stopped working is a hardware question for the manufacturer, not a settings question.
• Region and issuer coverage. Apple requires a supported card from a participating issuer, and Google's tap-to-pay support varies by country and by card. A card that has never worked in a wallet is a different problem from one that stopped.
• The phone is managed by an employer. Device management policies can restrict features, and those restrictions are not always visible in the ordinary settings screens.

A Working Order for the Next Failed Tap

1. Unlock the phone, then present it. Do not tap a locked handset and read the silence as a fault.
2. Move the phone across the reader face — top, then middle — and hold it still until the checkmark or blue check appears.
3. Open the wallet. Confirm the card is still listed. If it is gone, stop: it has to be added again, and that is not a counter-side job.
4. On iPhone, check Settings, Apps, Default Apps for a contactless app that is not Apple Wallet. If one is set, pay by opening the Wallet app directly and double-clicking the side button.
5. On Android, confirm NFC is on and Google Wallet is the contactless payments app, under Settings, Connected devices, Connection preferences, NFC.
6. On Android, confirm the screen lock is a PIN, pattern, password or Class 3 biometric, and that the Play Store's About screen reports the device as certified.
7. If one item still pays on a locked phone while the rest do not, check Express Mode in the Wallet app — that item is bypassing authentication by design.
8. If a response reaches the terminal and is refused, stop diagnosing the phone. The remaining answer is with the card issuer.

The recurring pattern in device-side contactless failures is that the phone was working exactly as documented, and something on it had changed: a screen lock swapped for a convenience unlock, a default contactless app set months earlier, a card silently removed after 90 idle days, or an Express Mode switch that makes one item behave unlike every other. None of those look like faults, which is why they are worth checking before anything gets reinstalled.