Google Pay: w aplikacji i internecie

1) Co to jest Google Pay online

Google Pay (GPay) - warstwa bezpiecznej płatności nad szynami kart (Visa/Mastercard/itp.) , gdzie PAN jest zastąpiony przez token urządzenia/sieci (token DPAN/sieciowy), a transakcja jest podpisywana jednorazowym kryptogramem EMV. Uwierzytelnianie - biometria/blokada ekranu + powiązanie urządzenia.
Dla handlowca jest to zasadniczo płatność CNP karty ze zwiększoną konwersją i mniejszą ilością oszustw. Spory/odmowy - zgodnie z zasadami karty.

2) Kanały i scenariusze

2. 1 Strona internetowa

Integracja za pośrednictwem Google Pay JS.
Działa w nowoczesnych przeglądarkach (najlepszym UX jest Chrome/Android).
Potwierdzenie w przeglądarce/przez powiązane urządzenie (telefon/zegarek) z biometrią.

2. 2 In-App (Android)

Google Pay API dla Androida (natywny arkusz).
Głębokie potwierdzenie Link/App2App w aplikacji GPay, status powrót do aplikacji.

2. 3 POS (NFC)

scenariusz CP za pośrednictwem HCE/SE; poza internetowym artykułem, zasady obciążenia zwrotnego są różne.

3) Tokenizacja i bezpieczeństwo

DPAN/Network Token jest wydawany przez usługę tokenów sieciowych; PAN nie opuszcza urządzenia.
Dla każdej płatności powstaje kryptogram EMV (jednorazowy podpis).
SCA jest zamknięty przez biometrię/blokadę ekranu urządzenia (kompatybilny z PSD2).
Token płatności jest odszyfrowywany w PSP/gateway (tryb bramy) lub u handlowca z odpowiednimi certyfikatami (tryb bezpośredni; rzadko).

4) model SCA/3DS i ryzyko

W EC/PSD2, SCA jest często wykonywane na poziomie Google Pay → oddzielny 3DS może nie rozpocząć (bank/PSP decyduje).
Emitent/sieć może zażądać dodatkowej weryfikacji/odrzucenia transakcji (w szczególności w przypadku MCC wysokiego ryzyka).
Selektywne awarie i zmniejszone limity są możliwe dla wrażliwych pionów.

5) MIT/nawrót i COF

Token płatności Google za transakcję jednorazową nie kwalifikuje się do ponownego obciążenia.

• Pierwsza płatność za pośrednictwem GPay → uzyskać zgodę na MIT → tokenizacja karty w COF (Network Token/VTS/MDES) z PSP/acquirer.
• Kolejne odpisy są jak MIT z tokenem COF z poprawnym znacznikiem transakcji.
• Bez zgody COF i banku - wysokie ryzyko spadku/obciążenia zwrotnego.

6) Opcje połączeń: brama vs bezpośrednie

Brama (zalecana): 'tokenizationSpecyfikacja. type = "PAYMENT_GATEWAY"' → PSP odszyfrowuje token i wykonuje autoryzację. Szybki start, mniej zgodności.
Direct: 'type = „DIRECT” → handlowiec niezależnie odszyfrowuje token sieci kart. Potrzebujesz certyfikatów/kluczy i najsurowszych zabezpieczeń; rzadko stosowane.

• 'allowedKeyMethods' → 'type:' CARD ',' parameters '. „AuthMethods” („PAN _ ONLY”, „CRYPTOGRAM _ 3DS”), „”, „Parameters”.
• „tokenizationSpecyfikacja” → „gateway” ила „direct”.
• 'tra, Info' → kwota/waluta/ Status.
• 'merchantInfo' → 'merchantId'/' merchantName'.

7) Przepływy integracyjne

7. 1 Strona internetowa (kroki)

1. Inicjalizacja klienta GPay → Sprawdź Sprawdź.
2. Zbiór Aplikacji (z sieciami, metodami uwierzytelniania i tokenizacją).
3. Wyświetl arkusz GPay → użytkownik potwierdza (SCA).
4. Otrzymuj dane metodologiczne (token szyfrowy) i wysyłaj do PSP.
5. Отвей PSP: 'autoryzowany/succeeded/failed' + webhook.
6. „przechwytywanie/refundacja” według potrzeb; recon - według dziennych rejestrów.

7. 2 Android (w aplikacji)

Podobnie, utwórz ' Client', podaj '', zdobądź token i przekaż go do backendu/PSP.

8) Statusy, osiedla i zwroty

Statusy online: „autoryzowane/udane/nieudane/anulowane” (+ „oczekujące” w niektórych PSP).
Rozrachunek: przez PSP/rejestry nabywców, zwykle T + 1/T + 2. Oddzielny sukces online i rejestracja rachunkowości.
Zwrot: częściowy/kompletny według zasad karty.
Obciążenie zwrotne: procedura karty (INR/NAD itd.) pozostaje istotna.

9) Częste przypadki awarii (spadki)

MCC/pionowe (iGaming/quasi-cache) - selektywne blokowanie emitentów/PSP.
Niedopasowanie geo (lokalizacja kraju/IP/handlowca).
Niepoprawna konfiguracja 'Menu' (sieci/metody uwierzytelniania), nieprawidłowy tryb 'merchantId' lub tokenizacji.
MIT bez COF/zgody.
SCA Timeouts/User Flow Interrupt.

10) wzory UX (co zwiększa konwersję)

Mobile-first: wyjmij pierwszy przycisk Google Pay na Androida.
Duży przycisk GPay na karcie produktu/koszyku/realizacji transakcji; Postępuj zgodnie z przewodnikiem marki.
Kwota wstępnego wypełnienia/podatki/dostawa do arkusza (liczba widoczna dla użytkownika).
Odzyskiwanie: bezpieczne powtarzanie w czasie, przełączanie na cards/A2A przy powtarzających się awariach.
Komputer stacjonarny: QR/hand-off, jeśli użytkownik potwierdzi w telefonie.

11) Inteligentne routing

Oferta GPay na Android/Chrome i dla BIN/banków o wysokiej stopie zatwierdzenia.
Automatycznie derating GPay na określonych BIN/geo, gdy wskaźniki są zdegradowane.
Dla powtórzeń: najpierw płatność za pośrednictwem GPay → COF, a następnie MIT bez interwencji użytkownika.

12) Bezpieczeństwo i zgodność

Walidacja podpisów wiadomości PSP/haków internetowych, ścisłe URI 'przekieruj/zwracaj'.
Klucze/sekrety - w skarbcu, lista IP dla punktów końcowych zwrotnych.
Footprint PCI jest minimalny w trybie bramy (nie dotyka PAN/sekrety).
Dzienniki: wskazówki urządzenia, kody uzasadnienia, SCA/potwierdzenie czasu.

13) iGaming: Funkcje

Dostępność i ograniczenia różnią się w zależności od jurysdykcji, PSP i emitenta.
Oczekiwać wybranych awarii i/lub zmniejszonych limitów; sprawdź lokalne zasady.
Okresowe odpisy - tylko MIT z COF i udokumentowane zgody gracza.
Zachowaj alternatywy: A2A/open-banking, lokalne portfele, eCash. Wejdź, jeśli spadek jest wysoki na GPay.

14) Pojednanie i sprawozdawczość (zwiad)

• "pa Id/ Id", " Id', sieć (Visa/MC/...), BIN/bank, kwota/waluta, status/kod odmowy, kanał (Web/In-App), znaczniki czasowe, ARN/UTR z rejestrów.

Dzienny auto-recon + okresowy pełny zwiad.
Wpisy: „sukces online bez rejestru”, „podwójne przechwytywanie”, „starzenie się auth”.

15) KPI i zarządzanie metodami

Wskaźnik zatwierdzenia GPay vs karty regularne (według banków/BIN/geo/urządzenia).
Udział GPay w ruchu Android, „retry win-rate”.
Decline matrix (kody powodów), дола SCA timeouts.
Stawka chargeback/ODR, lag rozliczeniowy, дола częściowe refundacje.
Reguły progowe automatycznego wyprowadzania (na przykład zatwierdzają <X% dla określonego BIN/geo).

16) Lista kontrolna wyjściowa

1. Podłącz GPay w PSP; get merchantId, skonfiguruj Methods/networks i tokenizationSpecyfikacja.
2. Wdrożenie arkusza Web/In-App, 'authorize/capture/refund', webhooks (signature/NMAS), idempotence i retrays.
3. Skonfiguruj tokenizację COF/sieci dla zgody sklepu MIT +.
4. Włącz smart-routing: GPay priorytet na Androida, fallback na cards/A2A.
5. Sprawdzanie przewodników marki (przyciski/ikony/prawa autorskie).
6. Zbuduj zwiad i wpisy: z synchronizacji, starzenie się auth, podwójne przechwytywanie.
7. Testy E2E: Web/Android, częściowe przechwytywanie/zwrot, timeouts/replays, degradacja PSP, wysokie obciążenia.

Karta orientacyjna

kolej: karta (Visa/MC/...); obciążenie zwrotne - zgodnie z zasadami karty.
SCA: biometria/blokada ekranu (kompatybilna z PSD2); 3DS zwykle nie jest wymagany oddzielnie.
Tokenizacja: kryptogram DPAN + EMV; dla powtarzania - COF/token sieciowy.
Статса: „autoryzowany/schwytany/zastąpiony/nieudany/refundowany/nieważny”.
Rozrachunek: według rejestrów PSP (T + 1/T + 2).
Ograniczenia: dostępność według urządzenia/przeglądarki/geo; dla iGaming - polityka PSP/emitenta.

Wznów streszczenie

Google Pay to akcelerator płatności kartą o wysokiej konwersji mobilnej i wbudowanej SCA. Zintegruj się przez tryb bramkowy, spełnić wymagania dotyczące Request, zbudować wokół haków webowych + idempotence + recon i użyć COF do powtórzeń. Dla iGaming - utrzymać alternatywne szyny i inteligentne trasy, ponieważ dostępność i ograniczenia różnią się w zależności od jurysdykcji, banku i PSP.