Redirect Authentication Flow

Overview

The purpose of the Authentication flow is to identify and authenticate the user to the Payment Integrator (integrator).

Authentication is an input to other methods. Particularly for associateAccount. This means that the proof of authentication is used as an input (parameter) to those two methods.

Google can also use the authentication flow in standalone mode to verify a user. In this case it is not used as an input to any other flow, but only to verify that a user is able to authenticate this identity.

Keep in mind that when you are onboarding, Google will work with you to choose the authentication mechanism that will best fit your product.

How the flow works

User authentication is facilitated with web or Android app redirects.

Redirect authentication

A Google user who needs authentication may be redirected to the integrator's app or their website to have their identity verified. Here is a brief overview of the steps in this flow:

1. Google redirects the user to the integrator's web or Android app where they can be authenticated.
2. To authenticate, the authentication requestId (from AuthenticationRequest) is used as proof of authentication.
3. This results in a signed response, called the AuthenticationResponse.
4. Afterwards, the app or website redirects the user back to Google.

Note: In standalone mode, the signed response (step 3), and the gspResult determine if the authentication has been successful.

The redirect authentication uses an HTTP GET method, with parameters encoded in the URL for a web application. It uses an Android Intent for an Android application authentication. For more details on encoding, see Web Authentication, and for Android intent parameters, see Android Authentication.

The result from each of these authentication mechanisms is a signed response called the AuthenticationResponse. This intent should include the encrypted, encoded Google Standard Payments Authentication Response (gspAuthenticationResponse) to communicate a successful authentication. If used in standalone mode, the gspResult and signature are used to determine the successful authentication.

Note: The integrator must provide both a mobile friendly web version and a desktop friendly version of their web app.

The following sequence diagram shows the interaction between the user's browser, Google, and the integrator's web application:

Redirect-Web authentication flow

Here is a list of the objects and what they represent:

• User: This is the person who wants to add a payment method to their Google Account.
• Google UI: In this case, the web interface at Google, where the customer begins to setup a payment method.
• Google Server: The backend server at Google that does the authentication check, along with other authentication tasks.
• Payment Integrator Web: The website of the integrator where the user has an account.

For this authentication flow, we already assume the user is on Google's website (Google UI) and is trying to add a payment method. Here is where everything starts.

1. The Google UI creates an authentication URL which is sent to the Google Server (backend). This is what triggers the authentication process.
2. The Google Server creates an authentication request (AuthenticationRequest).
3. The authentication request sent to the Google UI.
4. The user receives the prompt that they need to authenticate their ID with the integrator.
5. The user responds that they want to authenticate, which sends that message to the integrator's website.
6. The Payment Integrator's website asks for verification of the user's identity.
7. The user provides proof of their identity, which is sent to the Payment Integrator's website.
8. The integrator creates a response (authenticationResponse) to the evidence they were given (with the authenticationResponse encoded in the message).
9. This response URL is sent to the user.
10. The response URL is immediately sent from the user to the Google UI.
11. The Google UI sends the response the Google Server.
12. The Google Server interprets the response as verified.

The next sequence diagram shows the interaction between the user's phone, Google, and the integrator's Android application:

Redirect-Android app authentication flow

Note: neither of the preceding two diagrams illustrate the use of the authenticationId as input to another flow, but that is most often how it will be used.

Here are the objects and what they represent:

• User: This is the person who wants to add a payment method to their Google Account.
• Google UI: In this case, the app interface, where the customer begins to setup a payment method.
• Google Server: The backend server at Google that does the authentication check, along with other authentication tasks.
• Payment Integrator APK: The integrator's app where the user has access to their integrator account.
• Payment Integrator Server: The backend server of the integrator where the user's information is stored.

Since this is an authentication flow, we already assume the user is using an app (Google UI) and is trying to add a payment method. This is where initialization begins.

1. The Google UI creates an authentication call which is sent to the Google Server (backend).
2. The Google Server create an authentication request (AuthenticationRequest).
3. The Google Server sends a call APK to the Google UI (app), requesting authentication.
4. The Google UI sends the user information to the Payment Integrator APK (AUTHENTICATE_V1(authReq)).
5. The Payment Integrator APK sends the request (authReq) to the Payment Integrator's server.
6. The Payment Integrator Server sends a challenge back to the Payment Integrator APK.
7. The Payment Integrator APK sends the challenge back to the user.
8. The user provides proof of their identity, which is sent to the Payment Integrator APK.
9. This proof is then sent to the Payment Integrator Server.
10. The Server creates a signed authenticationResponse.
11. The authentication response is successful, and an authResp message is sent to the Payment Integrator APK.
12. The success message (authResp) is sent to from the Payment Integrator APK to the Google UI.
13. The Google UI sends the response to the Google Server.
14. The Google Server interprets the successful response.

Best practices and other considerations

Choice of platforms

Providing a mobile app and desktop web authentication flow will allow the integrator to reach the most users. Google strongly recommends that integrators support the Android application as it provides the best user experience resulting in the highest conversion rate. The parameters passed in the authentication APIs for the web and Android applications are the same.