I’ve used the Google Pay API in several Android apps, and something that wasn’t clear to me from the start was the meaning of the available options for card authentication.

In this article, I’ll explain what each option means and what you need to do in each case.

There are two available options: PAN_ONLY and CRYPTOGRAM_3DS.

PAN_ONLY Link to heading

With PAN_ONLY, Google Pay displays the cards stored in the user’s Google account (cards on file) that are not tokenized (see the CRYPTOGRAM_3DS section for what this means).

During the transaction, if your payment provider requires 3DS authentication, you’ll need to implement the 3DS flow yourself.

Depending on the transaction’s risk profile, the 3DS flow may complete silently (frictionless) or require user verification through a browser (challenge flow).

The complexity of implementing the 3DS flow in your Android app depends on the payment provider you choose.

In one project where I used Stripe, I didn’t have to do anything at all (not even specify which authentication methods I wanted to support). In another where I used Worldpay, I had to use the Cardinal SDK to implement the 3DS flow. Finally, in another case, I didn’t use any 3rd-party SDK and handled the redirect to a WebView manually.

CRYPTOGRAM_3DS Link to heading

With CRYPTOGRAM_3DS, Google Pay displays the cards that the user has previously added to the Google Wallet app.

When adding them, depending on the bank’s requirements, the user may need to verify their identity. At the end, a device-specific token is created, and we refer to these cards as “tokenized”.

Since authentication has already been completed, you don’t need to implement a 3DS flow in your app.

If the user selects one of these cards for a transaction, they won’t go through 3DS. They’ll simply be asked to confirm the transaction using biometrics, PIN, or pattern, depending on their device settings.

Even if the user switches devices, these cards will continue to be available for Google Pay payments, since they’re stored in their Google Account. The first time they try to use one of them on the new device, however, a new device-specific token will need to be created (following the same process described above).

Finally, a clarification: the device-specific token (DPAN) is not the same as the token that the Google Pay API creates to send to the payment provider. It is, however, used to generate it.

Which method should I choose? Link to heading

It’s best to specify both methods, as long as they’re supported by your payment provider. PAN_ONLY is supported by all providers, while for CRYPTOGRAM_3DS you’ll need to check.

The Google Pay API automatically selects the method for each card. If the card is tokenized, it prefers the more secure CRYPTOGRAM_3DS; otherwise, it uses PAN_ONLY.

Further reading Link to heading

Google’s step-by-step tutorial for implementing Google Pay is excellent, and I don’t think you’ll need anything more detailed:

https://developers.google.com/pay/api/web/guides/tutorial

The following blog post also explains some things about the available authentication options, but it’s more technical than practical. It’s worth a look, though, now that you know what they mean in practice:

https://developers.googleblog.com/configure-google-pay-payment-options/

If you want to read more about 3DS and see the full specification:

https://www.emvco.com/emv-technologies/3-d-secure/