اجعل Webhooks المالية آمنة عند التكرار

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

عُمَر العلوي مقال

تعتمد بوابات الدفع على إعادة المحاولة عندما لا يصلها رد واضح، وقد يصل Webhook نفسه مرتين أو بالتوازي. إذا نفذ النظام الإيداع عند كل وصول، يمكن أن يضيف الرصيد أكثر من مرة رغم أن الدفع حدث مرة واحدة.

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

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

شاركني رأيك

يسعدني مشاركة وجهة نظرك من خلال ترك تعليق في المقالة الأصلية في مواقع التواصل

مقالات مرتبطة

تطوير Backend وقواعد البيانات ·

اجعل Excel جزءًا من سير العمل داخل النظام

دعم الاستيراد والتصدير ليس كافيًا دائمًا؛ بعض المستخدمين يحتاجون إلى التعامل مع الجداول والمعادلات دون مغادرة النظام.

قراءة المقال

تطوير Backend وقواعد البيانات ·

ترحيل MySQL كبير دون إيقاف الخدمة

نسخة Hot Backup مع Replication قد تكون أنسب من mysqldump عندما تكون قاعدة الإنتاج كبيرة وتستمر فيها الكتابة أثناء الترحيل.

قراءة المقال