شاهکار در فرم ثبت‌نام: ترتیب، پاسخ منفی و محدودیت تلاش

در ثبت‌نام، شاهکار جای رمز یک‌بارمصرف را نمی‌گیرد؛ کنارش می‌نشیند. هر کدام یک سؤال متفاوت را جواب می‌دهند، و جریانی که این دو را قاطی کند یا کاربر درست را می‌رانَد یا کاربر جعلی را راه می‌دهد.

این نوشته برای کسی است که می‌خواهد استعلام شاهکار را در فرم ثبت‌نام بگذارد و می‌پرسد: کجای جریان؟ با کدام ترتیب؟ و وقتی جواب منفی بود چه؟

دو سؤال که اغلب یکی فرض می‌شوند

رمز یک‌بارمصرف می‌پرسد: این آدم الان به این گوشی دسترسی دارد؟

شاهکار می‌پرسد: این شماره به نام این کد ملی ثبت شده؟

کسی که کد ملی دیگری را دارد و گوشی خودش را، از OTP رد می‌شود و از شاهکار نه. کسی که سیم‌کارت پدرش را در دست دارد، از OTP رد می‌شود و از شاهکار هم رد می‌شود، با اینکه کلاهبردار نیست. بنابراین دو آزمون دو چیز متفاوت را می‌سنجند و جایگزین هم نیستند. تفاوت سومی هم هست، تشخیص زنده‌بودن چهره، که در راهنمای رمز یک‌بارمصرف، شاهکار و تشخیص چهره آمده؛ آن را اینجا تکرار نمی‌کنم.

ترتیب پیشنهادی

اگر جای شما بودم، این ترتیب را می‌گذاشتم:

1. فرم را بگیرم: کد ملی و موبایل.
2. اعتبارسنجی محلی: رقم کنترلی کد ملی و قالب موبایل. هزینه‌ای ندارد و خطای ورودی را پیش از هر پرسشی می‌گیرد.
3. OTP به همان موبایل.
4. فقط پس از تأیید OTP، شاهکار.

چرا شاهکار پس از OTP؟ چون پرسش شاهکار هزینه دارد و پاسخ منفی‌اش هم هزینه دارد. اگر اول OTP بگیرید، کسانی که اصلاً به گوشی دسترسی ندارند همان‌جا می‌ایستند و بابت آن‌ها پرسشی انجام نمی‌شود. کسی که ماشین‌وار هزار کد ملی را امتحان می‌کند، پول شما را نمی‌سوزاند.

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

وقتی پاسخ منفی است

اینجا جریان خوب از جریان بد جدا می‌شود. پاسخ matched: false چند علت بی‌گناه دارد (خط شرکتی، خط والدین، انتقال تازه). علت‌ها را در راهنمای پاسخ منفی شاهکار برای سیم‌کارت شرکتی باز کرده‌ایم. اینجا فقط خروجی تصمیم را می‌گویم.

سه مسیر معقول پشت پاسخ منفی:

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

چیزی که نباید بکنید: «حساب شما رد شد» و تمام. کاربری که یک بار این پیام را ببیند، برنمی‌گردد.

محدودیت تعداد تلاش

شاهکار سدّی است در برابر سوءاستفاده، ولی خودش را هم باید در برابر سوءاستفاده نگه دارید. کسی که می‌تواند بی‌نهایت جفت کد ملی و موبایل بفرستد، می‌تواند از فرم شما یک ابزار تأیید رایگان بسازد.

• برای هر IP و هر نشست سقف تلاش بگذارید.
• برای هر کد ملی در بازهٔ زمانی، تعداد پرسش را محدود کنید.
• پاسخ را به کاربر دقیق‌تر از «مطابقت دارد/ندارد» نشان ندهید.

آخری مهم است: اگر فرم شما اعلام کند «این کد ملی با این شماره نمی‌خواند ولی با شمارهٔ دیگری ثبت شده»، شما اطلاعاتی را فاش کرده‌اید که حتی سرویس مرجع هم فاش نمی‌کند. شاهکار عمداً فقط بله و خیر می‌دهد.

کش و تکرار

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

پاسخ API فیلدی به نام source دارد که می‌گوید پاسخ از کش آمده یا نه. به آن تکیه نکنید که تکراری‌ها را برایتان حذف کند؛ منطق نشست مال خودتان است.

یک نمونه برای فهم جریان

تصور کنید یک مارکت‌پلیس فروشنده می‌پذیرد. فروشنده‌ای کد ملی و شماره‌اش را وارد می‌کند، OTP می‌گیرد و درست وارد می‌کند. شاهکار منفی برمی‌گردد. جریان شما می‌تواند بگوید: «شماره‌ای که وارد کردید به نام شما ثبت نشده است. اگر خط شرکتی است یا به نام فرد دیگری است، یک شماره دیگر وارد کنید یا مدرک بارگذاری کنید.» هر دو راه روشن‌اند، هیچ‌کدام کاربر را متهم نکرده‌اند.

خطاها را از پاسخ منفی جدا کنید

سه چیز در سمت شما شبیه هم دیده می‌شوند و باید سه مسیر جدا داشته باشند:

ردیف سوم را بیشتر تیم‌ها جا می‌اندازند. اگر سرویس مرجع جواب نداد و شما کاربر را رد کردید، خرابی آن سمت را به حساب کاربر نوشته‌اید. در مستندات API فهرست کدهای خطا و اینکه کدام صورتحساب می‌شوند آمده است؛ به کد تکیه کنید و نه به متن پیام.

یک اسکلت ساده برای تصمیم‌گیری سمت سرور:

js const res = await fetch('https://example.com/api/v1/shahkar/', { method: 'POST', headers: { Authorization: Bearer ${process.env.MELLIAPI_API_KEY}`, 'Content-Type': 'application/json', }, body: JSON.stringify({ nationalCode, mobile }), }); const body = await res.json();

if (body.ok && body.data?.matched === true) return 'verified'; if (body.ok) return 'try-another-path'; // matched: false if (body.error?.code === 'invalid_input') return 'fix-field'; return 'retry-later'; // خرابی از ما یا مرجع، نه تقصیر کاربر ```

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

چه چیزی را اندازه بگیرید

پس از راه‌اندازی، دو عدد را هفتگی نگاه کنید. اول، نسبت پاسخ‌های منفی به کل پرسش‌ها. اگر خیلی بالا باشد، فرم شما احتمالاً کاربر را به وارد کردن شمارهٔ اشتباه هدایت می‌کند (مثلاً شماره‌ای که جلوتر از همه در حافظهٔ مرورگرش بوده). دوم، از کسانی که پاسخ منفی گرفتند چند نفر ثبت‌نام را کامل کردند. عدد دوم می‌گوید مسیر دومتان کار می‌کند یا فقط روی کاغذ هست.

این دو عدد را هیچ مقاله‌ای برای شما حساب نمی‌کند؛ بستگی به مخاطب و محصول شما دارد. من هیچ عدد «طبیعی» نمی‌شناسم که بشود وعده داد.

آنچه شاهکار برای ثبت‌نام نمی‌کند

• هویت کاربر را کامل نمی‌کند. تأیید می‌کند که یک شماره به یک کد ملی تعلق دارد، نه اینکه پشت صفحه همان آدم نشسته است. برای آن به مرحله‌ای مثل تشخیص زنده‌بودن چهره نیاز دارید.
• نام و مشخصات برنمی‌گرداند. اگر پر کردن خودکار نام را می‌خواهید، استعلام اطلاعات هویتی با تاریخ تولد کار می‌کند.
• پیش از شروع، وضعیت خط (فعال یا مسدود) را نمی‌گوید.
• جایگزین قانونی‌بودن جریان شما نیست؛ ذخیرهٔ کد ملی و موبایل قواعد خودش را دارد.

در یک نگاه

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