نظرة عامة

يتم تحديدها لاحقًا: أضِف وصفًا موجزًا للمحفظة الإلكترونية (كما هو الحال مع النقود الإلكترونية)

يتم تحديدها لاحقًا: يمكنك الاطّلاع على عرض توضيحي لتدفق المحفظة الإلكترونية بعد إعداد FoP في كيانات Google.

في ما يلي شرح لخطوات رئيسية في خدمة "دفعات Google العادية" المرتبطة بمعاملة المحفظة الإلكترونية.

مسار عملية الربط

تتيح خدمة Google Standard Payments للشركات المتعهّدة إنشاء طريقة لإنشاء أداة وعملية شراء بهدف توفير تجربة دفع سريعة وسلسة للمستخدمين.

يمتلك عميل Google أداة واحدة أو أكثر. الأداة هي طريقة للدفع مقابل الخدمات والسلع داخل النظم البيئية والأسواق المختلفة لشركة Google. لإضافة أداة، يجب على المستخدم ربط أداة ببيانات اعتماد خارجية ومصادقة بيانات الاعتماد هذه. وخير مثال على ذلك هو بطاقة الائتمان. تتضمن بطاقة الائتمان رقم بطاقة (PAN) تخزنه Google ورقم التحقق من البطاقة (CVN) الذي يتم استخدامه للمصادقة. ويضيف المستخدم أداة عن طريق إدخال رقم PAN ورقم CVN في واجهة مستخدم Google. وتخزّن Google رقم PAN بشكل آمن بعد أن يتحقق معالج بطاقة الائتمان من رقمَي PAN وCVN. وبالمثل في هذه المواصفات، سنربط مستند إثبات المصادقة بأداة من جانب Google. ونسمي ربط الحساب بأداة تدفق الارتباط.

نتيجة عملية الربط هي عملية تبادل الرمز المميّز للدفع من Google (GPT) المُتفق عليه بين Google والشركة المتعهّدة. وأثناء الالتقاط، يتم تمرير علامة GPT إلى وحدة تكامل عمليات الدفع (التي تمتلك حساب المستخدم) لتحديد حساب المستخدم المطلوب إصدار فواتيره.

هناك العديد من الطرق لمصادقة مستخدم لإثبات ملكية حساب. تعتبر أسماء المستخدمين وكلمات المرور طريقة واحدة، ولكن استخدام كلمات المرور لمرة واحدة (OTP) ومعلومات المقاييس الحيوية وأسئلة الأمان جميعها حلول قابلة للتطبيق أيضًا. لا تميل Google إلى إملاء كيفية تحقق الشركة لتكامل الدفع من المستخدم. نعتقد أنّ جهة تكامل الدفعات تفعل ذلك بالطريقة الأفضل. ولذلك، كجزء من هذه المواصفات، تريد Google الاستفادة من واجهات المستخدم المتعددة الخاصة بالجهة المسؤولة عن عملية تكامل الدفع من أجل مصادقة المستخدم وتزويد Google بدليل على المصادقة. نسمي هذا تدفق المصادقة.

ويكون نتيجة مسار المصادقة إثباتًا للمصادقة.

لإكمال عملية الربط، يجب أن تقدّم Google مستندًا لإثبات المصادقة من خلال عملية دمج الدفعات. قبل مسار الربط، تستدعي Google مسار المصادقة للحصول على هذا الدليل.

يوضح المثال أدناه الخطوات التي سيجريها المستخدم لتدفق المصادقة وتدفق الربط. يرشدك المثال أدناه عبر محفظة إلكترونية مزيّفة تسمى InvisiCash.

مسار الربط

ملاحظات في هذا الرسم البياني:

  • في الخطوتَين 1 و3، نشير إلى أنّ هوية المستخدم (البريد الإلكتروني) تختلف بين Google وInvisiCash. sf@gmail.com وsally@otheremail.com على التوالي. هذا جيد ومتوقع.
  • بين الخطوتين 3 و4، يمكن لتطبيق InvisiCash (أو واجهة مستخدم الويب في حال عدم تثبيت المستخدم التطبيق) تنفيذ كل ما هو ضروري لمصادقة المستخدم، بما في ذلك التحدث إلى خادم InvisiCash.

مسار الشراء

وبعد اكتمال عملية الربط والحصول على أداة جديدة، يمكن للمستخدم استخدام هذه الأداة لشراء السلع والخدمات من خلال Google. عند الشراء، قد يكون المستخدم في جلسة أو لا يكون كذلك. يتوقف كل ذلك على سياق الشراء. على سبيل المثال، في عملية شراء مستندة إلى اشتراك، لن يكون المستخدم على الأرجح في الجلسة. في وقت الشراء، ستعرض Google علامة GPT على وحدة تكامل الدفع. ستستخدم جهة تكامل الدفعات علامة GPT هذه لتحديد الحساب الصحيح الذي تريد سحبه. وهذا ما يسمى بتدفق الشراء.

يستمر المثال أدناه بعد إجراء المستخدم sf@gmail.com للربط وإنشاء الأداة. المستخدم يريد الآن شراء السلع.

تدفق الشراء البسيط

في بعض الأحيان، قد تطلب كل من شركة تكامل الدفع أو Google مصادقة المستخدم قبل إجراء عملية شراء. وهناك أسباب مختلفة لذلك. على سبيل المثال:

  • يتأكّد محرّك المخاطر في Google من أنّ عملية الدفع تبدو مريبة
  • تتطلب المتطلبات التنظيمية الحصول على كلمة مرور لمرة واحدة عند كل عملية شراء

في هذه الحالات، ستقرن Google مسار المصادقة بمسار الشراء. سيتمّ إرسال المستخدم إلى واجهة المستخدِم في عملية الدمج للمصادقة. تعد نتيجة مسار المصادقة إثباتًا لهوية المستخدم والمصادقة. يتم بعد ذلك إرسال هذا الإثبات مع معلومات الشراء أثناء مسار الشراء.

في المثال أدناه، أجرى المستخدم sf@gmail.com عملية الربط وتم إنشاء أداة. أثناء مسار الشراء، يسعى خادم Google إلى مطالبة المستخدم بالحماية من الاحتيال:

تدفق عمليات الشراء التي يواجهها المستخدم

إعادة تحميل مسار الرمز المميّز

خلال عملية الربط، يمكن للجهة المتعهّدة للدفع إعلام Google بأنّ صلاحية GPT هذه ستنتهي صلاحيتها بعد X شهر. على الرغم من أن Google تفضل الرموز المميزة التي لا تنتهي صلاحيتها، فإنّها تقرّ بأنّه لا يمكن أن تكون هذه هي الحال دائمًا، وبالتالي تتيح انتهاء صلاحية الرمز المميّز. في الحالات التي يوشك فيها الرمز المميّز على الانتهاء، ترسل Google المستخدم إلى المستخدم خلال خطوات المصادقة. سيتم إرسال المستخدم إلى واجهة المستخدم في عملية الدمج للمصادقة. تعد نتيجة مسار المصادقة إثباتًا لهوية المستخدم ومصادقته. ويتم بعد ذلك إرسال هذا الإثبات إلى الشركة المتعهّدة لتمديد وقت انتهاء صلاحية علامة GPT. ويُطلَق على ذلك مسار إعادة التحميل رمز التحديث.

يستمر المثال أدناه بعد إجراء المستخدم sf@gmail.com للربط وإنشاء الأداة. ستنتهي صلاحية الرمز المميز للمستخدم قريبًا، لذلك تطلب Google من المستخدم تحديث الأداة:

إعادة تحميل مسار الرمز المميّز

وتُستخدم عملية المصادقة في طريقتين مختلفتين. الأولى هي أثناء محاولة مصادقة المستخدم خلال وقت الربط. في هذا الوقت هوية المستخدم غير معروفة، والأمر متروك للمستخدم لإدخالها. قد تبدو الهوية اسم مستخدم أو عنوان بريد إلكتروني أو رقم هاتف. وتتمثل الطريقة الثانية في محاولة مصادقة أن يعرف المستخدم بيانات الاعتماد الخاصة بأداة موجودة. في هذه الحالة، يكون المستخدم قد أضاف الوسيلة وربط حساب الشركة المسؤولة عن عملية الدفع. في هذه الطريقة نريد التحقق من أن الشخص لديه بيانات اعتماد لهوية مستخدم معينة. ويجب ألا يتمكن المستخدم من تغيير هوية الحساب الذي يتم التحقق منه. ولإجراء ذلك، نرسل إلى إتمام عملية دمج الدفعات رقم تعريف المؤسسة في وقت المؤسسة. وعند إجراء عملية المصادقة، ترسل Google رقم تعريف الارتباط نفسه إلى الشركة المتعهّدة. تستخدم الجهة المتعهّدة رقم تعريف الارتباط للبحث عن الحساب الذي يجب مصادقته.

تدفق الحوالات المالية

Google هي نظام محاسبة السجل ومسؤولية تحويلات الحوالات المالية. وترسل Google يوميًا بيان حوالة مالية إلى الجهة المتعهّدة للدفعات. يقدم كشف الحساب ملخصًا للمبلغ الذي تدين به شركة تكامل الدفعات إلى Google مع تعليمات حول كيفية الدفع إلى Google. لكي تتمكّن شركة تكامل الدفع من تسوية، يمكن لها الاستعلام عن تفاصيل مستوى المعاملة التي يتألف منها كشف التحويل من Google.

في ما يلي مثال على الخطوات التي يجب اتّباعها: تدفق الحوالات المالية