Quy trình Uỷ quyền xác thực
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Tổng quan
Mục đích của quy trình xác thực là xác định và xác thực người dùng với Trình tích hợp thanh toán (tích hợp).
Cách sử dụng xác thực phổ biến nhất là làm đầu vào điều kiện tiên quyết cho các phương thức khác, đáng chú ý là generateDirectDebitAuthorization.
Dữ liệu đầu ra của lệnh uỷ quyền xác thực (là bằng chứng xác thực) được dùng làm dữ liệu đầu vào (tham số) cho phương thức nêu trên.
Phương thức uỷ quyền xác thực
Google Standard Payments hỗ trợ việc uỷ quyền xác thực thông qua Redirect
Authentication-Authorization.
Chuyển hướng uỷ quyền xác thực
Xác thực chuyển hướng xảy ra khi Google chuyển hướng người dùng đến một tài sản do nhà tích hợp sở hữu(ví dụ: ứng dụng web hoặc ứng dụng Android) để thực hiện việc xác thực. Sau khi hoàn tất, ứng dụng phải chuyển hướng trở lại Google. Ứng dụng đó có thể là ứng dụng web, ứng dụng Android hoặc cả hai.
Việc cung cấp quy trình xác thực web dành cho thiết bị di động và web dành cho máy tính sẽ cho phép nhà tích hợp tiếp cận tất cả người dùng trên các nền tảng được hỗ trợ. Trình tích hợp cũng có thể tuỳ ý hỗ trợ lệnh chuyển hướng ứng dụng Android. Các trình tích hợp nên hỗ trợ ứng dụng Android vì ứng dụng này mang lại trải nghiệm tốt nhất cho người dùng, mang lại tỷ lệ chuyển đổi cao nhất. Các tham số được truyền đến ứng dụng web và ứng dụng Android là như nhau. Lệnh chuyển hướng ứng dụng web sử dụng lệnh chuyển hướng HTTP GET với các tham số được mã hoá trong URL. Để biết thêm thông tin chi tiết về quá trình mã hoá này, hãy xem phần Xác thực web.
Kết quả từ mỗi cơ chế xác thực này là một phản hồi đã ký có tên là AuthenticationAuthorizationResponse. Việc trả về phản hồi này cho Google sẽ báo hiệu cho Google rằng quá trình uỷ quyền xác thực đã thành công. Khi được sử dụng ở chế độ độc lập, gspResult và chữ ký được dùng để xác định lần uỷ quyền xác thực thành công.
Để xác thực một luồng (ví dụ: chụp), requestId xác thực (từ AuthenticationAuthorizationRequest) sẽ được dùng làm bằng chứng về việc cho phép xác thực.
Sơ đồ trình tự sau đây cho thấy sự tương tác giữa trình duyệt của người dùng, Google và ứng dụng web của nhà tích hợp:
Quy trình uỷ quyền xác thực của Android sử dụng một Ý định Android để chuyển hướng người dùng. Để biết thêm thông tin chi tiết về tham số Ý định, hãy xem bài viết Xác thực Android.
Sơ đồ trình tự sau đây cho thấy sự tương tác giữa điện thoại của người dùng, Google và ứng dụng Android của nhà tích hợp:
Mọi quyền được bảo lưu. Java là một nhãn hiệu đã đăng ký của Oracle và/hoặc chi nhánh của Oracle.
Cập nhật lần gần đây nhất: 2025-07-25 UTC.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 2025-07-25 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:"]]
