Google Pay: in-app и веб
1) Что такое Google Pay в онлайне
Google Pay (GPay) — слой безопасной оплаты поверх карточных рельсов (Visa/Mastercard/и др.), где PAN заменяется токеном устройства/сети (DPAN/network token), а транзакция подписывается одноразовой EMV-криптограммой. Аутентификация — биометрия/скрин-лок + device binding.
Для мерчанта это по сути карточный CNP-платеж с повышенной конверсией и меньшим фродом. Диспуты/рефанды — по карточным правилам.
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)
CP-сценарий через HCE/SE; вне рамок онлайновой статьи, правила чарджбеков иные.
3) Токенизация и безопасность
DPAN / Network Token выдается токен-сервисом сети; PAN не покидает устройство.
Для каждого платежа формируется EMV-криптограмма (одноразовая подпись).
SCA закрывается биометрией/скрин-локом устройства (PSD2-совместимо).
Payment Token дешифруется у PSP/шлюза (gateway-mode) или у мерчанта при наличии соответствующих сертификатов (direct-mode; редко).
4) Модель SCA/3DS и риск
В ЕС/PSD2 SCA зачастую выполнена на уровне Google Pay → отдельный 3DS может не запускаться (решает банк/PSP).
Эмитент/сеть может запросить доп-проверку/отклонить транзакцию (особенно для high-risk MCC).
Для чувствительных вертикалей возможны селективные отказы и пониженные лимиты.
5) MIT/рекуррент и COF
Токен Google Pay для one-off транзакции не пригоден для повторного списания.
Для MIT/рекуррентов:- Первый платеж через GPay → получить согласие на MIT → токенизировать карту в COF (Network Token / VTS/MDES) у PSP/эквайера.
- Дальнейшие списания — как MIT с COF-токеном с корректной разметкой транзакции.
- Без COF и согласия банка — высокие decline/chargeback риски.
6) Варианты подключения: gateway vs direct
Gateway (рекомендуется): `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.
6. `capture/refund` по потребности; recon — по ежедневным реестрам.
7.2 Android (in-app)
Аналогично: создаете `PaymentsClient`, передаете `PaymentDataRequest`, получаете токен и передаете его в бэкенд/PSP.
8) Статусы, расчеты и возвраты
Онлайн-статусы: `authorized/succeeded/failed/canceled` (+ `pending` у некоторых PSP).
Settlement: по реестрам PSP/эквайера, обычно T+1/T+2. Разделяйте онлайн-успех и бухгалтерское зачисление.
Refund: частичный/полный по карточным правилам.
Chargeback: карточная процедура (INR/NAD и др.) остается актуальной.
9) Частые причины отказов (declines)
MCC/вертикаль (iGaming/квази-кэш) — селективные блокировки у эмитентов/PSP.
Mismatch гео (страна карты/IP/локация мерчанта).
Неверная конфигурация `PaymentDataRequest` (сети/методы аутентификации), неправильный `merchantId` или режим токенизации.
MIT без COF/consent.
Таймауты SCA/прерывание пользовательского флоу.
10) UX-паттерны (что повышает конверсию)
Mobile-first: выносите кнопку Google Pay первым методом на Android.
Крупная кнопка GPay на карточке товара/корзине/checkout; соблюдайте бренд-гайд.
Pre-fill суммы/налогов/доставки в Sheet (user-visible total).
Recovery: безопасный повтор при таймаутах, переключение на карты/A2A при повторных отказах.
Десктоп↔мобайл: QR/hand-off, если пользователь подтвердит на телефоне.
11) Смарт-маршрутизация
Предлагайте GPay при Android/Chrome и для BIN’ов/банков с высоким approve-рейтом.
Авто-дерейтинг GPay на конкретных BIN/гео при деградации показателей.
Для рекуррентов: первый платеж через GPay → COF, затем MIT без участия пользователя.
12) Безопасность и комплаенс
Валидация подписей сообщений/веб-хуков PSP, строгие `redirect/return` URI.
Ключи/секреты — в vault, IP-allowlist для callback-эндпоинтов.
PCI-след минимален в gateway-mode (вы не трогаете PAN/секреты).
Логи: device hints, reason codes, время SCA/confirm.
13) iGaming: особенности
Доступность и лимиты зависят от юрисдикции, PSP и эмитента.
Ожидайте селективные отказы и/или пониженные лимиты; проверяйте локальные правила.
Рекуррентные списания — только MIT с COF и документированным согласиям игрока.
Держите альтернативы: A2A/open-banking, локальные кошельки, eCash. Введите fallback при высоком decline на GPay.
14) Сверка и отчетность (recon)
Логируйте:- `paymentId/transactionId`, `orderId`, network (Visa/MC/…), BIN/банк, сумма/валюта, статус/коды отказа, канал (Web/In-App), timestamps, ARN/UTR из реестров.
Daily auto-recon + периодический full-recon.
Алерты: «онлайн-успех без реестра», «двойной capture», «aging auth».
15) KPI и управление методом
Approval rate GPay vs обычные карты (по банкам/BIN/гео/устройствам).
Share of GPay в Android-трафике, `retry win-rate`.
Decline matrix (reason codes), доля SCA timeouts.
Chargeback rate/ODR, settlement lag, доля partial refunds.
Пороговые правила авто-дерейтинга (например, approve < X% у конкретного BIN/гео).
16) Чек-лист вывода в прод
1. Подключите GPay у PSP; получите merchantId, настройте allowedPaymentMethods/networks и tokenizationSpecification.
2. Реализуйте Web/In-App Sheet, `authorize/capture/refund`, webhooks (подпись/HMAC), идемпотентность и ретраи.
3. Настройте COF/network tokenization для MIT + храните consent.
4. Включите smart-routing: приоритет GPay на Android, fallback на карты/A2A.
5. Проверка бренд-гайдов (кнопки/иконки/копирайт).
6. Постройте recon и алерты: рассинхроны, aging auth, двойные capture.
7. E2E-тесты: Web/Android, partial capture/refund, таймауты/повторы, деградация PSP, высокие нагрузки.
Карточка ориентиров
Рельс: карточный (Visa/MC/…); chargeback — по правилам карт.
SCA: биометрия/скрин-лок (PSD2-совместимо); 3DS обычно не требуется отдельно.
Токенизация: DPAN + EMV-криптограмма; для рекуррента — COF/network token.
Статусы: `authorized/captured/succeeded/failed/refunded/voided`.
Settlement: по реестрам PSP (T+1/T+2).
Ограничения: доступность по устройствам/браузерам/гео; для iGaming — политика PSP/эмитентов.
Резюме
Google Pay — «ускоритель» карточных платежей с высокой мобильной конверсией и встроенной SCA. Интегрируйте через gateway-mode, соблюдайте требования к PaymentDataRequest, строите вокруг webhooks + идемпотентность + recon и используйте COF для рекуррентов. Для iGaming — держите альтернативные рельсы и смарт-маршрутизацию, так как доступность и лимиты зависят от юрисдикции, банка и PSP.