Authentication-Authorization flow
Stay organized with collections
Save and categorize content based on your preferences.
Overview
The purpose of the Authentication flow is to identify and authenticate the user
to the Payment Integrator
(integrator).
The most common use of authentication is as a precondition input to other
methods, notably,
generateDirectDebitAuthorization.
The output of the authentication-authorization, which is authentication proof is used as an
input (parameter) to the above mentioned method.
Modes of Authentication-Authorization
Google Standard Payments supports authentication-authorization via Redirect
Authentication-Authorization.
Redirect Authentication-Authorization
Redirect authentication occurs when Google redirects the user to an integrator-
owned property(e.g. web app or Android app) to perform the authentication. Once
finished the app must redirect back to Google. That application could be a web
application, Android application or both.
Providing a mobile web and desktop web authentication flow will allow the
integrator to reach all users on supported platforms. The integrator can
optionally support the Android application redirect as well. 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 to the web application and the Android application are the same. The web
application redirect uses an HTTP GET redirect with parameters encoded in the
URL. For more details on this encoding see
Web Authentication
.
The result from each of these authentication mechanisms is a signed response
called the
AuthenticationAuthorizationResponse
. Returning this response to Google signals to
Google that the authentication-authorization was successful. When used in standalone mode,
the gspResult and signature are used to determine successful authentication-authorization.
To authenticate a flow (e.g. capture), the authentication requestId (from the
AuthenticationAuthorizationRequest)
is used as proof of authentication-authorization.
The following sequence diagram shows the interaction between the user's browser,
Google, and the integrator's web application:
The Android authentication-authorization flow uses an
Android Intent
to redirect the user. For more details on the Intent parameters, see
Android Authentication
.
The following sequence diagram shows the interaction between the user's phone,
Google, and the integrator's Android application:
All rights reserved. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2024-09-03 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-09-03 UTC."],[[["\u003cp\u003eGoogle Standard Payments uses authentication to verify user identity before actions like setting up direct debit authorizations.\u003c/p\u003e\n"],["\u003cp\u003eAuthentication is primarily done through redirects, where Google sends users to the payment integrator's web or Android app for login.\u003c/p\u003e\n"],["\u003cp\u003eIntegrators are strongly encouraged to support Android app redirects for optimal user experience and conversion rates.\u003c/p\u003e\n"],["\u003cp\u003eAuthentication results in a signed response, confirming successful user authentication to Google.\u003c/p\u003e\n"],["\u003cp\u003eThe authentication request ID serves as proof of authentication for subsequent actions within the payment flow.\u003c/p\u003e\n"]]],["Authentication identifies users to the payment integrator, often as a prerequisite for other actions like `generateDirectDebitAuthorization`. This is achieved via `Redirect Authentication-Authorization`, where users are redirected to the integrator's web or Android app for authentication and then back to Google. The process results in an `AuthenticationAuthorizationResponse`, signaling success. The `requestId` from the request serves as proof of authentication. Integrators are recommended to support both web and Android app redirects, leveraging HTTP GET or Android Intent, respectively.\n"],null,["# Authentication-Authorization flow\n\nOverview\n--------\n\nThe purpose of the Authentication flow is to identify and authenticate the user\nto the [Payment Integrator](/standard-payments/reference/glossary#payment_integrator)\n(integrator).\n\nThe most common use of authentication is as a precondition input to other\nmethods, notably,\n[`generateDirectDebitAuthorization`](/standard-payments/payment-processor-service-api/v1/TopLevel/generateDirectDebitAuthorization).\nThe output of the authentication-authorization, which is authentication proof is used as an\ninput (parameter) to the above mentioned method.\n\nModes of Authentication-Authorization\n-------------------------------------\n\nGoogle Standard Payments supports authentication-authorization via `Redirect\nAuthentication-Authorization`.\n\n### Redirect Authentication-Authorization\n\nRedirect authentication occurs when Google redirects the user to an integrator-\nowned property(e.g. web app or Android app) to perform the authentication. Once\nfinished the app must redirect back to Google. That application could be a web\napplication, Android application or both.\n\nProviding a mobile web and desktop web authentication flow will allow the\nintegrator to reach all users on supported platforms. The integrator can\noptionally support the Android application redirect as well. Google strongly\nrecommends that integrators support the Android application as it provides the\nbest user experience resulting in the highest conversion rate. The parameters\npassed to the web application and the Android application are the same. The web\napplication redirect uses an HTTP GET redirect with parameters encoded in the\nURL. For more details on this encoding see\n[Web Authentication](/standard-payments/v1/payment-integrator-hosted-api/client-to-server-api/web-auth-api)\n.\n\nThe result from each of these authentication mechanisms is a signed response\ncalled the\n[`AuthenticationAuthorizationResponse`](/standard-payments/v1/authentication-authorization-api/authenticationAuthorizationResponse)\n. Returning this response to Google signals to\nGoogle that the authentication-authorization was successful. When used in standalone mode,\nthe `gspResult` and signature are used to determine successful authentication-authorization.\n\nTo authenticate a flow (e.g. capture), the authentication `requestId` (from the\n[`AuthenticationAuthorizationRequest`](/standard-payments/v1/authentication-authorization-api/authenticationAuthorizationRequest))\nis used as proof of authentication-authorization.\n\nThe following sequence diagram shows the interaction between the user's browser,\nGoogle, and the integrator's web application:\n\nThe Android authentication-authorization flow uses an\n[Android Intent](https://developer.android.com/reference/android/app/Activity)\nto redirect the user. For more details on the Intent parameters, see\n[Android Authentication](/standard-payments/v1/payment-integrator-hosted-api/client-to-server-api/android-auth-api)\n.\n\nThe following sequence diagram shows the interaction between the user's phone,\nGoogle, and the integrator's Android application:"]]