Host Card Emulation Series: Stored-Value Cards and HCE

This post will focus on using stored-value cards for payment at contact-less NFC terminals through an HCE (Host Card Emulation) solution. HCE technology present in NFC payment apps can be used with various different cards. A large number of retailers are offering company branded stored-value cards to consumers. This use case will look at precisely that, using stored-value cards at NFC terminals.

     For this example we are using the McDonald's Arch Card. 

     

           

           

              McDonald's Arch Card

McDonald’s for some time has had contact-less NFC capable payment terminals installed and operational in all of  its franchises in the U.S. This example will use the re-loadable Arch card to pay as well as re-load balance at contact-less NFC terminals. The Arch Card is available for purchase at various locations including all McDonald's restaurants. This specific card as well others with similar architecture are able to be loaded into the system SimplyTapp has created utilizing HCE. For this example I will be using the “Tapp“Application now available for free on Google Play store.

https://play.google.com/store/apps/details?id=com.tapp&hl=en

Simple process of loading your Arch Card for payment into Tapp app:

1. Downloaded Tapp app from Google Play store.
2. Log in and select to add a card from the add card button indicated by + sign in the action bar.
3. Select Mcdonald's Arch Card and purchase.
4. Refresh card list and Arch card will be loaded into Tapp App.
5.      Select Arch Card for payment.

At this point my Tapp app is ready to make payments with your Arch Card at McDonald’s contact-less terminals, which are standard at all locations in the U.S.

Paying with your KitKat Android  4.4 device using the HCE architecture found in the Tapp app provides a great user experience.  There is no specific or additional  instructions necessary when using your digital copy of your Arch Card loaded into your Tapp app.  Flow of transaction was similar to a typical experience, order was placed and cashier simply asked cash or card. Card was indicated as form of pay and at this time phone was placed over terminal and payment was made with my Arch Card. The experience for the merchant as well as the user was seamless. A video of the experience is found below:

  Pay with Arch Card:

                                        https://www.youtube.com/watch?v=6Off6nvl3t8

At McDonald’s I was also able to add additional funds to my re-loadable Arch Card that was previously loaded in my Tapp app. The process was simple and strait forward. I told the cashier that I had a re-loadable Arch Card and I wished to add additional funds to it.  The cashier rang me up and I handed cash over. I then placed my phone over the terminal and card was reloaded. From a user experience reloading and payment were the same. A video of the experience is found below:

   Reload Arch Card:

                                      https://www.youtube.com/watch?v=iCJTJSWhFEc

All of my transactions with my Arch Card can be monitored through McDonald's website.The Tapp app does not currently possess functionality to update balances on application. The HCE digital transaction shown in videos above are reflected in the following statement.

Having the Tapp app with HCE capabilities it allowed me to use the Arch Card at  McDonald's terminal from my mobile phone. My completely digital transaction added to my user experience and gave a great glimpse in to the future of payments from the view point of stored-value cards. The pairing of HCE and stored-value cards offer a great way to add value on either side of the transaction.

Host Card Emulation Series: SwipeYours - Tap Using A Card From Your Wallet

While various Android HCE (Host Card Emulation) examples have been popping up, until now there has been no simple examples that could be easily tested with live payment terminals. SwipeYours fills this space.

SwipeYours is a small, self contained app from which your card data never leaves the phone except to make NFC payments.  It uses the Visa-MSD (Magnetic Stripe Data) protocol to make tap payments. While Visa-MSD is now deprecated, it is supported by most NFC payment terminals in North America and this is unlikely to change in the near future. In Austin, TX we’ve successfully used SwipeYours at all of the following:

• CVS drugstore
• McDonald’s
• Jack in the Box
• Taco Bell
• Jamba Juice
• Valero Gas Stations

Links:

• SwipeYours source code
• Direct Link to the PaymentService class
• Google Play Download

What you need to use SwipeYours:

• A magnetic stripe reader to pull your card data. These can be purchased cheaply on both Amazon and Ebay in the US.
• An NFC phone running Android 4.4+ (KitKat or above).
• A non-chipped Visa credit or debit card. If the card already has a smart chip for native tap payments, the authorization processor is most likely expecting a different variation of Visa MSD than what we can provide. 
• An issuing bank (or its outsourced processor) that does not check the delivery method: swipe, dip or tap.The processor has access to the delivery method of the card data and can reject a tap transaction if it wants to. All tested prepaid Visa cards have not had this issue and most major banks like Chase work fine. Capital One cards and the processor for some small credit unions, unfortunately, do have this issue.

Small Print Disclaimer:

SimplyTapp does not encourage the storage of payment credentials on your phone and provides secure cloud based solutions.  I have provided the source code and Google play download via my personal Github and Google accounts respectively.  Adding your own magnetic stripe data to SwipeYours may work, but it is not a supported payment method by Visa or your issuing bank.  

Visa-MSD Payment example:

Applications implementing HCE send and receive data with a POS (Point Of Sale) terminal using a byte array abstraction called an APDU (Application Protocol Data Unit).

The MainActivity of SwipeYours logs these APDU exchanges to the screen so developers can better understand how the process works.  Below I’ll show the data from a typical Visa-MSD transaction performed by SwipeYours.  If you want to better understand the values in the hex strings below, the source code to the SwipeYours PaymentService has lots of detailed comments.

POS → SwipeYours

PaymentService Received PPSE select: 00A404000E325041592E5359532E444446303100

Here the POS sent our app a PPSE (Proximity Payment Service Environment) select.  This is the first APDU sent in any payment transaction.  It asks the payment device to send a list of supported payment types.

The AID (Application IDentifier) in the request is highlighted in red. It's the ASCII string 2PAY.SYS.DDF01 represented in hexadecimal.  If you are not using HCE (Host Card Emulation), these select statements would be delivered to a JavaCard applet registered to that AID.  JavaCard is a subset of Java designed for low power chips.

With HCE, there is no requirement to use JavaCard applets.  The PaymentService entry in our Android manifest specifies a list of AID values that should be directed to our service.

POS ← SwipeYours

Response: 6F23840E325041592E5359532E4444463031A511BF0C0E610C4F07A00000000310108701019000

Our PPSE response contains a single AID value letting the POS know that we only support Visa credit and debit transactions.  

POS → SwipeYours

PaymentService Received Visa-MSD select: 00A4040007A000000003101000

Now the POS selects the only payment AID that we offered above.

POS ← SwipeYours

Response: 6F1E8407A0000000031010A513500B56495341204352454449549F38039F66029000

SwipeYours sends Visa-MSD select response. For trivia sake, the second value in red above is the ASCII string VISA CREDIT represented in hexadecimal.

POS → SwipeYours

PaymentService Received GPO: 80A80000048302800000

POS sends the Get Processing Options (GPO) command.

POS ← SwipeYours

Response: 80060080080101009000

Payment devices supporting Visa transactions can support different payment protocols (Visa uses the term "path" instead of protocol).  Our response lets the POS terminal know that we only support Visa-MSD.   Our GPO response above lets the POS know that we only support Visa -MSD.

POS → SwipeYours

PaymentService Received READ REC: 00B2010C00

POS sends Read Record command. It's a short command requesting the payment data.

POS ← SwipeYours

Response: 701557134046460664629718D16101210000018100000F9000

Here SwipeYours sends your credit card data to the terminal in the read record response. The format of the data is known as track 2 equivalent data. Its a fairly straight forward transformation of the track 2 portion of the card's magstripe data. You replace the '=' with a valid hex digit 'D' and you add a single 'F' to the end if needed to create an even number of hex digits. The extra 'F' digit was necessary in this example, because each hex value is 4 bits of binary data and we need an even number of hex digits to convert to a whole number of 8-bit bytes.

Here is the track 2 data that was used to create the APDU above:

;4046460664629718=16101210000018100000?

The track 2 syntax is:

• Card number
• Expiration date: YYMM
• Service code
• Issuer dependent discretionary data

How to decipher the service code, XXX:

1. Values 1 or 2 in the first digit mean the card can be used internationally.  Values 6 or 7 say the card is restricted to the issuer's country or some group of countries. 2 and 7 indicate that the card has a built in chip for tap payments and the magstripe data on these cards will probably not work with SwipeYours.
2. The middle digit specifies who provides authorization processing.  Value 0 means normal, 2 is by the issuer or their processor, and 4 is the issuer unless a bilateral agreement applies.
3. The last digit specifies allowed services and pin requirements.  Values 0, 1 and 6 mean that there are are no restrictions. Values 2, 5 and 7 are restricted to goods and services (i.e. no cash). 3 is ATM only. 4 is cash only /// Values 1, 2 and 4 indicate that no pin is required. Values 0, 3 and 5 indicate that a pin is required. 6 and 7 say the pin is required when a pin input device is present.