Overview

TBD: Add a brief description of eWallet (same as done for eMoney)

TBD: See a demo of eWallet flow after you onboard your FoP onto Google entities.

The key Google Standard Payments flows that are involved in an eWallet transaction are described below.

Association flow

Google Standard Payments enables integrators to create an instrument creation flow and buy flow to provide a fast and seamless checkout experience for their users.

A Google customer has one or more instruments. An instrument is a way to pay for services and goods within Google's various ecosystems and marketplaces. In order to add an instrument, the user must link an instrument with external credentials and authenticate those credentials. A good example of this is a credit card. A credit card has a card number (PAN) that Google stores and a card verification number (CVN) that is used for authentication. The user adds an instrument by entering the PAN and the CVN in a Google UI. Google stores the PAN securely after the credit card processor verifies the PAN and CVN numbers. Similarly in this spec we will link the proof of authentication with an instrument on Google's side. We call this linking of the account to an instrument the association flow.

The output of the association flow is the exchange of the Google Payment Token (GPT) which is agreed by both Google and the integrator. During capture, the GPT is passed to the payment integrator (who holds the user account) to identify the user account to bill.

There are a lot of ways to authenticate a user in order to prove ownership of an account. Usernames and passwords are one way, however OTPs, biometric information and security questions are all viable solutions too. Google doesn't intend to dictate how a payment integrator verifies a user. We think that the payment integrator does this the best. So as part of this specification Google wants to leverage the payment integrator's various user interfaces to authenticate the user and simply provide Google with proof of authentication. We call this the authentication flow.

The output of the authentication flow is proof of authentication.

The association flow requires that Google provides proof of authentication by the payment integrator. Prior to the association flow, Google invokes the authentication flow to acquire this proof.

The example below shows the steps that a user will go through for the authentication flow and association flow. The example below walks you through a fake e-wallet called InvisiCash.

Notes on this diagram:

• In steps 1 & 3 note that the user's identity (email) is different between Google and InvisiCash. [e-mail] and [e-mail] respectively. This is okay and expected.
• Between steps 3 & 4 the InvisiCash app (or the web UI if the user doesn't have the app installed) can do whatever is necessary to authenticate the user including talking to the InvisiCash server.

Note: It’s possible for two Google users to share the same integrator payment method. In this case Google provides unique AssociationIds and GPTs to authenticate each user.

Purchase flow

Once the association has finished and the user has a new instrument, they can use that instrument to purchase goods and services through Google. At purchase time the user may or may not be in session. It all depends on the context of the purchase. For example, for a subscription based purchase the user likely won't be in session. At purchase time, Google will present the GPT to the payment integrator. The payment integrator will use this GPT to identify the correct account to debit. This is called the purchase flow.

The example below continues on after user [e-mail] has performed the association and an instrument has been created. The user now wants to purchase goods.

Note: The InvisiCash app is not involved in this buy flow. It only involves the GPT stored on the Google server.

Occasionally, both the payment integrator or Google may require the user to be authenticated before making a purchase. There are various reasons for this. For example:

• Google's risk engine determines a payment looks suspicious
• Regulatory requirements demand an OTP upon every purchase

In such cases, Google will pair the authentication flow with the purchase flow. The user will be sent to the integrator's UI for authentication. The authentication flow's outcome is proof of user identity and authentication. This proof is then sent along with the purchase information during the purchase flow.

In the example below the user [e-mail] has performed the association and an instrument has been created. During the purchase flow, the Google server desires to challenge this user to protect against fraud:

Note: The InvisiCash app is involved in the buy flow. It is critical here that the InvisiCash App pre-fills in [e-mail]. Google is specifically challenging this identity. It is important that the user cannot change this identity. In order to improve the authorization rate between Google and InvisiCash, notice that in step 7, Google passes InvisiCash the proof of authentication. This allows InvisiCash to know that the user was in the buy flow and the user was challenged.

Refresh token flow

During the association flow the payment integrator can tell Google that this GPT expires in X months. While Google prefers non-expiring tokens, it acknowledges that this can't always be the case and thus it supports token expiration. In cases when a token is near expiration, Google sends the user through an authentication flow. The user is sent to the integrator's UI for authentication. The authentication flow's outcome is proof of user identity and authentication. This proof is then sent to the integrator to extend the GPT's expiration time. This is called the refreshToken flow.

The example below continues on after user [e-mail] has performed the association and an instrument has been created. The user's token is expiring soon, so Google is asking the user to refresh their instrument:

The authentication flow is used in two different modalities. The first is while trying to authenticate a user during association time. At this time the user's identity is unknown, and it is up to the user to enter it in. The identity might look like a username, an email address or a phone number. The second modality is trying to authenticate that the user knows the credentials for an existing instrument. In this situation, the user has already added the instrument and has associated their payment integrator's account. In this modality we want to verify the person has credentials for a particular user identity. The user must not be able to change the account identity being verified. In order to do this we send the payment integrator an association ID at association time. At authentication time, Google sends the same association ID to the integrator. The integrator uses the association ID to look up the account that needs to be authenticated.

Remittance flow

Google is the accounting system of record and does accounting for remittance transfers. On a daily basis, Google sends a remittance statement to the payment integrator. The statement provides a summary of the amount that the payment integrator owes to Google along with instructions on how to pay Google. In order for the payment integrator to reconcile, the integrator can query Google for the transaction level details that make up the remittance statement.

Below is the example flow: