March 2, 2015
The details behind the concept of generic ProxyEMVPay cards as an ubiquitous and cheap non-mobile equivalent to Apple Pay, were described in How To Enable Tokenization With Physical Payment Cards. Essentially, the ProxyEMVPay card could be offered as Visa, MasterCard, or American Express compatible. It is personalized and issued with an ‘inactive’ token (linked to a NULL PAN inside the payment network Tokenization Service Provider or TSP) and set to standard EMV keys and profile data elements (i.e. full EMV and/or MagStripe/MSD mode). The payment network (or certified 3rd party) EMVCo compliant TSP should provide all required personalization data elements and encryption keys to a card personalization bureau (i.e. Gemalto, G&D, Oberthur, etc.), who then acts as the token requestor during the card production process.
ProxyEMVPay cards must be securely ‘activated’ by the consumer via the activation portal, before they can be used. The activation process effectively links the ProxyEMVPay card’s token to the real underlined payment card PAN. The activation process also ensures that the issuer of the underlined payment card securely authenticates the cardholder. Since all ‘active’ ProxyEMVPay cards, when used, protect the underlined payment card’s PAN, they can be used for secure in-app payments (let’s call this method OnlineEMVPay). The basic requirements for OnlineEMVPay are:
The in-app payment flow begins with the consumer confirming the transaction details and clicking on the ‘Pay With OnlineEMVPay’ button on the merchant’s mobile application checkout screen. The merchant mobile application code calls the OnlineEMVPay API and provides the ‘merchant-id’. After that, the OnlineEMVPay API sends the ‘merchant-id’ data to the OnlineEMVPay server, via SSL connection.
The OnlineEMVPay server uses the ‘merchant-id’ to verify that the merchant is enabled for OnlineEMVPay and responds to the OnlineEMVPay API with the Unpredictable Number (i.e. random nonce). After receiving the Unpredictable Number from the OnlineEMVPay server, the OnlineEMVPay API activates the phone’s NFC card reader and instructs the consumer to hold the ‘active’ ProxyEMVPay card close to the phone.
The consumer presents/taps the card close to the phone. The OnlineEMVPay API reads the standard PPSE directory from the card and detects which type (MasterCard, Visa, etc.) of ProxyEMVPay card is being used. Once the type of the ProxyEMV card is determined, the OnlineEMVPay API adjusts the set of contactless APDU commands to match the card type.
NOTE: for the purpose of this article, we will assume that OnlineEMVPay API and ProxyEMVPay card execute simple MasterCard PayPass MagStripe mode or Visa payWave MSD profile APDU flow, rather than full EMV.
During the APDU exchange, the OnlineEMVPay API may provide to the ProxyEMVPay card the Unpredictable Number (for Visa MSD profile card, the Unpredictable Number isn’t used).
The OnlineEMVPay API uses READ RECORD APDU and reads Track 2 Equivalent Data from the ProxyEMVPay card. In the case of a Visa MSD profile card, the Track 2 Equivalent Data record already contains the calculated, unique, per transaction dCVV cryptogram (it was calculated inside GET PROCESSING OPTION APDU). In case of the MasterCard MagStripe mode card, the OnlineEMVPay API obtains a unique, per transaction CVC3 cryptogram value from the COMPUTE CRYPTOGRAPHIC CHECKSUM APDU call (Unpredictable Number is an input parameter) and then overwrites the static CVC inside the Track 2 Equivalent Data with CVC3. In any case, at the end of the APDU exchange, the Track 2 Equivalent Data record contains dCVV / CVC3 cryptogram, the ProxyEMVPay Token, ProxyEMVToken Expiry Date, Unpredictable Number, etc. The OnlineEMVPay API then encrypts Track 2 Equivalent Data content with OnlineEMVPay server’s public RSA key and sends it to an OnlineEMVPay server using SSL connection.
The OnlineEMVPay server decrypts the Track 2 Equivalent Data received from the OnlineEMVPay mobile application, then re-encrypts it with online merchant public RSA key and responds back to the OnlineEMVPay API. The OnlineEMVPay API returns the Track 2 Equivalent Data value encrypted with the merchant server’s public RSA key to the merchant mobile application code. The merchant’s mobile application then forwards the encrypted Track 2 Equivalent Data to the merchant server for further processing.
The merchant server decrypts the received Track 2 Equivalent Data with its private RSA key and uses it to prepare the online transaction authorization request in the standard format used with its processor. The merchant’s payment processor routes it to the proper payment network (by BIN of the ProxyEMVPay Token).
The payment network recognizes, by the BIN of the ProxyEMVPay Token, that it is not a real PAN and then forwards the ProxyEMVPay Token, ProxyEMVPay Token Expiry Date, dCVV/CVC3 cryptogram, and Unpredictable Number (if present) to the TSP. The TSP de-tokenizes the ProxyEMVPay token back to the linked/underlined card PAN, verifies the dCVV [Visa] / CVC3 [MasterCard] cryptogram and that all predefined parameters for the 'active' ProxyEMVPay card are still within allowed limits. If everything checks OK, the payment network prepares the standard authorization request with the underlined card PAN and sends it to the issuer of the underlined payment card for final authorization. The underlined card issuer authorizes the transaction normally against the account of the underlined card.
The presence of the valid ProxyEMVPay Token Cryptogram (CVC3 [MasterCard] or dCVV [Visa]) proves to the payment network’s TSP that the valid ProxyEMVPay card is 'present' during the in-app payment. When ProxyEMVPay card has biometric capabilities (i.e. Zwipe or equivalent), it can seamlessly authenticate the cardholder, similar to TouchID authentication in Apple Pay.
The flow described above is more secure, efficient, and convenient than traditional online payments based on HTML forms, digital wallets, or merchant cards on file databases. The temporary nature of ‘active’ ProxyEMVPay cards, plus their usage of tokenization and unique per transaction cryptograms, makes them ideal for online in-app payments without the risks associated with providing real PAN to online merchants.