ملی ای‌پی‌آی

کارت، شبا یا شماره حساب: کدام را با کد ملی بسنجیم؟

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

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

سه سرویس این کار را می‌کنند: تطابق کد ملی و کارت، تطابق کد ملی و شبا و تطابق کد ملی و شماره حساب. هر سه می‌پرسند «این شناسه مال همین کد ملی است؟» و هر سه جواب بله یا خیر می‌دهند. تفاوتشان در ورودی، در رفتار در لحظهٔ خطا، و در چیزی است که کاربر از حفظ دارد.

هر سه چه می‌خواهند

کارتشباشماره حساب
کد ملیبلهبلهبله
تاریخ تولد شمسیبلهبلهبله
شناسهشانزده رقمIR و بیست‌وچهار رقمرشتهٔ ارقام با جداکننده‌ها
بانکلازم نیستلازم نیستلازم است
کنترل ساختار پیش از ارسالالگوریتم کنترلیرقم کنترلی شبافقط حداقل طول

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

کاربر کدام را بلد است

این سؤال از همه مهم‌تر است و ربطی به فناوری ندارد.

کارت. هر کاربر کارتش را دارد، می‌تواند عکس بگیرد، از برنامه کپی کند. کمترین اصطکاک. ولی کارت چیزی است که عوض می‌شود: گم می‌شود، منقضی می‌شود، تعویض می‌شود.

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

شماره حساب. عامه‌ترین نیست. بیشتر برای کسانی است که رسید یا دفترچه دارند. اغلب لازم نیست مستقیم از کاربر بگیرید؛ می‌توانید با شبا جایگزینش کنید.

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

خطا در لحظهٔ ورودی

سه خطای متمایز در همهٔ سه سرویس هست:

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

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

یک نمونه برای تصمیم‌گیری

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

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

سه شناسه برای سه مورد، ولی هر مورد فقط یک سنجش دارد. این نکته مهم است: شما مالکیت را برای مقصدی می‌سنجید که پول به آن می‌رود، نه برای همهٔ شناسه‌هایی که کاربر دارد.

چرا هر سه را نمی‌سنجید

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

یک استثنا: اگر کاربر دو حساب متفاوت دارد و هر دو را به‌عنوان مقصد ثبت می‌کند، هر دو را بسنجید. قاعده این است که «هر مقصدی که پول به آن می‌رود، یک بار».

وقتی کاربر شناسه‌اش را عوض کرد

کاربر کارتش را عوض می‌کند، شبا یا حساب جدیدی ثبت می‌کند. سنجش قبلی روی شناسهٔ قبلی بود و نباید به شناسهٔ جدید منتقل شود. مدل داده‌ای که نتیجه را به «کاربر» می‌چسباند، نه به «شناسه»، دیر یا زود یک واریز به مقصد بررسی‌نشده می‌سازد. نتیجه را کنار شناسه بنویسید (چهار رقم آخر کافی است): {userId, kind, last4, checkedAt, result}.

اگر سنجش نشد، واریز چه می‌شود

سه سیاست ممکن است و انتخابشان با شماست:

  1. هیچ واریزی تا تأیید. محتاط‌ترین. برای مبلغ بالا مناسب است.
  2. واریز با سقف. تا حد کم بدون تأیید، بالاتر از آن با تأیید. به شما انعطاف می‌دهد ولی قاعده باید نوشته و حسابرسی‌پذیر باشد.
  3. واریز و پیگیری بعدی. پرخطرترین. فقط وقتی که مبلغ ناچیز است و برگشت راحت.

من برای شروع سیاست اول را می‌گذارم و بعد شل می‌کنم، نه برعکس. کم‌کردن سخت‌گیری از روی داده‌ای که جمع کرده‌اید ساده است؛ سخت‌کردن بعد از یک حادثه، سخت.

ثبت‌نام و هزینه

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

تاریخ تولد، در هر سه

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

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

  • هیچ‌کدام نام صاحب را برنمی‌گردانند.
  • هیچ‌کدام موجودی یا مسدودی را نمی‌گویند.
  • هیچ‌کدام برای حساب شرکت با کد ملی شخص حقیقی معنا ندارند.
  • هیچ‌کدام علت پاسخ منفی را تفکیک نمی‌کنند.
  • «تعلق شناسه به کد ملی» با «اجازهٔ واریز» برابر نیست. قانون و قرارداد شما قاعدهٔ خودش را دارد.

برای هزینه و تعرفه هر سه، صفحهٔ قیمت را ببینید؛ عددش را من اینجا نمی‌نویسم چون عوض می‌شود.

پیشنهاد من

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

آخرین بازبینی: تیم تحریریه ملی ای‌پی‌آی

وب‌سرویس مرتبط با این راهنما

API تطابق کد ملی و شماره حساب

بررسی تعلق یک شماره حساب بانکی به یک کد ملی.

مشاهده مشخصات فنی و تعرفه

راهنماهای مرتبط

پرسش و تجربه کاربران

اگر این راهنما جوابتان را نداد، همین‌جا بپرسید. پرسش‌ها را تیمملی ای‌پی‌آی پاسخ می‌دهد و هر نظر پیش از انتشار بررسی می‌شود.

هنوز پرسشی ثبت نشده، اولین نفر باشید.