کنترل نام صاحب حساب پیش از پرداخت گروهی به پیمانکار
بررسی نام را یک بار هنگام ثبت حساب و بار دیگر برای حساب‌های قدیمی یا مبلغ بالا پیش از پرداخت بگذارید و هر سطر مشکل‌دار را جدا نگه دارید.
پیش از پرداخت گروهی به پیمانکاران، فقط یک سؤال را جواب بدهید: این شماره حساب واقعاً مال همان کسی است که قرار است پول بگیرد؟ تطبیق نام و شماره حساب این سؤال را به یک مرحلهٔ خودکار در فرایند پرداخت تبدیل می‌کند.
این مقاله برای تیم مالی یا فنی است که فایل پرداخت می‌سازد: حقوق، تسویه با پیمانکار، پرداخت خسارت. بحث بر سر طراحی است، نه خود استعلام: کجای فرایند بگذاریدش، با «خیر» چه کنید و چه چیزی را ثبت کنید.
چرا قبل از پرداخت، نه بعد
بازگرداندن پولی که به حساب اشتباه رفته کار سنگینی است و همیشه شدنی نیست. بررسی ارزان است و پیش از دستور پرداخت انجام می‌شود. این همان منطقی است که در بانکداری بین‌المللی به آن «تأیید گیرنده» می‌گویند: پیش از ارسال پول، نام گیرنده با حساب چک می‌شود.
سرویس تطبیق شماره حساب و نام سه ورودی می‌گیرد (بانک، شماره حساب، نام) و matched برمی‌گرداند. نمونه از سمت سرور شما:
bash curl -X POST 'https://<دامنه-ما>/api/v1/account-name-match/' \ -H 'Authorization: Bearer melli_live_…' \ -H 'Content-Type: application/json' \ -d '{"bank":"mellat","bankAccount":"<شماره-حساب>","name":"<نام>"}'
فرض کنید یک شرکت پیمانکاری هر ماه ده‌ها تسویه دارد. اگر بررسی را هنگام ثبت پیمانکار انجام دهد، فقط یک بار به ازای هر حساب هزینه می‌دهد؛ اگر هر ماه در فایل پرداخت انجام دهد، هزینه تکرار می‌شود ولی تغییرات حساب را هم می‌گیرد. تصمیم میان این دو به ریسک شما بستگی دارد.
دو نقطهٔ ممکن در فرایند
هنگام ثبت حساب. وقتی پیمانکار یا کارمند حسابش را وارد می‌کند. مزیتش: خطا همان لحظه که او آنجاست اصلاح می‌شود. عیبش: بعد از آن حساب ممکن است عوض شود یا بسته شود و شما نمی‌دانید.
هنگام ساخت فایل پرداخت. درست پیش از دستور. مزیتش: آخرین وضعیت را می‌بینید. عیبش: اگر نتیجه «خیر» بود، پرداخت گروهی منتظر می‌ماند.
راه میانی که به نظر من خوب است: بررسی هنگام ثبت اجباری باشد، و هنگام پرداخت فقط برای حساب‌هایی که از آخرین بررسی‌شان مدتی گذشته یا مبلغ بالاست. آستانهٔ «مدت» و «مبلغ» را شما با ریسک خودتان تعیین می‌کنید؛ عدد درستی که برای همه صادق باشد نداریم.
با هر پاسخ چه کنید
چهار نتیجه دارید و هرکدام تصمیم جدا:
| نتیجه | یعنی | عمل |
|---|---|---|
matched: true | با این ورودی تطابق است | ادامه |
matched: false | تطابق نیست | نگه‌داشتن آن سطر، نه کل فایل |
invalid_input | ورودی ناقص | اصلاح و دوباره، بدون هزینه |
| خطای گذرا | استعلام انجام نشد | دوباره بعداً، «خیر» حسابش نکنید |
مورد دوم مهم است: یک سطر مشکل‌دار نباید کل دسته را متوقف کند. سطرها را جدا کنید، سطرهای سالم را پرداخت کنید، و فهرست «نیازمند بازبینی» را به مسئول بدهید. اگر نتیجه را پیش از پرداخت همه ندارید، دستهٔ پرداخت را به اندازهٔ سطرهای بررسی‌شده ببندید.
دلایل رایج «خیر» را در راهنمای علل پاسخ خیر جدا نوشته‌ایم؛ بیشتر آن‌ها قابل رفع‌اند و نباید به برچسب «مشکوک» برسند.
چه چیزی ثبت کنید
برای هر بررسی این‌ها را نگه دارید:
- شناسهٔ درخواست (
requestId) از پاسخ؛ برای پیگیری با پشتیبانی. - زمان بررسی، نتیجه، و اینکه پاسخ از کش بوده یا تازه (
source). - نام و بانک ارسال‌شده؛ و شمارهٔ حساب فقط به شکل پوشیده (چهار رقم آخر).
شماره حساب کامل را در گزارش‌های عمومی و لاگ برنامه ننویسید. ما هم در گزارش‌های داخلی‌مان آن را پوشیده نگه می‌داریم، و شما هم همین کار را بکنید.
حساب شرکتی و فرم
سه اشتباه فرم که «خیر» تولید می‌کند:
- فیلد نام را برای شرکت و شخص یکی می‌گیرد. برای شرکت، نام شرکت لازم است.
- بانک را آزاد تایپ می‌کند. از فهرست انتخاب کنید.
- شماره را بدون قالب بانک ذخیره می‌کند. جداکننده‌ها را حفظ کنید، چون ما دستشان نمی‌زنیم.
اگر فقط شبا دارید، تطبیق شبا با نام مسیر نزدیک است.
آنچه این سرویس نمی‌کند
مالکیت را به‌معنای حقوقی ثابت نمی‌کند، فقط تطابق نام را می‌سنجد. نام صاحب حساب را نشان نمی‌دهد. وضعیت حساب (باز یا بسته) را جداگانه گزارش نمی‌کند. و ضمانت پرداخت نیست: «بله» یعنی پیش از پرداخت نام خواند، نه اینکه واریز موفق می‌شود.
پاسخ منفی ممکن است به‌خاطر نام باشد یا حسابی که دیگر وجود ندارد، و این دو از هم جدا نمی‌شوند. در فرایند خودتان برای «خیر» مسیر انسانی بگذارید.
نمونهٔ جریان کار (فرضی)
فرض کنید یک بیمه‌گر فایل پرداخت خسارت را هر هفته می‌سازد. هر سطر یک ذی‌نفع دارد با بانک، شماره حساب و نام. پیش از ساخت فایل، سرور سطرها را یکی‌یکی برای تطبیق نام و حساب می‌فرستد، سطرهای matched: true را در فایل می‌گذارد و بقیه را در صفحه‌ای جدا به کارشناس نشان می‌دهد. کارشناس می‌تواند نام را اصلاح کند، حساب جدید بخواهد یا سطر را رد کند.
نکتهٔ طراحی: درخواست‌ها را همزمان و بی‌حد نفرستید. سقف نرخ وجود دارد (rate_limited با هدر Retry-After)، پس صف ساده با تعداد محدود درخواست همزمان بسازید و در صورت 429 به مقدار هدر صبر کنید.
هزینه‌های پنهان یک بررسی نکردن
یک پرداخت به حساب اشتباه فقط خود مبلغ را هزینه نمی‌کند. زمان تیم مالی برای پیگیری، مکاتبه با بانک، تأخیر در پرداخت به ذی‌نفع درست، و گاهی اعتماد پیمانکار را هم می‌برد. این هزینه‌ها در عدد نمی‌آیند و برای همین کنترل‌های ساده را کم‌اهمیت جلوه می‌دهند. ولی برای تصمیم، لازم نیست عدد دقیق داشته باشید: کافی است سه مورد پرداخت اشتباه سال گذشته‌تان را فهرست کنید و بپرسید «اگر قبلش بررسی می‌شد، چند تا جلوگیری می‌شد؟». ما برای شما آماری نداریم، ولی این سؤال را خودتان می‌توانید جواب بدهید.
اگر هیچ پرداخت اشتباهی نداشته‌اید، ممکن است بررسی هنگام ثبت (نه هنگام هر پرداخت) برایتان کافی باشد.
پرسش‌هایی که پیش از اجرا باید جواب بدهید
پیش از وصل‌کردن این مرحله به پرداخت واقعی، چهار پرسش را روی کاغذ جواب بدهید. اگر بررسی «خیر» داد، چه کسی تصمیم می‌گیرد و در چه مدت؟ اگر سرویس در دسترس نبود، پرداخت منتظر می‌ماند یا با بررسی دستی جلو می‌رود؟ نتیجهٔ بررسی تا چه مدت معتبر است؟ و چه کسی به گزارش‌ها دسترسی دارد؟ جواب هر چهار را بنویسید و به تیم بدهید؛ بدون آن، «خیر» اول که بیاید فایل پرداخت در صندوق یک نفر گیر می‌کند.
در یک نگاه
بررسی را یک بار هنگام ثبت حساب و یک بار برای حساب‌های قدیمی یا مبلغ‌های بالا هنگام پرداخت بگذارید. نتیجه را چهار دسته کنید، سطر مشکل‌دار را جدا نگه دارید و ردی از بررسی بسازید. اگر جای شما بودم، «خیر» را هیچ‌وقت خودکار به «رد» تبدیل نمی‌کردم.
وب‌سرویس مرتبط با این راهنما
API تطابق شماره حساب و نام
بررسی اینکه یک شماره حساب به نام فرد موردنظر است یا نه.
راهنماهای مرتبط
پرسش و تجربه کاربران
اگر این راهنما جوابتان را نداد، همین‌جا بپرسید. پرسش‌ها را تیمملی ای‌پی‌آی پاسخ می‌دهد و هر نظر پیش از انتشار بررسی می‌شود.
هنوز پرسشی ثبت نشده، اولین نفر باشید.