فرم تسویه با شماره کارت به‌جای شبا: طراحی جریان تبدیل

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

این مقاله دربارهٔ طراحی چنین جریانی است، با سرویس تبدیل کارت به شبا در قلب آن. موضوع، کد تنها نیست؛ جاهایی که جریان می‌شکند و کاری که برای هر کدام می‌توان کرد.

جریان پیشنهادی در پنج گام

1. کاربر شماره کارت را وارد می‌کند. کادر ورودی با فاصله‌گذاری چهارتایی و ارقام فارسی و لاتین را بپذیرد.
2. شما ساختار را می‌سنجید. شانزده رقم، رقم کنترل کارت. خطای واضح همین‌جا گرفته می‌شود.
3. تبدیل را فراخوانی می‌کنید. شبا، نام بانک و نام صاحب کارت برمی‌گردد.
4. نام را به کاربر نشان می‌دهید و تأیید می‌گیرید.
5. شبا را ذخیره می‌کنید، شماره کارت را نه.

هر گام ساده است؛ ارزش جریان در ترتیب و در گام ۵ است.

چرا شماره کارت را ذخیره نکنیم

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

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

نمایش نام، سه راه

نام صاحب کارت در پاسخ هست. چطور به کاربر نشانش دهید؟

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

به نظر من نیمه‌پوشیده برای جریان‌های برداشت مناسب‌ترین است، و مقایسهٔ بی‌نمایش برای تسویه با فروشنده، جایی که نام ثبت‌شده را از قبل دارید.

حالت‌های شکست و پیام‌ها

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

و اگر کاربر شبا را مستقیم بدهد

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

هزینه و تکرار

هر تبدیل موفق یا «پیدا نشد» هزینه دارد. دکمه را بعد از کلیک غیرفعال کنید و در سمت سرور هم جلوی تکرار پیاپی را بگیرید. نگاشت کارت به شبا کند تغییر می‌کند و ممکن است پاسخ تکراری از کش بیاید (source.cached)، ولی برنامه‌تان نباید برای صرفه‌جویی روی آن حساب کند. هزینهٔ روز را از تعرفه ببینید.

نمونه فراخوان

bash curl -X POST 'https://<دامنه>/api/v1/card-to-iban/' \ -H 'Authorization: Bearer melli_live_…' \ -H 'Content-Type: application/json' \ -d '{"cardNumber": "6037XXXXXXXXXXXX"}'

شماره کارت مثال ساختاری است. کلید API را در کد سمت کاربر نگذارید؛ فراخوان باید از سرور شما انجام شود تا کلید لو نرود.

یک سناریوی فرضی

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

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

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

امنیت فراخوان

فراخوان تبدیل را فقط از سرور خودتان انجام دهید. کلید API در کد مرورگر یا اپلیکیشن موبایل، لو می‌رود. شماره کارت را هم هرگز در نشانی (query string) نفرستید؛ این سرویس‌ها فقط POST می‌پذیرند و دلیلش این است که نشانی در لاگ‌ها و تاریخچه می‌ماند. بدنهٔ JSON کافی است.

دسترس‌پذیری فرم

کادر شماره کارت را برای ورودی راست‌به‌چپ و ارقام چپ‌به‌راست درست تنظیم کنید: متن فارسی در برچسب، ولی خود عدد با جهت چپ‌به‌راست. با inputmode="numeric" صفحه‌کلید عددی باز می‌شود و فاصله‌های خودکار بین چهار رقم‌ها خوانایی را بالا می‌برد. این جزئیات کوچک تعداد خطای تایپی را کم می‌کند.

ورودی ارقام فارسی

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

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

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

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

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

جزئیات ورودی و خروجی در صفحهٔ API تبدیل کارت به شبا هست.