Google Pay: Uygulama içi ve web

1) Google Pay çevrimiçi nedir

Google Pay (GPay) - kart rayları üzerinden güvenli ödeme katmanı (Visa/Mastercard/vb.) PAN'ın bir cihaz/ağ belirteci (DPAN/ağ belirteci) ile değiştirildiği ve işlemin bir kerelik EMV kriptogramı ile imzalandığı yer. Kimlik doğrulama - biyometri/ekran kilidi + cihaz bağlama.
Satıcı için, bu aslında artan dönüşüm ve daha az dolandırıcılık ile bir kart CNP ödemesidir. Anlaşmazlıklar/refandlar - kart kurallarına göre.

Bazı bölgelerde (örneğin, Hindistan), Google Pay ayrıca UPI niyetinin "başlatıcısı'olarak hareket eder. Bu makalede, çevrimiçi kart ödemelerine odaklanılmıştır (Web/In-App).

2) Kanallar ve senaryolar

2. 1 Web

Google Pay JS (PaymentDataRequest) ile entegrasyon.
Modern tarayıcılarda çalışır (en iyi UX Chrome/Android'dir).
Tarayıcıda/biyometrik ile ilişkili cihaz (telefon/saat) aracılığıyla onay.

2. 2 Uygulama İçi (Android)

Android için Google Pay API (yerel sayfa).
GPay uygulamasında derin Link/App2App onayı, durum uygulamanıza geri döner.

2. 3 POS (NFC)

HCE/SE aracılığıyla CP senaryosu; Çevrimiçi makalenin dışında, ters ibraz kuralları farklıdır.

3) Tokenizasyon ve güvenlik

DPAN/Network Token, ağ belirteci hizmeti tarafından verilir; PAN cihazı terk etmez.
Her ödeme için bir EMV kriptogramı (bir kerelik imza) oluşturulur.
SCA, cihazın biyometrik/ekran kilidi (PSD2 uyumlu) ile kapatılır.
Ödeme Belirteci, PSP/ağ geçidinde (ağ geçidi modu) veya uygun sertifikalara sahip satıcıda (doğrudan mod; Nadiren).

4) SCA/3DS modeli ve risk

EC/PSD2'da, SCA genellikle Google Pay düzeyinde gerçekleştirilir - ayrı bir 3DS başlamayabilir (banka/PSP karar verir).
İhraççı/ağ, işlemin ek olarak doğrulanmasını/reddedilmesini isteyebilir (özellikle yüksek riskli MCC için).
Seçici arızalar ve azaltılmış limitler hassas dikeyler için mümkündür.

5) MIT/nüks ve COF

Bir defaya mahsus işlem için Google Pay belirteci yeniden borçlandırma için uygun değildir.

• GPay aracılığıyla yapılan ilk ödeme - MIT için onay alın - kartı PSP/ediniciden COF (Network Token/VTS/MDES) olarak tokenize edin.
• Diğer yazılar, doğru işlem işaretlemesi ile bir COF belirteci olan MIT gibidir.
• COF ve banka onayı olmadan - yüksek düşüş/ters ibraz riskleri.

6) Bağlantı seçenekleri: gateway vs direct

Gateway (önerilen): 'tokenizationSpecification. Type = "PAYMENT_GATEWAY"' - PSP belirtecin şifresini çözer ve yetkilendirme yapar. Hızlı başlangıç, daha az uyum.
Direct: 'type = "DIRECT"' - tüccar bağımsız olarak kart ağ belirtecinin şifresini çözer. Sertifikalara/anahtarlara ve en katı güvenliğe ihtiyaç duyulması; nadiren uygulanır.

• 'allowedPaymentMethods' - 'type: "CARD"', 'parametreleri. AllowedAuthMethods '(' PAN _ ONLY ',' CRYPTOGRAM _ 3DS '),' allowedCardNetworks ',' billingAddressParameters '.
• 'tokenizationSpecification' - 'gateway' или 'direct'.
• 'tractionInfo' - miktar/para birimi/totalPriceStatus.
• 'merchantInfo' - 'merchantId'/' merchantName'.

7) Entegrasyon akışları

7. 1 Web (adımlar)

1. GPay client initialization - isReadyToPay check.
2. PaymentDataRequest'in toplanması (ağlar, kimlik doğrulama yöntemleri ve tokenization ile).
3. Ekran GPay Sayfası - kullanıcı onaylar (SCA).
4. PaymentMethodData (şifreleme belirteci) alın ve PSP'ye gönderin.
5. Ответ PSP: 'Yetkili/başarılı/başarısız' + webhook.
6. İhtiyaca göre 'yakalama/geri ödeme'; keşif - günlük kayıtlar tarafından.

7. 2 Android (uygulama içi)

Benzer şekilde, bir 'PaymentsClient' oluşturun, bir 'PaymentDataRequest' iletin, bir belirteç alın ve arka uç/PSP'ye iletin.

8) Durumlar, yerleşimler ve iadeler

Çevrimiçi durumlar: 'Yetkili/başarılı/başarısız/iptal edildi' (+ bazı PSP'lerde 'beklemede').
Çözüm: PSP/edinen kayıtlar tarafından, genellikle T + 1/T + 2. Ayrı online başarı ve muhasebe kayıt.
Geri ödeme: Kart kurallarına göre kısmi/tam.
Ters ibraz: kart prosedürü (INR/NAD, vb.) ilgili kalır.

9) Sık başarısızlık nedenleri (düşüşler)

MCC/vertical (iGaming/quasi-cache) - Yayıncılar/PSP için seçici engelleme.
Uyumsuz coğrafi (harita ülke/IP/tüccar konumu).
Yanlış 'PaymentDataRequest' yapılandırması (ağlar/kimlik doğrulama yöntemleri), yanlış 'merchantId' veya tokenization modu.
COF/rıza olmadan MIT.
SCA Zaman Aşımları/Kullanıcı Akışı Kesme.

10) UX kalıpları (dönüşümü artırır)

Mobil ilk: Android'de Google Pay düğmesini ilk yöntemi ortaya çıkarın.
Ürün kartı/sepet/ödeme üzerindeki büyük GPay düğmesi; Marka kılavuzunu takip edin.
Ön doldurma tutarı/vergiler/Sheet'e teslimat (kullanıcı tarafından görülebilir toplam).
Kurtarma: Zaman aşımlarında güvenli tekrarlama, tekrarlanan arızalarda cards/A2A geçiş.
Desktop↔mobayl: Kullanıcı telefonda onaylarsa QR/elden çıkarma.

11) Akıllı yönlendirme

GPay'i Android/Chrome'da ve BIN'ler/bankalar için yüksek bir onay oranıyla sunun.
Göstergeler bozulduğunda belirli BIN/geo üzerindeki GPay'in otomatik olarak azaltılması.
Tekrarlar için: ilk ödeme GPay üzerinden COF, daha sonra kullanıcı müdahalesi olmadan MIT.

12) Güvenlik ve uyumluluk

PSP mesaj imzalarının/web kancalarının doğrulanması, sıkı 'yönlendirme/iade' URI'leri.
Anahtarlar/sırlar - kasada, geri çağrı uç noktaları için IP-allowlist.
Ağ geçidi modunda PCI ayak izi minimumdur (PAN/sırlara dokunmazsınız).
Günlükler: cihaz ipuçları, sebep kodları, SCA/onaylama süresi.

13) iGaming: Özellikler

Kullanılabilirlik ve limitler yetki alanına, PSP'ye ve ihraççıya göre değişir.
Seçici arızalar ve/veya azaltılmış limitler beklemek; Yerel kuralları kontrol edin.
Tekrarlayan yazmalar - sadece COF'lu MIT ve belgelenmiş oyuncu onayları.
Alternatifleri saklayın: A2A/open-banking, yerel cüzdanlar, eCash. GPay'de düşüş yüksekse fallback girin.

14) Uzlaşma ve raporlama (keşif)

• 'PaymentId/transactionId', 'orderId', network (Visa/MC/...), BIN/bank, tutar/para birimi, durum/ret kodları, kanal (Web/In-App), zaman damgaları, kayıtlardan ARN/UTR.

Günlük otomatik keşif + periyodik tam keşif.
Uyarılar: "Kayıt defteri olmadan çevrimiçi başarı", "çift yakalama", "yaşlanan auth".

15) KPI ve yöntem yönetimi

Onay oranı GPay vs normal kartlar (bankalar/BIN/geo/cihazlar tarafından).
GPay'in Android trafiğindeki payı, 'kazanma oranını yeniden deneyin'.
Düşüş matrisi (sebep kodları) доля SCA zaman aşımları.
Ters ibraz oranı/ODR, uzlaşma gecikmesi доля kısmi geri ödemeler.
Otomatik türetme eşik kuralları (örneğin, belirli bir BIN/coğrafi için <% X'i onaylayın).

16) Çıktı kontrol listesi

1. PSP'de GPay'i bağlayın; merchantId alın, allowedPaymentMethods/networks ve tokenizationSpecification'ı yapılandırın.
2. Web/Uygulama İçi Sayfa, 'yetkilendirme/yakalama/geri ödeme', webhooks (imza/NMAS), idempotency ve retrays uygulayın.
3. MIT + mağaza onayı için COF/ağ tokenizasyonunu yapılandırın.
4. Akıllı yönlendirmeyi etkinleştirin: Android'de GPay önceliği, cards/A2A'da geri dönüş.
5. Marka kılavuzlarını denetleme (düğmeler/simgeler/telif hakları).
6. Keşif ve uyarılar oluşturun: senkronizasyon dışı, yaşlanan auth, çift yakalama.
7. E2E testleri: Web/Android, kısmi yakalama/geri ödeme, zaman aşımları/tekrarlar, PSP bozulması, yüksek yükler.

Landmark kartı

Demiryolu: kart (Visa/MC/...); Ters ibraz - kart kurallarına göre.
SCA: Biyometri/ekran kilidi (PSD2 uyumlu); 3DS genellikle ayrı olarak gerekli değildir.
Tokenization: DPAN + EMV kriptogramı; Tekrarlayan için - COF/ağ belirteci.
Статусы: 'yetkilendirilmiş/yakalanmış/başarılı/başarısız/iade edilmiş/geçersiz'.
Çözüm: PSP kayıtları tarafından (T + 1/T + 2).
Sınırlamalar: Cihaz/tarayıcı/coğrafi olarak kullanılabilirlik; IGaming için - PSP/veren politikası.

Özgeçmiş Özeti

Google Pay, yüksek mobil dönüşüm ve yerleşik SCA'ya sahip bir kartlı ödeme hızlandırıcısıdır. Ağ geçidi modu ile entegre edin, PaymentDataRequest gereksinimlerini karşılayın, webhooks + idempotency + recon etrafında oluşturun ve yinelemeler için COF kullanın. IGaming için - kullanılabilirlik ve limitler yetki alanına, bankaya ve PSP'ye göre değiştiği için alternatif raylar ve akıllı yönlendirme bulundurun.