زیرساخت پیامکی برای سرویس های آنلاین؛ از OTP تا اعلان تراکنش

کاربر چند بار روی «ارسال مجدد کد» می زند، سه پیامک دریافت می کند و نمی داند کدام معتبر است. مشتری دیگری دو رسید پرداخت می گیرد و نگران برداشت دوباره پول می شود.

برای حل این مشکلات، سرویس OTP پیامکی باید به منطق درست برنامه متصل باشد. از جدول زیر شروع کنید و سپس مسیر ورود و اعلان پرداخت را مرحله به مرحله بسازید.

برای هر نیاز کدام مسیر ارسال را انتخاب کنیم

اول ورود و یک اعلان ضروری را راه اندازی کنید. مثلاً سرویس OTP پیامکی را برای ورود فعال کنید و اعلان پرداخت را اضافه کنید. اتصال همه رویدادهای محصول از روز اول، پیدا کردن خطا را دشوار می کند.

سرویس OTP پیامکی چه کاری انجام می دهد

سرویس OTP پیامکی رمز یکبارمصرف را به موبایل کاربر می فرستد. کاربر کد را وارد می کند و برنامه، اعتبار آن را بررسی می کند. نتیجه این فرایند، تأیید دسترسی به شماره است؛ نه اثبات هویت قانونی فرد.

قبل از برنامه نویسی، مسئولیت ها را مشخص کنید. اگر ارائه دهنده فقط پیام می فرستد، تولید کد و انقضا و اعتبارسنجی با شماست. اگر API تأیید هم دارد، رفتار ارسال مجدد، محدودیت تلاش و زمان اعتبار آن را بخوانید.

این تفاوت عملی است: موفق بودن درخواست ارسال، مجوز ورود کاربر نیست. ورود فقط پس از تأیید کد انجام می شود.

پیش از اتصال این اطلاعات را آماده کنید

برای استفاده از سرویس OTP پیامکی، کلید API، شناسه قالب، نام متغیرها، قالب شماره و روش دریافت وضعیت ارسال را مشخص کنید. شرایط مسیر خدماتی و ارسال به شماره های مسدودکننده تبلیغات را هم بپرسید.

برای بررسی وب سرویس پیامکی پیام رسان، صفحه https://payam-resan.com/web-service/ را ببینید. سپس قابلیت های موردنیاز پروژه را با مستندات جاری سرویس تطبیق دهید؛ به خصوص ارسال پترن و گزارش وضعیت.

اول یک درخواست آزمایشی از سرور بفرستید. پاسخ و شناسه پیام را ثبت کنید. وقتی ارسال کار کرد، آن را به فرم ورود متصل کنید.

ورود پیامکی را در چهار مرحله پیاده کنید

مرحله اول درخواست کد را از سرور بفرستید

در یک فروشگاه، کاربر شماره را وارد می کند. مرورگر باید درخواست را به بک اند فروشگاه بفرستد و بک اند، سرویس OTP پیامکی را فراخوانی کند.

کلید API را در JavaScript مرورگر یا اپلیکیشن قرار ندهید. آن را در تنظیمات امن سرور نگه دارید و در خروجی خطا نمایش ندهید.

شماره را یکسان سازی کنید. ورودی با ارقام فارسی، انگلیسی یا پیش شماره متفاوت نباید محدودیت ارسال را دور بزند. مثلاً شکل های معتبر یک شماره ایرانی را به یک قالب داخلی تبدیل کنید.

مرحله دوم برای کد یک درخواست مشخص بسازید

اگر مدیریت رمز با شماست، کد را با مولد تصادفی امن تولید کنید. رکورد درخواست باید شماره، هدف، زمان انقضا، شمارنده تلاش و وضعیت مصرف را داشته باشد.

کد ورود را برای تغییر شماره نپذیرید. هدف هر درخواست را جدا ثبت کنید. برای نگهداری کد نیز از سازوکاری مانند HMAC با کلید محرمانه سرور استفاده کنید و مقدار خام را در لاگ ننویسید.

به نقل از OWASP:

OTPs are authentication secrets and should be handled with password-like hygiene.

ترجمه: رمزهای یکبارمصرف اطلاعات محرمانه احراز هویت هستند و باید با مراقبت هایی مشابه گذرواژه مدیریت شوند.

در عمل، سرویس OTP پیامکی نباید باعث ذخیره کد در ابزار تحلیل رفتار، گزارش خطا یا لاگ درخواست شود. برای عیب یابی، شناسه درخواست و وضعیت آن کافی است.

مرحله سوم ارسال مجدد را محدود کنید

این تنظیمات، نمونه اولیه برای آزمایش هستند و باید با ریسک و رفتار کاربران تنظیم شوند:

کنترل ها را در سرور اعمال کنید. غیرفعال کردن دکمه در مرورگر، جلوی درخواست مستقیم به API را نمی گیرد. محدودیت را بر شماره یا حساب و IP اعمال کنید؛ IP به تنهایی کافی نیست.

به نقل از NIST:

Generating a new authentication secret SHALL NOT reset the failed authentication count.

ترجمه: تولید یک رمز احراز هویت جدید نباید شمارنده تلاش های ناموفق احراز هویت را صفر کند.

یعنی مهاجم نباید با هر درخواست کد جدید، پنج فرصت تازه برای حدس زدن بگیرد. در سرویس OTP پیامکی، سقف ارسال و سقف تلاش تأیید را جداگانه مدیریت کنید.

مرحله چهارم کد را یک بار مصرف کنید

هنگام تأیید، انقضا، هدف، شماره و تطابق کد را بررسی کنید. تأیید و تغییر وضعیت به مصرف شده باید در یک عملیات اتمیک انجام شود تا دو درخواست هم زمان نتوانند با یک کد وارد شوند.

پس از موفقیت، نشست کاربر را ایجاد کنید. با صدور کد جایگزین، کد قبلی را بی اعتبار کنید. اگر سرویس خارجی تأیید را انجام می دهد، نتیجه آن را در بک اند بررسی کنید و به پاسخ مرورگر اعتماد نکنید.

نمونه پیام قابل استفاده:

فروشگاه سپید
کد ورود: ۴۸۲۱۹۶
اعتبار: ۲ دقیقه
این کد را در اختیار دیگران نگذارید.

اگر کد دیر رسید تجربه ورود را خراب نکنید

فرض کنید کاربر کد دوم را درخواست کرده و بعد، پیامک اول می رسد. اگر کد اول بی اعتبار شده باشد، باید در فرم بنویسید: «کد مربوط به آخرین درخواست را وارد کنید».

قبل از ارسال مجدد، شماره را به صورت پوشیده نشان دهید؛ مثلاً «ارسال به ۰۹۱۲***۴۵۶۷». امکان اصلاح شماره را هم بگذارید. گاهی مشکل سرویس نیست؛ کاربر یک رقم را اشتباه وارد کرده است.

برای سرویس OTP پیامکی، صف جدا از اعلان های انبوه در نظر بگیرید. پردازشگر باید کد منقضی را از صف حذف کند. کدی که بعد از پایان اعتبار فرستاده شود، فقط یک پیامک هزینه دار و بی فایده است.

رسید پرداخت را به رویداد معتبر وصل کنید

در پرداخت آنلاین، بازگشت کاربر از درگاه کافی نیست. مسیر اجرا را این طور طراحی کنید:

1. نتیجه پرداخت را در سرور با درگاه تأیید کنید.

2. وضعیت پرداخت و رویداد اعلان را در یک تراکنش پایگاه داده ذخیره کنید.

3. برای رویداد، کلید یکتا مانند ترکیب «شناسه پرداخت و نوع اعلان» ثبت کنید.

4. پردازشگر پس زمینه، رویداد را بخواند و پیامک را ارسال کند.

این روش، همان الگوی Transactional Outbox است. اگر سرور بعد از ثبت پرداخت متوقف شود، رویداد باقی می ماند و بعداً پردازش می شود. callback تکراری هم نباید رویداد جدید بسازد.

پرداخت موفق را به موفقیت پیامک وابسته نکنید. قطع ارسال پیام نباید سفارش پرداخت شده را ناموفق نشان دهد. وضعیت مالی و وضعیت اعلان را جدا ذخیره کنید.

نمونه پیام:

فروشگاه سپید
پرداخت سفارش ۷۵۲۴ ثبت شد.
وضعیت سفارش در حساب کاربری شما قابل مشاهده است.

درخواست ناموفق را کورکورانه تکرار نکنید

اگر کلید API یا متغیر قالب اشتباه باشد، ارسال دوباره همان درخواست مشکل را حل نمی کند. خطا را ثبت کنید و تنظیمات یا داده را اصلاح کنید.

برای خطای موقت، تلاش مجدد محدود با فاصله افزایشی بگذارید. تعداد تلاش و زمان پایان را مشخص کنید. برای OTP، این زمان نباید از اعتبار کد عبور کند.

اما timeout وضعیت متفاوتی دارد: ممکن است سرویس درخواست را پذیرفته باشد و پاسخ به شما نرسیده باشد. ابتدا امکان پیگیری یا استفاده از کلید جلوگیری از تکرار را در مستندات بررسی کنید. بدون این قابلیت ها، ارسال دقیقاً یک باره را تضمین شده فرض نکنید.

هزینه و کیفیت ارسال را قابل اندازه گیری کنید

برای سرویس OTP پیامکی، فقط موجودی پنل را نگاه نکنید. این سه شاخص به تصمیم عملی کمک می کنند:

• نرخ تأیید کد: درخواست های تأییدشده تقسیم بر درخواست های واجد شرایط دریافت کد. تعریف مخرج را ثابت نگه دارید.

• نرخ درخواست مجدد: سهم جریان های ورود که به کد دوباره نیاز دارند. افزایش آن، بررسی تأخیر و رابط کاربری را ضروری می کند.

• سن رویدادهای ارسال نشده: زمان گذشته از ثبت اعلان تا پردازش. افزایش آن می تواند نشانه عقب افتادن صف باشد.

برای تشخیص سوءاستفاده، افزایش ناگهانی درخواست از یک شماره، IP یا الگوی شماره ها را بررسی کنید. سقف مصرف و هشدار بگذارید؛ هر افزایش هزینه، رشد واقعی کاربران نیست.

پیش از انتشار این موارد را تست کنید

سرویس OTP پیامکی را با کد صحیح، اشتباه، منقضی و مصرف شده آزمایش کنید. دو درخواست تأیید هم زمان بفرستید و مطمئن شوید فقط یکی موفق می شود.

سپس callback پرداخت را دوبار اجرا کنید و سرویس پیامک را موقتاً از دسترس خارج کنید. باید یک رویداد اعلان ساخته شود و پرداخت موفق باقی بماند. وضعیت ارسال مبهم را هم جدا از شکست قطعی ثبت کنید.

سوالات متداول

چرا سرویس OTP پیامکی موفق است اما کد به کاربر نرسیده

پاسخ موفق API ممکن است فقط پذیرش درخواست باشد. شناسه پیام و گزارش تحویل را بررسی کنید. سپس شماره، قالب، وضعیت مسیر ارسال و زمان باقی مانده اعتبار کد را کنترل کنید.

چرا کاربر چند کد دریافت می کند و هیچ کدام پذیرفته نمی شود

ممکن است درخواست های هم زمان یا تأخیر پیامک باعث بی اعتبار شدن کد قبلی شده باشد. صدور کد را برای هر شماره و هدف کنترل کنید و در فرم، ورود کد آخرین درخواست را توضیح دهید.

چرا مشتری دو پیامک رسید پرداخت دریافت می کند

callback تکراری یا تلاش مجدد پس از timeout می تواند علت باشد. ابتدا یکتایی رویداد را کنترل کنید. سپس وضعیت درخواست قبلی و امکانات جلوگیری از تکرار در API ارائه دهنده را بررسی کنید.

آیا سرویس OTP پیامکی برای ورود مدیر کافی است

کد پیامکی در برابر فیشینگ مصون نیست و دسترسی به شماره هم ممکن است به خطر بیفتد. برای حساب های حساس، روش مقاوم در برابر فیشینگ مانند Passkey و مسیر بازیابی کنترل شده را ارزیابی کنید.

اتصال را با ورود و اعلان پرداخت شروع کنید

یک قالب کد ورود و یک قالب رسید پرداخت آماده کنید. محدودیت درخواست، اعتبار کد، رویداد یکتا و پیگیری ارسال را پیش از انتشار فعال کنید.

برای راه اندازی سرویس OTP پیامکی، مستندات وب سرویس پیام رسان را بررسی کنید و دریافت کلید API و شرایط فعال سازی قالب را از پنل یا پشتیبانی پیگیری کنید. اتصال را با شماره آزمایشی شروع کنید و بعد از عبور از سناریوهای خطا، در اختیار کاربران قرار دهید.