کارت به شبا
Luhn و BIN؛ تبدیل قطعی فقط وقتی الگوریتم همان بانک در ابزار باشد.
الگوریتم واحد برای همهٔ بانکها وجود ندارد. شماره کارت لاگ و ارسال نمیشود.
۱۶ رقم وارد کنید.
مرتبط
جستجوی «تبدیل شماره کارت به شبا» یکی از پرتکرارترین queryهای کاربران بانکداری دیجیتال ایران است: فردی برای واریز پایا فقط PAN دوستش را دارد، یا فروشنده شبا را در قرارداد جا گذاشته و مشتری کارت را نشان میدهد. امید این است که با یک فرمول عمومی از ۱۶ رقم، ۲۶ نویسهٔ IBAN ساخته شود. واقعیت این است که در اکوسystem بانکی ایران — برخلاف برخی کشورها — الگوریتم reverse عمومی و یکسان از PAN به Sheba منتشر نشده؛ هر بانک ساختار داخلی حساب، نگاشت card token، و گاهی rangeهای PAN را خودش مدیریت میکند. ابزار کارت به شبا در FinAI صادقانه در همین محدوده کار میکند: Luhn را میسنجد، با BIN بانک را نام میبرد، و اگر تبدیل قطعی برای آن بانک در codebase تعریف نشده باشد، بهجای حدس شبا، پیام میدهد از درگاه یا اپ رسمی استفاده کنید. این متن از زاویهٔ فنی و حریم خصوصی میگوید چرا حدس زدن خطرناک است، FinAI چه مراحلی را طی میکند، و چه جایگزینهای مطمئن دارید.
چرا «یک فرمول برای همهٔ بانکها» شکل نگرفته
شبا (IBAN) روی BBAN ساخته میشود: کد بانک + شماره حساب padded + دو رقم کنترل mod 97. شماره کارت sixteen رقمی روی شبکهٔ شتاب شناسهٔ پرداخت است، نه لزوماً همان literal حساب دفتری. بانک ممکن است برای یک حساب چند PAN (تمدید، reissue، virtual) صادر کند؛ یا PAN را به proxy map کند. بدون مستندات رسمی از side بانک، infer کردن ۱۹ رقم حساب از ۱۰ رقم باقیمانده PAN — حتی با Luhn درست — combinatorial و غیرقابل اثبات است.
در بعضی کشورها API open banking «account identifier from card» دارد؛ در ایران ابزار عمومی FinAI به چنین API متصل نیست و نباید شماره کارت کامل را به سرور بفرستد تا «شبا حدسی» برگرداند. هر سایتی که ادعا میکند همیشه و برای همه بانکها شبا میدهد، یا از منبع غیررسمی استفاده میکند یا خطر mis-route پول دارد.
مسیر واقعی ابزار FinAI؛ گام به گام
ورودی: ۱۶ رقم (با نرمال ارقام فارسی). اگر طول غیر ۱۶ باشد، خروجی null. مرحلهٔ اول اعتبارسنجی Luhn است؛ اگر Luhn رد شود، تبدیل اصلاً شروع نمیشود — چون پایهٔ PAN مشکوک است. مرحلهٔ دوم BIN و نام بانک. اگر BIN در جدول نباشد، باز هم شبای قطعی ارائه نمیشود.
مرحلهٔ سوم: آیا برای این bankId در repository الگوریتم encode تعریف شده؟ در بسیاری از releases فعلی پاسخ «خیر» است. خروجی نمونه: «بانک X شناسایی شد. برای این بانک تبدیل قطعی کارت به شبا در این ابزار نیست؛ از درگاه بانک یا اپ رسمی استفاده کنید.» فیلد definitive=false و sheba=null. این رفتار feature است، نه bug — جلوگیری از واریز اشتباه مهمتر از نمایش یک IBAN plausible-but-wrong است.
تفاوت با generateSheba وقتی حساب را خودتان دارید
در کد FinAI تابعی برای ساخت شبا از کد بانک سهرقمی + شماره حساب (تا ۱۹ رقم) با mod 97 وجود دارد — وقتی شماره حساب را از statement دارید، نه وقتی فقط PAN دارید. آن مسیر با card-to-sheba اشتباه گرفته نشود: کاربر عادی PAN دارد، نه account number دفتری.
خطر واریز به شبای حدسی
IBAN معتبر mod 97 میتواند به حساب کسی دیگر belong کند اگر رقم حساب را wrong guess کنید — checksum جلوی typo random را میگیرد ولی نه جلوی algorithm attack ساختگی. مسئولیت مالی on sender است. بانکها بعد از transfer کمک محدود دارند. پس «شبای ساختگی که valid است» بدتر از «invalid» است چون اعتماد کاذب میدهد.
FinAI این risk را با non-definitive default mitigates میکند. کاربر باید از منوی «کپی شبا» در اپ بانک، یا نوشتن شبا روی invoice، یا transfer test با مبلغ کم + تایید گیرنده استفاده کند.
حریم خصوصی؛ PAN را local نگه دارید
مثل سایر ابزارهای banking در FinAI، card-to-sheba در مرورگر اجرا میشود؛ PAN به backend FinAI برای conversion ارسال نمیشود. دلیل: PAN دادهٔ حساس؛ نگهداری log روی server بدون compliance PCI غیرمسئولانه است. اگر app موبایل third-party میخواهد «کارت به شبا»، permission و storage policy شفاف لازم دارد — FinAI model client-side را promote میکند.
در گفتگوهای social، screenshot کارت + درخواست «برام شبا دربیار» را public نکنید. حتی بدون CVV، PAN برای fraud surface کافی است.
جایگزینهای عملی که کار میکنند
- اپ بانک صادرکننده: بخش «اشتراکگذاری شبا» یا «اطلاعات حساب».
- درگاه با تایید نام: بعضی transferها name beneficiary را match میکنند — به PAN نیاز ندارید اگر شبا را دارید.
- کارت به کارت vs شبا: اگر فقط PAN دارید، ممکن است rail کارت-to-کارت در ATM/APP مناسبتر از invent کردن IBAN باشد.
- دریافت شبا از گیرنده: برای B2B، شبا روی letterhead یا PDF signed.
بعد از گرفتن شبا، اعتبارسنجی شبا checksum را قبل از مبلغ بالا چک میکند — مکمل card-to-sheba، نه جایگزین.
سوءتفاهم با BIN و کد بانک
کاربر میبیند BIN گفت بانک ملت؛ فکر میکند میتواند کد ۰۱۲ را در فرمول IBAN بگذارد و ten رقم PAN را به عنوان account paste کند. بدون spec بانک، این almost always اشتباه است. کد بانک در شبا با encoding داخلی branch ممکن است align باشد ولی account field padding rules per bank فرق دارد. card-to-sheba این extrapolation را انجام نمیدهد.
برای پذیرندگان و marketplace
فروشگاه نباید از PAN مشتری شبا infer کند؛ باید شبا را در checkout field جدا بگیرد یا payout via wallet internal. اگر فقط PAN از POS مانده، settlement policy با acquirer است — نه IBAN ساختگی. FinAI tool برای consumer education است.
برای حسابداران و حقوق
لیست PAN در payroll legacy ممکن است باشد؛ migration به شبا با export از HR banking یا bulk request به بانک انجام میشود، نه batch card-to-sheba online tool. ابزار FinAI یک ردیف را sanity-check میکند، نه فایل ۵۰۰۰ نفره را automate میکند.
آیندهٔ محصول؛ اگر الگوریتم بانک اضافه شود
اگر روزی برای bank خاصی algorithm verified در repo بیاید، definitive=true و sheba پر میشود — با test vectors در unit test. تا آن زمان copy صریح «قطعی نیست» نمایش داده میشود. کاربران نباید expect کنند همهٔ بانکها یکباره پوشش بگیرند؛ هر addition نیاز به legal/technical review دارد.
رابطه با validate-card و lookup
سه ابزار مکملاند: lookup فقط prefix؛ validate-card Luhn+BIN؛ card-to-sheba همان validate plus honesty دربارهٔ IBAN. workflow پیشنهادی FinAI: PAN را در validate-card بزنید — اگر Luhn fail، digit fix کنید. اگر OK، bank را ببینید. سپس card-to-sheba را باز کنید؛ اگر sheba null، اپ همان bank را باز کنید. شبا را در validate-sheba mod 97 کنید قبل از واریز.
سؤالاتی که این ابزار عمداً پاسخ نمیدهد
نام صاحب حساب، موجودی، status کارت، linkage card-to-account در core، و شبای کارتهای هدیه یا corporate pooled. برای آنها تماس با صادرکننده یا استفاده از سامانههای مجاز بانک لازم است. FinAI topical authority را با transparency دربارهٔ limits میسازد، نه با fake completeness.
جمعبندی
تبدیل کارت به شبا در ایران برای عموم یک فرمول واحد ندارد. ابزار FinAI Luhn و BIN را اعمال میکند، بانک را نام میبرد، و بدون algorithm verified شبای قطعی نشان نمیدهد. برای واریز درست، شبا را از منبع رسمی بگیرید، با اعتبارسنجی شبا typo را بگیرید، و PAN را در client نگه دارید — نه در سرور ناشناس. این محدودیت آزاردهنده به نظر میرسد، ولی از mis-payment و نشت داده جلوگیری میکند؛ در banking، conservatism feature است.
چرا سایتهای شخص ثالث گاهی «شبا» نشان میدهند
برخی سرویسها database leak یا partnership نیمهرسمی دارند؛ برخی فقط padding حساب از PAN با heuristic غلط انجام میدهند. FinAI در دستهٔ دوم نمیخواهد باشد. اگر شبای دریافتی از third party با mod 97 در validate-sheba OK شد، هنوز name match در درگاه را skip نکنید — IBAN valid ≠ حساب intended.
کارت به کارت در برابر نیاز به شبا
بسیاری از کاربران فقط برای «پول برساندن» PAN دارند؛ rail کارت-to-کارت در Shaparak/App bank همان PAN را میپذیرد بدون IBAN. card-to-sheba وقتی relevant است که counterparty یا employer فقط شبا میپذیرد (حقوق، برخی B2B). انتخاب rail درست از invent کردن IBAN بهتر است.
تست واحد و definitive flag در محصول
در codebase FinAI، cardToSheba وقتی luhnOk false باشد note متفاوت دارد؛ وقتی bank null باشد note دیگر؛ وقتی bank known ولی algorithm نباشد sheba null و definitive false. UI باید این سه را confuse نکند — user نبیند «شبا خالی» و فکر کند bug است. copy فارسی صریح part of experience است.
مثال داستانی بدون شمارهٔ واقعی
فرض کنید مستأجری برای واریز اجارهٔ ماهانه شبای موجر را میخواهد؛ موجر فقط شماره کارت مستأجر قبلی را در دفترچه دارد. مستأجر فعلی همان PAN را در ابزار کارت به شبا میزند؛ خروجی میگوید بانک شناسایی شد ولی تبدیل قطعی نیست. در تماس تلفنی از موجر میخواهد شبا را از اپ بانک در پیامک بفرستد. پس از دریافت، شبا را در اعتبارسنجی شبا چک میکند و بعد مبلغ را میفرستد. در این روایت، PAN فقط سرنخ بود، نه منبع IBAN.
ردیابی آماری و حریم خصوصی
حتی وقتی پردازش سمت مرورگر است، اگر اسکript تحلیل بازدید بدون رضایت hash شماره کارت بفرستد، مسئلهٔ حریم باقی میماند. خانوادهٔ ابزار بانکی FinAI عمداً PAN را به analytics ارسال نمیکند. افزونههای ناشناس مرورگر ممکن است ورودی فرم را ببینند؛ کاربر باید از محیط امن استفاده کند.
ادغام بانک و card-to-sheba
اگر BIN نام bank جدید و card-to-sheba همان نام را بدهد ولی customer هنوز card با brand قدیمی دارد، conversion algorithm — اگر someday add شود — باید per legacy issuer باشد نه per marketing name. این یکی از دلایل technical که unified formula دیر میآید.
نکته برای نویسندگان و مدرسان مالی
اگر در مقاله یا دوره آموزشی مینویسید «با شماره کارت شبا بهدست میآید»، محدودیت الگوریتم و حریم خصوصی را هم بگویید. این صفحه مرجع wording مسئولانه است. تیترهای clickbait از جنس «فقط ۱۶ رقم کافی است» میتواند به واریز اشتباه منجر شود.
مسیر بعد از tool
Luhn fail → validate-card و fix digits. Luhn OK, bank unknown → lookup یا app bank. Bank known, sheba null → app bank. Sheba obtained → validate-sheba. هیچ step PAN را به server FinAI نمیفرستد.