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

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

نظرة عامة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Symbols & Conventions

The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in these documents are to be interpreted as described in RFC 2119.

Timestamps

All timestamps are represented as milliseconds since the Unix epoch (Jan 1, 1970) in UTC.

For example:

• April 23, 2019 8:23:25 PM GMT = 1556051005000 milliseconds
• August 16, 2018 12:28:35 PM GMT = 1534422515000 milliseconds

Amounts

Monetary values in this API are in a format called "micros," a standard at Google. Micros are an integer based, fixed precision format. To represent a monetary value in micros, multiply the standard currency value by 1,000,000.

For example:

• USD$1.23 = 1230000 micro USD
• USD$0.01 = 10000 micro USD

Idempotency

All method calls within this API must have idempotent behavior. Google will sporadically retry requests to ensure that transactions are in the same state on both sides. Integrators should not attempt to reprocess any request already successfully processed. The response for the successful processing should be reported instead. All methods have a common RequestHeader which contains a requestId. This requestId is the idempotency key for all calls.

Any non terminal response (a non HTTP 200-success), must not be idempotently processed. So a request that previously got a 400 (bad request/failed precondition), when called a second time, must not idempotently return 400, it must be re-evaluated. At re-evaluation, it could return a 400 or be processed successfully.

For more information on idempotency see this detailed guide.

Integrator

A company who uses Google’s Payment Platform for their business. It could be internal (1P), such as Youtube or AdWords, It can also be an external (3P) business wanting to integrate their service to work with Google’s ecosystem.

FOP

Form of Payment. This is more general than an instrument. Visa, MasterCard, and PayPal are all FOPs.

Instrument

A particular instance of a form of payment by a specific customer. For instance, a user’s credit card, or their PayPal account. A tokenized FOP for a particular customer is also an instrument, because it is an instance of a form of payment for that customer, securely stored on our system.

Token

A representation, on Google’s system, of a specific user’s payment method. Since it contains all the information needed to make a purchase, a token is also an instrument. This may include such information as an account number a user has with their integrator.

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

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

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

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 أداة يمكن استخدامها في عمليات الشراء المستقبلية.