HCE: The User Experience That Nobody Talks About

Host Card Emulation (HCE) is an incredibly enabling technology. For Android developers there are a few nuances to be aware of in the form of OS rules. Not understanding how these rules apply can have a negative impact and create an embarrassing or awkward customer experience if the system should render a 'payment failure'. Here are four scenarios to keep in mind to avoid point-of-sale issues.

Avoid The Embarrassment

The only limiting factor for the NFC radio in an Android device is whether or not the screen is lit up. What that means is that the NFC radio will turn on and could be ready for an HCE transaction is:

screen is dark:    NO
screen is lit:       YES

That rule alone is an Android rule, not an application rule, and so the application will have the ability to further limit this HCE experience if it wants to.

To support the best user experience, an application must be able to respond and complete an HCE transaction on demand if the screen is lit up. This should hold true even if:

1) application is running in the foreground
2) application is running in the background
3) application is NOT running at all because android has "repo'd" or removed it from running memory, or not started at all since a re-boot of the phone.
4) application is NOT running and a time based  Limited Use Key has expired since the application stopped running

The 1st and 2nd cases above are the easy ones as transaction data can be store in the running application memory space.

Here is how android works on the 3rd and 4th scenarios. When the phone antenna engages the terminal antenna and the terminal requests a particular AID, then the android OS looks at that AID request from the terminal and decides which Card Emulation Service to startup based on the "Tap and Pay" menu options.  That service is NOT your app, it is a component of your application that is expected to respond to APDU requests from the terminal. An APDU stands for Application Protocol Data Units.  The challenge is that the service will most likely not contain the APDU data to respond with as the rest of the application is not currently running at that time and the data required may not be loaded. It would require that the APDU data that the reader is asking for actually must be persistent in some way on the device so that the service could get access to it and answer the terminal properly with card data.

There are a few ways to store data locally, but the point is that it must happen in order to respond to the reader in time for a proper user experience. We have noted that simply expecting the application to be running on the phone at tap time is simply not reliable and that in a 24 hour window, it the app is not used, then Android has likely removed that application from memory.

This is just food for thought as you are thinking of designing your own HCE application or using a vendor like ST.  By the way, the SimplyTapp SDK supports all 4 scenarios listed above. The 4th is slightly more complicated, but i'll leave it up to you to noodle at.

Are you a Tier 1 or a Tier 2 token requestor? (It matters)

With all the talk about Token Service Providers (TSP) and token requesting, I felt it was worth describing a bit more about the role of a "Token Requestor." The way the term is bandied about would lead most to believe that this is a single entity that works to pull temporary or dynamic transactional data from a master TSP for use on the mobile device, but you are about to find out it's a bit more complicated and the decision you make around this topic can have serious consequences in the future.

We all know that the current normalized TSPs or Master Token Service Provider services are the domain of the card networks - presently MasterCard, Visa and AMEX. I don't expect that role to change overnight or in the next year or for some banks, maybe ever. But if banks expect to be able to control their own destiny with the decision, they’ll need to understand some important differences about the term “Token Requestor.”

What’s really going on under the hood

Contrary to what some providers may tell you, “Token Requestor” isn’t a single entity but actually two separate roles which work in tandem. The goal of this article is to help readers understand the roles better because in reality the roles are as different as comparing apples and oranges (or more appropriately stated "service" and "consumer of service").  And more importantly, the selection of the roles dictate the end result of the service and in that, how “locked in” or “not locked in” you are to one provider.

Here is a high level diagram that depicts how tokens are issued to help better understand the 2 tiered roles of token requestors.

Let’s break down the "Token Requestor" blob we have above into two distinct roles before identifying the practical examples of entities that fill those roles.

Tier 1 token definition: The root token requested from the Token Service Provider which is static data for the life of the issued card.  A Tier 1 token has the ability to be autonomous from the TSP and service individual transaction level Tier 2 token issuance because all data required to create many Tier 2 tokens are available in their respective parent Tier 1 token.  So basically, the Tier 1 token is the creator for all Tier 2 tokens.  It is a parent->children relationship.

The tier 1 role is that of being the primary service provider for individual cards and can be summarized by these tasks:

• Requesting the static token from the TSP which includes the tokenized PAN and the card master key
• Protecting the card master key
• Generating all Tier 2 tokens from the card master key
• Responding to service requests to receive new Tier 2 tokens
• Responding to issuer triggers for card life cycle events such as:
• card personalization
• card termination
• card disable
• card enable

Tier 2 token definition:  The secondary or child token that is generated from the root or parent token and used for individual payment transactions. This token is considered limited use and is deemed "ok" to be housed in the mobile device application.

The Tier 2 role is to protect and deliver the tokenized payment information to the acquirer for individual transactions and can be summarized by these tasks:

• Requesting the dynamic token from the Tier 1 service
• Protecting the dynamic token
• Managing the lifecycle of the dynamic token
• Delivering the dynamic token to the acquirer when requested

Some practical examples of the token request process are listed below and include some current day entities who are performing those roles:

It is especially important to note in the diagram above how both the Master Token Service and Tier 1 Token Requestor are the same entity in some cases.  THEY DO NOT HAVE TO BE AND THEY PROBABLY SHOULDN'T BE.  For example both Visa and MasterCard offer the master TSP service but are also performing as a Tier 1 service requestor to their own TSP at the same time.  That would mean that a service like we provide as a Tier 1 requestor consumes MasterCard or Visa TSP services, but then ALSO COMPETES directly with them as a Tier 1 requestor. Essentially, what some card networks have proposed greatly reduces your ability to chose competitive service offerings if your needs change in the future.

If this scenario makes you uncomfortable, you have reason to be concerned, the implications could be very costly to your mobile payments strategy in the long run.

The key business driver and need for a company like SimplyTapp in the Tier 1 Requestor role is that we offer a configuration option for the Master TSP services for each card brand which in turn can offer autonomy from the card networks similar to what Apple is able to do through Apple Pay (once they request a token from the networks, they run the service on that token through securing the token master key on the Secure Element).  This helps maintain the existing card issuance relationship with the networks status quo when comparing to the existing issuance model of plastic.  

Does the Tier 1 Token Requestor service you use allow you to configure or dictate the Master TSP?

See this chart:

You are a Tier 2 token requestor and

Your Tier 1 Requestor Service is:	You Can Configure and change the Master TSP mid-service	Switch From TSP without card by card migration
Visa	NO, use Visa TSP only	NO
MasterCard	NO, use MasterCard TSP only	NO
3rd Party	Yes, use VISA, MC, or even your own later	YES

So, the 3rd party Tier 1 Requestor service helps issuing customers with greater migration control.  If an issuer has aspirations to run it's own TSP at some point, or select a different TSP, this is an important point NOT to miss.

If a group of cards has been issued through the TSP service to a Tier 1 Requestor, changing that Tier 1 requestor leads to a MIGRATION process rather than just a switch over of the entire card set.  This further impacts the mobile application itself as it would be required to be a Tier 2 Requestor to possibly multiple Tier 1 requestors during the change over.  

In the event the Tier 1 requestor offers TSP configuration, that configuration to use a different TSP can be changed very similar to a DNS registration which makes the switch overnight and designed not to impact anything downstream (no impact on Tier 2 requestor --mobile app--, or existing cards).  

In the event the Tier 1 requestor DOES NOT offer a TSP configuration option, then the only way to move TSP would be to move Tier 1 requestor services, which has a dramatic impact downstream to the Tier 2 requestor / mobile app and also creates a migration switch rather than immediate.

The key question that needs to be asked:

Does your Tier 1 Token Requestor service offer independent configuration of the TSP master service?

If the answer is NO, then you are mostly likely locked-in for the long haul.

If the answer is YES, then you will have more flexibility to some day:

• Run your own or change to a different TSP.
• Negotiate better rates because there is no technical limitation to an immediate switch instead of a slow and resource consuming migration.

A Watershed Moment for the Payments Industry

Did you see the news? If you blinked, you might have missed it but its importance has ramifications throughout the payments industry.

Last Friday, Royal Bank of Canada (RBC) became the first North American bank to launch a pure Cloud Based Payments (CBP) solution utilizing Host Card Emulation (HCE) technology. Kudos to RBC! Read their release here.

An important aspect of the announcement is that the Canadian debit organization Interac was included with it’s Flash for Cloud Based Payments. Interac’s Flash seems to have beaten all other payments networks and their specifications to the punch by bringing a working solution to the market.

From our perspective, this marks the beginning of an anticipatory shift by financial institutions away from analog payments into digital. The shift will accelerate over the next several years as many financial institutions look for more effective ways to engage customers and distribute products to an ever more mobile and demanding consumer base. Juniper Research estimates mobile retail purchases to eclipse $700B annually by 2017. This transformation will not only impact the way banks engage with customers, but will drive what kinds of financial products and services are developed and how they are offered to customers throughout an ever evolving environment.

We’ve heard these predictions before, why now?

The payments industry ecosystem is at an inflection point. The meteoric rate at which innovation is happening foretells of much needed change and the necessity for more adaptive business models.

Enter CBP and HCE.

The concept of CBP and HCE did not exist until SimplyTapp introduced them in August 2012.  CBP is the framework for storing payment credentials in a virtual Secure Element (SE) in the cloud while HCE provides the path of getting those credentials from the cardholder’s mobile phone to the retailer’s Point of Sale (POS). Groundbreaking as that was, it only represented the first of several enablers that were needed before widespread adoption could take place within the industry. The next step that was needed occurred nearly one year later with the inclusion of HCE inside Android 4.4 (KitKat) in September 2013 which provided developers with a proven, widely distributed platform to build wallets and mobile banking applications. Earlier this year at Mobile World Congress in Barcelona, Visa and MasterCard gave their much needed support and endorsement for CBP and HCE providing immediate legitimacy and freeing up issuing banks for innovation. Only one critical requirement remained in order to drive adoption of this technology. A forward-looking bank needed to take the initiative and roll-out a live implementation with real data and real transactions. RBC’s announcement last week fulfilled that requirement.

With each of these key enablers firmly in place, the stage is set for mobile payment proliferation. Each day, consumers are expecting to do more with their mobile devices than ever before. The emergence of groundbreaking core technology and services, including the launch of Apple Pay, reveals a new and largely unmet demand for point-of-sale mobile purchases. More and more consumers will come to rely upon customer-centric financial institutions to help them conduct secure and convenient mobile purchases.

Being the first at anything is never easy. It requires vision, a smart assessment of the path ahead and a resolve to overcome any obstacles discovered along the way. For those who are willing, the rewards greatly outweigh the risks. We applaud RBC’s and Interac’s industry leadership and focus on the customer. And we join them in ushering a new year full of innovation.

Agree? Disagree? Let us know what you think.

The Absolute Simplest HCE "Pay" Application Enablement

Most of the code below relates to GUI messaging,  but this Android app is full HCE for a Cloud Based Payments card.  It is a total of 201 lines of code including comments, and line spaces. It is a single class application for simplicity.
The goal is to show that the libraries for managing CBP on the mobile app are lightweight for developers to use.
The libs are designed to be placed into ANY application that may want to enable CBP.  The one below is about the simplest integration.
The full application is called SimplestTapp and can be downloaded and tested here:
http://wiki.simplytapp.com/home/self-driven-hce-pilot/make-a-payment-card/simplytapp-s-vcbp-changelog/software-dev-kits/mobile-sdk

it also may be good to view this help resource for creating and managing the card perso and lifecycle in the cloud:
http://wiki.simplytapp.com/home/using-admin-api-console

The core of the card download and enablement is really contained in this section.  This section instantiates a VirtualCard that will be loaded from the remote server.  In order to instantiate the CBP card, you will see that there are some required credential information because a request will be made to the CBP server to retrieve the card that will be used.
The data in the snippet is sample data only.

The AsyncTask is used because the load() method makes network calls and can't be run on the UI thread.

        // Create a card with data from AdminApi console
        // See wiki for help:
        // http://wiki.simplytapp.com/home/using-admin-api-console
        //
        // Values are found within your AdminApi Console. Click Get APP
        // Credentials.
        //
        // card agent code hash is found inside the Issuer Entity portion of the
        // web portal
        //
        final VirtualCard card = VirtualCardBuilder
                .cardId("5901")
                .mobileAppConsumerKey(
                        "oJmqoey7I97FBOZQDXoH0A9RbM7BciXbD8CHZDMU")
                .mobileAppConsumerSecret(
                        "ugTD5dGjBUEC1pyzxjMNtw6k9TUocGtY4plta9he")
                .walletAccessToken("O15F4jG3PcwC44NpkfEqv1ZD7tjNo5NhGpHHFEax")
                .walletTokenSecret("Ur504iPQn2lxgsS5fVBycf2zK9uuSglppvn2mBa3")
                .cardAgentCodeHash("aa4185c2364048447a38aa02499a9897")
                .context(this).build();

        // now load the card...
        // this requires network connectivity and is blocking
        // so we must use AsyncTask to avoid running this in UI thread
        //
        new AsyncTask() {
            @Override
            protected Void doInBackground(Void... params) {
                try {
                    myActivity.postUi("=================================="
                            + "\n" + "=====Loading Card From Server====="
                            + "\n" + "=================================="
                            + "\n");
                    card.load();
                } catch (IOException ex) {
                    Log.e(TAG, "Failed to load", ex);
                }
                return (Void) null;
            }
        }.execute();

 Once the VirtualCard successfully loads, it has a mind of it's own and will perform all activities related to making a successful payment when requested to do so.  For this, the feedback mechanism from the card to the mobile application is a messaging interface and should be defined in a block similar to the one below.  You will notice that the block below is responsible for handling feedback from the card and also notifying the card to activate after it was successfully created:

    // define the message default card message handler
    // and set it in the lib
    static {
        VirtualCardMessaging virtualCardMessenger = new VirtualCardMessaging() {
            @Override
            public void virtualCardMessage(VirtualCardMessaging.Message message) {
                switch (message.getCode()) {
                case VirtualCardMessaging.CARD_CREATION_COMPLETED:
                    try {
                        // when card is created, then activate the card agent,
                        // then connect it to the ApduService,
                        // then ask the user if they want this app the default
                        // app
                        // for servicing the reader
                        message.getVirtualCard().activate();
                        ApduService.setVirtualCard(message.getVirtualCard());
                        myActivity.postUi("========================"
                                + "\n"
                                + "=====Card Created======="
                                + "\n"
                                + "========================"
                                + "\n"
                                + "==Card Id: "
                                + message.getVirtualCard().getVirtualCardId()
                                + "\n"
                                + "==Num: "
                                + message.getVirtualCard()
                                        .getVirtualCardNumber()
                                + "\n"
                                + "==Card Exp: "
                                + message.getVirtualCard()
                                        .getVirtualCardExpDate() + "\n"
                                + "==Card Type: "
                                + message.getVirtualCard().getVirtualCardType()
                                + "\n" + "==Card Logo: "
                                + message.getVirtualCard().getVirtualCardLogo()
                                + "\n");
                        myActivity.postUi("========================" + "\n"
                                + "=====Card Activating====" + "\n"
                                + "========================" + "\n");
                    } catch (IOException e) {
                        e.printStackTrace();
                    }
                    break;
                case VirtualCardMessaging.CARD_ACTIVATE_COMPLETED:
                    myActivity.postUi("========================" + "\n"
                            + "========================" + "\n"
                            + "========================" + "\n"
                            + "=====Card Activated=====" + "\n"
                            + "=====Ready To Tap=======" + "\n"
                            + "========================" + "\n"
                            + "========================" + "\n"
                            + "========================" + "\n");
                    break;
                case VirtualCardMessaging.TRANSACTION_ENDED:
                    myActivity.postUi("========================" + "\n"
                            + "========================" + "\n"
                            + "========================" + "\n"
                            + "===Ready To Tap Again====" + "\n"
                            + "========================" + "\n"
                            + "========================" + "\n"
                            + "========================" + "\n");
                    break;
                default:
                    break;
                }

                // log the message
                Log.d(TAG,
                        message.getMessage() + " cardId="
                                + message.getVirtualCardId() + " code="
                                + message.getCode());
                myActivity.postUi(message.getMessage() + " cardId="
                        + message.getVirtualCardId() + " code="
                        + message.getCode() + "\n");
            }

        };

        // set the default messenger
        VirtualCard.setDefaultVirtualCardMessaging(virtualCardMessenger);
    }

You will notice above that the messaging loop is logging all messages from the card and printing them to the screen of the app and the debugger.  This can give you an idea of the events the card notifies the app.  As far as API requests to the card from the app, the VirtualCard library contains many methods.  Here is the JavaDoc:
http://simplytapp.github.io/android/virtualcard/doc/

Full activity class code for this example:

package com.simplytapp.example.simplesttapp;

import java.io.IOException;

import com.simplytapp.virtualcard.ApduService;
import com.simplytapp.virtualcard.VirtualCard;
import com.simplytapp.virtualcard.VirtualCardBuilder;
import com.simplytapp.virtualcard.VirtualCardMessaging;

import android.app.Activity;
import android.content.ComponentName;
import android.content.Intent;
import android.nfc.NfcAdapter;
import android.nfc.cardemulation.CardEmulation;
import android.os.AsyncTask;
import android.os.Bundle;
import android.text.method.ScrollingMovementMethod;
import android.util.Log;
import android.widget.TextView;

public class MainActivity extends Activity {
    private static final String TAG = MainActivity.class.getSimpleName();
    private static MainActivity myActivity = null;
    private TextView tv = null;

    // this method posts strings to the textview box in the UI thread
    private void postUi(final String t) {
        new Runnable() {
            public void run() {
                runOnUiThread(new Runnable() {
                    public void run() {
                        tv.append(t);
                        if (tv.getLayout() != null) {
                            // auto-scroll vertically
                            final int scrollAmount = tv.getLayout().getLineTop(
                                    tv.getLineCount())
                                    - tv.getHeight();
                            // if there is no need to scroll, scrollAmount will
                            // be <=0
                            if (scrollAmount > 0)
                                tv.scrollTo(0, scrollAmount);
                            else
                                tv.scrollTo(0, 0);
                        }
                    }
                });
            }
        }.run();
    }

    // define the message default card message handler
    // and set it in the lib
    static {
        VirtualCardMessaging virtualCardMessenger = new VirtualCardMessaging() {
            @Override
            public void virtualCardMessage(VirtualCardMessaging.Message message) {
                switch (message.getCode()) {
                case VirtualCardMessaging.CARD_CREATION_COMPLETED:
                    try {
                        // when card is created, then activate the card agent,
                        // then connect it to the ApduService,
                        // then ask the user if they want this app the default
                        // app
                        // for servicing the reader
                        message.getVirtualCard().activate();
                        ApduService.setVirtualCard(message.getVirtualCard());
                        myActivity.postUi("========================"
                                + "\n"
                                + "=====Card Created======="
                                + "\n"
                                + "========================"
                                + "\n"
                                + "==Card Id: "
                                + message.getVirtualCard().getVirtualCardId()
                                + "\n"
                                + "==Num: "
                                + message.getVirtualCard()
                                        .getVirtualCardNumber()
                                + "\n"
                                + "==Card Exp: "
                                + message.getVirtualCard()
                                        .getVirtualCardExpDate() + "\n"
                                + "==Card Type: "
                                + message.getVirtualCard().getVirtualCardType()
                                + "\n" + "==Card Logo: "
                                + message.getVirtualCard().getVirtualCardLogo()
                                + "\n");
                        myActivity.postUi("========================" + "\n"
                                + "=====Card Activating====" + "\n"
                                + "========================" + "\n");
                    } catch (IOException e) {
                        e.printStackTrace();
                    }
                    break;
                case VirtualCardMessaging.CARD_ACTIVATE_COMPLETED:
                    myActivity.postUi("========================" + "\n"
                            + "========================" + "\n"
                            + "========================" + "\n"
                            + "=====Card Activated=====" + "\n"
                            + "=====Ready To Tap=======" + "\n"
                            + "========================" + "\n"
                            + "========================" + "\n"
                            + "========================" + "\n");
                    break;
                case VirtualCardMessaging.TRANSACTION_ENDED:
                    myActivity.postUi("========================" + "\n"
                            + "========================" + "\n"
                            + "========================" + "\n"
                            + "===Ready To Tap Again====" + "\n"
                            + "========================" + "\n"
                            + "========================" + "\n"
                            + "========================" + "\n");
                    break;
                default:
                    break;
                }

                // log the message
                Log.d(TAG,
                        message.getMessage() + " cardId="
                                + message.getVirtualCardId() + " code="
                                + message.getCode());
                myActivity.postUi(message.getMessage() + " cardId="
                        + message.getVirtualCardId() + " code="
                        + message.getCode() + "\n");
            }

        };

        // set the default messenger
        VirtualCard.setDefaultVirtualCardMessaging(virtualCardMessenger);
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        myActivity = this;
        tv = (TextView) findViewById(R.id.textView1);
        tv.setMovementMethod(new ScrollingMovementMethod());

        // try to set this app as the default HCE application app
        CardEmulation cardEmulationManager = CardEmulation
                .getInstance(NfcAdapter.getDefaultAdapter(this));
        ComponentName paymentServiceComponent = new ComponentName(
                getApplicationContext(), ApduService.class.getCanonicalName());

        if (!cardEmulationManager.isDefaultServiceForCategory(
                paymentServiceComponent, CardEmulation.CATEGORY_PAYMENT)) {
            Intent intent = new Intent(CardEmulation.ACTION_CHANGE_DEFAULT);
            intent.putExtra(CardEmulation.EXTRA_CATEGORY,
                    CardEmulation.CATEGORY_PAYMENT);
            intent.putExtra(CardEmulation.EXTRA_SERVICE_COMPONENT,
                    paymentServiceComponent);
            startActivityForResult(intent, 0);
        }

        // Create a card with data from AdminApi console
        // See wiki for help:
        // http://wiki.simplytapp.com/home/using-admin-api-console
        //
        // Values are found within your AdminApi Console. Click Get APP
        // Credentials.
        //
        // card agent code hash is found inside the Issuer Entity portion of the
        // web portal
        //
        final VirtualCard card = VirtualCardBuilder
                .cardId("5901")
                .mobileAppConsumerKey(
                        "oJmqoey7I97FBOZQDXoH0A9RbM7BciXbD8CHZDMU")
                .mobileAppConsumerSecret(
                        "ugTD5dGjBUEC1pyzxjMNtw6k9TUocGtY4plta9he")
                .walletAccessToken("O15F4jG3PcwC44NpkfEqv1ZD7tjNo5NhGpHHFEax")
                .walletTokenSecret("Ur504iPQn2lxgsS5fVBycf2zK9uuSglppvn2mBa3")
                .cardAgentCodeHash("aa4185c2364048447a38aa02499a9897")
                .context(this).build();

        // now load the card...
        // this requires network connectivity and is blocking
        // so we must use AsyncTask to avoid running this in UI thread
        //
        new AsyncTask() {
            @Override
            protected Void doInBackground(Void... params) {
                try {
                    myActivity.postUi("=================================="
                            + "\n" + "=====Loading Card From Server====="
                            + "\n" + "=================================="
                            + "\n");
                    card.load();
                } catch (IOException ex) {
                    Log.e(TAG, "Failed to load", ex);
                }
                return (Void) null;
            }
        }.execute();

    }

}

Cryptogram calculation clarity for CBP

This is the key concept and change between EMV and what is required for CBP cryptograms.

Effectively the cryptogram in the CBP payment is created half in the cloud and then the other half when you tap the phone.

The reason for this is because the network connectivity may not allow a scenario like the left side of the diagram below as the UN would get cut off from transmitting from the POS to the calculation space, or it would be subject to network latency and create a "Tap and Hover" effect that would be an awful user experience.

The CBP cryptogram allows all components to be used as before and exposes a "relay threat" only to the android app after the SUK is received, but not to the POS terminal.   It also allows the Phase 2 calculation to happen independent of cloud availability at tap time.  The Phase 1 calculation and delivery to the phone from the cloud is expected to be preformed prior to tapping the phone, but not during the tap itself.

The thought is to offset the relay threat with in app security and sensor rich android OS.

It becomes a net neutral from a security standpoint really, IMO.

Innovators’ Spotlight

Asia-The New Frontier for Contactless Payments

Asia is pivotal to the future of mobile contactless payments. The region has the numbers, and the markets are mostly EMV compliant or in the process. Some have moved further down the path of contactless than many others across the rest of the world. Veterans of the payments space will recollect the early pioneers of mobile payments came from this region. There is a quiet confidence in innovation centered around consumer aspirations, cashless evolution and new strategic paths. 

NFC via HCE is important for the future of cashless Asia. This region consists largely of dense urban ecosystems where footfalls are high, queues are long, security is highly desired and the need to keep moving is critical. Contactless modes allow ease of payments(tap, no signature below a limit), a strong sense of security (I don’t hand over my card) and speed of throughput (smaller queues at checkout).

Host Card Emulation enables contactless transactions across devices and carrier networks, allowing issuers to take control of the payment process and brand, and invest in growing their market. It enables banks to shift issuance towards real time, virtual and customized offerings without spending a fortune. Customers and banks are able to interact to control spend and credit exposure. Transforming transactions for the mass affluent by offering them the security of a physical tap via mobile with the scale and ease of a digital backend is the core appeal of HCE.  SimplyTapp brought HCE to the world in 2012 and has since worked with key stakeholders to make it universally available. For issuers in emerging and mature Asia, SimplyTapp offers a highly flexible, lean and cost-effective solution that can launch services in a few weeks. Beyond the solution, we have committed ourselves to helping issuers, networks and regulators build innovation frameworks to take digital transactions to the masses. At the 5^th Asian Smart Card Conference in Bangkok, we look forward to enriching conversations that help move mobile contactless transactions in this region to the next level. Talk to us. We are committed to Asia. 

-Kaustuv Ghosh runs the Asia business for SimplyTapp. He is based in Singapore and is available at kaustuv.ghosh@simplytapp.com. Reach out to Kaustuv or to info@simplytapp.com to discuss how SimplyTapp can help you launch mobile contactless payments rapidly and cost effectively.