يتيح برنامج متجر كروت الشحن للشركات بيع شحن الألعاب، وبطاقات الهدايا، واشتراكات البرمجيات، وأرقام تعبئة شركات الاتصالات، وغيرها من الأكواد عبر الإنترنت، مع تسليم الكود للعميل خلال ثوانٍ من الدفع. يبدو المنتج بسيطاً من واجهة المتجر، لكن الجزء الخلفي من النظام يجب أن يتعامل مع مخزون يُقاس بالأكواد، ومدفوعات قد تفشل أحياناً بعد أن تكون الأموال قد انتقلت، وموردين يجب مطابقة حساباتهم. يعرض هذا الدليل الميزات التي نوصي ببنائها من البداية، استناداً إلى عملنا في منصات السلع الرقمية.
كيف يختلف برنامج متجر كروت الشحن عن المتجر الإلكتروني العادي
يتتبع المتجر الفعلي وحدات تُلتقط وتُعبأ وتُشحن. أما متجر الكروت فيتتبع قيماً سرية يجب أن تصل إلى مشترٍ واحد فقط، ولا يجوز عرضها مرتين. هذا الفرق وحده يغيّر معظم قرارات التصميم.
- المخزون عبارة عن مجموعة أكواد، وليس عدداً من الوحدات. لكل كود مورد وفئة وتكلفة وحالة.
- التسليم هو المنتج. إذا لم يظهر الكود في حساب العميل أو رسالته بسرعة، فالطلب فشل حتى لو نجح الدفع.
- الاسترجاع والنزاعات أصعب. بمجرد كشف الكود غالباً لا يمكن للمتجر استخدامه، لذلك يجب أن يؤكد مسار الطلب الدفع قبل كشف أي شيء.
- الهوامش ضيقة والحجم كبير، لذلك تكون التسوية مع الموردين ومزودي الدفع أهم مما هي عليه في معظم تجارة التجزئة.
الميزات الأساسية التي يجب بناؤها من اليوم الأول
1. مخزون الأكواد مع قواعد تخصيص صارمة
مجموعة الأكواد هي قلب النظام. تُستورد الأكواد من الموردين (عادة كملف أو عبر واجهة برمجية)، وتُخزن مشفرة، وتُربط بمنتج وفئة محددة. عند دفع الطلب، يخصص النظام كوداً متاحاً واحداً ويضع عليه علامة "مباع" في عملية واحدة. لا ينبغي أبداً أن يحصل مشتريان على الكود نفسه، حتى في أوقات الازدحام الشديد. ولهذا نستخدم قفل مستوى قاعدة البيانات أو التحديثات الذرية للتخصيص، بدلاً من استعلام بسيط "اختر ثم حدّث".
2. التسليم بعد الدفع أولاً
يجب أن يكون ترتيب العملية كالتالي: إنشاء الطلب، ثم حجز كود، ثم استلام الدفع، ثم تأكيد الدفع، ثم كشف الكود. إذا فشل الدفع أو انتهت مهلته، يُعاد الحجز إلى المجموعة. قد ترسل مزودو الدفع التأكيدات متأخرة أو مرتين، لذلك يجب أن يكون النظام idempotent، بحيث لا يؤدي التأكيد المكرر إلى تخصيص كود ثانٍ. وتفيد المهام الخلفية هنا في إعادة محاولة التأكيدات وتحرير الحجوزات المنتهية.
3. الدفع المحلي وبطاقات الدفع
يدفع العملاء في الشرق الأوسط وشمال أفريقيا غالباً عبر المحافظ الإلكترونية المحلية، أو التحويلات البنكية، أو البطاقات مسبقة الدفع، بينما يستخدم آخرون البطاقات الدولية. صمم صفحة الدفع بحيث يمكن إضافة وسائل دفع جديدة دون إعادة كتابة مسار الطلب. اعرض الإجمالي بالعملة المحلية، واحفظ سعر الصرف المستخدم وقت الشراء حتى تبقى التقارير اللاحقة متطابقة.
4. محفظة العميل
تتيح المحفظة للعميل أن يشحن رصيداً مرة واحدة ويشتري مراراً دون إعادة إدخال بيانات البطاقة. كما تقلل المدفوعات الفاشلة، وتمنح الشركة سيولة يمكنها التخطيط لها. أرصدة المحافظ التزامات مالية، لذلك يجب أن يكون كل إيداع وسحب قيداً في دفتر أستاذ مرتبطاً بالطلب أو عملية الشحن، لا رقماً واحداً يُعدَّل مباشرة.
5. سجل الطلبات وإثبات التسليم
يحتاج العملاء إلى إيجاد كود اشتروه الأسبوع الماضي دون التواصل مع الدعم. احتفظ بسجل للطلبات يتضمن الحالة والتوقيت وطريقة آمنة لعرض الكود مرة أخرى. ويحتاج موظفو الدعم إلى الرؤية نفسها، مع القدرة على رؤية الجدول الزمني للطلب دون رؤية الأكواد، إلا إذا سمح دورهم بذلك.
6. تنبيهات الموردين والمخزون
عندما تنخفض فئة ما عن حد معين، ينبغي أن يعلم الفريق بذلك قبل أن يرى العملاء عبارة "غير متوفر". التنبيهات عبر البريد الإلكتروني أو لوحة المتابعة، مع مراعاة مدد توريد الموردين، تمنع ضياع المبيعات. وتتبّع الأكواد المباعة مقابل فواتير الموردين حتى يتمكن الفريق من تأكيد المستحقات.
7. ضوابط الاحتيال وإساءة الاستخدام
تجذب السلع الرقمية الاستردادات المصرفية والمشتريات الآلية وبيانات الدفع المسروقة. تشمل الضوابط الأساسية تحديد معدل الطلبات لكل حساب ولكل عنوان IP، وفحص السرعة للمدفوعات الفاشلة، وقواعد مراجعة يدوية للطلبات الكبيرة أو غير المعتادة، وحظر المحاولات المتكررة للبطاقات. سجّل كل كشف لكود مع المستخدم والوقت والجهاز، حتى يمكن التحقيق في النزاعات.
8. التقارير والتسوية المالية
يحتاج قسم المالية إلى ثلاثة أرقام يومياً: ما الذي بيع، وما الذي دُفع، وما الذي سُلّم. يجب أن تطابق التقارير كل عملية بيع مع تكلفة المورد ورسوم الدفع وأي استرداد إن وُجد. يوفّر التصدير الشهري إلى نظام المحاسبة ساعات من المطابقة اليدوية. وغالباً ما تغطي أعمالنا في أنظمة ERP هذا الربط بين المبيعات والمخزون ودفتر الأستاذ.
مقارنة الميزات: ما الأهم عند الإطلاق
| الميزة | لماذا تهم | أولوية البناء |
|---|---|---|
| التخصيص الذري للأكواد | يمنع تكرار الأكواد وشكاوى العملاء | ضرورية |
| الكشف بعد الدفع مع تحرير الحجز | يمنع منح الأكواد لطلبات غير مدفوعة | ضرورية |
| webhooks دفع idempotent | التأكيدات المتأخرة أو المكررة لا تسبب تسليماً مزدوجاً | ضرورية |
| تشفير تخزين الأكواد وسجلات الكشف | يحمي الأكواد ويدعم معالجة النزاعات | ضرورية |
| محفظة العميل مع قيود دفتر الأستاذ | تكرار الشراء وإدارة أفضل للسيولة | عالية |
| تنبيهات المخزون وتتبع الموردين | يتجنب خسائر نفاد المخزون | عالية |
| تصدير المحاسبة والتسوية | يقلل جهد نهاية الشهر | عالية |
| تحليلات متقدمة وتوصيات | مفيدة بعد استقرار الحجم | لاحقاً |
تسلسل بناء عملي
- ارسم مسار الأموال والأكواد. ارسم كل مسار يمكن أن يسلكه الكود، من المورد إلى محجوز، ثم مباع، ثم مكشوف، ثم مسترد أو منتهٍ.
- ابنِ مجموعة الأكواد والتخصيص أولاً. اختبرهما تحت عمليات شراء متزامنة قبل إضافة أي تصميم لواجهة المتجر.
- اربط مزود دفع واحداً واختبر حالات النجاح والفشل وانتهاء المهلة وتكرار الـ webhooks.
- أضف التسليم وسجل الطلبات، بما في ذلك سجل الكشف.
- أطلق بمنتج أو منتجين، ثم أضف الفئات والمحافظ والموردين الإضافيين بعد أن تصبح التسوية صحيحة.
يشبه هذا التسلسل النهج المرحلي الموضح في دليلنا حول الجداول الزمنية لتطوير البرمجيات المخصصة. يمكن تسليم إصدار أول مركّز بسرعة، بينما تُضاف بقية المنتجات ووسائل الدفع في إصدارات لاحقة.
أخطاء يجب تجنبها
- كشف الأكواد قبل تأكيد الدفع. هذا أغلى خطأ في هذا المجال.
- تخزين الأكواد كنص عادي أو إرسالها عبر بريد إلكتروني غير مشفر.
- معاملة أرصدة المحافظ كرقم واحد قابل للتعديل. بدون دفتر أستاذ لا يستطيع الدعم تفسير الرصيد.
- تأجيل التسوية. تتراكم الفروقات بسرعة عندما تكون هناك آلاف الطلبات الصغيرة.
متى تبني نظاماً مخصصاً ومتى تبدأ من منتج جاهز
تتعامل منشئات المتاجر الجاهزة مع صفحات المنتجات والدفع، لكن كثيراً منها لا يتعامل جيداً مع مجموعات الأكواد واستيراد الموردين ودفاتر أستاذ المحافظ. إذا كان هامشك يعتمد على هذه التفاصيل، فغالباً يكون النظام المخصص أو منصة موسعة بشكل كبير هو الخيار الأفضل. يتضمن ملف أعمالنا متجراً أردنياً للسلع الرقمية يغطي التسليم الفوري للأكواد، والدفع المحلي وببطاقات الدفع، ومحفظة للعملاء، وهو مرجع مفيد لتحديد النطاق.
إذا كنت تخطط لمتجر من هذا النوع، فـاطلب استشارة وأحضر قائمة الموردين لديك، والحجم اليومي المتوقع، ووسائل الدفع التي يستخدمها عملاؤك. هذه المدخلات الثلاثة كافية لتحديد حجم الإصدار الأول. وللأعمال الأوسع في المنصات، اطلع على مجموعة خدماتنا الكاملة.
الأسئلة الشائعة
ما الفرق بين برنامج متجر كروت الشحن ومنصة التجارة الإلكترونية العادية؟
تدير المنصة العادية وحدات مادية تُشحن لاحقاً. أما برنامج متجر كروت الشحن فيدير مجموعة من الأكواد السرية، ويسلمها فوراً بعد الدفع، ويجب أن يمنع بيع أي كود أو كشفه مرتين. وهذا يتطلب تخصيصاً ذرياً، وتسليماً بعد الدفع، وسجلات كشف تفصيلية.
هل يمكنني استيراد الأكواد من الموردين تلقائياً؟
نعم، تستورد معظم المتاجر الأكواد من ملفات الموردين أو الواجهات البرمجية. يجب أن يتحقق الاستيراد من كل كود، ويكتشف التكرار، ويشفّر القيم، ويربطها بالمنتج والتكلفة الصحيحة. كما تجعل عمليات الاستيراد الآلية تنبيهات المخزون أدق.
ماذا يحدث إذا نجح الدفع لكن فشل تسليم الكود؟
يعيد النظام المصمم جيداً محاولة التسليم عبر المهام الخلفية، ويُبقي الطلب في حالة واضحة إلى أن يُعرض الكود أو يُسترد المبلغ. يجب أن يرى موظفو الدعم الجدول الزمني للطلب وحالة الكشف. ويجب دائماً ربط الدفع وتخصيص الكود بمرجع طلب واحد.
كم يستغرق بناء النسخة الأولى؟
يمكن تسليم إصدار أول مركّز يضم عدداً محدوداً من المنتجات ومزود دفع واحداً وسجل طلبات أساسياً خلال أسابيع. وتأتي إضافة المحافظ والموردين المتعددين والتقارير المتقدمة عادة في إصدارات لاحقة. نتفق على المراحل الرئيسية قبل بدء البناء.
