المعاملات التي يبدأها التاجر (MIT)

نظرة عامة على "دعم MIT"

المعاملات التي يبدأها التاجر (MIT) هي معاملات تتم معالجتها بدون أن يكون المستخدم في جلسة نشطة. يوفّر هذا التعديل على واجهة Google Pay Online API إمكانية ظهور محسّنة لأنواع المعاملات هذه، وتجربة مستخدم محسّنة من خلال تجربة مستخدم مخصّصة لتفاصيل الفوترة، واستمرارية أفضل للدفع.

أبرز حالات الاستخدام

  • الدفعات المتكرّرة: خدمات البث الرقمي أو الاشتراكات أو المرافق
  • الدفعات المؤجّلة: حجوزات الفنادق أو الطلبات المُسبَقة أو رسوم عدم الحضور
  • عمليات إعادة التعبئة التلقائية: عمليات إعادة تعبئة القيمة المخزّنة لبطاقات النقل العام أو بطاقات الهدايا

تنفيذ واجهة برمجة التطبيقات MIT

‫MIT API هي إضافة إلى واجهة برمجة التطبيقات الحالية LoadPaymentData . يجب أن يدرج المدمجون عنصر *TransactionInfo واحدًا بالضبط لتحديد نية الفوترة. توفّر Google 3 خيارات حسب نوع المعاملة التي يبدأها التاجر:

نوع المعاملة اسم الكائن الوصف
متكرّرة RecurringTransactionInfo تُستخدَم للرسوم الثابتة المتكرّرة. يتيح فترات تجريبية ونظام فوترة للدفع المُسبَق والدفع الآجل.
مؤجَّلة DeferredTransactionInfo تُستخدَم لتحصيل رسوم لمرة واحدة في وقت مستقبلي محدّد مسبقًا.
إعادة التحميل التلقائي AutomaticReloadTransactionInfo تُستخدَم لإعادة تعبئة حساب ذي قيمة مخزّنة عندما ينخفض الرصيد عن الحدّ الأدنى.

خطوات الدمج

  1. المستندات: تقع تعريفات العناصر الثلاثة الجديدة في قسم "مرجع العناصر" ضمن المستندات، وهي مرتبطة مباشرةً بالقائمة السابقة.
  2. التنفيذ: استخدِم عناصر *TransactionInfo ذات الصلة بنظامك في طلب البيانات من واجهة برمجة التطبيقات.
    • يُرجى العِلم أنّه يمكن تمرير عنصر واحد فقط لكل طلب إلى واجهة برمجة التطبيقات. ويعود إلى التاجر الفردي تحديد الكائن الذي سيستخدمه وتعبئة الحقول.
  3. الاختبار: استخدِم بيئة الاختبار للتأكّد من أنّ تفاصيل الفوترة تظهر بشكل صحيح في ورقة الدفع.
  4. الإطلاق: يمكنك بدء البث المباشر بعد التأكّد من صحة المَعلمات.

إدارة مراحل نشاط الرموز المميّزة (TLM)

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

أحداث الرموز المميزة الرئيسية

  • إيقاف التفعيل/الحذف: يتم إرسال إشعار عندما يصبح الرمز المميّز غير قابل للاستخدام.
  • تعديلات لاحقة على رقم الحساب الأساسي للتمويل: تحدث عندما يتم تعديل رقم الحساب الأساسي للتمويل الأساسي.

متطلبات إعداد الخادم

على التجّار المباشرين ومقدّمي خدمات الدفع إنشاء نظام لتلقّي هذه الرسائل وفك تشفيرها ومعالجتها.

المتطلبات الوصف
نقطة النهاية نقطة نهاية HTTPS آمنة لتلقّي طلبات POST
المصادقة يجب أن يتعامل مع إثبات صحة التوقيع وفك تشفير الرسالة.
الردّ يجب عرض SUCCESS لمواصلة تلقّي الإشعارات، أو TOKEN_NOT_FOUND/TOKEN_NOT_IN_USE لإيقافها.
إشعار التاجر على مقدّمي خدمات الدفع إبلاغ التجّار بحالة الرمز المميّز.

ملاحظات التنفيذ

يجب إدخال نقطة النهاية tokenUpdateUrl مع المعاملة لتلقّي إشعارات بشأن الرمز المميّز. بالنسبة إلى مقدّمي خدمات الدفع، تقع على عاتقهم مسؤولية تحديد الطريقة التي سيتلقّى بها التجّار عنوان URL هذا وكيفية ملء هذا العنوان في عنصر *TransactionInfo ذي الصلة.

يُرجى العلم أيضًا أنّ الحمولة المشفّرة ستعرض حقلًا اختياريًا إضافيًا، merchantTokenId، لعمليات الشراء التي تتم داخل التطبيق. للحصول على تفاصيل محدّدة، يُرجى الاطّلاع على مستندات تشفير بيانات الدفع (للتجّار) أو مستندات بنية الحمولة (لمقدّمي خدمات الدفع).