دفعات Google العادية:

طريقة الدفع المحوَّلة إلى رمز مميّز

نظرة عامة

طريقة الدفع المرمَّزة على رمز مميّز هي أحد أنواع دمج الدفع في "منصة الدفعات". ليتمكّن المستخدم من الدفع باستخدام "طريقة الدفع" هذه، على "Google" والشركة المسؤولة عن عملية تكامل الدفع إجراء عملية تبادل بيانات اعتماد هوية الحساب لمرة واحدة. وهذا بدوره يؤدي إلى إنشاء رمز مميز، يمثل طريقة الدفع تلك للمستخدم بعينه. ويمكن بعد ذلك استخدام هذا الرمز المميّز للدفع مرارًا وتكرارًا. هناك حاليًا إصداران من واجهات برمجة التطبيقات هذه. يتوافق الإصدار 2 مع مشغّلي شبكات الجوّال ومزوّدي الأرقام المرجعية. ويجب على جميع موفري خدمات الدفع بالرمز المميز الآخرين تنفيذ الإصدار 1. يركز باقي هذا المستند على الإصدار 1.

تستخدم Google مسارين لتحديد الهوية وإنشاء هذا الرمز المميّز:

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

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

أخيرًا، تتم جميع عمليات نقل الأموال بين مصرف الجهة المدمَجة ومصرف Google خلال مسار الحوالة المالية.

1) يختار المستخدم منتجًا لشرائه.

2) اختيار طريقة دفع بعد ذلك

3) أضاف الآن طريقة دفع جديدة.

4) تتم إعادة توجيه المستخدمين للمصادقة.

5) وأخيرًا، تمت المصادقة عليهم ويمكنهم إجراء عمليات شراء.

يوضح هذا الرسم البياني نظرة عامة واسعة على التدفقات:

نظرة عامة على طرق الدفع المحوَّلة إلى رموز مميّزة

على مستوى عالٍ، تشتمل عملية إضافة خدمتك كطريقة دفع إلى منتجات Google على الخطوات التالية:

1. خطوات المصادقة
2. مسار الربط
3. مسار الشراء
4. خطوات ردّ الأموال
5. تدفق الحوالة المالية

يتم وصف هذه المسارات بمزيد من التفصيل في الأقسام أدناه، وبمزيد من التفصيل في قسم الأدلّة.

المفاهيم والمصطلحات

رموز مؤتمرات

يمكن استخدام الكلمات الرئيسية "يجب" "يجب ألا" "REQUIRED"، و"SHALL" "يجب ألا يتم" "يجب" "يجب ألا"، "يُنصح به" "أيار (مايو)" و"OPTIONAL" في هذه المستندات على النحو الموضح في RFC 2119.

الطوابع الزمنية

يتم عرض جميع الطوابع الزمنية بالمللي ثانية منذ تاريخ يونكس (1 كانون الثاني/يناير 1970) بالتوقيت العالمي المنسّق.

مثلاً:

• 23 نيسان (أبريل) 2019، الساعة 8:23:25 مساءً بتوقيت غرينيتش = 1556051005000 مللي ثانية
• 16 آب (أغسطس) 2018، الساعة 12:28:35 بعد الظهر بتوقيت غرينتش = 1534422515000 مللي ثانية

المبالغ

وتكون القيم النقدية في واجهة برمجة التطبيقات هذه بتنسيق يسمى "micros"، معيار في Google. المايكرو هي تنسيق دقة ثابت يستند إلى عدد صحيح. لتمثيل قيمة نقدية بالميكرو، اضرب قيمة العملة العادية في 1,000,000.

مثلاً:

• 1.23 دولار أمريكي = 1230000 ميكرو دولار أمريكي
• 0.01 دولار أمريكي = 10,000 ميكرو دولار أمريكي

المثلية

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

يجب عدم معالجة أي استجابة غير طرفية (نجاح غير HTTP 200) بشكل غير صحيح. وبالتالي، إذا تلقّى الطلب الذي تلقّى في السابق خطأ 400 (حالة سيئة أو تعذّر تنفيذ شرط مسبق)، عند استدعائه للمرة الثانية، يجب ألا يعرض الخطأ 400 بشكل مفاجئ، يجب إعادة تقييمه. وعند إعادة التقييم، يمكن أن تعرض خطأ 400 أو تتم معالجتها بنجاح.

لمزيد من المعلومات حول تحديد الهوية الجنسية، يُرجى الاطّلاع على هذا الدليل التفصيلي.

الشركة المتعهّدة

شركة تستخدم منصة الدفع من Google في أنشطتها التجارية ويمكن أن يكون نشاطًا تجاريًا داخليًا (مثل YouTube أو AdWords) أو نشاطًا تجاريًا خارجيًا (3P) يريد دمج خدمته لتعمل مع منظومة Google المتكاملة.

طرق الدفع

طريقة الدفع هذا أكثر عمومية من الأداة. وVisa وMasterCard وPayPal جميعها طرق دفع.

الوسيلة

مثال معيّن على طريقة دفع من قِبل عميل معيّن. على سبيل المثال، بطاقة ائتمان المستخدم أو حسابه على PayPal. وهي أيضًا وسيلة لتسهيل الدفع التي يتم تحويلها إلى رمز مميّز لعميل محدّد، لأنّها نسخة من طريقة الدفع التي يستخدمها العميل ومخزنة بشكل آمن على نظامنا.

الرمز المميز

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

المسارات الرئيسية

مسار المصادقة

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

1. مصادقة كلمة المرور لمرة واحدة (OTP) عبر SMS-MT (تم إنهاء الجوَّال للرسائل القصيرة SMS، كلمة المرور الصالحة لمرة واحدة)
2. مصادقة إعادة التوجيه

تعمل الشركات المتعهّدة لدى الشركة مع Google لاختيار آليات المصادقة التي تناسب منتجاتها على أفضل نحو.

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

مصادقة SMS-MT OTP

وفي آلية المصادقة هذه، يُدخِل المستخدم رقم هاتف في واجهة مستخدم Google. ترسل Google رقم الهاتف هذا إلى شركة الدمج (عبر طريقة sendOtp). ترسل جهة الدمج كلمة مرور صالحة لمرة واحدة إلى المستخدم. يُدخل المستخدم كلمة المرور في واجهة مستخدم Google، ما يرسلها إلى شركة الدمج. يؤدّي ذلك إلى نجاح عملية تكامل عمليات الدفع.

وعند استخدام المصادقة عبر كلمة المرور لمرة واحدة (OTP) عبر الرسائل القصيرة SMS في الوضع المستقل، يتم إرسال قيمة كلمة المرور لمرة واحدة إلى جهة الدمج باستخدام طريقة verifyOtp. تتحقق هذه الطريقة من أن كلمة المرور لمرة واحدة (OTP) التي تم تقديمها هي تلك التي تم إرسالها.

مصادقة إعادة التوجيه

وتتم مصادقة إعادة التوجيه عندما تعيد Google توجيه المستخدم إلى تطبيق تملكه جهة الدمج. قد يكون هذا التطبيق ويب أو تطبيق Android.

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

وعلى الشركات المدمَجة التي تختار هذه العملية توفير عنوان URL لمصادقة الويب، لأنّ هذا هو القاسم الأكثر شيوعًا على جميع مساحات العرض (أجهزة الكمبيوتر المكتبي أو الأجهزة الجوّالة). ومع ذلك، ننصح بشدة باستخدام مصادقة Android، لأنّ ذلك يوفّر أفضل تجربة للمستخدم على الأجهزة الجوّالة.

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

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

ملاحظة: إذا كانت شركة الدمج ستستخدم كلمة المرور لمرة واحدة (OTP) عبر SMS-MT أثناء إعادة التوجيه، تقترح Google بشدة الاستفادة من مصادقة SMS- MT OTP المذكورة أعلاه. وتقدِّم للمستخدم تجربة أكثر سلاسة على خدمات Google.

لمزيد من المعلومات عن المصادقة، يمكنك الاطّلاع على هذا الدليل التفصيلي.

مسار الارتباط

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

1. يتفاوض على هوية تسمى رمز مميز لتمثيل هذا المستخدم.
2. تقديم معلومات الحساب لإبلاغ محرّك بحث Google المسؤول عن المخاطر
3. يجمع معلومات الإعداد اللازمة لأول مرة لإنشاء GPT وإنشائه.

وتكون النتيجة هي موافقة كلّ من Google وشركة الدمج على GPT.

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

ستساعدك هذه الصورة التوضيحية في التعرّف على طريقة دفع وهمية عبر رمز مميّز بعنوان InvisiCash. يوضح هذا الخطوات التي سينفذها المستخدم في تدفق المصادقة وتدفق الربط.

نظرة عامّة على مسار الربط

1. تريد إحدى مستخدمي Google الذين لديهم عنوان بريد إلكتروني على العنوان [e-mail] إضافة حسابها على InvisiCash إلى "متجر Google Play" حتى تتمكّن من استخدامه في عمليات الشراء.
2. يفتح "متجر Google Play" تطبيق InvisiCash للمصادقة.

3. يسجّل المستخدم الدخول إلى حسابه على InvisiCash باستخدام عنوان البريد الإلكتروني [e-mail]. وربما تستخدم عنوان بريدها الإلكتروني على Gmail لكلٍّ من الحسابين إذا كان ذلك هو معلومات تسجيل الدخول إلى حسابها على InvisiCash.

   ملاحظة: تتوفر طرق أخرى للمصادقة. هذا مثال واحد فقط. ويمكن أن يتم ذلك على الويب وليس من خلال تطبيق.

4. يُرسِل تطبيق InvisiCash معرّف المصادقة إلى "متجر Google Play".

5. يرسل "متجر Google Play" معرّف المصادقة إلى خوادم Google.

6. ويرسل خادم Google رسالة إلى خادم InvisiCash لربط الحساب. وتشمل عملية الربط هذه معرّف المصادقة وGPT (الرمز المميّز للدفع من Google) ورقم تعريف الربط.

7. تخزِّن خوادم InvisiCash الرمز المميّز للدفع من Google (GPT) ومعرّف الربط. كلاهما مرتبط الآن بحساب InvisiCash.

8. توافق InvisiCash على عملية الربط هذه. ثم تنشئ خوادم Google أداة يمكن استخدامها في عمليات الشراء المستقبلية.