Best practices

Adding support for Google Pay may seem like a standard process, but there are many decisions you need to make that impact the success of your Google Pay integration project. Technical shortcuts may place additional burdens on your users, so it's important to keep user experience in mind when planning an integration. By looking for opportunities to optimize how your cards are added and managed in the user's wallet, you'll enjoy higher tokenization success rates, greater customer engagement, significantly fewer customer service calls, and represent your brand well through Google Pay.

Integrate with Google Pay APIs

Google Pay offers APIs that enable you to more tightly manage how your customers interact with Google Wallet. The Push Provisioning API lets you add Google Wallet functionality to your own banking app or website. Many issuers around the world have chosen to integrate with our Push Provisioning API to reduce operational complexity and save costs arising from running their own HCE wallet.

Support instant issuance

Google Pay can support any eligible payment card regardless of how long it has existed. Instant issuance lets your customers start using their payment card before the physical card arrives in the mail. As with regular cards, users can add them through the regular Google Pay provisioning flow. No special integration is required to support instant issuance since device tokenization will work for any eligible payment instrument. But, most often, issuers combine the ability to instantly issue cards with our Android Push Provisioning API. By leveraging push provisioning, issuers are able to enhance key user journeys in their apps like setting up an account or reporting a card lost or stolen to create an amazing payment experience for users.

Don't make the ID&V process harder than it needs to be

Well thought out and high performing ID&V processes yield token activation rates of +90% on Google Pay. The purpose of ID&V is to prevent fraudulent activity on the device, but, in practice, many legitimate users are also lost at this step. Any legitimate users lost during ID&V will not be able to use your card in Google Pay and will be forced either to use another issuer's card in Google Pay or resort to physical cards. Making a little extra investment up front to support a more diverse set of ID&V options pays off significantly in terms of adoption, security, and reduced support calls.

Make the most of risk signals

Google provides various risk signals and recommendations through each of the TSPs. The specific signals depend on the TSP and the data they provide to you. These signals can significantly reduce the risk of fraud without requiring any additional interaction by the customer. The most successful partners consider these signals carefully during the ID&V process and avoid making overly generic or cumbersome risk rules that cause legitimate customers to abandon the tokenization process. Speak to your TSP for more details about the fields they can provide to optimize your risk assessment.

Support multiple forms of yellow path ID&V, especially OTP

A major challenge with yellow path ID&V is that many legitimate users are lost at this stage due to the method of authentication implemented by the issuer. For example, if a user opened their account a long time ago, they may have old contact information on file, meaning they have a difficult time completing ID&V. Supporting a diverse and frictionless set of options rather than just the minimum we require gives users the best chance of seeing a viable option.

SMS OTP is consistently the most successful and smoothest ID&V option favored by users across all of our issuers, followed closely by email OTP. Of the best practices, adding SMS OTP support is probably the most important one to consider.

The app-to-app method can be challenging and create friction for users as they may not have already installed your app or created an online account. If they need to install your app, they may not want to do so while on mobile data or may be put off by additional steps in the process, causing them to exit the tokenization flow, likely never to resume it. The app-to-app method should not be viewed as a way to drive customers to install your app or create an online account.

Call center has the lowest success rate. Also, supporting a call center is labor intensive and prone to social engineering attacks, making this very expensive in the long run. With that said, this method is a great fallback option for customers who legitimately cannot complete ID&V through one of the other available options.

When FPANs change, any device tokens for that card can be updated to link to the new FPAN. The update keeps the token active and updates the last four digits of the FPAN shown in the Google Pay UI. The update can optionally update other metadata attributes like card art. This capability is often overlooked, even though it provides great customer benefit.

For example, when a customer's card expires and a replacement is reissued, the token created with the old card can be updated to link to the new FPAN. This means users do not need to go through the hassle of re-tokenizing their card and potentially being faced with a new yellow path ID&V challenge.

Similarly, when fraud is detected on the account, it is usually not related to the token on the user's device. It is typically concentrated to the physical card or a single token. If the fraud happened on the physical card, the old account can be cancelled and replaced with a new account. Here too, you can provide a great customer experience by relinking the token to the new FPAN so they can use the token while they wait for the replacement card in the mail.

For more information on how to implement token repointing, speak to your TSP.