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。