Dual-Network Cards and Mobile Wallet Technology 3. Mobile Wallet Technology

When a customer presents their card details in a mobile payments transaction, they do so from either their financial institution's mobile payments/banking application (‘app’) or via a third-party mobile wallet. Before the digital representation of a ‘card’ can be used in an app or wallet, it must be ‘provisioned’ in that app or wallet. There are two broad ways in which a cardholder can initiate this process:

  • via a third-party mobile wallet provider. This method typically requires the cardholder to provide their 15 or 16 digit card number – the primary account number (PAN) – and name. This may involve the cardholder entering his/her card details manually or using the phone's camera to scan the card, with the details recognised by optical character recognition (OCR).
  • via an issuer-managed process, typically through an issuer's own mobile wallet or mobile banking app (although this process can potentially also be used to provision a card into a third-party wallet).

Provisioning a card requires ‘tokenisation’ of that card, which is a procedure that has been introduced by card networks in recent years to reduce payments fraud. Tokenisation involves de-identifying card details by replacing the PAN with an alternate essentially random number (a ‘token’), and storing that number on the cardholder's mobile device. This has two key implications:

  • the PAN is no longer part of the message flow in a card transaction. This reduces the risk of it being obtained by fraudsters (especially as there is no longer the risk that a merchant will store a cardholder's PAN)
  • the processes of encrypting the card details and decrypting the token information are a required part of the transaction message flow. This involves the use of token service providers (TSPs), with each of the various payment schemes having all set up their TSPs in recent years.

In a tokenised transaction, the token (rather than the PAN) is passed to the merchant's terminal/facility (Figure 1). This token passes with the authorisation request through the acquirer and the scheme to the TSP, which converts the token back to the PAN for the card issuer to authorise the transaction. The authorisation message flows back to the TSP to convert to a ‘token authorisation’, which is relayed back to the merchant.

Figure 1
Figure 1: Information Flows in a Tokenised Transaction

The process of provisioning a token on a mobile device depends on whether the cardholder initiates the process through a third-party wallet provider or an issuer-managed process.

  • When a third-party wallet provider is used, the card details are entered into the mobile device and a token request is sent by the mobile wallet provider to the TSP for the relevant network. The TSP then sends a message to the card issuer to seek authorisation for issuing a token. The token is then stored on the user's device.
  • When the provisioning of a card is initiated via the issuer's mobile or internet banking app, the cardholder logs in to the app and selects the card (or account) that they would like to provision. The issuer then requests a token to be associated with the card/account. A token is then assigned by the TSP and then linked to the cardholder's mobile device.

The above description of the provisioning process has referred to the process of tokenising a single network. However, equivalent processes can be followed where the card is a dual-network card. In the first case, the mobile wallet provider sends messages to two different TSPs, each contacts the issuer for authorisation, and two tokens are stored on the user's device. In the second case, the issuer can request separate tokens from different TSPs for the two networks that are enabled on the account.

Once tokens for the two networks are issued, the dual-network card can then be shown in the cardholder's mobile device in one of two visual representations:

  • As two separate cards in the cardholder's mobile wallet or app, with the cardholder able to choose (possibly on a transaction-by-transaction basis) which will be his/her ‘front of wallet’ card
  • As a single card, with some form of ‘button’ within the wallet or app that enables the cardholder to set (and reset) his/her default network for that card.

The dual-network card can then enable transactions via either network, with the same effect as occurs when a cardholder dips their physical card in a terminal and uses the terminal buttons (‘cheque’, ‘savings’ or ‘credit’) to choose the network (and in some cases the account).