Can multiple NFC tap-and-pay applications coexist on the same phone? The premise may sound overly ambitious, considering that getting even a single wallet to work has been a challenge during this nascent period of mobile payments. Until recently Google Wallet was only available on Sprint and unlocked T-Mobile/AT&T devices, while the ISIS project from US wireless carriers depends on switching to a special SIM card.
This quagmire was caused less by any inherent limitation in technology and more by strategic maneuvering on the part of wireless carriers and OEMs to control payments. Both the embedded secure element originally used by Google Wallet and the new UICC hardware required for ISIS support the presence of multiple applications, in accord with Global Platform specifications. In principle that permits multiple wallets to co-exist on the same hardware, but the catch is secure elements are locked down platforms. Users can not install their own choice of applications. Special privileges typically obtained via contractual arrangements with the entity controlling the chip are required. Such deals have not materialized at large-scale.
Host-card emulation offers one way out of the quagmire by removing dependency on the secure element. Payment applications no longer require a secure element– only NFC controller– being able to install new apps on that dedicated SE or special privileges for interfacing with SE from an Android application. Does this solve the problem of multiple wallets? That depends on the definition of what it means for multiple wallets to coexist on the same device.
Detour: NFC transactions
Before diving into why having multiple wallets coexisting is still a challenge, here is quick primer on how EMV protocol operates. Starting from the moment the customer brings their device into the induction field of the NFC reader:
- Terminal detects the presence of an NFC type-4 tag, or what Android calls ISO-Dep type.
- A connection is set-up for exchanging messages called APDU or Application Protocol Data Unit.
- Terminal activates the PPSE (Proximity Payment System Environment) application by sending an APDU containing a SELECT command with the well-known AID for PPSE.
- Terminal interacts with PPSE to get a list of payment instruments available on the “card” (which in this case is actually a phone operating in NFC card-emulation mode) Each instrument is represented by a unique AID, in order of user preference. For example if the user prefers to pay with their Discover and use Visa as fallback in case that is not honored by the merchant, PPSE would present 2 AIDs with the Discover application appearing first.
- Based on user preferences and merchant capabilities, one of these options is chosen by the terminal.
- The terminal SELECTs the chosen payment application by AID and executes the network-specific protocol, such as PayPass for MasterCard or payWave for Visa.
One wallet at a time
Tap & Pay settings from Kitkat
Designating a single application for payments is straightforward: Android settings features a dedicated view to pick between available options. Under the hood, that setting controls routing for a specific AID: the one reserved for PPSE. The expectation is that each mobile wallet capable of handling NFC payments will declare that it can handle PPSE and other AID prefixes associated with different networks (for example A0000004 for MasterCard)
There is one subtlety: the syntax used for declaring HCE services permits the application to define groups such that either all or none of the AIDs in that group will be routed to the application. This avoids the situation when PPSE and cards get out of sync. Consider two wallet applications each containing a MasterCard. If the user decides to activate the first one, all future PPSE traffic will be routed there. But if the AID prefix for MasterCard remains associated with wallet #2, an inconsistent transaction state will arise. PPSE emulated by wallet #1 is used to pick a card for payment, but the actual payment is handled by wallet #2, contrary to user preference.
Multiple active wallets
While the scenario for a single NFC payment application is handled gracefully, the same approach does not work for combining multiple cards from different wallets.
The problem is the directory view presented by PPSE. Because PPSE is routed to one specific wallet, at any point only the payment options associated with that application are available for NFC payments. Each wallet application maintains its own directory of cards, blissfully unaware of other wallets installed on the same device. Using another card associated with a different mobile payment application requires changing the PPSE routing.
There is no system-wide PPSE instance to aggregate cards from multiple payment applications and create a unified representation to the point-of-sale terminal, containing all the payment options available to that customer. (Strictly speaking, it does not have to be an OS feature. In principle payment apps could agree on a standard among themselves to use Android intents for communicating card information to each other. But this assumes products from competing providers will cooperate for the higher-cause of serving the user, and possibly to their own detriment when a competitor’s payment option is prioritized above their own. This is asking a bit too much, which is why such functionality is best centralized in the core operating system.)
CP
Random Oracle 
Looks like the L release changes this, though not clear if for the better:
In general, even if the EMV standard allow it, there is just one payment application listed in PPSE. There are terminals out there which get confused if PPSE returns more or could apply steering, ie not choosing the first or highest priority payment due to fee structure for the merchant (which is forbidden by EMV, but we are paranoid after the incidents we experienced).
I agree that PPSE should be part of the OS for HCE payment.
Interesting.
A terminal getting confused sounds like a buggy implementation.
Steering may be OK, as long as the user has an opportunity to confirm the choice. For example, after initial tap and SELECTing the applet, phone can interrupt the transaction and display which card is being used to pay if the terminal did not pick the first listed AID.