چرا استعلام شاهکار برای سیم‌کارت شرکتی «تطابق ندارد» می‌دهد؟

اگر استعلام شاهکار برای یک شماره موبایل «تطابق ندارد» برگرداند، یعنی فقط همین: در پایگاهی که پرسیده‌ایم، این شماره به نام این کد ملی ثبت نشده. نه بیشتر، نه کمتر. دلیلش را هیچ‌کس در پاسخ نمی‌نویسد، و اغلب دلیل، تقلب نیست.

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

یک پاسخ منفی، چند علت ممکن

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

علت‌هایی که در عمل پشت این بیت پنهان می‌شوند:

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

چه چیزی را از بیرون می‌شود تشخیص داد

بخشی از علت‌ها را پیش از ارسال می‌شود فیلتر کرد و بخشی را هرگز.

قابل‌فیلتر: کد ملی نامعتبر و موبایل بدشکل. هر دو در API ما پیش از رسیدن به سرویس مرجع رد می‌شوند و پاسخ invalid_input می‌گیرند. چنین درخواستی صورتحساب نمی‌شود؛ مستندات API خطاها و اینکه کدام‌ها هزینه دارند را کنار هم گذاشته است. شما هم می‌توانید همین بررسی را سمت خودتان انجام دهید تا کاربر بی‌دلیل منتظر نماند.

غیرقابل‌فیلتر: هر چیزی که در پایگاه ثبت اتفاق افتاده. اینجا هیچ کد خطایی نیست که بگوید «خط شرکتی است» یا «تازه منتقل شده». پاسخ، یک matched: false ساده است، و در API ما یک پاسخ معتبر محسوب می‌شود و هزینه دارد، چون پرسش انجام شده و جواب گرفته‌ایم.

چرا سیم‌کارت شرکتی خاص است

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

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

به نظر من تصمیم غلطِ رایج این است که پاسخ منفی را به «رد شد» ترجمه کنند. درست‌ترش این است که آن را به «این مسیر تأیید نشد» ترجمه کنید و مسیر دیگری جلوی کاربر بگذارید. در راهنمای ساخت جریان ثبت‌نام با شاهکار سه مسیر جایگزین را مفصل نوشته‌ایم.

کاربر چه کاری می‌تواند بکند

شما ابزاری برای تغییر ثبت‌ها ندارید، ولی کاربر دارد. اگر پیام خطای شما راه را نشان بدهد، خیلی از پاسخ‌های منفی بدون تیکت حل می‌شوند.

1. شماره دیگری را امتحان کند. بسیاری از کاربران بیش از یک خط دارند. پیام «این شماره به نام شما ثبت نشده، شماره دیگری را امتحان کنید» ساده‌ترین راه است.
2. بداند چند خط به نامش است. رگولاتور سامانه‌ای دارد که با کد ملی تعداد خط‌های ثبت‌شده را نشان می‌دهد؛ نشانی آن را در راهنمای زومیت درباره استعلام سیم‌کارت‌های ثبت‌شده می‌بینید. ما آن سامانه را کنترل نمی‌کنیم و پیشنهاد نمی‌کنیم در محصولتان به آن وابسته شوید؛ فقط برای راهنمایی کاربر مفید است.
3. مالکیت خط را منتقل کند. این کار نزد اپراتور انجام می‌شود، و چه زمانی اثرش در پایگاه دیده شود به اپراتور بستگی دارد. وعدهٔ زمان نده.

در سیستم خودتان چه ثبت کنید

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

شماره موبایل و کد ملی را هم در لاگ خام ننویسید. نتیجه کافی است، و اگر مجبورید نشانه‌ای نگه دارید، شکل پوشانده‌شده (چهار رقم آخر) بس است.

آنچه این سرویس نمی‌کند

بگذارید دقیق باشیم تا انتظار اشتباه ساخته نشود.

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

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

بدنه‌ای که به API می‌فرستید دو کلید دارد. موبایل را با 09، با +98 یا با ارقام فارسی هم بفرستید، پیش از اعتبارسنجی یکدست می‌شود.

bash curl -X POST 'https://example.com/api/v1/shahkar/' \ -H 'Authorization: Bearer melli_live_…' \ -H 'Content-Type: application/json' \ -d '{"nationalCode":"0013542419","mobile":"09120000000"}'

در پاسخ، data همان خروجی سرویس مرجع است. اگر matched نادرست بود، billing.amountRial نشان می‌دهد این پرسش حساب شده، و نبودن آن یعنی چیزی کسر نشده.

اگر عجله دارید

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