OTP 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 and capture. 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

There are two ways to authenticate a user, each with its own flow. At the time of integration, the integrator must determine which to use.

1. Redirect authentication
2. SMS-MT OTP authentication

SMS-MT OTP Authentication

Another authentication method is Short Message Service, Mobile Terminated, One-Time Password (SMS-MT OTP). This mechanism utilizes the user’s phone number to send them a one-time password for authentication. Google asks the integrator to send an OTP to the user’s phone number, and after a user receives it, and then inputs this into Google’s interface, the user will be verified.

This includes the following steps:

1. Google’s user interface (UI) prompts the user to enter the phone number, which is already registered with the integrator.
2. User enters a phone number in the Google UI.
3. Google triggers the integrator (calls the sendOtp method) to send a one-time password (OTP) to the user.
4. The user receives the SMS message with the OTP.
5. The user then enter the OTP (used as input for capture, associateAccount, and verifyOtp) they received into Google’s interface, authenticating the user. This is proof of authentication.

In standalone mode, only the verifyOtp method will be called to verify the OTP value.

The following sequence diagram shows the interaction between the user's phone, Google, and the integrator when sending an OTP:

Phone (sending OTP) authentication flow

Note: The above diagram does not illustrate the use of the OTP as input to another call. However this would be used as input to a variety of calls, such as verifyOtp, and associateAccount.

Here is a list of objects in the diagram 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, a Google website or phone app where the customer begins to setup a payment method. Note: If the Google UI is a phone app, the first couple of steps will be skipped because the phone already knows the user’s phone number.
• Google Server: The backend server at Google that does the authentication check, along with other authentication tasks.
• Payment Integrator Server: The backend server of the integrator where the user’s information is stored.

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

1. The Google UI (phone or website) prompts the user for their phone number.
2. The User enters their phone number into the Google UI.
3. The Google UI sends the number (sendChallenge(phoneNum)) to the Google Server.
4. The Google Server sends a request to the Payment Integrator Server (SendOtp(phoneNum)) to send a one-time password.
5. The Payment Integrator Server sends a one-time password (OTP) to the user.
6. The Payment Integrator Server responds to Google's request in #5, signalling the OTP was successfully sent.
7. The User enters this OTP into the Google UI (phone or website).
8. The Google UI sends the OTP to the Google Server where it is eventually sent to the payment integrator for verification. This verifies the user’s identity and authenticates the user.