Shift4 answers some questions and highlights some differences between true tokenization, PCI-redefined tokenization, and how they both apply to the Apple Pay technology.
Brief history: The concept of tokenization existed long before the term, even long before computers. Tokenization is simply referring to data via an unrelated reference number – like a case number might refer to a criminal investigation, an invoice number might refer to one or more purchased items, or a record ID might refer to any arbitrary set of data.
Tokenization can be applied to secure any data. All the answers below refer to tokenization, as it applies to securing payment cardholder data (CHD) and/or Apple Pay.
1. What is the primary purpose of tokenization?
As defined by Shift4, to secure data, specifically CHD, for merchants. In the Apple Pay model, the tokenization secures CHD stored on the device and hides the CHD from the merchants it interacts with for payment processing.
1a. Whose interests does it serve?
The whole goal of our releasing tokenization into the public domain back in 2005 was to simplify and secure payment processing for merchants. We realized that for tokenization to succeed, it would need broad-based support. Locking this technology to a single company (us in this case) would have hindered its acceptance.
Now, one thing to be aware of (and I assume the reason for this question) is that some vendors do lock you into their services using tokenization, among other tightly coupled service offerings. We don’t do that. Within our contract, merchants are free to leave at any time, and we will provide an encrypted file containing the tokens and the associated CHD. To the best of my knowledge, we are the only provider offering this.
More on Apple Pay’s interest below in question #4.
2. Does tokenization eliminate the need for the CNP category of transactions?
No. Tokenization secures CHD and makes the data useless to steal. Tokenization in and of itself does not address card authenticity. CNP, for the most part, are anonymous transactions that are hand-keyed by an untrusted person, and these factors will always have a higher risk than their card-present counterpart.
3. Exactly what benefits does it provide to the various parties involved? Merchants, processors, issuers, payment networks, acquirers, etc.? Does the value equation change as a result?
Merchants – it secures CHD by taking the princess out of the castle (removing the vulnerable data from the merchant environment). True tokenization makes any data stolen useless to hackers.
Processors, Gateways, and Acquirers – a selling point and maybe a slight reduction in liability risk from breach lawsuits (we offer secure solutions; it’s not our fault the merchant chose not to use them).
Issuers and Payment Networks – less risk from fraud related to stolen CHD; less risk of black eyes from media exposure.
4. Who are the biggest beneficiaries of the currently proposed tokenization regime?
The biggest benefactor is Apple – they will sell more devices. Apple has a tendency to patent almost anything and everything, so look for some aggressive patent infringement lawsuits on Apple’s competitors that incorporate similar functionality.
5. Who are the biggest losers as a result of the proposed tokenization approach?
I see three:
6. Does tokenization foster or impede innovation in payments? Does it perpetuate the status quo?
True tokenization, I believe, fosters innovation. The less effort that is focused on securing CHD, the more effort that can be focused in other areas. Depending on how Apple Pay defines the tokens (per PCI’s liberal expansion of the definition or more true to the original definition) will determine if the tokens are truly secure. Encryption or hashing solutions that try to wear a tokenization name badge – or as we like to call them, Tokenization In Name Only (TINO) – is not nearly as secure as true tokenization.
7. Exactly who can become a TSP (Token Service Provider) and when? Are the protocols set up for entities other than the three major networks to provide this service?
We’re still investigating.
8. Is the Apple Pay implementation of tokenization compliant with any industry-standard, or is it totally proprietary?
Here is a big grey area. Tokenization, as Shift4 defines it, replaces the CHD for a single transaction or series of related transactions for a merchant. Tokenization, as defined by both PCI and EMVCo, for the most part, addresses the same – a single transaction or series of related transactions for a merchant. With Apple Pay, the tokenization is being applied to the CHD that would otherwise be stored on the device and transmitted to the merchant. The existing standard addresses the merchant scope that Apple Pay applies to the cardholder. It’s an entirely different scope that some analysts believe is related to the new card-brand-based tokenization methodology from Visa and Mastercard, but until I’ve seen Visa’s standard firsthand, I cannot verify that. Ultimately, I believe how Apple patented the process and/or how freely they allow others to use the process will dictate whether this becomes a standard or remains proprietary. (As I mentioned before, they are notorious for aggressively defending their patented technologies.)
8a. Does that approach help or hurt the cause?
There are too many variables at play here to answer this question. Are we talking about the cause of data security, or merchant security, or tokenization? In any case, I think the answer is to be determined as we see how adoption rates play out and whether the technology expands beyond Apple products.
9. Does tokenization (as proposed and implemented) take the industry a step forward or backward?
It depends on the proposal you are referring to. True tokenization – the original definition – is a simple method to secure CHD, and I think this was a step forward. PCI tokenization, while it does not preclude true tokenization solutions from existing, liberally expanded what can be called a token and added a lot of to be determined by your acquirer or QSA to plug the holes they added. While they had the opportunity to take a step forward, I think they dropped the ball and didn’t advance security. Apple Pay tokenization, while there are quite a few unknowns, holds promise as a step forward. How big of a step is obviously dependent on the details.
10. Wait, did someone say this is an innovation?
Referring specifically to Apple Pay, while we’re still gathering information and the verdict is still out, we have not yet seen anything that precludes the innovation benefit I previously mentioned. For the application writers, the less effort that is focused on securing CHD, the more effort that can be focused in other areas.
To learn about Prove’s identity solutions and how to accelerate revenue while mitigating fraud, schedule a demo today.
Join over 1,000 businesses that rely on Prove across multiple industries, including banking, FinTech, healthcare, insurance, and e-commerce. Contact us today.
Trusted by 1,000+ leading companies to reduce fraud and improve consumer experiences. Contact us today to learn how you can frictionlessly secure your digital consumer journey — from onboarding to ongoing transactions.
Tap the button below to read our latest white-paper on the subject as industry leaders.
Contact us to learn how leading companies are using Prove Pre-Fill to modernize the account creation process by shaving off clicks and keystrokes that kill conversion.
Get in touch to find out how we can help you identify your customers at every stage of their journey and offer them seamless and secure experiences.
Let our expert team guide you through our identity verification and authentication solutions. Select a date and time that works for you.
Find out how we can help you deliver seamless and secure customer experiences that comply with PSD2/SCA. Select a date and time that works for you.
Download Aite-Novarica Group’s full report about Prove Pre-Fill, including a product overview, customer results, and how the product works.
Download the guide now to learn how you can improve security, cut down on fraud, and create the best possible customer experience.