OnlineEMVPay – Using ProxyEMVPay Cards for Secure In-App Online Payments

March 1, 2015     By : Milos Dunjic

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:

  •      A consumer’s ProxyEMVPay card must be contactless capable and ‘active’
  •      A consumer must have the smartphone which can act as a personal NFC/contactless card reader and has the merchant’s mobile application installed
  •      The merchant’s mobile application is integrated with an OnlineEMVPay SDK and displays the “Pay With OnlineEMVPay” button, meaning that the online merchant officially accepts the OnlineEMVPay payment method

In-App Payment Flow Description Using ProxyEMVPay Card

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.

Online Authorization Request 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.

Conclusion

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.

Stay Fresh on FinTech. Get our Daily Insights.

Milos Dunjic

Milos Dunjic is FinTech executive fascinated with and focused on payments and insurance innovation. All opinions are his own and not of his employers
  1. #1 Ganeshji Marwaha 8 March, 2015, 20:49

    This is an interesting idea. Among other things, it helps make online payments (essentially in-app payments) into a card-present transaction. Got a couple of questions though.

    1. Typically, who will play the role of OnlineEMVPay – the SDK and the Server etc.
    2. Why do we have to encrypt Track2 data using OnlineEMVPay Public Key and send it over to their server, just to expect back Track2 data encrypted using merchant’s public key in return. Can’t the SDK return the Track2 data back to the merchant app that called it and the app itself can encrypt using the merchant’s public key before sending it over to the merchant’s server. I am probably missing something. Is there anything else that the OnlineEMVPay server does other than decrypting and re-encrypting (using merchant’s public key) before returning.

    Thanks.

    Reply this comment
    • Milos 9 March, 2015, 06:07

      Hi Ganeshji

      1. the role will usually be played by an issuer of the generic tokenized ProxyEMVPay card. That could be traditional payment network like Visa, MasterCard, American Express, etc., an independent 3rd party provider, OR even card manufacturer / card personalization bureau like Gemalto, Oberthur, G&D, …

      2. the OnlineEMVPay server originally provided Unpredictable Number to the OnlineEMVPay SDK when the in-app payment transaction started. The goal of the proposed flow was to ensure that the merchant mobile application code does not manipulate the transaction messages in any way. However eventual optimizations of the flow are certainly possible, depending on the risk assessment, I agree. Will think about it.

      Thanks for reading

      Reply this comment
      • Ganeshji Marwaha 9 March, 2015, 12:27

        Thanks for the quick response Milos and for sharing your thoughts in this blog. I enjoy reading them.

        If the mobile app belongs to the merchant anyways and the merchant server can get access to the decrypted Track2 data as well, i was wondering if there was really any point in disallowing the merchant app code to access Track2 data in the raw? I am not trying to argue, just trying to understand your thought behind it. If your original thought was that merchant’s app code could be compromised because of a rooted phone, then the same applies to OnlineEMVPay SDK code as well.

        Thanks once again for a very informative blog.

        Reply this comment
        • Milos 9 March, 2015, 22:43

          Yes what you say is very true … Track 2 Equivalent Data content in case of ProxyEMVPay cards would contain token data and not real underlined card data … now, when I look back to the reason why I have proposed this kind of flow – it is that it resembles 100% in-app purchase flow during ApplePay so I just thought I would show this can do the exact same flow … but of course both could be optimized probably further. Thanks for suggestion.

          Reply this comment