How do Apple Pay and Google Pay handle sensitive credit card information? Which one is better?

Apple Pay started in 2013. Let’s take a look. We’ll start by stating that both implementations are secure. But the technical details are a bit different. 

 

It was a novel idea. Then, it perfected the concept called tokenization, where only a payment token representing sensitive credit card information is needed to complete a purchase. It requires close cooperation from payment networks, like Visa, and large issuing banks that JPMC to build a new system to support the wide adoption of payment tokens.

 

 Google Pay has been around since 2018. Before that, it was known as Android Pay. And before that Google Wallet, the branding is confusing and it appears that now Google Pay is Google Wallet again, in some countries, we will refer to the current version that uses payment tokenization as Google Pay, let’s take a look at how these systems work.

 

 Both platforms start by collecting sensitive credit card information on the device. It is worth noting that both platforms claim that they do not store the pan or primary account number on the device itself. The pan is then sent to the respective servers over HTTPS.

 

 At the Apple server, the credit card info is not stored anywhere. It is used to identify the payment network, and the issuing bank for the credit card to simplify will refer to the payment network like Visa and the bank that issued the credit card as just the bank from here on out. The credit card info is then sent from the Apple server to the bank securely over the network. 

 

The bank validates the number and returns a token called Dan or a device account number. This number is uniquely generated for us by the device. The generation of the token and the mapping of the token to the pan are usually offloaded to a tsp or a token service provider.

 

 The TSP is where the most sensitive information lives. The token is then returned to the Apple server, and Apple server four was the token to the iPhone that was stored securely in a special chip called a secure element. Logically, the Apple server is just a pass-through. 

 

It is as if the iPhones directly sent the credit card info to the bank in exchange for the token. For Google Pay, this process is a little bit different. by Apple, the pan is sent securely by the device to the Google server. The Google server uses the number to identify the bank. 

 

The number is then sent to the bank securely over the network. The bank validates the pan and forwards it to the TSP for payment token. The token is sometimes called the pan or device pan to the token and is then sent back to the Google server where it is forwarded to the device for safe storage. 

 

Now there are two points worth mentioning here that are different than Apple. 

 

1. The token is not stored in a secure element like Apple devices. It is stored in the wallet app itself 

 

2. Apple boasted of never storing the payment tokens on its servers. 

 

Google makes no such claim and in fact, its Terms of Service states that the payment information is stored on servers. We explained so far, how each implementation turns the credit card info into some form of on-device payment token. Let’s take a look at how these tokens are used to make a purchase.

 

 For the iPhone, once we click pay, the token is retrieved from the secure element and sent to the merchant’s point of sale terminal over NFC or near-field communication. This is really secure because the token is sent directly from the secure element to the NFC controller on the device, where it is then transmitted to the point of sale terminal. From the point of sale terminal, the token is sent to the Merchants Bank.

 

 The Merchants Bank identifies the payment network from the token and securely routes it to the payment network. The payment network validates the token and then makes a request to the TSP to D tokenize. it back to the original pan. 

 

The original number is sent securely from the TSP to the bank where the payment is authorized. For Google Pay, the flow is similar once the payment token reaches the point of sale terminal. Now how it gets from the device to the point of sale terminal is quite different.

 

 Android devices do not store the payment token in the secure element. You instead use something called host card emulation, or HCE. With HCE, the payment token is stored in the wallet app, or retrieved at transaction time by the Wallet app securely from the cloud. 

 

The NFC controller and the Wallet app work together to transmit the payment token over NFC to the point of sale terminal.

 

At that point, the rest of the transaction is the same as apples to conclude. Both Apple Pay and Google Pay take advantage of payment tokenization technology, Apple Pay perfected the technology and made it user-friendly and secure. 

 

Google pays implementation is similar. The main difference is how the payment token is stored, handled, and transmitted on the device, and how the payment token could potentially be stored on the Google servers.