Google Pay: în aplicație și web

1) Ce este Google Pay online

Google Pay (GPay) - un strat de plată sigură peste șine cu cardul (Visa/Mastercard/etc.) , în cazul în care PAN este înlocuit cu un dispozitiv/token de rețea (DPAN/token de rețea), iar tranzacția este semnată cu o criptogramă EMV unică. Autentificare - biometrie/blocare ecran + dispozitiv de legare.
Pentru comerciant, aceasta este, în esență, o plată CNP cu card cu conversie sporită și mai puțină fraudă. Litigii/restituiri - conform regulilor cardului.

2) Canale și scenarii

2. 1 Web

Integrarea prin Google Pay JS (PaymentDataRequest).
Funcționează în browsere moderne (cel mai bun UX este Chrome/Android).
Confirmarea în browser/prin dispozitivul asociat (telefon/ceas) cu date biometrice.

2. 2 În-App (Android)

Google Pay API pentru Android (foaie nativă).
Confirmarea Link/App2App profunde în aplicația GPay, revenirea stării în aplicația dvs.

2. 3 POS (NFC)

Scenariul PC prin HCE/SE; în afara articolului online, regulile de chargeback sunt diferite.

3) Tokenizare și securitate

DPAN/Network Token este emis de serviciul token de rețea; PAN-ul nu părăsește dispozitivul.
Pentru fiecare plată, se formează o criptogramă EMV (semnătură unică).
SCA este închis prin biometrie/ecran de blocare a dispozitivului (PSD2-compatibil).
Plata Token este decriptată la PSP/gateway (modul gateway) sau la comerciant cu certificatele corespunzătoare (modul direct; rareori).

4) modelul SCA/3DS și riscul

În EC/PSD2, SCA este adesea efectuat la nivelul Google Pay → un 3DS separat nu poate începe (bank/PSP decide).
Emitentul/rețeaua poate solicita verificarea/respingerea suplimentară a tranzacției (în special pentru MCC cu risc ridicat).
Eșecurile selective și limitele reduse sunt posibile pentru verticalele sensibile.

5) MIT/recurență și COF

Google Pay token pentru tranzacție unică nu este eligibil pentru re-debitare.

• Prima plată prin GPay → obține consimțământul pentru MIT pentru → tokeniza cardul în COF (Network Token/VTS/MDES) de la PSP/achizitor.
• Alte write-off-uri sunt ca MIT cu un jeton COF cu marcajul tranzacției corecte.
• Fără COF și consimțământul băncii - riscuri ridicate de declin/chargeback.

6) Opțiuni de conectivitate: gateway vs direct

Gateway (recomandat): 'tokenizationCaietul de sarcini. tip = "PAYMENT_GATEWAY"' → PSP decriptează tokenul și efectuează autorizația. Pornire rapidă, mai puţină conformitate.
Direct: 'type =' DIRECT '' → comerciant decriptează independent tokenul rețelei de carduri. Aveți nevoie de certificate/chei și de cea mai strictă securitate; rar aplicate.

• 'allowedPaymentMethods' →' tip: "CARD', 'parametri. allowedAuthMethods' ('PAN _ ONLY', 'CRYPTOGRAM _ 3DS'),' allowedCardNetworks', 'billingAddressParametrii'.
• „tokenizationCaietul de sarcini” → „gateway” или „direct”.
• 'tractionInfo' → suma/moneda/totalPriceStatus.
• "merchantInfo" → "comerciantId'/" comerciantName".

7) Fluxurile de integrare

7. 1 Web (paşi)

1. → de inițializare a clientului GPay este verificarea ReadyToPay.
2. Colectarea PaymentDataRequest (cu rețele, metode de autentificare și tokenizare).
3. Display GPay Sheet → utilizator confirmă (SCA).
4. Primiți plățiMetodăDate (cifru token) și trimiteți la PSP.
5. Ответ PSP: 'autorizat/reușit/eșuat' + webhook.
6. „Captură/restituire” în funcție de necesitate; recunoaștere - prin registre zilnice.

7. 2 Android (în aplicație)

În mod similar, creați un 'PaymentsClient', treceți un 'PaymentDataRequest', obțineți un token și treceți-l la backend/PSP.

8) Statusuri, așezări și returnări

Statusuri online: „autorizat/reușit/eșuat/anulat” (+ „în așteptare” în unele PSP-uri).
Decontare: prin registre PSP/achizitor, de obicei T + 1/T + 2. Succesul online separat și înregistrarea contabilă.
Rambursare: parțială/completă după regulile cardului.
Chargeback: procedura cardului (INR/NAD etc.) rămâne relevantă.

9) Cauze frecvente de eșec (scăderi)

MCC/vertical (iGaming/cvasi-cache) - blocare selectivă pentru emitenți/PSP.
Nepotrivire geo (țară hartă/IP/locație comercială).
Configurație incorectă 'PaymentDataRequest' (rețele/metode de autentificare), mod incorect' merchantId' sau tokenization.
MIT fără COF/consimțământ.
SCA Timeouts/User Flow Întrerupe.

10) Modele UX (care stimulează conversia)

Mobile-first: scoate butonul Google Pay prima metodă pe Android.
Buton GPay mare pe cardul de produs/coș/checkout; urmați ghidul mărcii.
Înainte de a umple suma/taxele/livrarea în foaie (total vizibil pentru utilizator).
Recuperare: repetarea în condiții de siguranță la timeout, trecerea la cards/A2A la eșecuri repetate.
Desktop↔mobayl: QR/hand-off dacă utilizatorul confirmă la telefon.

11) Rutare inteligentă

Oferta GPay pe Android/Chrome și pentru BIN-uri/bănci cu o rată mare de aprobare.
Auto-deratarea GPay pe anumite BIN/geo atunci când indicatorii sunt degradate.
Pentru recurenți: prima plată prin GPay → COF, apoi MIT fără intervenția utilizatorului.

12) Siguranță și conformitate

Validarea semnăturilor mesajelor PSP/cârlige web, URI stricte de redirecționare/returnare.
Chei/secrete - în seif, IP-allowlist pentru callback-endpoints.
Amprenta PCI este minimă în modul gateway (nu atingeți PAN/secrete).
Jurnale: indicii dispozitiv, coduri motiv, SCA/confirma timp.

13) iGaming: Caracteristici

Disponibilitatea și limitele variază în funcție de jurisdicție, PSP și emitent.
Așteptați eșecuri selective și/sau limite reduse; verificați regulile locale.
Write-off-uri recurente - numai MIT cu COF și consimțământul jucătorului documentat.
Păstrați alternative: A2A/open-banking, portofele locale, eCash. Introduceți rezervă dacă declinul este ridicat pe GPay.

14) Reconciliere și raportare (reconciliere)

• 'paymentId/transactionId',' orderId', network (Visa/MC/...), BIN/bank, cuantum/valută, status/refuz coduri, canal (Web/In-App), marcaje temporale, ARN/UTR din registre.

Auto-recunoaștere zilnică + recunoaștere completă periodică.
Alerte: „succes online fără registru”, „dublă captură”, „îmbătrânire auth”.

15) KPI și managementul metodei

Rata de aprobare GPay vs carduri regulate (de către bănci/BIN/geo/dispozitive).
Cota de GPay în traficul Android, „încercați din nou rata de câștig”.
Declin matrice (coduri motiv), доля SCA timeout.
Rata de chargeback/SOL, decontare decontare, доля restituiri parțiale.
Reguli de prag derivate automat (de exemplu, aproba <X% pentru un anumit BIN/geo).

16) Lista de verificare de ieșire

1. Conectați GPay la PSP; get merchantId, configure allowedPaymentMethods/networks and tokenizationCaietul de sarcini.
2. Implementați Web/In-App Sheet, 'autorizare/captură/rambursare', webhooks (semnătură/NMAS), idempotency și retrays.
3. Configurați tokenizarea COF/rețea pentru consimțământul magazinului MIT +.
4. Activați rutarea inteligentă: prioritate GPay pe Android, rezervă pe cards/A2A.
5. Verificarea ghidurilor de brand (butoane/icoane/drepturi de autor).
6. Construiți recunoaștere și alerte: din sincronizare, îmbătrânire auth, captură dublă.
7. Teste E2E: Web/Android, captură parțială/rambursare, timeout/reluări, degradare PSP, sarcini mari.

Carte de reper

Feroviar: card (Visa/MC/...); chargeback - în conformitate cu regulile de carduri.
SCA: biometrie/ecran de blocare (PSD2-compatibil); 3DS nu este de obicei necesar separat.
Tokenizare: criptogramă DPAN + EMV; pentru tokenul recurent - COF/rețea.
Статусы: „autorizat/capturat/reusit/esuat/rambursat/anulat”.
Decontare: pe registre PSP (T + 1/T + 2).
Limitări: disponibilitate după dispozitiv/browser/geo; pentru iGaming - politica PSP/emitent.

Rezumat reluare

Google Pay este un accelerator de plată cu cardul cu conversie mobilă ridicată și SCA încorporat. Integrați-vă prin modul gateway, îndepliniți cerințele PaymentDataRequest, construiți în jurul cărților web + idempotency + recon și utilizați COF pentru recurenți. Pentru iGaming - păstrați șine alternative și rutare inteligentă, deoarece disponibilitatea și limitele variază în funcție de jurisdicție, bancă și PSP.