總覽
驗證流程的目的在於為付款整合商 (整合商) 識別及驗證使用者。
驗證是對其他方法的輸入。尤其是 associateAccount
和 capture
。也就是說,驗證證明會做為這兩個方法的輸入 (參數) 使用。
Google 也可以在獨立模式下使用驗證流程來驗證使用者。在此例中,它並未當做任何其他流程的輸入內容,只會用於驗證使用者是否能驗證這個身分。
請記住,新手上路流程中,Google 會協助你選擇最適合產品的驗證機制。
流程運作方式
驗證使用者的方法有兩種,分別有各自的流程。整合時,整合商必須決定要使用何種服務。
- 重新導向驗證
- SMS-MT OTP 驗證
重新導向驗證
需要驗證的 Google 使用者可能會重新導向至整合商的應用程式或網站,以便驗證身分。以下簡要說明這個流程中的步驟:
- Google 會將使用者重新導向至整合服務商的網頁或 Android 應用程式,以便使用者進行驗證。
- 進行驗證時,系統會使用
AuthenticationRequest
提供的requestId
驗證功能做為驗證證明。 - 這會產生已簽署的回應,稱為
AuthenticationResponse
。 - 之後,應用程式或網站將使用者重新導回 Google。
重新導向驗證使用 HTTP GET 方法,並在網頁應用程式的網址中編碼參數。這個 API 使用 Android 意圖進行 Android 應用程式驗證。如要進一步瞭解編碼,請參閱「網路驗證」;如需 Android 意圖參數,請參閱「Android 驗證」。
每個驗證機制的結果均為已簽署的回應,稱為 AuthenticationResponse
。這個意圖應包含經過編碼的經過加密 Google 標準付款驗證回應 (gspAuthenticationResponse
),才能告知驗證成功。如果是在獨立模式下使用,系統會使用 gspResult
和簽章判斷驗證是否成功。
下圖顯示使用者瀏覽器、Google 和整合商網頁應用程式之間的互動情形:
重新導向網頁驗證流程
以下列出這些物件及其代表的意義:
- 使用者:這位使用者想在 Google 帳戶中新增付款方式。
- Google 使用者介面:在此情況下,客戶會開始設定付款方式的 Google 網頁介面。
- Google 伺服器:Google 的後端伺服器,用於執行驗證檢查和其他驗證工作。
- 付款整合商網站:使用者擁有帳戶的整合商網站。
在這個驗證流程中,我們已假設使用者位於 Google 網站 (Google UI),正在嘗試新增付款方式。這就是一切的起點。
- Google UI 會建立驗證網址,並傳送至 Google 伺服器 (後端)。驗證程序。
- Google 伺服器會建立驗證要求 (
AuthenticationRequest
)。 - 傳送至 Google 使用者介面的驗證要求。
- 使用者會收到提示,要求他們透過整合商驗證自己的 ID。
- 使用者要求進行驗證,因此將訊息傳送到整合商的網站。
- 付款整合商的網站要求驗證使用者的身分。
- 使用者必須提供身分證明,該證明會傳送到「付款整合商」的網站。
- 整合商會針對他們獲得的證據建立回應 (
authenticationResponse
),並在訊息中編碼為authenticationResponse
。 - 系統會將這個回應網址傳送給使用者。
- 回應網址會立即將使用者傳送到 Google 使用者介面。
- Google UI 將回應傳送至 Google 伺服器。
- Google 伺服器會將回應解讀為已驗證。
下一張序列圖顯示了使用者手機、Google 和整合商的 Android 應用程式之間的互動方式:
重新導向 Android 應用程式驗證流程
以下是物件及其代表的項目:
- 使用者:這位使用者想在 Google 帳戶中新增付款方式。
- Google 使用者介面:在這個情況下,客戶開始設定付款方式的應用程式介面。
- Google 伺服器:Google 的後端伺服器,用於執行驗證檢查和其他驗證工作。
- 付款整合商 APK:整合商的應用程式,使用者可以存取自己的整合商帳戶。
- 付款整合商伺服器:儲存整合商使用者資訊的後端伺服器。
由於這是驗證流程,因此我們已假設使用者正在使用應用程式 (Google UI),並嘗試新增付款方式。此時初始化作業就是這裡的起點。
- Google UI 會建立驗證呼叫,並傳送至 Google 伺服器 (後端)。
- Google 伺服器建立驗證要求 (
AuthenticationRequest
)。 - Google 伺服器將呼叫 APK 傳送至 Google UI (應用程式),要求驗證。
- Google 使用者介面將使用者資訊傳送至付款整合商 APK (
AUTHENTICATE_V1(authReq)
)。 - 付款整合商 APK 將要求 (
authReq
) 傳送至付款整合商的伺服器。 - 付款整合商伺服器將驗證問題傳回給付款整合商 APK,
- 付款整合商 APK 將驗證問題傳回給使用者。
- 使用者必須提供自己的身分證明,並傳送至付款整合商 APK。
- 我們會將這份證明傳送給付款整合商伺服器。
- 伺服器會建立已簽署的
authenticationResponse
。 - 驗證回應成功,系統會將
authResp
訊息傳送至付款整合商 APK。 - 成功訊息 (
authResp
) 會從付款整合商 APK 傳送至 Google 使用者介面。 - Google UI 會將回應傳送至 Google 伺服器。
- Google 伺服器會解讀成功的回應。
SMS-MT OTP 驗證
另一種驗證方式為短訊息服務、行動網路終止、動態密碼 (SMS-MT OTP)。這種機制會利用使用者的電話號碼傳送動態密碼並進行驗證。Google 會要求整合商傳送動態密碼到使用者的電話號碼,並在使用者收到後,將這項資訊輸入 Google 介面中,就代表使用者進行驗證。
其中包含下列步驟:
- Google 使用者介面 (UI) 會提示使用者輸入已向整合商註冊的電話號碼。
- 使用者在 Google 使用者介面中輸入電話號碼。
- Google 會觸發整合商 (呼叫
sendOtp
方法),將動態密碼 (OTP) 傳送給使用者。 - 使用者會收到內含動態密碼的簡訊。
- 使用者接著在 Google 介面中輸入動態密碼 (做為
capture
、associateAccount
和verifyOtp
的輸入資料),驗證使用者。這是驗證證明。
在獨立模式下,系統只會呼叫 verifyOtp
方法來驗證動態密碼值。
下圖說明傳送動態密碼的使用者手機、Google 和整合商之間的互動方式:
電話 (傳送動態密碼) 驗證流程
以下是圖中的物件清單以及物件代表的意義:
- 使用者:這位使用者想在 Google 帳戶中新增付款方式。
- Google UI:在此情況下,客戶開始設定付款方式的 Google 網站或應用程式應用程式。 注意:如果 Google UI 是手機應用程式,由於手機已經知道使用者的電話號碼,因此系統會略過前兩個步驟。
- Google 伺服器:Google 的後端伺服器,用於執行驗證檢查和其他驗證工作。
- 付款整合商伺服器:儲存整合商使用者資訊的後端伺服器。
由於此為動態密碼驗證流程,我們已假設使用者使用的是 Google 手機應用程式或網站 (Google UI),正在嘗試新增付款方式。此時初始化作業就是這裡的起點。
- Google UI (手機或網站) 會提示使用者輸入電話號碼。
- 使用者在 Google 使用者介面中輸入電話號碼。
- Google UI 將號碼 (
sendChallenge(phoneNum)
) 傳送至 Google 伺服器。 - Google 伺服器傳送要求至付款整合商伺服器 (
SendOtp(phoneNum)
),以便傳送動態密碼。 - 付款整合商伺服器將動態密碼 (OTP) 傳送給使用者。
- 付款整合商伺服器在 #5 中回應 Google 的要求,指出動態密碼已成功傳送。
- 使用者在 Google UI (手機或網站) 中輸入這個動態密碼。
- Google UI 會將動態密碼傳送至 Google 伺服器,最終傳送給付款整合商進行驗證。驗證使用者的身分並驗證使用者。
驗證與重新驗證
以下是驗證程序的兩個時間點:
- 初始驗證:用於識別及驗證使用者。初始驗證會做為
associateAccount
方法的輸入。 - 重新驗證:用於所有其他情境,例如獨立或
capture
的輸入內容。
重新驗證與初始驗證不同。您不需要重新識別使用者,而是直接進行重新驗證。Google 會使用重新驗證機制來要求使用者證明自己擁有特定帳戶,這項作業是由 Google 自行斟酌。
在這項程序中,系統會將稱為 associationId
的參照提供給原始關聯 (從連結流程)。這項資訊是在連結流程中透過呼叫 associateAccount
方法提供。associationId
可識別要驗證的帳戶。基於安全考量,使用者不得變更要驗證的帳戶。
如果是 SMS-MT OTP 重新驗證,Google 會保留原始通話 sendOtp
中提供的電話號碼,做為固定號碼。為了安全起見,這項設定無法變更。
在下方範例中,Google 會在購物前決定進行 (重新驗證) 的流程:
重新驗證流程
物件清單以及物件代表的意義如下:
- 使用者:這是指想要購物的使用者。
- Google 使用者介面:在這種情況下,客戶開始購買的 Google 網站或應用程式應用程式。
- 付款整合商 UI:面向客戶的網站或應用程式,使用者可透過整合商存取其帳戶資訊。
- Google 伺服器:Google 的後端伺服器,會執行重新驗證檢查及其他工作。
- 付款整合商伺服器:儲存整合商使用者資訊的後端伺服器。
當客戶開始購物時,重新驗證流程就會開始。這會初始化資料流,以便重新驗證使用者。
- 使用者決定購買商品或服務。
- 系統會將要求從 Google 使用者介面傳送到 Google 伺服器,
- Google 伺服器將驗證要求 (
authenticationRequest
) 傳回 Google UI。 - Google UI 傳送要求至付款整合商 UI,以便驗證 (
associationId
、authenticationRequest
) 使用者。 - 付款整合商 UI 會查詢使用者,以便驗證其身分 (
LookupIdentity
(associationId
))。 - 付款整合商 UI 會提示使用者在使用者介面 (整合商的網站或應用程式) 上提供憑證。
- 系統會將驗證回應傳送至付款整合商伺服器。
- 系統會將已簽署的驗證回應 (
authenticationResponse
) 傳回給付款整合商 UI。 - 系統會將驗證回應 (
authenticationResponse
) 從付款整合商 UI 傳送至 Google 使用者介面。 - Google 使用者介面將包含購買資訊的回應傳送至 Google 伺服器。
- Google 伺服器將
capture
訊息 (尋找可用資金) 傳送至付款整合商伺服器 (authenticationRequestId
、GPT、金額)。 - 付款整合商伺服器將成功訊息傳回 Google 伺服器,
- Google 的伺服器會將成功的訊息傳送至 Google 使用者介面。
- Google UI 會將商品交付給客戶 (或通知他們即將送達)。
SMS-MO 驗證
簡短訊息服務,利用行動裝置發出的聲音驗證流程,使用包含從使用者手機傳送至「付款整合商」的「驗證要求 ID」的 SMS,以驗證使用者。
以下是圖中的物件清單以及物件代表的意義:
- 使用者:這位使用者想在 Google 帳戶中新增付款方式。
- Google 使用者介面/裝置:在此情況下,客戶開始設定付款方式的 Google 手機應用程式。
- Google 伺服器:Google 的後端伺服器,負責產生內含驗證要求 ID (ARID) 的簡訊操作說明,並接收整合商傳送的驗證結果。
- 付款整合商伺服器:整合商的後端伺服器,接收驗證簡訊並將驗證要求 ID 傳回 Google。
由於這是驗證流程,因此我們已假設使用者正在使用應用程式 (Google UI),並嘗試新增付款方式。此時初始化作業就是這裡的起點。
- 使用者選擇要新增的權杖化付款方式。
- Google UI 會呼叫 Google 伺服器,啟動 SMS-MO 驗證。
- Google 伺服器會傳回 SMS 指示,其中包含目的地和包含驗證要求 ID 的內文。
- Google UI 隨即會傳送簡訊給付款整合商。
- 付款整合商伺服器會以驗證要求 ID 在 Google 伺服器上呼叫 validationResultNotification 端點。
- Google 伺服器會驗證驗證要求 ID,該伺服器會回應「成功」。
- Google UI 會呼叫 Google 伺服器,以取得驗證嘗試結果。
- Google 伺服器回應成功。
模擬 SMS-MO 驗證
為了執行 SMS-MO 驗證流程的診斷測試,Google 會定義「模擬簡訊」端點。如此一來,當您在沙箱環境中執行測試關聯時,就不需要傳送真實的簡訊,並進行驗證。
以下是圖中的物件清單以及物件代表的意義:
- 測試人員:這是指啟動 SMS-MO 關聯診斷測試的人。
- Google UI:這是 Google 使用者介面,可讓測試人員開始測試,並監控 SMS-MO 診斷測試的狀態。
- Google 伺服器:Google 的後端伺服器,能產生內含驗證要求 ID (ARID) 的簡訊操作說明、傳送模擬的簡訊,並從整合商接收驗證結果。
- 付款整合商伺服器:整合商的後端伺服器,接收模擬驗證簡訊,並將驗證要求 ID 傳回 Google。
這個流程中的步驟包括:
- 測試人員會提供測試訂閱者 ID (SID),啟動 SMS-MO 診斷測試。這個 SID 會包含在與付款整合商發出的
simulateSms
呼叫中。 - Google UI 會呼叫 Google 伺服器,啟動 SMS-MO 驗證。
- Google 伺服器會傳回 SMS 指示,其中包含目的地和包含驗證要求 ID 的內文。付款整合商的沙箱 HTTPS 連線將會覆寫目的地。
- Google UI 會呼叫 Google 伺服器,傳送模擬的簡訊。
- 系統會透過 Google 伺服器對付款整合商伺服器發出
simulateSms
呼叫。步驟 1 中提供的驗證要求 ID 和訂閱者 ID 皆包含在 API 呼叫中。 - 付款整合商伺服器回應「ACKNOWLEDGED」。
- Google 伺服器會對 Google UI 做出回應。
- 付款整合商伺服器會以驗證要求 ID 在 Google 伺服器上呼叫 validationResultNotification 端點。
- Google 伺服器會回應「成功」。
- Google UI 會呼叫 Google 伺服器,以取得驗證嘗試結果。
- Google 伺服器會回應「COMPLETED」。
- Google UI 會呼叫 Google 伺服器,執行關聯嘗試。
- 系統會透過 Google 伺服器對付款整合商伺服器發出
associateAccount
呼叫。 - 付款整合商伺服器回應「成功」。
- Google 伺服器會回應「成功」。
- Google 使用者介面更新,以便向測試人員表明 SMS-MO 診斷測試已完成。
最佳做法和其他注意事項
平台選擇
提供行動應用程式和電腦版網站驗證流程,整合商將可觸及最多使用者。Google 強烈建議整合商支援 Android 應用程式,因為這可以提供最佳使用者體驗,進而提高轉換率。無論在網頁和 Android 應用程式的驗證 API 中傳遞的參數相同,