Which card pays when you tap a phone?

One application answers

A terminal starts the exchange and the phone has to decide, in that instant, which of its installed wallets responds. Android models this as a default service for a payment category, and the Android card emulation reference documents both that and the way a foreground application can take precedence while it is on screen, unless the user has forbidden foreground applications from overriding the default payment service.

The same reference shows where the platform is going: the constant that used to open the default payment picker is deprecated in favour of a wallet role held by one application. The direction is the same on both platforms, one holder of the payment role rather than a negotiation at the till.

So the choice is made before the tap, on the phone, and nothing at the terminal can reach past it.

The default, and changing it

Inside the wallet, one card is the default and the others are a swipe away. Choosing a different one is a decision taken before the phone goes near the terminal, because once the exchange starts there is no interface left to use.

This is the practical difference from a physical wallet, where the choice is made by which piece of plastic your fingers find. Here the card that pays is the card that was selected, and a phone handed to someone else pays with whatever was selected last.

A card removed from a wallet stops being presentable immediately, which is a useful property when a card is replaced or cancelled and the plastic is still in a drawer.

Transit changes the rules

A transit card in a wallet is often allowed to answer a gate without the phone being unlocked, which is what makes a gate usable at all. That is a different mode with its own rules, and the section index covers it in the transit guides rather than here.

The consequence for this page is that a phone can hold something that answers automatically and something else that requires verification, and the gate or the terminal it meets decides which of the two is relevant.

Which is also why a transit card and a bank card in the same wallet occasionally produce the wrong outcome at the wrong reader, a case the transit guides take up.

When the wrong thing happens

A terminal that refuses is not always refusing the card. It may not accept phone payment at all, it may have taken the wrong application, or the phone may not have completed its verification, and the troubleshooting page separates the symptoms.

What a terminal actually receives is described on the terminal page, and it is less than most people assume: not your name, not your card number, and nothing about the other cards in the wallet.

And a phone that is off, or out of battery, behaves according to rules of its own, which the phone off page sets out.