منصة HstockPlus: كيف تتناسب الطلبات والتنفيذ وواجهة برمجة التطبيقات معًا فعليًا

تصف هذه الصفحة كيفية عمل السوق كنظام: الأدوار التي يتضمنها، والمسار الذي تسلكه الطلبية، وما يوفره الـ API. لا يُباع أي شيء من هذه الصفحة.

كتالوجان، وليس واحدًا

تحمل المنصة نوعين من المخزون، ويختلف سلوك كل منهما بشكل كافٍ لدرجة أن التعامل معهما كشيء واحد يسبب مشاكل.

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

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

عدد البائعين يبلغ بضع مئات حسب الكتالوج النشط، مقابل حوالي ألف وخمسمائة حساب يحمل دور البائع، موزعين على حوالي خمسمائة وستين متجرًا.

الأدوار وما يمكن لكل دور الوصول إليه

هناك ثلاثة أدوار، وهي تراكمية وليست حصرية، لذا يمكن لحساب واحد أن يكون مشتريًا وبائعًا في الوقت نفسه.

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

موافقة البائع مطلوبة حاليًا، وهي تتحكم في الـ API وكذلك في الواجهة: البائع الذي لم تتم الموافقة على حسابه يتلقى استجابة صريحة بأن الطلب قيد المراجعة بدلاً من كتالوج فارغ، وهو أمر مفيد لتمييزه عندما لا يُرجع التكامل أي شيء.

يجلس البائعون على واحدة من خمس طبقات مستمدة من المبيعات المنسوبة على مدى اثني عشر شهرًا متدحرجًا. الطبقة ليست شكلية. فهي تحدد المدة التي تنتظرها المنصة قبل تحرير الأموال تلقائيًا، وتغذي حساب حد القوائم.

كيف تتحرك الطلبية

تُتتبع حالة الطلبية وحالة الدفع بشكل منفصل، وكلاهما مهم عند قراءة الـ API.

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

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

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

الـ API، والتمييز الوحيد الأكثر أهمية

هناك سطحان للـ API، كلاهما موثق بمفتاح.

السطح الموجه للمشترين يتبع اصطلاح اللوحة المستخدم على نطاق واسع: نقطة نهاية واحدة تأخذ معامل action. جميع الإجراءات القياسية منفذة، لذا تعمل أدوات اللوحة الحالية معه: services لسرد ما هو متاح، add لوضع طلبية، status للتحقق من واحدة، balance، refill وcancel. فوق ذلك يضيف إجراءات لا يعرفها الاصطلاح: categories وsubcategory_info للتنقل في التصنيف، products وshops، allowcancel، inventory لفحوصات المخزون، ومجموعة كاملة من إجراءات التحقق عبر الرسائل النصية تغطي المشاريع والبلدان وطلب رقم والاستعلام عن الكود. تعامل معه كاصطلاح قياسي مع إضافات، وليس كنسخة مطابقة؛ الاستدعاءات القياسية ستعمل دون تغيير، والإضافات هي حيث تكمن القدرة الخاصة بالمنصة.

السطح الموجه للبائعين هو REST API تقليدي يغطي المنتجات والطلبيات والتذاكر والمدفوعات. داخله يوجد تمييز واحد يحدد ما إذا كان تكاملك صحيحًا، ومن السهل أن تخطئ فيه لأن كلا النقطتين ترجعان طلبيات.

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

أي شيء ينفذ تلقائيًا يجب أن يسحب، لا أن يسرد. استخدم القراءة للوحات المعلومات والتسوية، حيث رؤية نفس الطلبية مرتين غير ضارة.

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

المرجع الكامل لكلا السطحين موجود في توثيق API المشتري وتوثيق API البائع.

المدفوعات والأرصدة

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

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

الدعم والنزاعات

يعمل الدعم عبر نظام تذاكر مشترك بين الأدوار الثلاثة، لذا يمكن للمشتري والبائع والدعم أن يكونوا في محادثة واحدة بدلاً من ثلاث محادثات لا تلتقي أبدًا. تحمل التذاكر تصنيفًا للمشكلة، ويمكن للبائع حلها عن طريق استبدال العنصر المُسلَّم أو استرداد قيمته أو رفض الادعاء.

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

ما يعمل وفق جدول زمني

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

لا يُعلن أي من هذه عن نفسه للـ API. إذا رأت تسويتك طلبية تغير حالتها دون أي استدعاء منك، فعادةً ما يكون أحد هذه الأسباب هو السبب.

البدء

1. سجّل، ثم اطلب موافقة البائع إذا كنت تنوي البيع. الموافقة تتحكم في الـ API وكذلك في الواجهة.
2. أنشئ قوائم، أو استورد خدمات النمو من مزود خارجي مُهيأ بكميات كبيرة بدلاً من واحدة تلو الأخرى.
3. أنشئ مفتاح API وأكد دورك باستدعاء نقطة نهاية الملف الشخصي قبل أي شيء آخر.
4. إذا كنت تنفذ يدويًا، ابنِ على نقطة نهاية السحب من البداية. التحول من السرد إلى السحب بعد أن تكون قد أرسلت تسليمات مكررة هو يوم أسوأ من قراءة هذه الفقرة.
5. اضبط ساعات الضمان لكل قائمة عمدًا. إنها الساعة التي يعمل ضدها كل حماية للمشتري على المنصة، وتبدأ من التسليم.