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

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

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

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

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

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

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

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

خطوات الدمج

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

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

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

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

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

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

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

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

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

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

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