驗證使用者流程

總覽

驗證流程的目的在於為付款整合商 (整合商) 識別及驗證使用者。

驗證是對其他方法的輸入。尤其是 associateAccount 和 capture。也就是說，驗證證明會做為這兩個方法的輸入 (參數) 使用。

Google 也可以在獨立模式下使用驗證流程來驗證使用者。在此例中，它並未當做任何其他流程的輸入內容，只會用於驗證使用者是否能驗證這個身分。

請記住，新手上路流程中，Google 會協助你選擇最適合產品的驗證機制。

流程運作方式

驗證使用者的方法有兩種，分別有各自的流程。整合時，整合商必須決定要使用何種服務。

1. 重新導向驗證
2. SMS-MT OTP 驗證

重新導向驗證

需要驗證的 Google 使用者可能會重新導向至整合商的應用程式或網站，以便驗證身分。以下簡要說明這個流程中的步驟：

1. Google 會將使用者重新導向至整合服務商的網頁或 Android 應用程式，以便使用者進行驗證。
2. 進行驗證時，系統會使用 AuthenticationRequest 提供的 requestId 驗證功能做為驗證證明。
3. 這會產生已簽署的回應，稱為 AuthenticationResponse。
4. 之後，應用程式或網站將使用者重新導回 Google。

注意： 在獨立模式下，已簽署的回應 (步驟 3) 及 gspResult 會判斷驗證是否成功。

重新導向驗證使用 HTTP GET 方法，並在網頁應用程式的網址中編碼參數。這個 API 使用 Android 意圖進行 Android 應用程式驗證。如要進一步瞭解編碼，請參閱「網路驗證」；如需 Android 意圖參數，請參閱「Android 驗證」。

每個驗證機制的結果均為已簽署的回應，稱為 AuthenticationResponse。這個意圖應包含經過編碼的經過加密 Google 標準付款驗證回應 (gspAuthenticationResponse)，才能告知驗證成功。如果是在獨立模式下使用，系統會使用 gspResult 和簽章判斷驗證是否成功。

注意： 整合商必須提供適合行動裝置的網頁版，以及適合透過行動裝置瀏覽的網頁應用程式。

下圖顯示使用者瀏覽器、Google 和整合商網頁應用程式之間的互動情形：

重新導向網頁驗證流程

以下列出這些物件及其代表的意義：

• 使用者：這位使用者想在 Google 帳戶中新增付款方式。
• Google 使用者介面：在此情況下，客戶會開始設定付款方式的 Google 網頁介面。
• Google 伺服器：Google 的後端伺服器，用於執行驗證檢查和其他驗證工作。
• 付款整合商網站：使用者擁有帳戶的整合商網站。

在這個驗證流程中，我們已假設使用者位於 Google 網站 (Google UI)，正在嘗試新增付款方式。這就是一切的起點。

1. Google UI 會建立驗證網址，並傳送至 Google 伺服器 (後端)。驗證程序。
2. Google 伺服器會建立驗證要求 (AuthenticationRequest)。
3. 傳送至 Google 使用者介面的驗證要求。
4. 使用者會收到提示，要求他們透過整合商驗證自己的 ID。
5. 使用者要求進行驗證，因此將訊息傳送到整合商的網站。
6. 付款整合商的網站要求驗證使用者的身分。
7. 使用者必須提供身分證明，該證明會傳送到「付款整合商」的網站。
8. 整合商會針對他們獲得的證據建立回應 (authenticationResponse)，並在訊息中編碼為 authenticationResponse。
9. 系統會將這個回應網址傳送給使用者。
10. 回應網址會立即將使用者傳送到 Google 使用者介面。
11. Google UI 將回應傳送至 Google 伺服器。
12. Google 伺服器會將回應解讀為已驗證。

下一張序列圖顯示了使用者手機、Google 和整合商的 Android 應用程式之間的互動方式：

重新導向 Android 應用程式驗證流程

注意： 以上兩張圖表都說明將 authenticationId 當做其他流程的輸入內容，但最常見的用途是使用這個方式。

以下是物件及其代表的項目：

• 使用者：這位使用者想在 Google 帳戶中新增付款方式。
• Google 使用者介面：在這個情況下，客戶開始設定付款方式的應用程式介面。
• Google 伺服器：Google 的後端伺服器，用於執行驗證檢查和其他驗證工作。
• 付款整合商 APK：整合商的應用程式，使用者可以存取自己的整合商帳戶。
• 付款整合商伺服器：儲存整合商使用者資訊的後端伺服器。

由於這是驗證流程，因此我們已假設使用者正在使用應用程式 (Google UI)，並嘗試新增付款方式。此時初始化作業就是這裡的起點。

1. Google UI 會建立驗證呼叫，並傳送至 Google 伺服器 (後端)。
2. Google 伺服器建立驗證要求 (AuthenticationRequest)。
3. Google 伺服器將呼叫 APK 傳送至 Google UI (應用程式)，要求驗證。
4. Google 使用者介面將使用者資訊傳送至付款整合商 APK (AUTHENTICATE_V1(authReq))。
5. 付款整合商 APK 將要求 (authReq) 傳送至付款整合商的伺服器。
6. 付款整合商伺服器將驗證問題傳回給付款整合商 APK，
7. 付款整合商 APK 將驗證問題傳回給使用者。
8. 使用者必須提供自己的身分證明，並傳送至付款整合商 APK。
9. 我們會將這份證明傳送給付款整合商伺服器。
10. 伺服器會建立已簽署的 authenticationResponse。
11. 驗證回應成功，系統會將 authResp 訊息傳送至付款整合商 APK。
12. 成功訊息 (authResp) 會從付款整合商 APK 傳送至 Google 使用者介面。
13. Google UI 會將回應傳送至 Google 伺服器。
14. Google 伺服器會解讀成功的回應。

SMS-MT OTP 驗證

另一種驗證方式為短訊息服務、行動網路終止、動態密碼 (SMS-MT OTP)。這種機制會利用使用者的電話號碼傳送動態密碼並進行驗證。Google 會要求整合商傳送動態密碼到使用者的電話號碼，並在使用者收到後，將這項資訊輸入 Google 介面中，就代表使用者進行驗證。

其中包含下列步驟：

1. Google 使用者介面 (UI) 會提示使用者輸入已向整合商註冊的電話號碼。
2. 使用者在 Google 使用者介面中輸入電話號碼。
3. Google 會觸發整合商 (呼叫 sendOtp 方法)，將動態密碼 (OTP) 傳送給使用者。
4. 使用者會收到內含動態密碼的簡訊。
5. 使用者接著在 Google 介面中輸入動態密碼 (做為 capture、associateAccount 和 verifyOtp 的輸入資料)，驗證使用者。這是驗證證明。

在獨立模式下，系統只會呼叫 verifyOtp 方法來驗證動態密碼值。

下圖說明傳送動態密碼的使用者手機、Google 和整合商之間的互動方式：

電話 (傳送動態密碼) 驗證流程

注意： 上圖說明使用動態密碼做為其他呼叫的輸入方式。不過，這可做為各種呼叫的輸入內容，例如 verifyOtp 和 associateAccount。

以下是圖中的物件清單以及物件代表的意義：

• 使用者：這位使用者想在 Google 帳戶中新增付款方式。
• Google UI：在此情況下，客戶開始設定付款方式的 Google 網站或應用程式應用程式。 注意：如果 Google UI 是手機應用程式，由於手機已經知道使用者的電話號碼，因此系統會略過前兩個步驟。
• Google 伺服器：Google 的後端伺服器，用於執行驗證檢查和其他驗證工作。
• 付款整合商伺服器：儲存整合商使用者資訊的後端伺服器。

由於此為動態密碼驗證流程，我們已假設使用者使用的是 Google 手機應用程式或網站 (Google UI)，正在嘗試新增付款方式。此時初始化作業就是這裡的起點。

1. Google UI (手機或網站) 會提示使用者輸入電話號碼。
2. 使用者在 Google 使用者介面中輸入電話號碼。
3. Google UI 將號碼 (sendChallenge(phoneNum)) 傳送至 Google 伺服器。
4. Google 伺服器傳送要求至付款整合商伺服器 (SendOtp(phoneNum))，以便傳送動態密碼。
5. 付款整合商伺服器將動態密碼 (OTP) 傳送給使用者。
6. 付款整合商伺服器在 #5 中回應 Google 的要求，指出動態密碼已成功傳送。
7. 使用者在 Google UI (手機或網站) 中輸入這個動態密碼。
8. Google UI 會將動態密碼傳送至 Google 伺服器，最終傳送給付款整合商進行驗證。驗證使用者的身分並驗證使用者。

驗證與重新驗證

以下是驗證程序的兩個時間點：

1. 初始驗證：用於識別及驗證使用者。初始驗證會做為 associateAccount 方法的輸入。
2. 重新驗證：用於所有其他情境，例如獨立或 capture 的輸入內容。

重新驗證與初始驗證不同。您不需要重新識別使用者，而是直接進行重新驗證。Google 會使用重新驗證機制來要求使用者證明自己擁有特定帳戶，這項作業是由 Google 自行斟酌。

在這項程序中，系統會將稱為 associationId 的參照提供給原始關聯 (從連結流程)。這項資訊是在連結流程中透過呼叫 associateAccount 方法提供。associationId 可識別要驗證的帳戶。基於安全考量，使用者不得變更要驗證的帳戶。

如果是 SMS-MT OTP 重新驗證，Google 會保留原始通話 sendOtp 中提供的電話號碼，做為固定號碼。為了安全起見，這項設定無法變更。

在下方範例中，Google 會在購物前決定進行 (重新驗證) 的流程：

重新驗證流程

物件清單以及物件代表的意義如下：

• 使用者：這是指想要購物的使用者。
• Google 使用者介面：在這種情況下，客戶開始購買的 Google 網站或應用程式應用程式。
• 付款整合商 UI：面向客戶的網站或應用程式，使用者可透過整合商存取其帳戶資訊。
• Google 伺服器：Google 的後端伺服器，會執行重新驗證檢查及其他工作。
• 付款整合商伺服器：儲存整合商使用者資訊的後端伺服器。

當客戶開始購物時，重新驗證流程就會開始。這會初始化資料流，以便重新驗證使用者。

1. 使用者決定購買商品或服務。
2. 系統會將要求從 Google 使用者介面傳送到 Google 伺服器，
3. Google 伺服器將驗證要求 (authenticationRequest) 傳回 Google UI。
4. Google UI 傳送要求至付款整合商 UI，以便驗證 (associationId、authenticationRequest) 使用者。
5. 付款整合商 UI 會查詢使用者，以便驗證其身分 (LookupIdentity(associationId))。
6. 付款整合商 UI 會提示使用者在使用者介面 (整合商的網站或應用程式) 上提供憑證。
7. 系統會將驗證回應傳送至付款整合商伺服器。
8. 系統會將已簽署的驗證回應 (authenticationResponse) 傳回給付款整合商 UI。
9. 系統會將驗證回應 (authenticationResponse) 從付款整合商 UI 傳送至 Google 使用者介面。
10. Google 使用者介面將包含購買資訊的回應傳送至 Google 伺服器。
11. Google 伺服器將 capture 訊息 (尋找可用資金) 傳送至付款整合商伺服器 (authenticationRequestId、GPT、金額)。
12. 付款整合商伺服器將成功訊息傳回 Google 伺服器，
13. Google 的伺服器會將成功的訊息傳送至 Google 使用者介面。
14. Google UI 會將商品交付給客戶 (或通知他們即將送達)。

SMS-MO 驗證

簡短訊息服務，利用行動裝置發出的聲音驗證流程，使用包含從使用者手機傳送至「付款整合商」的「驗證要求 ID」的 SMS，以驗證使用者。

以下是圖中的物件清單以及物件代表的意義：

• 使用者：這位使用者想在 Google 帳戶中新增付款方式。
• Google 使用者介面/裝置：在此情況下，客戶開始設定付款方式的 Google 手機應用程式。
• Google 伺服器：Google 的後端伺服器，負責產生內含驗證要求 ID (ARID) 的簡訊操作說明，並接收整合商傳送的驗證結果。
• 付款整合商伺服器：整合商的後端伺服器，接收驗證簡訊並將驗證要求 ID 傳回 Google。

由於這是驗證流程，因此我們已假設使用者正在使用應用程式 (Google UI)，並嘗試新增付款方式。此時初始化作業就是這裡的起點。

1. 使用者選擇要新增的權杖化付款方式。
2. Google UI 會呼叫 Google 伺服器，啟動 SMS-MO 驗證。
3. Google 伺服器會傳回 SMS 指示，其中包含目的地和包含驗證要求 ID 的內文。
4. Google UI 隨即會傳送簡訊給付款整合商。
5. 付款整合商伺服器會以驗證要求 ID 在 Google 伺服器上呼叫 validationResultNotification 端點。
6. Google 伺服器會驗證驗證要求 ID，該伺服器會回應「成功」。
7. Google UI 會呼叫 Google 伺服器，以取得驗證嘗試結果。
8. Google 伺服器回應成功。

模擬 SMS-MO 驗證

為了執行 SMS-MO 驗證流程的診斷測試，Google 會定義「模擬簡訊」端點。如此一來，當您在沙箱環境中執行測試關聯時，就不需要傳送真實的簡訊，並進行驗證。

以下是圖中的物件清單以及物件代表的意義：

• 測試人員：這是指啟動 SMS-MO 關聯診斷測試的人。
• Google UI：這是 Google 使用者介面，可讓測試人員開始測試，並監控 SMS-MO 診斷測試的狀態。
• Google 伺服器：Google 的後端伺服器，能產生內含驗證要求 ID (ARID) 的簡訊操作說明、傳送模擬的簡訊，並從整合商接收驗證結果。
• 付款整合商伺服器：整合商的後端伺服器，接收模擬驗證簡訊，並將驗證要求 ID 傳回 Google。

這個流程中的步驟包括：

1. 測試人員會提供測試訂閱者 ID (SID)，啟動 SMS-MO 診斷測試。這個 SID 會包含在與付款整合商發出的 simulateSms 呼叫中。
2. Google UI 會呼叫 Google 伺服器，啟動 SMS-MO 驗證。
3. Google 伺服器會傳回 SMS 指示，其中包含目的地和包含驗證要求 ID 的內文。付款整合商的沙箱 HTTPS 連線將會覆寫目的地。
4. Google UI 會呼叫 Google 伺服器，傳送模擬的簡訊。
5. 系統會透過 Google 伺服器對付款整合商伺服器發出 simulateSms 呼叫。步驟 1 中提供的驗證要求 ID 和訂閱者 ID 皆包含在 API 呼叫中。
6. 付款整合商伺服器回應「ACKNOWLEDGED」。
7. Google 伺服器會對 Google UI 做出回應。
8. 付款整合商伺服器會以驗證要求 ID 在 Google 伺服器上呼叫 validationResultNotification 端點。
9. Google 伺服器會回應「成功」。
10. Google UI 會呼叫 Google 伺服器，以取得驗證嘗試結果。
11. Google 伺服器會回應「COMPLETED」。
12. Google UI 會呼叫 Google 伺服器，執行關聯嘗試。
13. 系統會透過 Google 伺服器對付款整合商伺服器發出 associateAccount 呼叫。
14. 付款整合商伺服器回應「成功」。
15. Google 伺服器會回應「成功」。
16. Google 使用者介面更新，以便向測試人員表明 SMS-MO 診斷測試已完成。

最佳做法和其他注意事項

平台選擇

提供行動應用程式和電腦版網站驗證流程，整合商將可觸及最多使用者。Google 強烈建議整合商支援 Android 應用程式，因為這可以提供最佳使用者體驗，進而提高轉換率。無論在網頁和 Android 應用程式的驗證 API 中傳遞的參數相同，