Google Pay: داخل التطبيق والويب

1) ما هو Google Pay عبر الإنترنت

Google Pay (GPay) - طبقة من الدفع الآمن عبر قضبان البطاقات (Visa/Mastercard/إلخ) ، حيث يتم استبدال PAN برمز الجهاز/الشبكة (DPAN/رمز الشبكة)، ويتم توقيع المعاملة باستخدام مخطط تشفير EMV لمرة واحدة. المصادقة - القياسات الحيوية/قفل الشاشة + ربط الجهاز.
بالنسبة للتاجر، هذه في الأساس بطاقة دفع CNP مع زيادة التحويل وتقليل الاحتيال. النزاعات/الردود - وفقًا لقواعد البطاقة.

2) القنوات والسيناريوهات

2. 1 ويب

التكامل عبر Google Pay JS (PaymentDataRequest).
يعمل في المتصفحات الحديثة (أفضل UX هو Chrome/Android).
تأكيد في المتصفح/من خلال الجهاز المرتبط (الهاتف/الساعة) باستخدام القياسات الحيوية.

2. 2 In-App (Android)

Google Pay API for Android (ورقة أصلية).
تأكيد Link/App2App العميق في تطبيق GPay، عودة الحالة إلى تطبيقك.

2. 3 نقاط البيع (NFC)

سيناريو CP عن طريق HCE/SE ؛ خارج المقال عبر الإنترنت، تختلف قواعد رد التكاليف.

3) الترميز والأمن

ويصدر رمز شبكة DPAN/Network Token بواسطة خدمة رمز الشبكة ؛ لا يترك PAN الجهاز.
لكل دفعة، يتم تشكيل مخطط تشفير EMV (توقيع لمرة واحدة).
يتم إغلاق SCA بواسطة القياسات الحيوية/قفل الشاشة للجهاز (متوافق مع PSD2).
يتم فك تشفير رمز الدفع عند PSP/البوابة (وضع البوابة) أو عند التاجر مع الشهادات المناسبة (الوضع المباشر ؛ نادرا ما).

4) نموذج SCA/3DS والمخاطر

في EC/PSD2، غالبًا ما يتم تنفيذ SCA على مستوى Google Pay → قد لا يبدأ 3DS منفصل (يقرر البنك/PSP).
ويجوز للجهة المصدرة/الشبكة أن تطلب مزيدا من التحقق/الرفض للمعاملة (لا سيما بالنسبة للجنة التنسيق الإداري ذات المخاطر العالية).
الإخفاقات الانتقائية والحدود المخفضة ممكنة للقطاعات الحساسة.

5) معهد ماساتشوستس للتكنولوجيا/التكرار و COF

رمز Google Pay للمعاملة لمرة واحدة غير مؤهل لإعادة الخصم.

• الدفعة الأولى من خلال GPay → الحصول على موافقة لمعهد ماساتشوستس للتكنولوجيا → ترميز البطاقة في COF (Network Token/VTS/MDES) من PSP/المستحوذ.
• المزيد من عمليات الشطب مثل MIT مع رمز COF مع ترميز المعاملات الصحيح.
• بدون موافقة COF والبنك - مخاطر انخفاض/تحميل عالية.

6) خيارات الاتصال: البوابة مقابل المباشرة

البوابة (موصى بها): 'ترميز المواصفات. النوع = "PAYMENT_GATEWAY"' → PSP يفك تشفير الرمز ويقوم بالترخيص. بداية سريعة، امتثال أقل.
Direct: 'type = «DIRECT» → تاجر يفك تشفير رمز شبكة البطاقة بشكل مستقل. الحاجة إلى شهادات/مفاتيح وإلى أشد الضمانات صرامة ؛ نادرا ما تطبق.

• نوع "طرق الدفع المسموح بها" →: "بطاقة"، "معايير. سمحت طرق AuthMethods' ("PAN _ ONLY"، "CRYPTOGRAM _ 3Ds')،" CardNetworks'، "FillingAddressParameters'.
• «tokenizationSpecification» → «gateway» или «direct».
• «معلومات الجر» → المبلغ/العملة/المجموع PriceStatus.
• 'merchantInfo' → 'MerchantId '/' MerchantName'.

7) تدفقات التكامل

7. 1 ويب (خطوات)

1. → بدء تشغيل العميل GPay هو فحص ReadyToPay.
2. جمع PaymentDataRequest (مع الشبكات وطرق التوثيق والترميز).
3. عرض ورقة GPay → يؤكد المستخدم (SCA).
4. استلم الدفع MethodData (رمز التشفير) وأرسل إلى PSP.
5. Ответ PSP: «مرخص/نجح/فشل» + شبكة ويب.
6. '1' «التقاط/استرداد» حسب الحاجة ؛ recon - حسب السجلات اليومية.

7. 2 Android (داخل التطبيق)

وبالمثل، قم بإنشاء "PaymentsClient"، واجتياز "PayingDataRequest'، واحصل على رمز وتمريره إلى الخلف/PSP.

8) الأوضاع والمستوطنات والعائدين

الحالات عبر الإنترنت: «مصرح بها/ناجحة/فاشلة/ملغاة» (+ «معلقة» في بعض PSPs).
التسوية: بواسطة سجلات PSP/المشتري، عادةً T + 1/T + 2. النجاح المنفصل على الإنترنت والتسجيل المحاسبي.
استرداد: جزئي/كامل بقواعد البطاقة.
رد التكاليف: لا يزال إجراء البطاقة (INR/NAD، إلخ) ذا صلة.

9) أسباب الفشل المتكررة (الانخفاضات)

MCC/عمودي (iGaming/شبه-cache) - حظر انتقائي للمصدرين/PSP.
Mismatch geo (map country/IP/merchant site).
تكوين غير صحيح لـ «PaymentDataRequest' (الشبكات/طرق المصادقة)، غير صحيح» MerchantId' أو وضع الترميز.
MIT بدون COF/الموافقة.
SCA Timeouts/مقاطعة تدفق المستخدم.

10) أنماط UX (التي تعزز التحويل)

الهاتف المحمول أولاً: أخرج طريقة زر الدفع من Google على Android.
زر GPay كبير على بطاقة المنتج/السلة/الخروج ؛ اتبع دليل العلامة التجارية.
المبلغ/الضرائب/التسليم المسبق للورقة (المجموع المرئي للمستخدم).
التعافي: التكرار الآمن في المهلة، والتحول إلى cards/A2A عند تكرار الإخفاقات.
Desktop↔mobayl: QR/تسليم إذا أكد المستخدم على الهاتف.

11) التوجيه الذكي

قدم GPay على Android/Chrome و BINs/البنوك بسعر موافقة مرتفع.
استنساخ GPay تلقائيًا على BIN/geo معين عند تدهور المؤشرات.
للتكرار: الدفعة الأولى عبر GPay → COF، ثم معهد ماساتشوستس للتكنولوجيا دون تدخل المستخدم.

12) السلامة والامتثال

التحقق من صحة توقيعات رسائل PSP/خطافات الويب، URIs الصارمة «إعادة التوجيه/الإرجاع».
المفاتيح/الأسرار - في القبو، IP-allowist لنقاط نهاية الاتصال.
بصمة PCI ضئيلة في وضع البوابة (لا تلمس PAN/الأسرار).
السجلات: تلميحات الجهاز، رموز الأسباب، SCA/تأكيد الوقت.

13) iGaming: ميزات

يختلف التوافر والحدود حسب الولاية القضائية وشركة PSP والجهة المصدرة.
توقع حالات فشل انتقائية و/أو حدود مخفضة ؛ تحقق من القواعد المحلية.
عمليات الشطب المتكررة - فقط معهد ماساتشوستس للتكنولوجيا مع COF وموافقة اللاعب الموثق.
احتفظ بالبدائل: A2A/open-banking، محافظ محلية، eCash. أدخل احتياطيًا إذا كان الانخفاض مرتفعًا على GPay.

14) المصالحة والإبلاغ (recon)

تسجيل الدخول

'PaymentId/TransactionId'، 'OrderId'، الشبكة (Visa/MC/...)، BIN/Bank، المبلغ/العملة، رموز الحالة/الرفض، القناة (Web/In-App)، الطوابع الزمنية، AR/UTR من السجلات.

الاستطلاع التلقائي اليومي + الاستطلاع الكامل الدوري.
التنبيهات: «النجاح عبر الإنترنت بدون سجل»، «التقاط مزدوج»، «شيخوخة أوث».

15) KPI وإدارة الأساليب

معدل الموافقة GPay مقابل البطاقات العادية (حسب البنوك/BIN/geo/devices).
حصة GPay في حركة مرور Android، «إعادة تجربة معدل الفوز».
رفض المصفوفة (رموز السبب)، доля مهلة SCA.
معدل استرداد التكاليف/تسوية المنازعات بالاتصال الحاسوبي المباشر، وتأخر التسوية، доля المبالغ المستردة جزئيا.
قواعد عتبة الاشتقاق التلقائي (على سبيل المثال، الموافقة على <X٪ لشركة BIN/geo محددة).

16) قائمة المخرجات المرجعية

1. قم بتوصيل GPay في PSP ؛ احصل على merchantId، وتكوين مسموح بهPayingMethods/networks و tomenizationSpecification.
2. تنفيذ ورقة الويب/In-App، «الإذن/الالتقاط/الاسترداد»، الخطابات الشبكية (التوقيع/NMAS)، الخصوصية وإعادة التصوير.
3. قم بتكوين رمز COF/الشبكة لموافقة متجر MIT +.
4. تمكين التوجيه الذكي: أولوية GPay على Android، احتياطيًا على cards/A2A.
5. التحقق من أدلة العلامة التجارية (الأزرار/الأيقونات/حقوق النشر).
6. بناء recon والتنبيهات: خارج المزامنة، شيخوخة auth، التقاط مزدوج.
7. اختبارات E2E: Web/Android، التقاط/استرداد جزئي، مهلة/إعادة تشغيل، تحلل PSP، أحمال عالية.

بطاقة تاريخية

السكك الحديدية: بطاقة (Visa/MC/...) ؛ رد التكاليف - وفقًا لقواعد البطاقات.
SCA: القياسات الحيوية/قفل الشاشة (متوافقة مع PSD2) ؛ عادة لا تكون 3DS مطلوبة بشكل منفصل.
الرمز: DPAN + EMV cryptogram; بالنسبة للرمز المتكرر - COF/network.
Статусы: 'المأذون به/المقبوض عليه/الناجح/الفاشل/المسترد/الملغى'.
التسوية: بواسطة سجلات PSP (T + 1/T + 2).
القيود: التوافر حسب الجهاز/المتصفح/الجغرافيا ؛ لـ iGaming - سياسة PSP/المصدر.

ملخص السيرة الذاتية

Google Pay هو مسرع دفع بالبطاقات مع تحويل عالي للهاتف المحمول و SCA مدمج. تكامل عبر وضع البوابة، وتلبية متطلبات PaymentDataRequest، وبناء حول خطافات الويب + idempotency + recon، واستخدام COF للتكرار. بالنسبة إلى iGaming - احتفظ بقضبان بديلة وتوجيه ذكي حيث يختلف التوافر والحدود حسب الولاية القضائية والبنك و PSP.