Fintech R&R ☕️📱 x Under the Hood 🛠 - Tokenisation, The ApplePay payment process, and mobile wallet growth
A Tokenisation deep dive, step-by-step ApplePay process, benefits and frictions that come with tokenisation and global mobile wallets growth
Hey Fintechers and Fintech newbies 👋🏽
My trip to the US was great. But, West to East jet lag is still lingering. I’ve done the trip a few times, and it’s never been this bad, but no amount of jet lag would have stopped me from getting this week’s edition out, especially since it’s stateside-inspired.
Although the trip was officially a holiday, fintech is everywhere so it’s pretty difficult to shut completely off, and there was one thing I noticed that has been a bugbear of mine that looks like it is on the decline.
Others who have travelled transatlantic and used their card in the US of A probably know what I’m about to say.
Yes, the popularity of Magstripe vs Chip & PIN/Tap to pay.
It’s always interesting to see how long technologies and trends take to adopt, and there are always varying drivers for adoption in different geos and for varying demographics.
For example, I understand the basic principle behind the historical preference of iMessage over WhatsApp in the US (unlimited message data plans and the iPhone adoption, to name two), but in another sense, it is still baffling that it’s not as prevalent as in other countries.
In 2019, Tap to Pay transactions in the US accounted for around 1% of transactions, and now 1 in 10 Visa transactions at POS are ‘tapped’, so it’s clearly on the rise. MasterCard research also shows 51% of Americans now use some form of contactless payment.
There’s no doubt that contactless-enabled terminals, an increase in contactless-enabled cards being issued by institutes, and the pandemic are huge drivers in the US taking advantage of this previously untapped opportunity. Get it. Untapped 😉
Another driver is ApplePay/GooglePay and the broader growing trend of using cards added to a mobile wallet as a form of payment.
It’s the process of ‘tokenizing’ a credit/debit card and adding it to a mobile wallets for payment is what I’m diving Under the Hood of in this week’s edition.
So as well as interesting news, puns + movie references, this edition includes the following:
Glossary of key terms
Card Tokenization and the Apple Pay Process
Benefits of Tokenization
Costs of Tokenization (and Apple-specific costs)
Global growth and popular wallets
Call me the Term-inator
Before we dive straight in, there are a few terms to describe that will be easier to outline here and use for reference rather than peppering it throughout. Hence the term-inator because I’m busting some jargon.
Tokenization (or tokenisation as I should call it)
This is the process of transforming and abstracting sensitive card data, such as your clear card number and expiry that is connected to an account, into a non-sensitive data representation known as a token. E.g. 4659 4422 1872 3451 -> 1029 2830 1028 3402
My go-to analogy for this is spending at a casino, where on arrival, cash is converted into chips (or tokens) at the cashier to make for a more secure casino floor and allow for greater control over the movement of cash in and out of the system and identification of ‘bad actors’.
PAN (Primary Account Number): The 16-digit number on your card.
DAN (Device Account Number) aka Payment Token: Apple’s tokenized representation of the card that's unique to the device that requested the token.
A little DAN reference for all you Partridge fans Issuing Bank/Institute: This is the institute where you hold funds and who issued the payment card. Often, it is a traditional bank but also includes e-money institutes with a BIN, the relevant licence to store funds and issue cards.
POS Terminal: Merchant Terminal, where the payment is made by the customer using NFC either via card or a compatible mobile device.
E-commerce Payment portal: Equivalent to the physical POS terminal but at an online store where a customer traditionally enters their card details or uses a ‘card on file’.
Token Service Provider (TSP): This is the service that takes your card details, generates a tokenized representation to store in the mobile wallet and maintains a secured mapping of the PAN.
Token Requester: Organisation that requests the token from the TSP. e.g. Apple, Google, and Samsung in the case of their respective wallets.
Token Vault: The place where PANs and DANs (or other Tokens) are stored and mapped. They are typically connected to payment networks, e.g. Inside Visa Token Service.
Secure Element: Industry-standard certified chip on Apple hardware that securely stores the DAN on devices and generates secure transaction details.
Payment Processor: Entity that communicates with providers, such as the payment network, can orchestrate payment flow, initiate card issuing and token issuing, and provide transaction authorisation.
Tokenization and Apple Pay payment process
Now that some of the key terms are explained, let’s dive into the step by step process.
Step 1 - Initiate addition of compatible card to wallet
In order to use a card via Apple Pay, it must first be tokenized to create and store a DAN on the device.
The customer initiates this by entering the details of the card they want added or taking a picture of the card.
Step 2 - Send to Apple Pay Servers and Issuing Bank
These details are sent from the Apple Wallet app to the Apple Pay servers, which identifies the issuing bank from the card number using BIN Mapping (Bank Identification Number) and initiates a Payment Token Request from the Issuing Bank/Institute.
For the token provisioning to work, the institute has to be a partner and member of the Apple Pay network. The full list of ApplePay EMEA member institutes is here.
Step 3 - Send Tokenization request to the Token Service Provider
Then, the Issuing Institute requests a payment token from the Token Service Provider. For credit and debit cards, the TSP is typically the same as the payment network associated with the card. Visa’s is the Visa Token Service, MasterCard’s is the Mastercard Digital Enablement Service (MDES), and American Express has the American Express Token Service. The full list of approved TSPs can be found on the EMVCO website.
Step 4 - Token Service Provider generates and stores PAN
The TSP receives the PAN, generates a Payment Token and stores both values in their Token Vault. It sends the Payment Token and a Payment Token Key back to the Issuing Bank/Institute who’ll add a CVV-Key (required for authorisation).
Step 5 - Apple Pay Servers receive details
The issuing institute sends the Payment Token, Key and CVV-Key back to the Apple Pay Servers.
Step 6 - Store Token on Device
The server securely pushes the Token, Key and CVV-Key to the Secure Element on the customer’s device, which can only be accessed by the customer’s biometrics or passcode.
NOTE: You can see the last 4 digits of the DAN in the wallet by selecting the card in you wallet, tapping the elipises in the corner, selecting ‘Card Details’ and looking at the number in the ‘Apple Pay’ box.
Payment Process
The payment process using Apple Pay at a merchant is very similar to the standard card payment process, with some slight additions and a bit of deciphering and re-ciphering . Check out the standard process here.
Step 1 - Payment Initiation
The customer authenticates themselves on their device using biometrics or PIN to unlock their phone, access key tokenized details stored on the Secure Element in the device and the payment card in the wallet.
Step 2 - Device generates payment packet
Once the customer has authenticated themselves as they tap on the terminal, the device generates a ‘Dynamic Cryptogram’, a combination of details required for payment authorisation, including the Payment Token (DAN), Payment Token Key, and Transaction Amount. It also generates a Dynamic CVV using the key from the issuing institute and passes these details via NFC to the POS terminal.
Step 3 - Routing via Merchant Acquiring service
The merchants acquiring service connected with the terminal routes the packet of payment information to the relevant scheme.
Step 4 - Network receives the message
The payment network receives the message with the Payment Token Key, recognises that it is a tokenized transaction (based on BIN mapping tables and the first 4-6 digits of the DAN having its own BIN) and sends the request to the Token Service Provider.
Step 5 - TSP deciphers real PAN
TSP receives the packet of information, including the tokenized PAN and transaction details. It uses the Payment Token Key + Payment Token to verify the request and lookup the real PAN from the Token Vault, then sends the real PAN along with transaction details to the Payment Network.
Step 6 - Payment Network sends Auth request to Issuing Bank/Institute
Payment Network sends the PAN, Dynamic CVV and transaction details to the Issuing Bank for authorisation.
Step 7 - Authorisation Routing and Stand-in via PP
A payment processor will often sit between the Payment Network and sometimes provide stand-in authorisation, otherwise, they will route the request to the Issuing Institute for approval.
Step 8 - Issuing Bank verifies and authorises payment request
Issuing bank deciphers Dynamic CVV and performs standard authorisation checks (read more about those here). It authorises or rejects the payment and sends the response back up the stack.
Step 9 - Authorisation message received by POS
The message is pushed back up the stack to the Payment Processor, Network, Acquirer and POS, where the customer and merchant see an ‘authorised’ message so they know the transaction has gone through.
Step 10 - Presentment and Settlement
More detail about this is in the standard card payment process here, but in short, this is where the issuing bank will receive lists of authorised transactions, reconcile that with the authorisations it’s provided and send a settlement amount in bulk that reaches the merchant bank usually all within 48 hours.
As mentioned in the Merchant Payment Card process, this all occurs in a matter of seconds and in the time it takes to bring your device close to the terminal, which usually responds with a happy beep and green tick on your device.
Tokenization Types
Broadly, the process of tokenization is relatively standard– providing sensitive card information, securing this by creating a randomised number along with a key and storing the PAN in a Token Vault where it can only be unlocked with the Token and Token Key – but there are some slight differences between the way Apple, Google and Samsungs implementation at a later date.
For now, the Apple Pay registration and addition process covers the main points of card tokenization.
The process I’ve described with the customer initiating adding a card to the wallet is called ‘Manual Provisioning’. This is one of the four main types of token provisioning. The other three are:
In-App Provisioning
Provisioning a tokenized card from an app, usually a banking app, so the customer doesn’t have to go into their mobile wallet and initiate from there.
Web Provisioning
Provisioning a card from a secure webpage where the tokenization process is initiated and completed with minimal customer interaction.
Card-on file Provisioning
This is where merchants tokenize a card on file at e-commerce stores, reducing PAN storage in the merchant ecosystem. The customer doesn’t see a difference and interacts with the store as normal.
Benefits of Tokenization
There are reasons why card tokenization and mobile wallet usage (including Apple & Google Pay but more broadly) is on the rise globally as there are some clear benefits.
Security 🔐
This is the clearest benefit to all parties. Fraud has been an issue for banks, merchants and networks since cards were introduced. The dramatisation of Frank Abagnale’s life in Catch Me if You Can demonstrates the early fraud techniques.
Since the introduction of the card number, or PAN as I’ve used in the walkthrough, Card Not Present fraud has been a thorn in the side of merchants, banks and credit card companies. This is where fraudsters steal your PAN from a merchant or by other means and use it to transact online or over the phone where the physical card isn’t needed.
As tokenization abstracts the PAN into a token, requires a token key and cyphers all-important transaction data at the point of payment, it makes it extremely difficult for hackers to get any usable data unless they have access to the device & authentication factors making tokenized payment cards a lot less susceptible to CNP fraud.
Speed of card usage 🏎
Security is the overwhelming benefit to all parties of tokenization, but there are other benefits to the customer.
One is the speed at which a tokenized card can be given to a customer to use at physical stores. Nowadays, account onboarding, KYC/KYB, and account creation with a card number that can be displayed in-app are done in minutes rather than days. However, due to the time it takes to create a card and deliver it to customers, they weren’t able to use their card immediately at a physical merchant until the advent of tokenization.
Tokenizing a card immediately after the creation of a virtual card means customers can transact at physical merchants immediately, and for the issuing institute, it could mean lower costs and greater revenue with the ability to earn interchange on transactions immediately and potentially remove the need for a costly physical card altogether with some customers themselves opting to forego the receipt of physical cards and preferring a tokenized card for payment instead.
Customer Convenience😃
This is a benefit purely for the customer. You can’t underplay the value of convenience when it comes to payments. Folks are accustomed to using mobile wallets, and providing a tokenized card has become a hygiene feature–a feature that customers expect and is the standard for a particular type of product– especially digital banking platforms.
Customers who already use tokenized cards in other offerings will expect the same in new ones because they are used to the habit of tapping to pay using a device and will continue to want that convenience in a new product they use.
The other convenient benefit of tokenized is that they do not strictly adhere to the contactless limits imposed by cards (max £100 per transaction here in the UK), and retailers can choose to increase those limits for transactions made via Apple/Google/Samsung pay meaning customers may not have to carry around cards at all if that’s what they’d like.
Costs of Tokenization (and Apple Pay)
It’s not all upside. You can’t do anything without giving up something.
Or, as I’ve referenced in a previous edition, “Newton’s third law, you gotta leave something behind” - Cooper, Interstellar.
Initial Setup 🏗
There is an additional setup required for tokenization. As listed in the step-by-step, Apple institutes must become members of the Apple network to use its servers and enable the tokenization of cards in its wallet. They also have to connect with a Token Service Provider, although Visa, Mastercard, Amex and the other networks make this fairly low friction.
NB: If using a payment processor like Marqeta or Thredd, some of this effort might be mitigated in exchange for a small cost
Nevertheless, it’s additional work, setup cost and/or time which should be weighed against the benefits.
Cost vs Risk 💰
With Apple, the issuing banks/institutes are charged 0.15% by Apple for each ApplePay transaction. The normal fees the FIs charge per transaction vary between 0.20% and 1.90% and also vary between payment networks and card types. So, 0.15% taken off that interchange fee might seem like a lot, and to some, it is, but this has to be balanced against the risk of fraud, which, looking at the Card Not Present fraud stats, it’s certainly making some progress.
NB: One way of mitigating the cost for neobanks and new institutes is to put the addition of ApplePay further down the line of product development, if possible until a certain mass of customers have been obtained and the economics make sense (the cost vs customer benefit balancing act).
Won’t get fooled again🕵🏼♀️
It’s important to note that while it’s more secure than a card alone, it’s not a completely fraud-proof system. Social engineering and mobile phone theft are still factors, with sophisticated fraudsters becoming wise to the process of using cards in a tokenized wallet to extract money from victims easily. Some steal your PAN and add it to a stolen device, which they can then use at stores above the normal £100 limit until the card is blocked.
This means issuing banks and institutes have to implement more robust customer journeys and 2FA during the addition of cards to wallets. This is where an experienced processor or partner with APIs and tried & tested tokenized card processes can help.
Going Global 🌍
It’s important to note that while I’ve included ApplePay as the core journey and referenced Google and Samsung Pay, these aren’t the only mobile wallets around and mobile wallets that can store tokenized cards aren’t a pure Western phenomenon. Mobile Wallet adoption is growing faster in Asia and the Middle East than anywhere else.
The most popular wallets in the seven fastest-growing mobile wallet markets are:
Thailand:
TrueMoney Wallet, SCB EASY, PromptPay, Rabbit LINE Pay, GrabPay
India:
Paytm, Google Pay (Tez), PhonePe, Amazon Pay, Mobikwik
Hong Kong:
Octopus, AlipayHK, WeChat Pay HK, TNG Wallet, Apple Pay
Philippines:
GCash, PayMaya, Coins.ph, GrabPay, Palawan Express Pera Padala
Malaysia:
GrabPay, Touch’ n Go eWallet, Boost, Maybank QRPay, BigPay
China:
Alipay, WeChat Pay, UnionPay, Baidu Wallet, JD Pay
Indonesia:
OVO, GoPay, LinkAja, Dana, Jenius
I don’t have a groundbreaking point to make with the global growth image. Just that it’s not only Apple, Google and Samsung driving mobile wallet adoption across the globe. In fact providers who understand their respective markets and can provide solutions that suit the needs of their customers can often gain higher adoption than traditional tech giants with decades of experience.
But I’ll likely cover regional mobile wallets and their respective USP, customer-centric features and strategy in the future.
The broader outcome of this edition was to provide more detail on what it takes to incorporate a tokenized card into a proposition and highlight the negatives as well as the positives. Ideally, someone building a fintech or adding a financial services element to their organisation can read this, get a better understanding of how tokenization works and use it to figure out if and when to implement it.
Because the long-term prediction is that mobile wallets will become the norm and likely sit alongside physical cards for a period, understanding how the process works is vital to fintech entrepreneurs and product folks alike, as tokenization won’t necessarily be cost-effective, beneficial and relevant for everyone.
If you do know any entrepreneurs and/or product people thinking about adding Apple Pay or other tokenization as part of their fintech proposition, then feel free to share this with them using the button below but regardless, thank you for reading and see you next time 👋🏽
P.S. I’m curious if anyone has come across any jargon busters or glossaries of terms on websites called “term-inators” because I think that might be my best original pun!!
Favourite bits of news
Currensea launches BuildMyCreditScore - The brainchild of the creators of the travel spending debit card Currensea launched credit building debit card BuildMyCreditScore (the most SEO-positive fintech name ever!). The debit card connects to existing bank accounts using Open Banking, encourages low-value spending using the provided card and collects payment for spending via direct debit, allowing the spending to be reported to credit reference agencies. This is a great example of a purposeful fintech bringing value to those looking to build a credit presence, whether they are young or new to the country, without the need for a credit-building credit card like Aqua.
A fun name for an Aqua vs Currensea face-off could be The Battle for Poseidon. 😉
NatWest launches transaction categorisation service - The bank launched the API enable transaction categorisation service called Enriched Transactions. It’ll give external businesses the ability to connect to this service and offer things like personal financial insights, advice on carbon footprint and even perform affordability checks for products like loans or mortgages. I need to dive into the API and see the totality of data available, but it could prove to be a cost-effective way for services to be built directly for NatWest customers at a lower cost basis than using TPP like Truelayer or Tink.
@jas - would you know if it is a mandate in USA to tokenize the card or is it still optional.
crystal as always, thanks Maestro. hoping for UTH episode on asset tokenization as well lol, which, to my naive brain, feels kinda like a fancier modern name for securitization tweaked somehow...