في عالم الدفعات العادية من Google، تُعتبر "الفوترة المضافة إلى فاتورة مشغّل شبكة الجوّال" طريقة دفع مرمزة (FOP)، ما يعني أنّ Google و"جهة تكامل الدفعات" تُجريان عملية تبادل لمرة واحدة لبيانات اعتماد هوية الحساب من أجل إنشاء رمز مميّز. في وقت لاحق، يتم تقديم هذا الرمز المميّز مرة أخرى إلى الشركة المسؤولة عن دمج الدفعات لتحديد الحساب المطلوب تحصيل الرسوم منه.
تستخدم طرق الدفع الأخرى أيضًا إنشاء الرموز المميّزة، لذا نقدّم نظرة عامة حول طرق الدفع التي تتضمّن رموزًا مميّزة والتي تكون مرتبطة بالدرجة الأولى بالفوترة المضافة إلى فاتورة مشغّل شبكة الجوّال. ويمكنك الاطّلاع على مزيد من التفاصيل حول خطوات المصادقة والربط والشراء والحوالة المالية. تقدّم هذه الصفحة المزيد من التفاصيل حول سياق "الفوترة المضافة إلى فاتورة مشغِّل شبكة الجوّال".
يتيح مشغّلو شبكات الجوّال استخدام Google Standard Payments من خلال تنفيذ واجهات برمجة التطبيقات التي تشكل العمليات التالية:
| تدفق | الوصف | مكافئ لمواصفات DCB3 |
|---|---|---|
| المصادقة | يحدد حساب المستخدم ويصادق عليه في نظام "وحدة تكامل الدفعات" الذي سيتم استخدامه لإجراء دفعات "الفوترة المباشرة لمشغِّل شبكة الجوّال". | SMS-MO مع GoogleUserToken |
| الربط | تبادل رمز مميّز طويل الأمد يمكن استخدامه بين Google و"جهة تكامل الدفعات" لإجراء الدفعات باستخدام حساب المستخدم على "وحدة تكامل الدفعات" | معاودة الاتصال بالموافقة على المستخدم باستخدام OperatorUserToken وGetProvidering() |
| FundsTransfer | نقل الأموال بشكل متزامن من حساب تكامل الدفع الخاص بالمستخدم. ينقل المسؤولية إلى شركة تكامل الدفعات | سطور Auth() و مفيدة في ملفات الطلبات المجمّعة |
| ردّ الأموال | بشكل متزامن ينقل المسؤولية إلى Google | سطور REFUND في ملفات طلب متعددة |
| الحوالة المالية | على أساس يومي، ويفضل أن تكون مستندة إلى واجهة برمجة التطبيقات | ملفّ تفاصيل الفاتورة الشهرية وملف تفاصيل الفاتورة الشهرية وملفّ التسوية اليومية |
| UpdateAssociatedAccount | يتم إبلاغ Google بالتغييرات التي تطرأ على حساب وحدة تكامل الدفعات للمستخدم (على سبيل المثال، حدود المعاملات أو حالة توفير المتطلبات اللازمة) | استطلاع GetProvisioning() |
| الاحتيال | يتم إبلاغ Google بشأن المعاملات التي تم إبطالها بسبب نزاع مستخدم. يُستخدم هذا لتحسين محرك مخاطر Google، ولكنه لا يؤثر على المسؤولية المالية | لا ينطبق |
المقارنة الإجمالية لمواصفات DCB3
تحلّ مواصفات Google Standard Payments المشاكل نفسها التي تحلها مواصفات DCB3. ومع ذلك، فإنها تستخدم تقنيات وتصميمات واجهة برمجة تطبيقات مختلفة تحسّن الحل. فيما يلي نظرة سريعة على الاختلافات الرئيسية:
مقارنة تقنية التكدس
يتم إجراء جميع عمليات الاتصال بواجهة برمجة التطبيقات باستخدام طلبات POST بتنسيق HTTPS مع تنسيق JSON مشفّر بتنسيق PGP. وهذا يعني أنّ كل من Google وشركة تكامل عمليات الدفع لديهم مفتاح PGP واحد فقط ليتم التبديل إليه. وتدعم هذه التقنيات أيضًا دعمًا أفضل من بروتوكول SOAP. يمكن العثور على مزيد من التفاصيل حول حزمة الاتصالات هنا.
مقارنة فلسفة واجهة برمجة التطبيقات
تعتمد DCB3 بشكل كبير على الملفات لتسوية حالة الدفع. لا تتضمن Google Standard Payments أي ملفات. تتم إعادة محاولة تنفيذ استدعاءات واجهة برمجة التطبيقات بشكل غير مسمى ولأجل غير مسمى حتى يتم تحديد الحالة النهائية.
تعتبر الحالات النهائية نهائية حقًا لمفتاح إثبات هوية معين. لا يتم تصنيف الأخطاء والحالات غير المحددة على أنها حالات رفض، بل على أنها استجابات ليست من فئة 200 HTTP. ويتيح لنا ذلك اكتشاف الأخطاء بسرعة أكبر وتجنُّب إخفاءها كرفض.
الميزات الجديدة
يوفّر Google Standard Payments ميزات جديدة، من بينها:
- لواجهة برمجة تطبيقات الاحتيال لإبلاغ محرك المخاطر في Google بالمحتالين
- يجب تحديث Associated Account API لإعلام Google بإدارة الحسابات وحدود المعاملات وتغييرات حالة الحساب
- توفير المزيد من الدعم لاختبارات المصادقة أثناء عمليات الشراء، مثل أرقام التعريف الشخصي USSD
- دورة الحوالات المالية اليومية
خريطة مصطلحات DCB3 إلى Google Standard Payments
في هذه المستندات والمواصفات نفسها، سترى مصطلحات تبدو جديدة، ولكنها في الواقع ليست سوى كلمات مختلفة للمفاهيم الحالية.
- مشغّل شبكة الجوّال -> وحدة تكامل الدفعات
تحذير: لتجنب حدوث أي التباس في مفهوم عملية تكامل DCB، يحاول هذا المستند استخدام "الجهة المتعهّدة للدفع" و "الجهة المتعهّدة لـ DCB" بدلاً من استخدام "الجهة المتعهّدة لـ DCB". ومع ذلك، تستخدم المستندات العامة لخدمة Google Standard Payments مصطلح "الدمج" بحرية كاختصار لكلمة "وحدة تكامل الدفعات" (Payment Integrator)
- رقم تعريف اتفاقية الفوترة -> رقم تعريف حساب وحدة تكامل الدفعات
- OperatorUserToken (OUT) -> GooglePaymentToken (GPT)
- segmentation_in_id ->
- حصة الأرباح -> الرسوم
مسار المصادقة
للحصول على نظرة عامة حول مسار المصادقة لإجراءات الدفع برمز مميّز، يُرجى الاطّلاع على هذه الصفحة.
تفاصيل فوترة مشغل شبكة الجوال
بالنسبة إلى فوترة مشغّل شبكة الجوّال، تهدف خطوات المصادقة إلى إثبات أنّ المستخدم يتحكّم في شريحة SIM المرتبطة بحساب مشغّل شبكة الجوّال. يمكن مصادقة مستخدمي الفوترة عبر مشغِّل شبكة الجوّال باستخدام أي من الآليات الثلاث التالية:
- مصادقة SMS-MO (التعريف في نظرة عامة على طريقة الدفع برمز مميّز)
- مصادقة إعادة التوجيه (التعريف في نظرة عامة على طريقة الدفع برمز مميّز)
- SMS-MT OTP (التعريف بطريقة الدفع برمز مميّز)
يمكن أن تعمل شركات تكامل الدفع مع Google لاختيار آليات المصادقة التي تناسب منتجاتها على أفضل وجه.
المقارنة مع DCB3
يحلّ خطوات المصادقة محلّ approveuser معاودة الاتصال إلى Google مع استخدام
OUT من ضمن مواصفات DCB3.
في DCB3، تم دمج المصادقة والارتباط في عملية واحدة. في Google Standard Payments، تُعد المصادقة مصدر قلق منفصل عن ربط الحساب.
مسار الربط
للحصول على نظرة عامة حول مسار الربط بطرق الدفع التي تتضمّن رموزًا مميّزة، يمكنك الاطّلاع على هذه الصفحة.
يكمن الفرق الرئيسي بين خطوات الربط المستخدَمة في وسائل "الفوترة المضافة إلى فاتورة مشغِّل شبكة الجوّال" وخطوات طرق الدفع العامة التي تم إصدار رمز مميّز في أنّ مستند المصادقة المقدَّم في طريقة associateAccount سيختلف بناءً على ما إذا كانت الشركة قد قدّمت طلبًا إضافيًا للتحقّق من المستخدم.
إذا ردت شركة تكامل الدفعات على رغبتها في إجراء تحدٍ إضافي من قِبل المستخدم، فسيكون إثبات المصادقة هو أي إثبات للهوية يتم تقديمه بواسطة آلية المصادقة المحددة التي استخدمتها Google للتحدي الإضافي. على سبيل المثال، إثبات المصادقة الذي تقدمه آلية
SMS-MT OTP هو معرّف الطلب لطريقة sendOtp بالإضافة إلى كلمة المرور لمرة واحدة (OTP) نفسها.
سمات الآلة الموسيقية
يناقش قسم "سمات الأداة" العام ضمن النظرة العامة التي تم فيها إنشاء طريقة دفع برمز مميّز مفهوم accountAlias وaccountNickname وfullAccountNickname.
تفاصيل فوترة مشغل شبكة الجوال
- يجب أن يكون
accountAliasرقم هاتف المستخدم. وسيتم استخدامها للمساعدة في تحديد الأداة في حال اتصل المستخدم بفريق دعم Google بخصوص حسابه. accountNicknameوfullAccountNicknameهما اسمان معروضان يُستخدمان لتحديد الأداة في واجهة المستخدم.
المقارنة مع مواصفات DCB3
يحل مسار الربط محل المكوّنات التالية لمواصفات DCB3:
- الحصول على استدعاء SOAP لإدارة الحسابات
- مكالمة SOAP في عنوان المشترك
- تنسيق OUT من إنشاء مشغِّل شبكة الجوّال
يكمن الاختلاف الكبير هنا في أنّ Google تنشئ الرمز المميّز للدفع من Google (GPT) أثناء عملية الربط بدلاً من مشغّل شبكة الجوّال الذي تنشئه.
من المهم أيضًا ملاحظة أنّه، على عكس DCB3 التي يتم فيها تحديد OUTs لمعرّف فوترة مُعيّن، لا يتم تحديد نطاق GPT لأي فئة مُحدّدة في PaymentIntegratorAccountID.
إعادة تحميل مسار الرمز المميّز
للحصول على نظرة عامة حول مسار الرمز المميّز لإعادة التحميل لطرق الدفع التي تتضمّن رموزًا مميّزة، يمكنك الاطّلاع على هذه الصفحة.
تفاصيل فوترة مشغل شبكة الجوال
بالنسبة إلى وسائل فوترة مشغّل شبكة الجوّال، لا ننصح أبدًا بشدّة بانتهاء صلاحية رموز Google Payment المميزة لأنّها تؤدي إلى إلغاء طلبات الاشتراك. بدلاً من الرموز المميزة التي تنتهي صلاحيتها والاعتماد على تدفق الرمز المميز للتحديث لإصلاحها، يمكن في كثير من الأحيان إتمام حالة الاستخدام باستخدام خطوات تحديث الحساب الموضحة أدناه.
عملية تحديث الحساب
تتيح عملية تعديل الحساب لـ "وحدة تكامل الدفعات" إعلام Google بالتعديلات التي تطرأ على حساب الدمج الخاص بالمستخدم. يتم تقديم هذه الحقول في الأصل إلى Google أثناء مسار الربط. في ما يلي بعض الأمثلة على بيانات الحساب التي قد تريد "وحدة تكامل الدفعات" تعديلها:
- حدود معاملات المستخدم الشهرية واليومية ولكل سلعة
- حالة توفير المتطلبات اللازمة لحساب الدمج الخاص بالمستخدم
- نوع حساب الدمج الخاص بالمستخدم (الدفع المسبق أو الدفع عند الاستخدام أو المؤسسات أو غير ذلك)
- "accountAlias" أو "accountاللقب" أو "fullAccountاللقب" للمستخدم
- سواء أعدّ المستخدم رقم تعريف شخصي ثابتًا تمت مشاركته مسبقًا أو أزاله أو غيّره
- ما إذا كان المستخدم قد أغلق حسابه أو غيّر رقم هاتفه -- مما يؤدي إلى إلغاء وسيلة المستخدم في نظام Google.
- حذف مسار الرمز المميّز
المقارنة مع مواصفات DCB3
تحل عملية تعديل الحساب محل المكوّنات التالية في مواصفات DCB3:
- استطلاع رأي لاستدعاء SOAP لإدارة الحسابات
- إبطال الرمز المميّز الدوري
مسار الشراء
للحصول على نظرة عامة حول مسار الشراء لإجراءات الدفع برمز مميّز، يُرجى الاطّلاع على هذه الصفحة.
تفاصيل فوترة مشغل شبكة الجوال
يستخدم بعض مشغّلي شبكة الجوّال نظام USSD أو تقنية أخرى للحصول على رقم التعريف الشخصي من المستخدمين أثناء كل عملية شراء. وبالنسبة إلى مشغلي شبكة الجوّال هؤلاء، فبدلاً من استدعاء Capture() الذي نسميه syncCapture() ، ونسمح لمدة 30 ثانية لمشغل شبكة الجوّال بمطالبة المستخدم برقم التعريف الشخصي وإنهاء عملية الالتقاط. عندما يتم تحديد الحالة النهائية للدفعة، يخبر مشغّل شبكة الجوّال Google بالنتيجة من خلال استدعاءcaptureResultNotification().
المقارنة مع مواصفات DCB3
حدثت تغييرات كبيرة هنا.
- استدعاء طريقة فردية ومتزامنة -- Capture() بدلاً من auth() + الملف المجمّع
- لا توجد ملفات دُفعية على الإطلاق
- ما مِن طريقة cancel() (التقاط + عملية ردّ الأموال بدلاً من المصادقة + الإلغاء)
- لم يتم الرد على أي حقل user_message. ويتم ربط رموز الرفض بالرسائل التي تملكها Google والمترجمة إلى لغة حساب المستخدم.
- التغييرات الرئيسية في المصطلحات:
- CorrelationId -> requestId
- BillingAgreementId -> paymentIntegratorAccountId
- OperatorUserToken -> googlePaymentToken
مسار الشراء الصعب
التطوير مستمر لدعم تدفق الشراء الذي يتضمن تحدي المصادقة للمستخدم قبل كل عملية شراء. يمكن أيضًا استخدام معظم طرق المصادقة التي يمكن استخدامها قبل مسار الربط قبل مسار الشراء الصعب، وذلك لتوفير مصادقة إضافية للمستخدم.
تدفق رد الأموال
لإلقاء نظرة عامة على سير عمليات ردّ الأموال لإجراءات الدفع برمز مميّز، يُرجى الاطّلاع على هذه الصفحة.
تتيح طريقة الدفع (FOP) المحوَّلة إلى رمز مميّز إمكانية تدفق ردّ الأموال في رسالة واحدة. تتيح طريقة استرداد الأموال إمكانية ردّ أموال عملية شراء كاملة أو ردّ أموال عملية شراء معيّنة. يمكن ردّ جزء من الأموال المدفوعة في عملية شراء واحدة.
تفاصيل فوترة مشغل شبكة الجوال
ما مِن إجراءات خاصة تتعلّق بوسائل فوترة مشغّل شبكة الجوّال في مسار ردّ الأموال.
المقارنة مع مواصفات DCB3
يتم بدء عمليات ردّ الأموال من خلال طلب بيانات متزامن من واجهة برمجة التطبيقات بدلاً من ملف. بالإضافة إلى ذلك، يمكن إنشاء عدة عمليات ردّ جزء من الأموال لعملية دفع أصلية واحدة بدلاً من تنفيذ عملية ردّ أموال واحدة فقط بقيمة كاملة.
تدفق الحوالات المالية
للحصول على نظرة عامة حول تدفّق الحوالات المالية لطرق الدفع التي تتضمّن رموزًا مميّزة، يُرجى الاطّلاع على هذه الصفحة.
يشير تدفّق الحوالات المالية إلى الطريقة التي تتّبعها Google وشركة تكامل الدفعات للتسوية. Google هو نظام محاسبة السجل ويقوم باحتساب تحويلات الحوالات المالية. ترسل Google بشكل منتظم بيان حوالة مالية إلى الجهة المتعهّدة للدفعات. ويقدم كشف الحساب ملخصًا للمبلغ الذي تدين به "شركة تكامل الدفع" إلى Google مع تعليمات حول كيفية الدفع إلى Google. وليتمكّن "جهة تكامل الدفع" من تسوية، يمكن لتلك الشركة الاستعلام من Google عن تفاصيل مستوى المعاملة التي يتألف منها بيان الحوالة المالية.
تفاصيل فوترة مشغل شبكة الجوال
تتضمّن فوترة مشغّل شبكة الجوّال remittanceStatementDetails حقولاً إضافية
غير مدرَجة في تعريفات واجهة برمجة التطبيقات ضمن تدفق الحوالات المالية حتى الآن. وتشمل هذه المعلومات ما يلي:
- revshareCategory
- itemPrice
- tax
- timestamp
بالنسبة إلى مشغّلي شبكة الجوّال الذين يعقدون اتفاقية مشاركة الأرباح مع Google بنسبة 50/50، يتم تجميع الرسوم
الواردة في remittanceStatementDetails لكل
revshareCategory بدلاً من تقديمها على أساس كل حدث.
المقارنة مع مواصفات DCB3
يحل مسار الحوالات المالية محل المفاهيم التالية في مواصفات DCB3:
- تقرير الدفع الشهري/PaymentReport بتنسيق PDF
- ملف CSV الذي يتضمّن تفاصيل الفواتير الشهرية
- ملفات CSV للاستعادة اليومية
تتمثل الاختلافات الرئيسية هنا في إزالة أي ملفات وتوفير التحويلات اليومية. وبدلاً من الملفات، يتمّ تسليم المبلغ المطلوب تحويله عبر واجهة برمجة تطبيقات متزامنة، وتتيح واجهة برمجة تطبيقات أخرى طلب البحث عن تفاصيل حول بيان الحوالة المالية.
مسار الإبلاغ عن الاحتيال
تتيح خطوات الإبلاغ عن عمليات الاحتيال لجهة تكامل عمليات الدفع إعلام Google بالمعاملات التي يُحتمل أن تكون احتيالية من خلال استخدام طريقة fraudNotification. يُستخدم هذا التدفّق لتحديث محرك المخاطر الداخلي في Google ولا يبدأ بأي حركة للأموال.
تفاصيل فوترة مشغل شبكة الجوال
لا توجد إجراءات خاصة بشأن وسائل فوترة مشغّل شبكة الجوّال في خطوات إشعار إبطال الدفع.