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

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

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

چهار وضعیت برای هر کارت

به‌جای دو حالت «تأییدشده/نشده»، چهار حالت در نظر بگیرید:

• pending: ثبت شده، هنوز بررسی نشده.
• verified: نام مطابق بود.
• needs_review: مطابق نبود ولی نشانه‌ای از بی‌گناهی هست.
• rejected: مطابق نبود و اشتراکی نیست، یا بررسی دستی رد کرد.

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

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

وضعیت verified ابدی نیست. سه رویداد باید آن را برگرداند به pending:

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

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

سقف تلاش: سرویس را اوراکل نکنید

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

پیشنهاد من:

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

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

قاعدهٔ ذخیره‌سازی

از کل این جریان، چه را نگه دارید؟

• وضعیت (verified و ...) و زمان آخرین بررسی.
• چهار رقم آخر کارت، برای نمایش.
• نتیجه، نه نام برگشتی.

شمارهٔ کامل کارت را پس از تأیید لازم ندارید اگر مسیر تسویه‌تان از شبا یا حساب می‌رود. برای تبدیل کارت به مقصد قابل‌واریز، داده‌های تسویه و کمینه‌سازی را ببینید.

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

bash curl -X POST 'https://…/api/v1/card-name-match/' \ -H 'Authorization: Bearer $MELLIAPI_API_KEY' \ -H 'Content-Type: application/json' \ -d '{"cardNumber": "6037…", "name": "علی رضایی"}'

کارت و نام در اینجا نمونه‌اند. پیش از ارسال، شماره کارت را با الگوریتم کنترلی بسنجید (رایگان) و نام را یکدست کنید (راهنما).

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

• هویت صاحب کارت را با کد ملی نمی‌سنجد؛ فقط کارت و نام.
• مطمئن نمی‌کند پول به کارت می‌نشیند؛ کارت ممکن است از نوعی باشد که دریافت را نمی‌پذیرد.
• ضامن نیست که کسی که فرم را پر می‌کند صاحب کارت است. نام روی کارت، حتی مطابق، اثبات حضور او نیست.

برای جزئیات خروجی دقیق و کدهای خطا، مستندات مرجع است.

یک سناریوی فرضی: فروشنده نام خود را عوض می‌کند

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

قاعدهٔ کلی: هر بار یکی از دو سمت مقایسه تغییر کرد، سمت دیگر را دوباره بسنجید. این کار ارزان است و جلوی پرداخت به کارتی را می‌گیرد که دیگر مطابق نیست.

ثبت رویداد، نه فقط وضعیت

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

تجربهٔ کاربر هنگام needs_review

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

برای دیدن اینکه خروجی دقیق و ورودی‌های این سرویس چیست، صفحهٔ API تطابق کارت و نام را ببینید.

آزمون پیش از انتشار

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

خلاصه برای مرور بعدی

• وضعیت کارت را مدل کنید، نه فقط نتیجهٔ یک فراخوان.
• هر تغییر کارت یا نام، وضعیت را به pending برگرداند.
• سقف تلاش بگذارید تا فرم شما اوراکل هویت نشود.
• فقط وضعیت و چهار رقم آخر را نگه دارید.