Host Card Emulation Series:User Experience

Getting a Feel for the User Experience: Example of the Initial Authorization Process 

Available with the mobile SDK download from SimplyTapp. http://wiki.simplytapp.com/index.php?title=Mobile_SDK

This post is meant to show and explain what a user's initial authorization experience might look like. Keep in mind that this is a user experience example only and the SimplyTapp Mobile SDK has already been integrated with the user's third party app.

The following post will take you through the initial authorization process and explain what is happening along the way. At the end you will have a independent third party app that will be loaded with one authorized payment card and will be ready for "tap and pay" use at contact-less terminals, like McDonald's.

Lets begin

User launches your app (clicking on the app icon from the phone screen)

The picture below illustrates what the user experience would look like from within the app.  The process is based on existing Open Authentication standards.  The application must first ask the user if they would like to approve the application for making payments with a payment card at a P.O.S. terminal.

 * Any SimplyTapp branding is purely for demo purposes. Branding would be replaced by issuing entity.

In the back end this is the process that goes on;  The box on the right side is typically a browser that verifies to the user that the application is authentic and that the application would like to ask permission to present payment cards as a form of payment at a P.O.S.  Upon user approval, the application will ultimately end up with an access token and secret that can be used only to allow transactions against a remote card, but not manage the card itself.

User Sets Pin

After you have successfully logged in and authorized the application  you will be brought from the browser back to the mobile app. You will be prompted to create a new 4 digit pin. This pin is for our newly added payment functionality and can be used instead of storing any Open Authentication secrets on the handset itself.  The pin is never stored locally on the handset and is used as a quick password entry.

 

In the background the open authentication process is used to synchronize the user's new pin with the token secret:

 

At this point the mobile application is approved by the user to make point of sale payments with any cards that it may contain.  The app itself does not contain any cards yet as the customer has not applied or registered for any digital cards.  In a similar process, the user is made aware that the app currently has cards available, but the user must apply for them.

User gets their first Card

The user has the ability to apply for cards from issuing entities. Simply Bank is a demo page set up to illustrate and provide a walk through for issuer card holder relationships.  Here you can load specific card from SimplyBank and then navigate back to home screen of app.  The process is similar to the approval process of the app to present cards for payment.  The main difference being the user must approve the issuing bank to place a card in the mobile application.  The user will be pushed from the mobile application to the issuing bank registration web page:

In the background, the card acquisition process is represented like this.  Ultimately, the personalized card is represented in the same format as an EMV chip card, however the data is stored remotely inside a secure vault instead of in a localized SIM chip:

User pushed back to their App and ready to pay

Once a payment card is acquired, you will view and navigate app as normal. In this example we can check balances and manage our money exactly the same as before with app.  The payment feature can happen in the background by simply tapping the phone to a payment terminal at any given time.

In the background, the payment process is triggered by an interrupt from the terminal and can happen at any time.  To be prepared, the mobile application has pre-fetched payment terminal data to use when making a payment.  This fetching process can happen at any time prior to the first tap and may consist of one or more tokens to be used for payment depending on configurations by the issuer:

Extra Info

Below are the logs from payment process happening on the back end.. These logs are part of the U.I. from the SingleCard app.

This example app is now fully authorized and ready for secure contact-less NFC payments.

SimplyTapp's developers wiki is available at http://wiki.simplytapp.com/index.php?title=Main_Page