وب سرویس پیامکی خدماتی برای اطلاع رسانی سفارش و کد تأیید

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

پیامک خدماتی چه تفاوتی با تبلیغات دارد

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

عنوان «خدماتی» به تنهایی به معنی دسترسی بدون شرط به همه شماره ها نیست. صفحه رسمی پیام رسان توضیح می دهد که ارسال به شماره های مسدودکننده تبلیغات، تابع شرایط خط خدماتی و ضوابط سرویس است؛ تأیید الگو نیز تحویل را تضمین نمی کند. این شرایط را پیش از طراحی مسیر ارسال بررسی کنید.

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

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

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

1. شماره مقصد را مطابق قالب همان متد نرمال و اعتبارسنجی کنید.
2. شناسه الگوی تأییدشده و متغیرهای لازم را از داده معتبر بسازید.
3. درخواست را با HTTPS و زمان انتظار مشخص ارسال کنید.
4. نتیجه عملیات و شناسه پیام را ذخیره و وضعیت تحویل را پیگیری کنید.

در پیام رسان، نمونه ارسال الگویی از فیلدهای ApiKey، TemplateKey، Destination و p1 استفاده می کند. مقادیر نمونه را مستقیم وارد محیط عملیاتی نکنید؛ الگو و پارامترهای حساب خودتان باید جایگزین شوند.

نتیجه ارسال را در چند سطح بررسی کنید

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

اعلان سفارش را به تغییر واقعی وضعیت متصل کنید

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

برای هر ترکیب سفارش و نوع اعلان، یک رکورد یکتا بسازید. این کنترل جلوی ایجاد دوباره کار ارسال بر اثر اجرای تکراری رویداد را می گیرد؛ بااین حال، ابهام ناشی از قطع شبکه همچنان به پیگیری نیاز دارد. نمونه متن: «سفارش شما ثبت شد. وضعیت سفارش را از حساب کاربری پیگیری کنید.»

کد تأیید به کنترل امنیتی جداگانه نیاز دارد

در راهنمای NIST SP 800-63B-4 در سال ۲۰۲۵، برای راز تصادفی احراز هویت خارج از باند، حداقل ۶ رقم ده دهی یا معادل آن تعیین شده است. همچنین احراز هویت باید حداکثر ظرف ۱۰ دقیقه تکمیل شود؛ این سقف، الزام به انتخاب اعتبار ده دقیقه ای نیست. این ها الزامات همان راهنما هستند، نه مشخصات همه سرویس های ایرانی. 

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

همانطور که در pages.nist.gov گفته شده: «Out-of-band authentication is not phishing-resistant.»

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

پرسش های متداول

آیا هر اتصال API ارسال خدماتی دارد

خیر؛ نوع خط، دسترسی حساب و شرایط الگو باید بررسی شود.

آیا کد تأیید را باید در مرورگر تولید کرد

خیر؛ تولید و اعتبارسنجی کد را در سمت سرور انجام دهید.

برای تشخیص تحویل چه چیزی ذخیره کنیم

شناسه پیام و وضعیت های دریافتی را کنار رکورد ارسال نگه دارید.

آیا ثبت سفارش و تأیید پرداخت یک رویداد هستند

لزوماً خیر؛ متن هر اعلان باید وضعیت واقعی همان رویداد را بیان کند.

پیش از راه اندازی چه سناریوهایی را آزمایش کنیم

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

منبع: payam-resan