معظم مشاكل ربط OTP لا تتعلق بإرسال الرمز نفسه — بل بالقرارات الصغيرة حوله: مدة صلاحيته، عدد المحاولات المسموحة، وما يحدث عند فشل التسليم. تغطي هذه القائمة القرارات التي يستحق اتخاذها بوعي قبل الإطلاق.
قبل الإطلاق
- مدة صلاحية الرمز قصيرة وواضحة للمستخدم (راجع OTP والتحقق لمعرفة المدد النموذجية)
- حدّ أقصى لعدد محاولات التحقق لكل رمز، لا لكل جلسة فقط
- فترة زمنية دنيا بين طلبات إعادة الإرسال لنفس الرقم
- الرمز نفسه لا يُكتب أبداً في السجلات أو أحداث التحليلات أو أدوات الدعم الفني بما يتجاوز الحاجة الفعلية
- قوالب الرسائل مُتحقق منها مقابل حدود مقاطع GSM-7/Unicode، خصوصاً بالعربي — راجع دليل طول الرسالة والترميز أو أداة حساب المقاطع
التعامل مع فشل التسليم
الرمز الذي لا يصل يعني تذكرة دعم فني قادمة. قرر مسبقاً: هل يحصل المستخدم على خيار "إعادة الإرسال" فوراً أم بعد مهلة؟ هل توجد قناة احتياطية (راجع واتساب بزنس API) إذا أُبلغ عن فشل تسليم الرسالة النصية؟ بناء هذا القرار ضمن التدفق قبل الإطلاق يجنبك تعديلاً مرتبكاً لاحقاً.
الاختبار قبل الإطلاق الفعلي
- اختبر بقوالب رسائل عربية وإنجليزية، لا بلغة واحدة فقط
- اختبر مسار انتهاء صلاحية الرمز، لا المسار المثالي فقط
- اختبر ما يحدث عند طلب المستخدم عدة رموز بسرعة متتالية
- تأكد أن التعامل مع تقرير التسليم يُفعّل فعلياً منطق الاحتياط أو إعادة المحاولة الذي بنيته، لا ما كنت تنويه فقط
أسئلة شائعة
كم عدد المحاولات التي يجب إعطاؤها للمستخدم لإدخال رمز OTP؟
لا يوجد رقم موحّد، لكن معظم التطبيقات تحدده بعدد صغير (عادة 3-5) لكل رمز قبل طلب رمز جديد، لتقليل احتمالية التخمين العشوائي.
هل يجب تسجيل رموز OTP لأغراض تصحيح الأخطاء؟
تجنّب تسجيل قيمة الرمز نفسها، حتى في بيئات غير الإنتاج. سجّل أن طلب رمز تم/تحقق منه/فشل، لا الرمز نفسه.
ماذا يجب أن يحدث عند فشل تسليم OTP؟
قرر هذا قبل الإطلاق لا أثناء حادثة فعلية: خيار إعادة إرسال ظاهر، قناة احتياطية (راجع واتساب بزنس API)، أو كلاهما.