كيف تعمل دورة الطلب في المتاجر الإلكترونية؟ من Checkout إلى Delivery

السلة وCheckout والطلب: ثلاثة أشياء مختلفة

السلة قابلة للتغيير: يضيف العميل منتجًا ويحذف آخر ويترك الموقع. Checkout هو مرحلة التحقق من البيانات والأسعار والتوفر ووسيلة الدفع والشحن. أما الطلب فهو سجل تجاري لمحاولة شراء محددة.

احفظ داخل بنود الطلب لقطة وقت الشراء: اسم المنتج وSKU والكمية والسعر والخصم والضريبة والعملة. تغيير سعر المنتج لاحقًا لا ينبغي أن يعيد كتابة تاريخ الطلب القديم.

ماذا يحدث عند الضغط على إتمام الشراء؟

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

نظام إدارة الطلبات OMS

OMS هو المنطق الذي ينسق انتقال الطلب بين الدفع والمخزون والتجهيز والشحن والمرتجعات. لا يشترط شراء نظام منفصل؛ قد يبدأ بوحدة منظمة داخل التطبيق الحالي.

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

افصل حالات الدفع والتجهيز والشحن

حجز المخزون ومنع بيع الكمية نفسها مرتين

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

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

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

تأكيد الدفع يأتي من قناة موثوقة

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

توضح Paymob دور callbacks في نتيجة العملية. اربط نتيجة الدفع بالطلب الصحيح وتحقق من القيمة والعملة ومعرّف العملية، ثم طبق انتقال الحالة مرة واحدة. جلسات الدفع وPayment Intents أمثلة لنماذج لها دورة حياة، وليست مجرد زر ينجح أو يفشل فورًا.

المصدر: Paymob: API integration · Stripe: Payment Intents

الفشل وإعادة المحاولة دون طلبات أو مبالغ مكررة

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

استخدم معرّفات مستقرة للعمليات الحساسة وقيودًا في قاعدة البيانات. Idempotency تعني أن إعادة تنفيذ العملية المنطقية لا تضاعف أثرها. مفتاح API وحده لا يمنع تكرار الشحن أو خصم المخزون؛ كل أثر جانبي يحتاج حماية مناسبة.

المصدر: Stripe: idempotent requests

التجهيز والشحن والتسليم

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

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

المصدر: Bosta: shipment status webhooks

المرتجع ليس هو الاسترداد

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

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

قاعدة بيانات وسجل أحداث قابلان للمراجعة

• orders وorder_items لحفظ الطلب وبنوده كقيمة تاريخية.
• payment_attempts وrefunds لفصل محاولات الدفع والاسترداد.
• inventory_reservations وstock_movements لحفظ الحجز والحركة الفعلية.
• shipments وshipment_items لدعم أكثر من شحنة وتتبع جزئي.
• order_events وwebhook_inbox لتسجيل سبب كل تغيير ومنع تكرار الأحداث.

بنية مناسبة للحجم، لا تعقيد لمجرد التعقيد

ابدأ بتطبيق منظم بحدود واضحة للطلبات والدفع والمخزون. Headless يصف فصل الواجهة عن محرك التجارة، بينما Monolith وMicroservices يصفان تنظيم الخلفية؛ ليست هذه المصطلحات بدائل متعارضة دائمًا.

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

المراقبة والمصالحة والأمان

تابع الطلبات المدفوعة غير المجهزة، والحجوزات المنتهية، وزمن تأكيد الدفع، وتعثر الشحن والاسترداد. ضع عملية مصالحة دورية تقارن الحالات العالقة مع المزود وتصلحها أو ترفعها للمراجعة.

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