Google Pay: in-app та веб

1) Що таке Google Pay в онлайні

Google Pay (GPay) - шар безпечної оплати поверх карткових рейок (Visa/Mastercard/та ін.), де PAN замінюється токеном пристрою/мережі (DPAN/network token), а транзакція підписується одноразовою EMV-криптограмою Автентифікація - біометрія/скрін-лок + device binding.
Для мерчанта це по суті картковий CNP-платіж з підвищеною конверсією і меншим фродом. Диспути/рефанди - за картковими правилами.

В окремих регіонах (наприклад, Індія) Google Pay також виступає як «ініціатор» UPI-intent. У цій статті фокус - карткові онлайнові платежі (Web/In-App).

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 і ризик

У EC/PSD2 SCA часто виконана на рівні Google Pay → окремий 3DS може не запускатися (вирішує банк/PSP).
Емітент/мережа може запитати доп-перевірку/відхилити транзакцію (особливо для high-risk MCC).
Для чутливих вертикалей можливі селективні відмови і знижені ліміти.

5) MIT/рекуррент і COF

Токен Google Pay для one-off транзакції не придатний для повторного списання.

• Перший платіж через 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)

МСС/вертикаль (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: безпечний повтор при таймаутах, перемикання на карти/А2А при повторних відмовах.
Desktop↔mobayl: 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 (підпис/НМАС), ідемпотентність і ретраї.
3. Налаштуйте COF/network tokenization для MIT + зберігайте consent.
4. Увімкніть smart-routing: пріоритет GPay на Android, fallback на карти/А2А.
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.