Stay organized with collections
Save and categorize content based on your preferences.
Authentication User 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.
Redirect authentication
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:
Google’s user interface (UI) prompts the user to enter the phone number, which is already registered with the integrator.
User enters a phone number in the Google UI.
Google triggers the integrator (calls the sendOtp method) to send a one-time password (OTP) to the user.
The user receives the SMS message with the OTP.
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
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.
The Google UI (phone or website) prompts the user for their phone number.
The User enters their phone number into the Google UI.
The Google UI sends the number (sendChallenge(phoneNum)) to the Google Server.
The Google Server sends a request to the Payment Integrator Server (SendOtp(phoneNum)) to send a one-time password.
The Payment Integrator Server sends a one-time password (OTP) to the user.
The Payment Integrator Server responds to Google's request in #5, signalling the OTP was successfully sent.
The User enters this OTP into the Google UI (phone or website).
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.
All rights reserved. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2024-10-16 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2024-10-16 UTC."],[[["\u003cp\u003eThe Authentication flow is primarily used to identify and authenticate users for payment integration, serving as input for account association and payment capture.\u003c/p\u003e\n"],["\u003cp\u003eThere are two main authentication methods: Redirect authentication and SMS-MT OTP authentication, with the integrator choosing the method during integration.\u003c/p\u003e\n"],["\u003cp\u003eSMS-MT OTP authentication involves sending a one-time password to the user's phone, which they then enter into Google's interface for verification.\u003c/p\u003e\n"],["\u003cp\u003eGoogle collaborates with integrators to select the most suitable authentication mechanism for their specific product.\u003c/p\u003e\n"],["\u003cp\u003eThe authentication flow can be used standalone to verify user identity or as an input for other processes like account association and payment capture.\u003c/p\u003e\n"]]],["The core of the authentication process involves verifying a user's identity with the Payment Integrator. One method is SMS-MT OTP authentication, where the user enters their registered phone number in Google's UI. Google then uses `sendOtp` to prompt the integrator to send an OTP via SMS to the user. The user inputs the received OTP in the Google UI which is verified using `verifyOtp`, `associateAccount`, or `capture` . This can be stand alone or input for another method.\n"],null,["Authentication User Flow\n\n\nOverview\n\nThe purpose of the Authentication flow is to identify and authenticate the user to the Payment Integrator (integrator).\n\nAuthentication is an input to other methods. Particularly for [`associateAccount`](/pay/korea-e-wallets-v1/payment-integrator-korea-e-wallets-api/associateAccount#google.standardpayments.flows.tokenized_fop_association.v1.PaymentIntegratorTokenizedAssociationService.AssociateAccount) and [`capture`](/pay/korea-e-wallets-v1/payment-integrator-korea-e-wallets-api/capture#google.standardpayments.flows.tokenized_fop_funds_transfer.v1.PaymentIntegratorTokenizedFundsTransferService.Capture). This means that the proof of authentication is used as an input (parameter) to those two methods.\n\nGoogle 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.\n\nKeep in mind that when you are onboarding, Google will work with you to choose the authentication mechanism that will best fit your product.\n\nHow the flow works\n\nThere are two ways to authenticate a user, each with its own flow. At the time of integration, the integrator must determine which to use.\n\n1. Redirect authentication\n2. SMS-MT OTP authentication\n\nSMS-MT OTP Authentication\n\nAnother 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.\n\nThis includes the following steps:\n\n1. Google's user interface (UI) prompts the user to enter the phone number, which is already registered with the integrator.\n2. User enters a phone number in the Google UI.\n3. Google triggers the integrator (calls the [`sendOtp`](/pay/korea-e-wallets-v1/payment-integrator-korea-e-wallets-api/sendOtp#google.standardpayments.flows.tokenized_fop_otp_authentication.v1.PaymentIntegratorTokenizedOtpAuthenticationService.SendOtp) method) to send a one-time password (OTP) to the user.\n4. The user receives the SMS message with the OTP.\n5. The user then enter the OTP (used as input for [`capture`](/pay/korea-e-wallets-v1/payment-integrator-korea-e-wallets-api/capture#google.standardpayments.flows.tokenized_fop_funds_transfer.v1.PaymentIntegratorTokenizedFundsTransferService.Capture), [`associateAccount`](/pay/korea-e-wallets-v1/payment-integrator-korea-e-wallets-api/associateAccount#google.standardpayments.flows.tokenized_fop_association.v1.PaymentIntegratorTokenizedAssociationService.AssociateAccount), and [`verifyOtp`](/pay/korea-e-wallets-v1/payment-integrator-korea-e-wallets-api/verifyOtp#google.standardpayments.flows.tokenized_fop_otp_authentication.v1.PaymentIntegratorTokenizedOtpAuthenticationService.VerifyOtp)) they received into Google's interface, authenticating the user. This is proof of authentication.\n\nIn standalone mode, only the [`verifyOtp`](/pay/korea-e-wallets-v1/payment-integrator-korea-e-wallets-api/verifyOtp#google.standardpayments.flows.tokenized_fop_otp_authentication.v1.PaymentIntegratorTokenizedOtpAuthenticationService.VerifyOtp) method will be called to verify the OTP value.\n\nThe following sequence diagram shows the interaction between the user's phone, Google, and the integrator when sending an OTP:\n\nPhone (sending OTP) authentication flow\n\n| **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`](/pay/korea-e-wallets-v1/payment-integrator-korea-e-wallets-api/verifyOtp#google.standardpayments.flows.tokenized_fop_otp_authentication.v1.PaymentIntegratorTokenizedOtpAuthenticationService.VerifyOtp), and [`associateAccount`](/pay/korea-e-wallets-v1/payment-integrator-korea-e-wallets-api/associateAccount#google.standardpayments.flows.tokenized_fop_association.v1.PaymentIntegratorTokenizedAssociationService.AssociateAccount).\n\nHere is a list of objects in the diagram and what they represent:\n\n- **User**: This is the person who wants to add a payment method to their Google account.\n- **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.\n- **Google Server**: The backend server at Google that does the authentication check, along with other authentication tasks.\n- **Payment Integrator Server**: The backend server of the integrator where the user's information is stored.\n\nSince 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.\n\n1. The Google UI (phone or website) prompts the user for their phone number.\n2. The User enters their phone number into the Google UI.\n3. The Google UI sends the number (`sendChallenge(phoneNum)`) to the Google Server.\n4. The Google Server sends a request to the Payment Integrator Server ([`SendOtp(phoneNum)`](/pay/korea-e-wallets-v1/payment-integrator-korea-e-wallets-api/sendOtp#google.standardpayments.flows.tokenized_fop_otp_authentication.v1.PaymentIntegratorTokenizedOtpAuthenticationService.SendOtp)) to send a one-time password.\n5. The Payment Integrator Server sends a one-time password (OTP) to the user.\n6. The Payment Integrator Server responds to Google's request in #5, signalling the OTP was successfully sent.\n7. The User enters this OTP into the Google UI (phone or website).\n8. 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."]]
