Under the Hood🛠 - How GooglePay works
A deep dive into how Google Pay works, the value of Tokens in Financial Services, and why 'Tokenized everything' will be the new normal in FS
How does GooglePay actually work?
Is ApplePay really more secure than Google’s equivalent?
How is a Casino relevant to the Tokenisation process?
What’s the difference between a DAN and a DPAN?
These questions and more will be answered in this week's edition.
Hey Fintechers and Fintech newbies 👋🏽
After the previous ranty edition on Zing, where I set the record straight on some of the myths flying around about the HSBC-backed project and gave some seedlings of hope for bank-led fintech projects, I'm switching it up a bit and writing another Under the Hood edition as a follow up to last years "How ApplePay and Card Tokenization" works.
It's partly inspired by the popularity of a previous edition of "How a Card Payment Works", which I reposted on Substack recently, but also by the "tokenization first" strategy many card programmes are taking, opting to provide a tokenized card that can be added to a wallet by default, and allowing customers to receive physical cards on request and sometimes at an additional cost.
As I see it, the main driver of this trend is to balance the economics of sometimes costly physical cards, a point raised in the edition about Zing and one of the reasons their program economics didn't stack up.
The benefits don't stop there, though.
From a product perspective, the ability to use a card product immediately after a successful onboarding journey rather than waiting for a physical card to arrive can:
👉🏽 Speed up time to account funding
👉🏽 Increase usage & spend
👉🏽 Increase time to value for the customers.
Then, there is the obvious impact of tokenization on fraud.
Tokenized cards mean less Card-on-file fraud, as PANs are never shared with merchants. You can't steal and sell PANs on the black market if they're never shared.
With the inevitable rise of wallet payments in the US and the opening up of NFC rules by Apple in a whole range of countries, tokenized cards will be the default for many fintechs in the future.
Tokenization isn't just about cards though.
Last year, Visa announced a wave of new products to their offering, including Visa data tokens, where consumers, whose financial institution participates in the program, consent to sharing their data with merchants who can then provide personalised offers facilitating real-time recommendations.
There are many more use cases for tokenization, especially when you abstract the fundamentals of tokenization and apply them to problem spaces across the financial landscape.
But before I go deeper into other areas of tokenization, I wanted to set this foundation block in place and give a complete picture of how the two most popular methods work.
Which is why, this week, I'm diving Under the Hood of…How Card Tokenization and GooglePay works.
As well as interesting news, puns + movie references, this edition includes the following:
Glossary of key terms
Card Tokenization and the GooglePay Process
Step-by-step walkthrough of the tokenisation and payment
ApplePay v GooglePay: The key differences
Benefits of Tokenization
Wallets and Tokenisation as the new normal
Fintech Spotlight🔦: Lenkie - Grow Now, Pay Later Provider
Interesting News: Monument readies itself for 2027 IPO
Now, let's get into it 💪🏽
Call me the Term-inator 🦾
This section has a lot of overlap with the ApplePay edition as much of the terminology is the same and it's important to clarify some of the acronyms that'll be referenced. I've also kept the header the same because I'm quite proud of the pun "term-inator" in reference to busting some jargon.
Tokenization: This is the process of transforming and abstracting sensitive card data, such as your clear card number and expiry that isconnected to an account, into a non-sensitive data representation known as a token. E.g. 4659 4422 1872 3451 -> 1029 2830 1028 3402
💡 NOTE: More on Tokenization with a handy and fun analogy later…
PAN (Primary Account Number): The 16-digit number on your card.
DPAN (Device Primary Account Number): Google's tokenized representation of the payment card.
Cryptogram: A unique, transaction-specific code generated by Google Pay (or the card issuer) to authenticate each payment. It ensures that a stolen token cannot be reused for another transaction.
Dynamic Card Verification Value (DCVV): A dynamically generated security code used during transactions instead of the static CVV on a physical card. It is generated for each transaction, ensuring additional security.
DAN (Device Account Number): Apple's tokenized representation of the card that's unique to the device that requested the token.
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.
Host Card Emulator: Host Card Emulation (HCE) is a software-based technology that allows a mobile device to simulate a physical card, like a credit card, using the phone's operating system.
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 the Google Pay payment process 💳
Now that some of the key terms are explained, let’s dive into the step by step process.
Tokenization Request
Step 1 - Initiate addition of compatible card to wallet
In order to use a card via Google Pay, it must first be tokenized by creating and adding a DPAN in the Google Wallet.
The customer initiates this by entering the details of the card they want added, by taking a picture of the card, or by simply tapping the card which captures data using NFC.
Step 2 - Send to Google Pay Servers and Issuing Bank
These details are sent from the Google Wallet app to the Google 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.
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 DPAN 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 agrees a DCVV specification for the token with the issuing bank.
Step 5 - GooglePay Servers receive details
The issuing institute sends the Payment Token, DCVV-Spec back to the Google Pay Servers.
Step 6 - Store Token on Device
The server securely pushes the Token to the Host Card Emulator in the Google Wallet which can only be accessed by the customer’s biometrics or passcode.
Payment Process
The payment process using Google Pay at a merchant is very similar to the standard card payment process, and pretty comparable to the Apple Pay process.
Step 1 - Payment Initiation
The customer authenticates themselves on their device using biometrics or PIN to unlock their phone, access key tokenized details stored in the Host Card Emulator in the Google 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 (DPAN), 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 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, and uses the Payment Token Key and 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 verifies 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 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.
Similarly to a standard card payment 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.
Differences between Apple Pay v Google Pay 🤔
If you've recently read the Apple Pay Tokenization write-up, you might think, "There don't seem to be many differences", but there is some nuance between the two methods.
For Google Pay the token is stored in the Host Card Emulator, not on the Secure Element
Host Card Emulation (HCE) is a software-based technology that allows a mobile device to simulate a physical card, like a credit card using the phone's operating system, while a Secure Element (SE) is a dedicated hardware chip embedded within the device that provides a more secure, tamper-resistant environment for storing sensitive data like payment information, essentially offering a higher level of security compared to HCE; with HCE, the payment data is managed primarily through the phone's software, while with an SE, the data is protected within a dedicated hardware component.
SE is more secure because it's built into the hardware and more tamper-resistant, but HCE is more flexible.
Storage of DPAN and Card info is stored on Google Pay servers
Apple doesn't store any card information on Apple Pay Servers, whereas Google stores the DPAN and other card info on its servers.
TSP sends authorisation and settlement notifications to Google Pay servers
When authorisations and notifications come back from the payment processor via the network, they are also stored on Google servers to manage notifications in the Google Wallet. Apple doesn't store any payment information (tokenized or otherwise) on its servers.
Google Wallet and Pay work on iOS, whereas Apple Pay doesn't work on Android
Because the implementation of HCE is software that emulates the Secure Element, it means it's hardware agnostic. That's why GooglePay works on Apple devices, as the HCE can be deployed to store tokens, whereas ApplePay uses the Secure Element (hardware in Apple devices), which is compatible with Android devices.
The Value of the Token 🪙
In the ApplePay edition I outlined some of the benefits of card tokenization, and I also touched on some of these at the start:
Security
Speed of usage
Customer Convenience
I also covered the different types of token provisioning, the costs of tokenization, and a range of regional digital wallets across the globe in addition to Apple and Google's.
So instead of treading on the same ground before closing, I want to talk more broadly about tokenization.
A simple analogy I like to use to set the scene of the value of tokenization broadly is the classic casino example.
In a casino, rather than carrying cash (Sensitive Data) around the gaming floor, you exchange it for chips (Tokens) at the secure cashier's cage (Token Service Provider). These chips have value within the casino but are worthless elsewhere.
That way, cash is kept secure and centralised behind a doubly secure cage, casino staff can be better focused on spotting chips that aren't part of the casino, and customers can carry chips around knowing they are in a secured ecosystem.
Similarly, in financial services, tokens represent sensitive information (such as a card number) without exposing the original data to external threats such as fraud, theft and misuse.
Digital tokenization goes a level beyond the standard casino analogy.
In digital tokenization (which in fintech we just call tokenization) it's as if every single chip you exchange for cash at the cashier is engraved with a personalised signature, so even if someone manages to steal your chips, they'll be unable to use them as they won't be able to provide the right credentials or signature to prove those chips are theirs.
So heisted chips or tokenized sensitive card data is worthless to heisters, which is great for consumers.
Tokenization isn't just a highly effective way of combating card fraud.
Visa's Data Token, for example, will help merchants access anonymised and secured data to better help consumers.
Card Tokenization will soon become the default.
The physical wallet will soon become a memory, the digital wallet will rule, and tokenization, across a range of areas will be the central reason why.
I'll outline some of these other ‘areas’ including Visa's 'Push' into Tokenization in a future edition now that I've two major most popular card tokenziation methods, so watch out for that.
That's it for this week.
I hope you enjoyed another in this Under the Hood series, and make sure you drop a comment and a like if you enjoyed it so future editions don't end up in your spam folder. 👋🏽
J.
Fintech Spotlight 🔦: Lenkie
Lenkie is a UK fintech company specialising in providing flexible credit facilities to SMEs. Their primary offering, "Grow Now, Pay Later," enables businesses to pay supplier invoices instantly using their lending facility while spreading repayments over manageable monthly instalments which ultimately stabilises cash flow and enables business to grow.
Product Details:
Repayment Terms: Businesses can select repayment periods ranging from 1 to 12 months, allowing them to tailor terms to their specific cash flow needs.
Credit Limits: Lenkie offers dynamic credit limits of up to £1 million, which can adjust in line with a company's growth and ongoing usage.
Application Process: The platform boasts a swift application process, with approvals possible within 24 hours, facilitating quick access to funds.
Digital Management: The platform allows customers to manage their applications and repayments Digital through their management dashboard
Recent Funding:
They recently secured £49 million in Series A funding, comprising £4 million in equity and a £45 million debt facility. This investment aims to enhance their data-driven underwriting models, expand partnerships, and explore new markets.
If you’re looking for a future embedded lending partner, a BNPL solution for SMEs or an addition to a SME focussed marketplace, reach out the to team or drop me a note and I can connect you.
Side Note: To prove how small the world of fintech is, I actually worked with one of the founders, Sanjeev, when he was a trader at Citibank and I was in the technology team for his desk back in 2012.
He was very switched on about Fin and Tech then, and certainly even more driven along with his co-founder, about the power of fintech solutions to add value for underserved SMEs.
Interesting News🗞
A Monumentous Achievement - Monument Bank, the UK-based challenger bank targeting mass-affluent clients that has gone under many people’s radars, is reportedly planning to raise £200 million in a Series C funding round. Approximately £30 million has already been secured. This round would build upon the £135 million previously raised by the bank, including a £40 million Series B. The new funding is expected to value the company at around £1 billion. Monument Bank aims to list on Nasdaq by the end of 2027, with a possible secondary listing on a major Middle Eastern or Indian exchange the following year.
DISCLAIMER: This write up and related diagram has been painstakingly put together by myself, Jas Shah. If you wish to use this content for a commercial project or intend to put any of this content behind a paywall, you must request permission first.