Testing

Testing requirements

We expect issuers to test their integrations to ensure the following criteria have been met before launching:

  • TSP signed off on your launch.
  • All applicable functional tests are passing.
  • Successful token added in each BIN range being launched.
  • Implemented at least two yellow path (verification required) authentication options.
  • 10 tokenizations with greater than 80% yellow path success rate.
  • 5 in-store taps with greater than 90% success rate.
  • 1 successful online transaction.
  • (if launching in Brazil only) 5 in-store transactions - with greater than 90% success rate - using QR code as detailed in Launch requirements for Brazilian issuers.
  • No critical problems related to in-store or online transactions.

Issuers should work directly with their TSP to certify their integration. Issuers do not need to seek launch approval directly from Google, though we may block a launch if we notice it does not satisfy these requirements.

Restricting access

Before launch, regular users should not be able to provision their cards. Work with your TSP to restrict tokenization access to only authorized test and internal user cards until your launch is approved.

Pilot testing

We encourage (but do not require) you to conduct an internal pilot with trusted employees before launching. The pilot helps increase the volume of tokenizations, taps, online transactions, and devices being used before launch.

Best practices for testing

Issuer testing patterns can be similar to fraud patterns since both typically involve making lots of provisioning requests and involve frequent declines. When performing testing, you may get blocked by our risk engine or start receiving lower than normal risk scores. Our risk rules apply to both our sandbox and production environments.

The test cases on this page are designed to exercise the integration fully while minimizing the overall number of tokenization attempts required to minimize the potential impact of Google and the issuer's respective risk engines.

Functional testing

We expect issuers to complete the following end-to-end tests for each network and card portfolio you issue to make sure your integration with Google Pay works flawlessly for cardholders:

Token creation test cases

Test case Exit criteria
1. Add a card via OCR and correct info (where OCR is available) Card added to Google Pay
2. Add a card via manual PAN entry using correct info Card added to Google Pay
3. Attempt to add a card with incorrect expiry Error message that the card could not be added or an error message prompting the user to check their card details. Note that the error message varies by network.
4. Attempt to add a card with incorrect CVV Error message that the card could not be added or an error message prompting the user to check their card details. Note that the error message varies by network.
5. Attempt to add a card with incorrect name (if checked by issuer) Error message that the card could not be added or an error message prompting the user to check their card details. Note that the error message varies by network.
6. Attempt to add a card with incorrect address (if checked by issuer) Error message that the card could not be added or an error message prompting the user to check their card details. Note that the error message varies by network.
7. Attempt to add a card with incorrect phone (if checked by issuer) Error message that the card could not be added or an error message prompting the user to check their card details. Note that the error message varies by network.
8. Add a green path card (if supported) Card added to Google Pay
9. Add a yellow path card for each supported ID&V method Card added to Google Pay
10. Attempt to add an ineligible card (if applicable) Error indicating that this card cannot be used with Google Pay because it is not yet supported
11. Add an "authorized user" card (if applicable) Card added to Google Pay
12. Add a "secondary cardholder" card (if applicable) Card added to Google Pay
13. Attempt to add a red path card Error asking the user to contact the card issuing bank. No further action possible.
14. Add the same card to Google Pay on another device Card added to Google Pay on second device. You have two active tokens for this card, one one each device.

In-store payment test cases

Test case Exit criteria
1. Make a low value transaction on a supported NFC terminal Successful payment
2. Check that transaction notifications are generated for successful transactions Last transaction is shown including the date, amount, and merchant name
3. Refund a full purchase The refund succeeded and produced a transaction notification about the refund
4. Partially refund a purchase The partial refund succeeded and produced a transaction notification about the refund
5. Payment fails on a supported NFC terminal when the issuer declines the transaction (e.g. insufficient funds) The purchase is declined and the user sees a transaction notification about the decline
6. Make a high value transaction on a supported NFC terminal Successful payment
7. (if launching in Brazil only) Make a QR code payment in a Cielo POS terminal that supports credit or debit payments using QR code Successful payment
8. (if launching in Brazil only) Make a QR code payment in a Rede POS terminal that supports credit or debit payments using QR code Successful payment
9. (if launching in Brazil only) Make a QR code payment in a Getnet POS terminal that supports credit or debit payments using QR code Successful payment
10. (if launching in Brazil only) Make a QR code refund in a Cielo POS terminal that supports credit or debit payments using QR code Successful refund
11. (if launching in Brazil only) Make a QR code refund in a Rede POS terminal that supports credit or debit payments using QR code Successful refund
12. (if launching in Brazil only) Make a QR code refund in a Getnet POS terminal that supports credit or debit payments using QR code Successful refund

In-app payment test cases

Test case Exit criteria
1. Make an in-app transaction and verify it succeeds Successful payment
2. Check that a transaction notification is displayed after the transaction Details about the transaction are shown, including the date, amount, and merchant name
3. Check that the rich receipt is displayed properly for that transaction. Details about the transaction are shown, including the date, amount, and merchant name

Token metadata test cases

Test case Exit criteria
1. Check card art on yellow path ID&V screen Correct card art is shown
2. Check card art for active tokens Correct card art is shown
3. Check the app link on the card details screen. Link to your app is visible and correct
4. Check the Terms of Service link on the card details screen. Link to your Terms of Service is visible and correct
5. Check the Privacy Policy link on the card details screen. Link to your Privacy Policy is visible and correct
6. Check the contact phone on the card details screen. Contact phone information is visible and correct
7. Update card metadata (e.g. card art, privacy policy link, etc.) Updates are applied to the token

Token relinking test cases

Test case Exit criteria
1. Update the card's PAN Check that the last 4 digits are updated on the token
2. Make an NFC transaction using the card with the updated PAN Successful payment

Deletion and suspension test cases

Test case Exit criteria
1. Delete token in Google Pay The card was removed from the card list in Google Pay and the deletion is visible in the issuer's back-end system
2. Delete token using issuer back end The card was removed from the card list in Google Pay within a short time (preferably a few seconds)
3. Suspend token using issuer back end (if applicable) The card shows a suspended status within a short time (preferably a few seconds)
4. Unsuspend token using issuer back end (if applicable) The card stops indicating a suspended status within a short time (preferably a few seconds)
5. Suspend card using issuer back end There are two possible exits for this test. The behavior varies by issuer.
Option 1: The card is suspended but the token remains active to make purchases.
Option 2: The card is suspended and all tokens are also suspended.
6. Unsuspend card using issuer back end The card stops indicating a suspended status within a short time after it was unsuspended (preferably a few seconds)
7. Attempt to add card that is currently suspended The provisioning attempt is declined by the issuer (red path)
8. Attempt to add a card that was previously suspended and unsuspended The provisioning attempt follows the green or yellow path tokenization scenario as usual
9. Make an NFC transaction using the token that was previously suspended and unsuspended Successful payment
10. Make an in-app transaction using the token that was previously suspended and unsuspended Successful payment