Google Pay: app და ვებ

1) რა არის Google Pay ონლაინ რეჟიმში

Google Pay (GPay) არის უსაფრთხო გადახდის ფენა ბარათის რელსების თავზე (Visa/Mastercard/და სხვ.), სადაც PAN იცვლება მოწყობილობის/ქსელის (DPAN/ქსელის ტოკენის) ნიშნით, ხოლო გარიგება გაფორმებულია ერთჯერადი EMV კრიპტეგიდით. ავთენტიფიკაცია - ბიომეტრია/screen-lock + binding.
მერჩანტისთვის, ეს არსებითად CNP ბარათის გადახდაა გაზრდილი კონვერტით და უფრო მცირე წინდახედვით. დებატები/რეფანდები - ბარათის წესების შესაბამისად.

2) არხები და სცენარები

2. 1 Web

ინტეგრაცია Google Pay JS- ის საშუალებით (Payship DataRequest).
მუშაობს თანამედროვე ბრაუზერებში (საუკეთესო 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/ქსელის ტოკენი გაიცემა ქსელის ნიშნის სერვისით; PAN არ ტოვებს მოწყობილობას.
თითოეული გადახდისთვის იქმნება EMV კრიპტოგრამი (ერთჯერადი ხელმოწერა).
SCA ხურავს მოწყობილობის ბიომეტრიულ/სკრინ-ლოკს (PSD2 თავსებადია).
Payment Token გაშიფრულია PSP/gateway (gateway-mode) ან merchant- ში, შესაბამისი სერტიფიკატების თანდასწრებით (პირდაპირი რეჟიმი; იშვიათად).

4) SCA/3DS მოდელი და რისკი

EC/PSD2 SCA- ში ხშირად მზადდება Google Pay- ის დონეზე, ცალკეული 3DS შეიძლება არ ამოქმედდეს (ბანკი/PSP გადაწყვეტს).
ემიტენტ/ქსელს შეუძლია მოითხოვოს დოპინგის შემოწმება/უარი თქვას გარიგებაზე (განსაკუთრებით მაღალი დონის MCC).
მგრძნობიარე ვერტიკალებისთვის შესაძლებელია შერჩევითი წარუმატებლობები და შემცირებული ლიმიტები.

5) MIT/რეკურენტი და COF

Google Pay- ის ნიშანი ერთჯერადი გარიგებისთვის არ არის შესაფერისი ხელახლა ჩამოწერისთვის.

• პირველი გადახდა GPay- ს საშუალებით შეგიძლიათ მიიღოთ თანხმობა MIT- სთან დაკავშირებით - ბარათის ტოკნიზირება COF (ქსელის ტოკენი/VTS/MDES) PSP/შეძენისთვის.
• შემდგომი გაუქმება ჰგავს MIT- ს COF ნიშნით გარიგების სწორად აღნიშვნას.
• COF- ის და ბანკის თანხმობის გარეშე - მაღალი decline/chargeback რისკები.

6) დაკავშირების პარამეტრები: gateway vs პირდაპირი

Gateway (რეკომენდებულია): 'tokenization Specification. ტიპი = „PAYMENT _ GATEWAY“ 'PSP გაშიფრავს ნიშანს და ატარებს ავტორიზაციას. სწრაფი დასაწყისი, ნაკლები შესაბამისობა.
პირდაპირი: 'ტიპი = „DIRECT“' ბარძაყის ტარება დამოუკიდებლად ახდენს ბარათის ქსელის ნიშნის გაშიფვრას. ჩვენ გვჭირდება სერთიფიკატები/გასაღებები და მკაცრი უსაფრთხოება; იშვიათად გამოიყენება.

• `allowedPaymentMethods` → `type: "CARD"`, `parameters. allowedAuthMethods` (`PAN_ONLY`, `CRYPTOGRAM_3DS`), `allowedCardNetworks`, `billingAddressParameters`.
• `tokenizationSpecification` → `gateway` или `direct`.
• 'transaction Info' - თანხა/ვალუტა/totalPriceStatus.
• `merchantInfo` → `merchantId`/`merchantName`.

7) ინტეგრაციის ნაკადები

7. 1 ვებ (ნაბიჯები)

1. GPay კლიენტის ინიციალიზაცია არის isReadyToPay შემოწმება.
2. PaysyRataRequest- ის შეგროვება (ქსელებით, ავთენტიფიკაციის მეთოდებით და ტოკენიზაციით).
3. GPay Sheet რუქა მომხმარებელი ადასტურებს (SCA).
4. MethodData (შიფროტოკენის) მიღება და PSP- ში გაგზავნა.
5. Ответ PSP: `authorized/succeeded/failed` + webhook.
6. 'capture/refund' მოთხოვნილების შესაბამისად; ჩანაწერები - ყოველდღიური რეესტრების მიხედვით.

7. 2 Android (in-app)

ანალოგიურად: შექმენით 'PaymenClient', გადასცემთ 'Paysible DataRequest' - ს, მიიღებთ ნიშანს და გადასცემთ მას უკანა პლანზე/PSP.

8) სტატუსები, გამოთვლები და ანაზღაურება

ონლაინ სტატუსები: 'authorized/succeeded/failed/canceled' (+ 'pending' ზოგიერთი PSP).
Settlement: PSP/Exwayer რესტავრაციისთვის, ჩვეულებრივ T + 1/T + 2. გაიზიარეთ ონლაინ წარმატება და ბუღალტრული აღრიცხვა.
Refund: ნაწილობრივი/სრული ბარათის წესების შესაბამისად.
Chargeback: ბარათის პროცედურა (INR/NAD და სხვ.) აქტუალური რჩება.

9) უარყოფის ხშირი მიზეზები (declines)

MSS/ვერტიკალური (iGaming/კვაზი ქეში) - შერჩევითი ბლოკირება ემიტენტებში/PSP.
Mismatch geo (ბარათის ქვეყანა/IP/მერჩანტის ადგილმდებარეობა).
არასწორი კონფიგურაცია 'PaysaDataRequest' (ქსელი/ავტორიზაციის მეთოდები), არასწორი 'merchantId' ან ტოკენიზაციის რეჟიმი.
MIT COF/consent გარეშე.
Taimauts SCA/მომხმარებლის flow შეწყვეტა.

10) UX ნიმუშები (რაც ზრდის კონვერტაციას)

მობილური პირველი: მიიღეთ Google Pay ღილაკი პირველი მეთოდით Android- ზე.
დიდი GPay ღილაკი საქონლის ბარათზე/კალათა/checkout; დაიცავით ბრენდის ჰაიდი.
Pre-fill თანხები/გადასახადები/მიწოდება Sheet- ში.
ჩანართი: უსაფრთხო გამეორება ტაიმუთში, გადართვა ბარათებზე/A2A განმეორებით გადახდაზე.
Desctop - მობილური: QR/hand-off, თუ მომხმარებელი დაადასტურებს ტელეფონით.

11) ჭკვიანი მარშრუტი

შესთავაზეთ GPay Android/Chrome და BIN/ბანკებისთვის მაღალი approve ფრენისთვის.
GPay ავტომობილების რეალიზაცია კონკრეტულ BIN/geo- ზე ინდიკატორების დეგრადაციის დროს.
რეკურსორებისთვის: პირველი გადახდა GPay - COF- ით, შემდეგ MIT მომხმარებლის მონაწილეობის გარეშე.

12) უსაფრთხოება და შესაბამისობა

შეტყობინებების ხელმოწერების/PSP ვებ - ჰუკების შესაბამისობა, მკაცრი 'redirect/return' URI.
გასაღებები/საიდუმლოებები - vault, IP-allowlist callback endpoints.
PCI ბილიკი მინიმალურია gateway რეჟიმში (თქვენ არ შეეხოთ PAN/საიდუმლოებებს).
Logs: მოწყობილობები, reason codes, SCA/confirm დრო.

13) iGaming: მახასიათებლები

ხელმისაწვდომობა და ლიმიტები დამოკიდებულია იურისდიქციაზე, PSP და ემიტენტზე.
დაელოდეთ შერჩევით წარუმატებლობას ან/და შემცირებულ ლიმიტებს; შეამოწმეთ ადგილობრივი წესები.
განმეორებითი ჩამოწერები - მხოლოდ MIT COF- ით და მოთამაშის დოკუმენტირებული თანხმობებით.
შეინარჩუნეთ ალტერნატივა: A2A/Open-banking, ადგილობრივი საფულეები, eCash. შეიყვანეთ fallback მაღალი decline GPay- ზე.

14) კრეკი და მოხსენება (ჩანაწერები)

• 'payhoud Id/transaction Id', 'orderid', ქსელი (Visa/MC/...), BIN/Bank, თანხა/ვალუტა, უარის თქმის სტატუსი/კოდი, არხი (Web/In-App), Timemestamps, amps, amps.

Daily auto-recon + პერიოდული full-recon.
ალერტები: „ონლაინ წარმატება რეესტრის გარეშე“, „ორმაგი სათაური“, „აგინგ აუტი“.

15) KPI და მეთოდის მართვა

Approval rate GPay vs ჩვეულებრივი ბარათებია (ბანკებისთვის/BIN/geo/მოწყობილობებისთვის).
GPay Share in Android ტრაფიკი, 'retry win-rate'.
Decline matrix (reason codes), доля SCA timeouts.
Chargeback rate/ODR, settlement lag, доля partial refunds.
მანქანის დარეგულირების ბარიერი წესები (მაგალითად, კონკრეტული BIN/geo approve <X%).

16) Check Life Prode

1. დაუკავშირდით GPay PSP- ს; მიიღეთ merchantID პარამეტრი allowedPaystray Methods/ქსელები და tokenizationSpecification.
2. გააცნობიერეთ Web/In-App Sheet, 'authorize/capture/refund', webhooks (ხელმოწერა/NMAS), imempotence და ratrai.
3. კონფიგურაცია COF/ქსელის ტოკენიზაციისთვის MIT + შეინახეთ consent.
4. ჩართეთ smart-routing: GPay პრიორიტეტი Android, fallback ბარათებზე/A2A.
5. ბრენდის ჰაიდების შემოწმება (ღილაკები/ხატები/საავტორო უფლებები).
6. ააშენეთ ჩანაწერები და ალერტები: რასინქრონები, აგინგ აუტი, ორმაგი კაპიტალი.
7. E2E ტესტები: Web/Android, partial capture/refund, tymauts/გამეორება, PSP დეგრადაცია, მაღალი დატვირთვა.

სახელმძღვანელო ბარათი

სარკინიგზო: ბარათი (Visa/MC/...); chargeback - ბარათების წესების შესაბამისად.
SCA: ბიომეტრია/სკრინ-ლოკი (PSD2 თავსებადი); 3DS ჩვეულებრივ ცალკე არ არის საჭირო.
ტოკენიზაცია: DPAN + EMV კრიპტოგრამი; რეკურენტისთვის - COF/ქსელის ტოკენი.
Статусы: `authorized/captured/succeeded/failed/refunded/voided`.
Settlement: PSP რეესტრებზე (T + 1/T + 2).
შეზღუდვები: მოწყობილობების/ბრაუზერების/გეოს ხელმისაწვდომობა; iGaming- ისთვის - PSP/ემიტენტის პოლიტიკა.

რეზიუმე

Google Pay არის ბარათების გადახდების „ამაჩქარებელი“ მაღალი მობილური კონვერტით და ჩაშენებული SCA. ინტეგრირება gateway რეჟიმში, დაიცავით მოთხოვნები PaystaDataRequest- ისთვის, ააშენეთ webhooks + idempotence + recon გარშემო და გამოიყენეთ COF რეკურენტებისთვის. iGaming- ისთვის - შეინახეთ ალტერნატიული რელსები და ჭკვიანი მარშრუტიზაცია, რადგან წვდომა და შეზღუდვები დამოკიდებულია იურისდიქციაზე, ბანკსა და PSP- ზე.