In part 1 of our 4 part series on mobile payments we touched upon the interdependencies among the various stakeholders participating in a mobile payments solution and the importance of integration – even if there's no central integrator. To appreciate why integration is such an important aspect of mobile payment solutions, first let's understand the following technical roles played in transacting mobile payments:
- Credential Issuer – Traditionally, this is the payment card issuer (such as the bank or retailer), but for the purpose of mobile payments this is more specifically the organization that issues personalized customer data used to identify the customer and initiate payments (such as a credit card number or pre-paid loyalty card number), which in many mobile payment models must be loaded onto the smartphone.
- Secure Element Manager (SEM) – This is the party that "manages" access to the credential. In an NFC-enabled smartphone, the SEM ensures that access to the credential, which sits in the "secure element" (in some models, this is a microSD card or SIM/UICC card), is only granted to trusted third parties via secure protocols.
- Trusted Service Manager (TSM) – This is the party that communicates with the secure element manager to "provision" (i.e., load) credentials onto the secure element on behalf of the credential issuer. It's somewhat analogous to the process that is required to load payment credentials onto a payment card with a chip, except for mobile payments this typically occurs wirelessly.
- Mobile Payment App Developer – This is the developer of applications on a smartphone that allow the user to transact mobile payments. These applications take different forms, depending on the manner in which the credential issuer allows the user to transact payments. It must be user-friendly, brand-savvy and integrated with the operating system, hardware and other applications of the smartphone.
These are only some of the roles played in a mobile payment solution and these roles can be played by a variety of organizations and multiple roles can be played by one organization. For example: a credential issuer can also be the app developer; the SEM can also be the TSM; a mobile network operator or smartphone manufacturer can be an SEM and an app developer. There are also the payment networks (e.g., MasterCard, Visa, Amex), technology powerhouses (e.g., Apple and Google) and regulators, to name a few, all of which are working to define their roles.
Once you understand the various roles played in a mobile payment solution, the next step is to understand the mobile payment architecture flow and depending on how the stakeholders are arranged, there are many different ways this can be accomplished. Consider the following as an example:
The credential issuer provides a credential to the TSM, which is granted access to the secure element by the SEM and loads the credential onto the phone (or in some cases, a remote location). The user opens the mobile payment app and initiates a payment with the click of a button, and the credential is broadcasted to the point of sale terminal.
Regardless of the selected arrangement, a successful solution is ultimately one that is integrated seemlessly, where the user understandably views mobile payments as a simple function unaware of the precise functions that had to be executed in order to make a purchase.
Therein lies the challenge: how to accomplish a seamless mobile payments solution when the stakeholders have different functions, goals and risk tolerances and no one party bears responsibility for the solution as a whole? For example: a credential issuer which owns the relationship with the customer or is more customer facing will be more concerned with seamless customer experience while the TSM or SEM may be more concerned with delivery or performance of its respective tasks and the risks associated with the interdependencies between the two (and other stakeholders).
Consider the following risks associated with this rather complex, interdependent, multi stakeholder technology solution: poor customer experience, delays in solution implementation, costly change orders, fraud and data security issues, uncertainty around service levels and performance metrics and minimal or no measurement of the success of the end to end solution.
In part 3, we will provide helpful tips in managing these risks and this rather complex and interdependent relationship prior to entering into a contractual arrangement.
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.
We operate a free-to-view policy, asking only that you register in order to read all of our content. Please login or register to view the rest of this article.