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](https://developers.google.com/pay/issuers/apis/push-provisioning/android) 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](https://developers.google.com/pay/issuers/apis/push-provisioning/android) 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](https://developers.google.com/pay/issuers/apis/push-provisioning/android) integration, Google recommends
incorporating the following best practices:

1. [Green path](https://developers.google.com/pay/issuers/apis/push-provisioning/android/best-practices#green_path): Green path push provisioning tokenizations, if possible.

2. [Instant issuance](https://developers.google.com/pay/issuers/apis/push-provisioning/android/best-practices#instant_issuance): Encourage users to add to Google Wallet while waiting for
   the physical card.

3. [Prominently feature the ability to push provision](https://developers.google.com/pay/issuers/apis/push-provisioning/android/best-practices#prominent): 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](https://developers.google.com/pay/issuers/apis/push-provisioning/android/best-practices).

## ID\&V best practices

Google supports a range of [ID\&V methods](https://developers.google.com/pay/issuers/tsp-integration/tsp-config#identity_and_verification_idv). 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](https://developers.google.com/pay/issuers/tsp-integration/tsp-config#supported_yellow_path_idv_methods)). 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](https://developers.google.com/pay/issuers/tsp-integration/tsp-config#risk_scores_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. 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.

Issuers are strongly encouraged to override Google's risk signals if their own
internal data verifies the user is legitimate. For example, if a user and device
are fully or partially verified, the issuer can override Google's recommendation
and return a Green or Yellow path decision. The issuer holds the final risk
decision.

- 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](https://developers.google.com/pay/issuers/tsp-integration/tsp-config#identity_and_verification_idv) offered to the user based on its [account
and device risk scores](https://developers.google.com/pay/issuers/tsp-integration/tsp-config#risk_scores_and_recommendations). 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.

To enhance user experience and maximize tokenization success rates, we strongly
recommend implementing and making available a diverse range of [ID\&V methods](https://developers.google.com/pay/issuers/tsp-integration/tsp-config#identity_and_verification_idv).
Relying heavily on only one or two methods, like SMS OTP or Email OTP, can
result in users failing to complete tokenization if their preferred option
isn't presented in a particular situation. Supporting multiple options,
including robust alternatives like [App to App verification](https://developers.google.com/pay/issuers/tsp-integration/app-to-app-idv), ensures users
always have a viable path to add their card to Google Wallet.

![best-practice-match-idv-options-to-risk-level](https://developers.google.com/static/pay/issuers/tsp-integration/images/best-practice-match-idv-options-to-risk-level.png)

### 3. Use RCS for SMS OTP

Issuers can ensure the OTP is sent using Rich Communication Services ([RCS](https://support.google.com/messages/answer/9487020)).
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.

![best-practice-rcs-for-sms-otp](https://developers.google.com/static/pay/issuers/tsp-integration/images/best-practice-rcs-for-sms-otp.png)

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

Whilst [App to App verification](https://developers.google.com/pay/issuers/tsp-integration/app-to-app-idv) 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.

![best-practice-sms-redirect-banking-app](https://developers.google.com/static/pay/issuers/tsp-integration/images/best-practice-sms-redirect-banking-app.png)

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

- If using SMS OTP, adopt [RCS](https://support.google.com/messages/answer/9487020) 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).

![best-practice-otp-general_messaging](https://developers.google.com/static/pay/issuers/tsp-integration/images/best-practice-otp-general_messaging.png)

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

[App to App verification](https://developers.google.com/pay/issuers/tsp-integration/app-to-app-idv) and **Web-based secure authentication** hosted by your
TSP (see illustration below), are also options to achieve [SCA](https://developers.google.com/pay/issuers/overview/region_specific/sca) compliance.

> [!NOTE]
> **Note:** The Web-based secure authentication method is only available for Visa customers at this time.

![best-practice-web-based-authentication](https://developers.google.com/static/pay/issuers/tsp-integration/images/best-practice-web-based-authentication.png)

## Relink tokens when FPANs change

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.