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.

Push Provisioning API best practices

To optimize your Push Provisioning API integration, Google recommends incorporating the following best practices:

  1. Green path: Green path push provisioning tokenizations, if possible.

  2. Instant issuance: Encourage users to add to Google Wallet while waiting for the physical card.

  3. Prominently feature the ability to push provision: Publish banners in your app to promote push provisioning and make the provisioning button accessible.

For further details, refer to Best practices for push provisioning.

ID&V best practices

Google supports a range of ID&V methods. Well thought out and high performing ID&V processes yield token activation rates of +90% on Google Pay (see list of ID&V methods in order of activation rate). 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 aren't able to use your card in Google Pay and are 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.

1. Make the most of risk signals

Google provides various risk signals and recommendations, including but not limited to account and device risk scores, 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. This data in addition to the issuer's risk engine allows the issuer to determine the right ID&V approach to offer the user for each provisioning request. For example:

  • Most issuers reserve the red path for an unacceptable risk rating, which is typically a very small fraction of attempts.

  • Most issuers send manual provisioning attempts to yellow path, except when it is a trusted device (e.g. setting up a new phone when the old phone already had a device token).

Speak to your TSP for more details about the fields they can provide to optimize your risk assessment.

2. Match ID&V options to risk level

Issuers can tailor the ID&V methods offered to the user based on its account and device risk scores. For example, for high-risk attempts, issuers could choose to offer the methods that they consider offer the highest security. Whereas for lower-risk attempts, offering the full suite of ID&V methods could be fine.


3. Use RCS for SMS OTP

Issuers can ensure the OTP is sent using Rich Communication Services (RCS). RCS chats can provide an upgraded, rich messaging experience offering more security (i.e. messages sent between sender and user are encrypted, sender ID and verified badge in app header). RCS is also available over both Wifi and mobile data.


4. Using SMS OTP to redirect the user through their banking app

Whilst App to App verification is available and would involve less friction, as an alternative issuers can also include a link in the SMS OTP for the user to log into their banking app. Once in their banking app they have the option to complete enrolment, or the actual OTP is shown (i.e. in notifications / messages). This OTP is then used to complete Google Wallet provisioning.


5. General messaging best practises for SMS OTP and Email OTP

  • If using SMS OTP, adopt RCS to offer a richer messaging experience.
  • Clearly mention that this is an attempt to add a card to Google Wallet.
  • Reinforce to the user not to share this number with anyone.
  • Send an additional confirmation SMS/email/app notification to the user when their card is added to Google Wallet. Include details for how the user can quickly flag & escalate (i.e. if they did not provision the card themselves).


6. Alternative ID&V methods which enable issuers to achieve SCA compliance

App to App verification and Web-based secure authentication hosted by your TSP (see illustration below), are also options to achieve SCA compliance.


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.