總覽
「開始重新導向」流程的目的是將使用者重新導向至付款整合商，並提供充分資訊來完成付款。整合商接著會將使用者重新導向至發卡機構的網頁介面，進而轉送 Google 提供的資訊。接著，使用者就能按照發卡機構提供的操作說明完成付款。這個動作會觸發「完整重新導向」流程。
流程運作方式
使用者可以透過兩種方式選取要做為付款方式 (FOP) 使用的發卡機構。
- 使用者在 Google 使用者介面 (UI) 中選取核發者。
- 使用者在 Google 使用者介面中選取整合商，並在整合商的使用者介面中選取發行者。
使用者在 Google UI 中選取核發者
在此情況下，使用者在 Google 的使用者介面選取 FOP 時必須選取發卡機構，因此 RedirectRequest 中 formOfPayment 物件的 issuerId 欄位會包含 Google 產生的專屬 ID，用來代表發卡機構。請注意，如果付款整合商和發卡機構為同一個實體，Google 會為付款整合商產生 issuerId。重新導向要求使用 HTTPS GET 方法，並在網址中加入參數。
開始重新導向流程 (已選取核發者)
以下序列圖顯示使用者在 Google 的使用者介面中選取核發機構後，瀏覽器、Google、整合商和核發者之間的互動情況：
以下是上圖中的物件清單：
- 使用者：這是指想要付款的使用者。
- Google 使用者介面：Google 的網頁或應用程式介面，是指客戶進行付款的位置。
- Google 伺服器：Google 的後端伺服器，用來建立重新導向要求。
- 付款整合商：整合商將使用者和重新導向要求轉送至發卡機構。
- 核發者：使用者擁有帳戶的發卡機構。
在「開始重新導向」流程中，我們已假設使用者位於 Google 的資源 (Google UI)，並選擇付款方式。這就是一切的起點。
- 使用者選取要用來付款的特定發卡機構。然後就會觸發「開始重新導向」流程。
- Google UI 會呼叫 Google 伺服器 (後端) 以建立新的重新導向要求。
- Google 伺服器會建立重新導向要求。
- 系統會將重新導向要求傳送至 Google UI。
- Google UI 將使用者重新導向至整合商的伺服器。
- 整合商會處理 Google 的重新導向要求，並產生發卡機構專屬的重新導向要求。
- 整合商會將使用者重新導向至核發者的網頁介面。
- 使用者會在核發者的網頁介面中進行驗證。
- 使用者按照畫面上的指示完成付款。
使用者在 Google 使用者介面中選取整合商
在此情況下，使用者可以在 Google 的使用者介面中選取整合商，因此RedirectRequest 的 formOfPayment 欄位會設為 noneChosen，因為只有核發者會視為有效的 FOP。整合商必須提供 UI，讓使用者選取其中一個已獲得 Google 核准的發卡機構。重新導向要求使用 HTTPS GET 方法，並在網址中加入參數。
開始重新導向流程 (已選取整合商)
下圖顯示使用者在 Google 使用者介面中選取整合商後，瀏覽器、Google、整合商和發卡機構之間的互動方式：
以下是上圖中的物件清單：
- 使用者：這是指想要付款的使用者。
- Google 使用者介面：Google 的網頁或應用程式介面，是指客戶進行付款的位置。
- Google 伺服器：Google 的後端伺服器，用來建立重新導向要求。
- 付款整合商：使用者選取發卡機構的整合商。
- 核發者：使用者擁有帳戶的發卡機構。
在「開始重新導向」流程中，我們已假設使用者位於 Google 的資源 (Google UI)，並選擇付款方式。這就是一切的起點。
- 使用者選取整合商 (而非特定發卡機構) 進行付款。然後就會觸發「開始重新導向」流程。
- Google UI 會呼叫 Google 伺服器 (後端) 以建立新的重新導向要求。
- Google 伺服器會建立重新導向要求。
- 系統會將重新導向要求傳送至 Google UI。
- Google UI 將使用者重新導向至整合商的網頁介面。
- 整合商會處理 Google 的重新導向要求。
- 整合商會向使用者顯示可用的發卡機構。
- 使用者選取要用來付款的特定發卡機構。
- 整合商會產生發卡機構專屬的重新導向要求。
- 整合商會將使用者重新導向至核發者的網頁介面。
- 使用者會在核發者的網頁介面中進行驗證。
- 使用者按照畫面上的指示完成付款。
最佳做法和其他注意事項
安全措施
重新導向要求網址會包含未加密的 callbackUrl 欄位和已加密的 redirectRequest 欄位。這兩個欄位都會包含目前交易的 requestId。供應商應驗證 callbackUrl 和加密酬載中的 requestId 是否相同，藉此確認兩者相關。