One of the many scenarios us mobile payment product people envision when we think of how someone will use our products is how our products will be used when the consumer’s device is “off-line”. When the consumer’s device cannot connect to their carrier’s data plan, how does our application and product react? Once you learn what your product does in this scenario, if the outcome is not desirable, you want to think about how often this happens, and then if this is a “blocker” or just a feature that can be added later in the release. When it comes to tokenization of payment data, this scenario is working its way through pilots and production right now, with varying degrees of success. We have taken a look at different host token technologies to see just how they would work in the off-line scenario, and the results are interesting.
There are three main technologies out there, which we will describe as:
- On-device-on-Secure Element
- Cloud-based, and
- On-device-in-device memory
Each type of technology has its proponents, and various incarnations in-market today. Examples of on-device-on-Secure Element are Apple Pay, Samsung Pay and Google Wallet (nee Softcard). These products require that the token representing the underlying data be hosted on a chip on the device called a Secure Element. Examples of cloud-based approaches are PayPal (nee Paydiant)/CurrentC, Carta Worldwide, and Sequent. These solutions require that the token is hosted in the cloud and that at the time of transaction, the mobile device calls the cloud to provision the token for use, or verify that the token generated by the POS is valid. The popular term (but a misnomer) for this implementation is HCE, or Host Card Emulation. Finally, an Example of on-device-in-device memory is the RCD host token by Cortex MCP.
Now let’s get back to the off-line use case. The on-device-on-secure element model works well in this scenario, in that all the token data is stored on the device in the Secure Element, so there is no need to use the carrier’s data connection to complete the transaction. You do, however, need a cloud connection to provision the tokens to the SE in the first place, but not at the time of the transaction. Secure elements provide a secure on-device storage method, however there are other costs associated with the SE, which is the subject of a different blog post. Let’s give the SE a passing grade (albeit at the BOM cost of the SE) for the off-line use case described above.
For all cloud-based approaches, the off-line use case is a killer. They require that the token is stored in the cloud and that the user pulls it down to their device (or validates a different token) when they want to run a transaction. If there is no data connection available, how can this approach work? As smart product people, they have come up with some ingenious hacks to the problem. In essence, the purveyors of this technology (see above) use the third example on-device-in-device memory. They load specific “off-line” tokens to the device and store them in device memory to be used only if the device’s radio is “off”. This can cause a problem, since if a token is on the device while it’s at rest, the token is available to be scraped by malware and potentially used fraudulently. The product folks anticipated this and have put limits on the tokens that are stored in device memory for this off-line use case. They have $ limits, time limits and # of use limits. What it also limits is the usability of these tokens for transactions for the consumer and that is not a viable long-term solution. While it may be considered “good enough” in some use cases (affluent Americans buying small market goods with reasonable data connectivity pre- and post- transaction) it is still a hack that is not allowing the token to be used “as designed.” It is also an issue for non-payment types of tokenization where there isn’t a concept of “limited use” tokens. The transaction doesn’t have a $ value associated with it, it’s either a valid token or not, say for access to financial data, or identification, or medical records. Once you have it, you’re in. These limits, make cloud-based approaches to tokenization, well, limited, and thus cannot be given a pass here.
We at Cortex MCP believe there is a better way to attack, not only this off-line scenario, but also all transactions without needing the complexity (and cost) of a Secure Element or a cloud connection. Instead of hosting the token on-device-in-device memory in a complete and usable/stealable form, we suggest leveraging our patented RCD host token method to securely store the tokens on the device is such a way that it is not usable and worthless to hackers while at rest in the device – via a structural fragmented token-based approach. Our token is only stored on-device-in-device memory in an incomplete form. For example, if a client was using a PAN-based token, a partial composition of the PAN will be stored on the device. The remaining characters are inserted into the composite token only when a user-defined action is completed on the device, say, inputting a PIN, or getting validated by using the device’s biometric scanner. This action, which verifies the user and is performed at the time of the transaction, completes the token and makes it usable. The RCD host token doesn’t have to be 16 digits. It can be any length. It can be alphanumeric. It depends on the parameters of the system being implemented. Storing the token on the device in a fragmented form eliminates the risk of the token being used inappropriately for payments while at rest. It creates a true integrated multi-factor payment and authentication methodology, while reducing the inherent friction from layering additional factors of authentication on a static, exposed token.
It also allows the token service provider to offer their clients in the non-payment space a solution that has no grey areas, only a yes-no answer. By implementing this consumer verification step (PIN or biometric) for ALL transactions, on-line or off-line, you maintain a smooth user flow regardless of the connectivity of the device.
When you think about what token technology is good for your mobile application, consider the scenarios, and see if your provider covers all the bases, or if there are “blockers” they aren’t telling you about. For more about comparing token technologies, please see this.