Google Pay：在應用程序和網絡上

1）什麼是Google Pay在線

Google Pay（GPay）是卡軌頂部的安全支付層（Visa/Mastercard/等），其中PAN被設備/網絡令牌（DPAN/network token）取代，交易由一次性EMV密碼簽名。身份驗證-生物識別/屏幕鎖+設備綁定。
對於商人來說，這本質上是紙牌CNP支付，轉換增加，欺詐減少。Disputs/Refands-根據卡規則。

2）渠道和腳本

2.1 Web

通過Google Pay JS （PaymentDataRequest）進行集成。
適用於現代瀏覽器（最好的UX-Chrome/Android）。
在瀏覽器中/通過帶有生物識別技術的相關設備（電話/手表）進行確認。

2.2 In-App (Android)

Google Pay API for Android (native sheet).

Deep Link/App2App在GPay應用程序中確認，狀態返回到您的應用程序。

2.3 POS (NFC)

通過HCE/SE的CP腳本；在網上文章之外，charjback規則不同。

3）令牌化和安全

DPAN/Network Token由網絡令牌服務發布；PAN不會離開設備。
每次付款都會形成EMV密碼圖（一次性簽名）。
SCA通過設備生物識別/屏幕鎖定（PSD2兼容）關閉。
Payment Token在PSP/網關（網關模式）中解密，或者在具有相關證書（direct-mode；很少）。

4） SCA/3DS模式和風險

EC/PSD2，SCA通常在Google Pay級別執行→單獨的3 DS可能無法運行（由銀行/PSP決定）。
發行人/網絡可以請求dop檢查/拒絕交易（尤其是對於高風險的MCC）。
對於敏感的垂直方向，可以選擇性故障和降低限制。

5）麻省理工學院/遞歸和COF

單筆交易的Google Pay令牌不適合重新註銷。

• 通過GPay首次付款→獲得麻省理工學院的同意，→從PSP/收購商處在 COF（Network Token/VTS/MDES）中標記卡。
• 進一步的註銷-作為帶有正確交易標記的COF令牌的MIT。
• 沒有COF和銀行同意-高風險decline/chargeback。

6）連接選項： gateway vs direct

網關（推薦）：'tokenizationSpecification。type="PAYMENT_GATEWAY"' → PSP解密令牌並進行授權。快速起步，順應性較小。
Direct：'type='DIRECT' →商人獨立解密卡網絡令牌。需要證書/密鑰和嚴格的安全性；很少使用。

• `allowedPaymentMethods` → `type: "CARD"`, `parameters.allowedAuthMethods` (`PAN_ONLY`, `CRYPTOGRAM_3DS`), `allowedCardNetworks`, `billingAddressParameters`.
• `tokenizationSpecification` → `gateway` или `direct`.
• 「transactionInfo」 → 金額/貨幣/totalPriceStatus。
• `merchantInfo` → `merchantId`/`merchantName`.

7）集成流

7.1 Web（步驟）

1.初始化GPay客戶端→驗證isReadyToPay。
2.收集PaymentDataRequest（帶有網絡，身份驗證方法和令牌化）。
3.顯示GPay Sheet →用戶確認（SCA）。
4.獲取paymentMethodData（密碼碼）並發送到PSP。

5.Ответ PSP: `authorized/succeeded/failed` + webhook.

按需求分列的「capture/refund」；recon-每日註冊表。

7.2 Android (in-app)

類似地：創建「PaymentsClient」，傳送「PaymentDataRequest」，獲取令牌並將其傳遞到後端/PSP。

8）狀態、計算和退款

在線狀態：「授權/指定/失敗/取消」（某些PSP中為+「pending」）。
定位：通過PSP/收購商註冊表，通常是T+1/T+2。分享在線成功和會計註冊。
退款：根據卡規則部分/完整。
Chargeback：卡過程（INR/NAD等）仍然有效。

9）頻繁的故障原因（declines）

iGaming/準緩存 （iGaming/準緩存） 是發行商/PSP中的選擇性鎖定。
Mismatch geo（地圖/IP國家/商人位置）。
「PaymentDataRequest」（網絡/身份驗證方法）的配置不正確，「merchantId」不正確或標記化模式。
沒有COF/consent的麻省理工學院。
SCA Taymauts/用戶流中斷。

10）UX模式（增加轉換）

移動第一：在Android上使用Google Pay按鈕。
商品/購物車/檢查卡上的主要GPay按鈕；遵守品牌海德。
Sheet中的預付金額/稅款/交付量（用戶可見總數）。
恢復：在時間間隔時安全重復,在重復故障時切換到卡/A2A。
Desktop↔mobayl： QR/hand-off,如果用戶在手機上確認。

11）智能路由

在Android/Chrome和BIN'ov/bank上提供GPay。
GPay自動丟棄特定的BIN/地質指標退化。
對於遞歸者：首先通過GPay → COF付款，然後在沒有用戶參與的情況下通過MIT付款。

12）安全和合規性

PSP消息/網絡鉤簽名驗證，嚴格的「redirect/return」 URI。
密鑰/保密-在vault中，用於呼叫後端的IP allowlist。
PCI跟蹤在網關模式中最小（您不觸摸PAN/秘密）。
Logs： device hints, reason codes, SCA/confirm時間。

13） iGaming： 功能

可用性和限制取決於司法管轄區，PSP和發行人。
期望選擇性故障和/或降低限制；檢查本地規則。
遞歸註銷-僅具有COF和玩家書面同意的MIT。
保留替代品：A2A/open-banking、本地錢包、eCash。在GPay上以高折線鍵入倒退。

14）核對和報告（recon）

• 「paymentId/transactionId」，「orderId」，網絡（Visa/MC/……），BIN/銀行，金額/貨幣，拒絕狀態/代碼，頻道（Web/In-App），timestamps，ARN/UTR來自註冊表。

每日自動記錄+定期完整記錄。
Alerta：「沒有註冊表的在線成功」，「雙重捕獲」，「aging auth」。

15） KPI和方法管理

Decline matrix (reason codes), доля SCA timeouts.

Chargeback rate/ODR, settlement lag, доля partial refunds.

Proval rate GPay vs普通卡（按銀行/BIN/地理/設備）。
在Android流量中分享GPay，「retry win-rate」。
自動刪除閾值規則（例如，特定BIN/geo的approve <X%）。

16）入口支票清單

1.從PSP連接GPay；獲得merchantId,配置allowedPaymentMethods/networks和tokenizationSpecification。
2.實現Web/In-App Sheet、「authorize/capture/refund」、webhooks （簽名/NMAS）、Idempority和retrai。
3.為MIT+配置COF/network tokenization以存儲consent。
4.啟用智能路由：Android上的GPay優先級,卡上的fallback/A2A。
5.品牌蓋德檢查（按鈕/圖標/復印機）。
6.構造recon和alerta：分步,aging auth, double capture。
7.E2E測試：Web/Android，部分捕獲/收回，定時/重播，PSP降解，高負載。

地標卡

Статусы: `authorized/captured/succeeded/failed/refunded/voided`.

導軌：卡片（Visa/MC/……）；chargeback-根據卡規則。
SCA：生物識別/屏幕鎖（PSD2兼容）；3 DS通常不需要單獨使用。
令牌化：DPAN+EMV密碼圖；對於遞歸-COF/network token。
Settlement：通過PSP註冊表（T+1/T+2）。
限制：設備/瀏覽器/地理位置的可用性；iGaming-PSP/發行人策略。

二.總結

Google Pay是具有高移動轉換和內置SCA的卡支付的「加速器」。通過網關模式進行集成,遵守PaymentDataRequest的要求,圍繞webhooks+idempentity+recon構建,並使用COF進行遞歸。對於iGaming-保持備用導軌和智能路由,因為可用性和限制取決於司法管轄區、銀行和PSP。