نظرة عامة
تتوافق خدمة Google Standard Payments مع طرق الدفع النقدية (FOP) مثل عمليات الشراء من المتاجر الصغيرة (مثل 7-Eleven). على مستوى عالٍ، ينشئ المستخدم الذي يريد الدفع مقابل الحصول على سلع رقمًا مرجعيًا من خلال شركة تكامل الدفع. يأخذ المستخدم بعد ذلك هذا الرقم المرجعي إلى متجر صغير أو كشك أو مصرف ويدفع الرقم المرجعي.
![]() |
![]() |
![]() |
المفاهيم والمصطلحات
رموز مؤتمرات
يمكن استخدام الكلمات الرئيسية "يجب" "يجب ألا" "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 نظرًا لأنه يحتوي على جميع المعلومات اللازمة لإجراء عملية شراء، فإن الرمز المميز يعد أيضًا وسيلة. وقد يشمل ذلك معلومات مثل رقم حساب مستخدم مع شركة الدمج التي يتعامل معها.
المسارات الرئيسية
تستخدم Google مسارَين أساسيَّين لإنشاء هذه الأرقام المرجعية والدفع مقابلها:
- إنشاء تدفق رقم المرجع.
- مسار الدفع المرجعي للرقم المرجعي
لاحقًا، تتم معالجة التسوية والتسوية من المشتريات الناتجة من خلال تدفق الحوالة المالية.
يوضح الرسم التخطيطي أدناه كل تدفق من هذه التدفقات.
نظرة عامة على طرق الدفع النقدية
يتم وصف أول مسارين بمزيد من التفصيل في الأقسام التالية. يمكنك الاطّلاع على صفحة تدفق الحوالة المالية إذا كنت تريد معرفة المزيد من المعلومات عن هذا المسار.
إنشاء رقم مرجعي
والغرض من عملية إنشاء الرقم المرجعي هو إنشاء وتبادل معرّف (رقم مرجعي) يمكن أن تستخدمه كلّ من Google وشركة الدمج لتحديد عملية شراء. يمكن للمستخدم بعد ذلك استخدام هذا الرقم المرجعي في متجر صغير أو كشك أو مصرف لإكمال عملية الشراء. تُنشئ شركة الدمج هذا المعرّف بناءً على طلب Google من خلال استدعاء الطريقة generateReferenceNumber
. يتضمن طلب إنشاء الرقم المرجعي مبلغًا ووصفًا للمعاملة.
يوضّح المخطّط التالي كيفية إنشاء رقم مرجعي وإرساله إلى العميل مع التعليمات.
إنشاء تدفق رقم مرجعي
في ما يلي قائمة بالكائنات وما تمثّله:
- المستخدم: الشخص الذي يريد الدفع مقابل شيء ما باستخدام طريقة الدفع هذه.
- واجهة مستخدم Google: وهي الواجهة التي يجري فيها المستخدم عملية الشراء. يمكن أن يكون من خلال الويب أو من خلال تطبيق.
- خادم Google: خادم الخلفية في Google الذي يطلب إنشاء الرقم المرجعي وينشئ تعليمات الدفع للمستخدم.
- خادم تكامل الدفع: خادم الخلفية التابع لشركة تكامل الدفع الذي يتتبع تفاصيل الدفع وينشئ الرقم المرجعي.
يبدأ هذا التدفق بالمستخدم الذي يريد استخدام طريقة الدفع النقدية هذه.
- يصل المستخدم إلى واجهة مستخدم Google التي ترسل طلبًا للحصول على رقم مرجعي.
- ترسل واجهة مستخدم Google رسالة إلى خادم Google مفادها أن هذه الرسالة تحتاج إلى رقم مرجعي (
getReferenceNumber
). - يطلب خادم Google من خادم تكامل الدفع إنشاء رقم مرجعي (
generateReferenceNumber
). - ينشئ خادم دمج عمليات الدفع الرقم المرجعي ويرسله إلى خادم Google.
- ينشئ خادم Google تعليمات الدفع لتتماشى مع الرقم المرجعي. ثم يرسل هذه المعلومات إلى واجهة مستخدم Google.
- ترسل واجهة مستخدم Google هذه التعليمات والرقم المرجعي إلى المستخدم.
ملاحظات على الأرقام المرجعية
يمكن دفع الأرقام المرجعية مرة واحدة فقط، ويمكن إلغاؤها من خلال عملية إلغاء الرقم المرجعي. يجب أيضًا أن تكون الأرقام المرجعية أبجدية رقمية، وأن تدعم تنسيقات عرض متعددة.
بالإضافة إلى عرض الرقم المرجعي، يمكن أن تمثّل واجهات المستخدم في Google الرقم المرجعي بشكل اختياري بتنسيق الرمز 128 (تنسيق رمز شريطي). يمكن أن تتيح تنسيقات الرموز الشريطية الأخرى عند الطلب.
رقم مرجع الدفع
وسيستخدم المستخدم هذا الرقم المرجعي في متجر صغير أو كشك أو مصرف لتحديد عملية الشراء التي يريد المستخدم الدفع مقابلها. ويجب أن تطلب شركة الدمج من المستخدم تأكيد عملية الشراء التي تم دفعها من خلال عرض مبلغ الشراء وتاريخه ووصف المعاملة قبل الدفع.
وبمجرد أن يختار المستخدم الدفع، فعليه الدفع بالكامل، والدفع مرة واحدة فقط. لا تتيح واجهة برمجة التطبيقات هذه إجراء دفعات زائدة أو ناقصة لرقم مرجعي واحد. ولا يمكن أيضًا إجراء دفعات متعددة برقم مرجعي واحد.
بعد أن يدفع المستخدم الرسوم، على شركة الدمج إعلام Google على الفور بأنّ هذا الرقم المرجعي قد تم دفعه باستخدام طريقة referenceNumberPaidNotification
. ومن خلال استدعاء هذه الطريقة في غضون ثوانٍ من إتمام المستخدم لعملية الدفع، تتيح الشركة للمستخدم استلام سلعه بسرعة. (يمكن إضافة هذه المكالمة إلى قائمة انتظار في حال تعطل الشبكة.)
بعد الدفع، سيتم تضمين الرقم المرجعي والمبلغ في كشف الحوالة المالية المُرسل في يومَي T+2.
فيما يلي مخطط متسلسل يوضح عملية دفع رقم مرجعي.
مسار دفع الرقم المرجعي
تمثّل الكائنات في المخطّط البياني ما يلي:
- المستخدم: الشخص الذي يريد الدفع مقابل شيء ما باستخدام طريقة الدفع هذه.
- متجر صغير: الموقع الجغرافي الذي يجري فيه المستخدم عملية الدفع باستخدام الرقم المرجعي والتعليمات المقدَّمة، مثل متجر صغير.
- خادم دمج الدفع: هو خادم الخلفية التابع لشركة تكامل الدفع الذي يتتبّع تفاصيل الدفع.
- خادم Google: خادم الخلفية في Google الذي يطلب إنشاء الرقم المرجعي وينشئ تعليمات الدفع للمستخدم.
يبدأ هذا التدفق بالمستخدم الذي يذهب إلى متجر صغير من أجل إجراء الدفع وفقًا للتعليمات المعطاة له.
- ينتقل المستخدم إلى متجر صغير لإجراء دفعة.
- بعد اكتمال المعاملة، يرسل المتجر الصغير إلى جهة تكامل الدفع لعملية الدفع.
- يرسل خادم تكامل الدفع رسالة نجاح إلى المتجر الصغير.
- يشير "المتجر الصغير" إلى أنّ المعاملة تمّت بنجاح للمستخدم، وأنّه سيتم تسليم السلع إليه قريبًا.
- ويرسِل خادم شركة تكامل الدفع رسالة إلى خادم Google تفيد بأنّه تم دفع الرقم المرجعي (
referenceNumberPaidNotification
). يجب ألا تحظر هذه الخطوة الخطوة 4. - يستجيب خادم Google برسالة نجاح إلى خادم تكامل الدفع.
إلغاء الرقم المرجعي
يمكن إلغاء الأرقام المرجعية من قِبل Google. إذا ألغت Google رقمًا مرجعيًا، سيتم استدعاء طريقة cancelReferenceNumber
. وعند تكرار هذه المكالمة بنجاح، لا يكون من المناسب دفع هذا الرقم المرجعي، وعلى شركة الدمج رفض الدفع لهذا الرقم. عند نجاح هذه المكالمة، ستتعذّر جميع المكالمات المستقبلية إلى referenceNumberPaidNotification
.
إذا سبق أن بدأت عملية الدفع، مثلاً إذا أدخل المستخدم رقمه المرجعي في Kiosk ولكنّه لم يدفع بعد، يجب أن تعرض شركة الدمج رمز استجابة HTTP 423 يتضمّن رسالة خطأ تتضمّن الرمز USER_ACTION_IN_PROGRESS
.
التالي: تدفق الحوالات المالية