واجهة Digiseller: أتمتة الدفع وتسليم المنتج

Digiseller في جوهرها محرّك دفع وتسليم تلقائي، والواجهة المتجرية تأتي لاحقاً. القيمة الحقيقية للموزّع لا تظهر إلا حين تخدم بطاقةَ المنتج خدمةٌ برمجية تخصّك — لا موظف ولا ملف أكواد مرفوع — تستدعي مورد الجملة لحظة وصول الدفع وتعيد كوداً صالحاً. نشرح هنا كيف يُبنى هذا الربط، وأين ينكسر، وكيف يُصلح.

إن لم تعمل على المنصة بعد فابدأ بالأساسيات في البيع على Digiseller.

ما الذي تغطيه واجهة Digiseller

تنقسم الواجهة إلى كتل واضحة المعنى. تحقّق من أسماء الدوال ومعاييرها في الوثائق الحالية — ما يلي هو المنطق لا قائمة التواقيع.

هناك أيضاً كتلة مراسلة المشتري. لا تؤتمت البيع لكنها مفيدة إن بنيت دعماً فوق المنصة.

التوكن ليس ثابتاً

ينتهي التوكن بعد مدة، ويُوقَّع الطلب بتجزئة على سرّك وطابع زمني. النتيجة العملية: لا تطلب توكناً جديداً مع كل استدعاء، ولا تخزّن واحداً إلى الأبد. النمط الصحيح هو حفظ التوكن مع وقت انتهائه، وتجديده قبل دقيقة أو دقيقتين، وتنفيذ إعادة مصادقة قسرية واحدة فقط عند استلام رد بانتهاء الصلاحية.

مسار الدفع حتى التسليم خطوة بخطوة

هكذا تبدو السلسلة من منظور خادمك.

1. يدفع المشتري على واجهة Digiseller أو على Plati.Market. يُحتجز المال لدى المنصة ولا يصير ملكك نهائياً بعد.
2. تُبلغ المنصة عن البيع. إمّا بإشعار إلى عنوانك أو باستعلام خدمتك عن الطلب. الإشعار أسرع والاستعلام أوثق — وعملياً تحتاج الاثنين.
3. تتحقق من الأصالة. لا تثق بمحتوى الإشعار وحده: استدعِ الواجهة برقم الطلب وتأكد أن البيع موجود والمبلغ مطابق والمنتج هو المتوقَّع.
4. تبحث عن الطلب في قاعدتك. إن وُجد سجل وكود صادر فأعد الكود المحفوظ. وإلا فأنشئ سجلاً بحالة pending.
5. تستدعي مصدر الجملة. تطلب خدمتك من المورد المنتج المقابل وتستلم الكود.
6. تسلّم المحتوى للمشتري وتعلّم الطلب كمُسلَّم على المنصة.
7. تكتب النتيجة — الكود، سعر الشراء، معرّف طلب المورد، الوقت.

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

مورد جملة خلف بطاقة المنتج

الفكرة بسيطة: البطاقة على المنصة واجهة عرض، والمستودع عند تاجر الجملة. لحظة البيع يترجم وسيطك رمز المنتج لدى المنصة إلى رمزه لدى المورد، ينشئ الطلب، ويعيد الكود.

ما تحتاجه لذلك:

• جدول مطابقة. منتج واحد على المنصة مقابل منتج واحد لدى المورد، مع المنطقة والفئة السعرية. بدون منطقة تفعيل صريحة ستولّد سيلاً من الاستردادات.
• فحص التوافر قبل البيع. استعلم عن مخزون المورد وأوقف بيع ما نفد — أرخص بكثير من إلغاء طلب مدفوع.
• مصدر بديل. مورد ثانٍ على منتجاتك الأكثر مبيعاً يزيل معظم مخاطر النفاد.
• ضبط سعر التكلفة. أسعار الجملة تتحرك؛ إن لم تحدّث الواجهة ستبيع تحت التكلفة فترةً دون أن تنتبه.

منع الازدواج يعيش في قاعدة بياناتك لا في ترويسة

أغلى عطل ممكن هو شراء الكود نفسه مرتين لبيعة واحدة. الأسباب عادية: إشعار مكرر من المنصة، انتهاء مهلة في استدعائك للمورد، إعادة تشغيل عامل المعالجة.

لا تفترض أن ترويسة idempotency لدى المورد ستنقذك. واجهة FoxReload مثلاً لا تملك ترويسة Idempotency-Key، وتكرار POST ينشئ طلباً ثانياً. النمط الذي يعمل مختلف:

• اكتب نيّتك في قاعدتك قبل استدعاء المورد — معرّف البيع، رمز المنتج، الوقت، حالة pending؛
• عند أي خطأ غامض (مهلة، انقطاع، 5xx) تحقّق من الحالة أولاً — اجلب طلبات المورد الأخيرة وابحث عن طلبك بالمنتج والوقت؛
• لا تُنشئ طلباً جديداً إلا بعد التأكد أن السابق لم يُنشأ؛
• فهرس فريد على معرّف البيع في جدولك هو خط الدفاع الأخير.

النمط كاملاً في مفاتيح Idempotency وإعادة المحاولة الآمنة.

إعادة المحاولة وطوابير المعالجة

صنّف الأخطاء وتعامل مع كل صنف بطريقته.

اجعل التأخير متصاعداً وأضف تشتيتاً عشوائياً بسيطاً، وإلا اندفع كل عمّالك نحو المورد في موجة واحدة بمجرد تعافيه. وحُدّ عدد المحاولات: الطلب الذي لا يُغلق خلال نافذة معقولة مكانه طابور المراجعة اليدوية لا حلقة لا نهائية.

التسوية هي ما يفصل الربح عن وهم الربح

الأتمتة بلا تسوية تنتج صورة جميلة وخاطئة. الحد الأدنى اليومي:

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

الفروقات موجودة دائماً. المهم أن تكتشفها آلياً لا عبر شكوى مشترٍ.

من أين تجلب البضاعة لهذا الربط

التصميم كله بجودة المصدر الذي يقف خلف البطاقة. كتالوج FoxReload للجملة يؤدي هذا الدور: أكثر من 900 منتج بين مفاتيح الألعاب وبطاقات الهدايا والشحن والاشتراكات، وواجهة REST واحدة بدل موردين متفرقين، وتسليم تلقائي. هكذا تُبقي طبقة ربط واحدة خلف متجرك على Digiseller بدل إعادة كتابة الكود كلما تغيّر المورد لمنتج بعينه.

مواد ذات صلة: أتمتة تسليم الأكواد الرقمية، ويب هوك الطلبات، وربط SBP بـ Digiseller.