خط لولهٔ کنترل پیش از واریز پایا: از اعتبارسنجی شبا تا تطابق نام

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

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

زنجیر چهارحلقه‌ای

حلقهٔ اول: شکل شبا (رایگان، محلی). رشته باید با IR شروع شود، ۲۴ رقم بعدش بیاید، و رقم کنترلی بخواند. هر ردیفی که رد شود، همین‌جا بیرون می‌رود. توضیح الگوریتم در اعتبارسنجی ساختار شبا آمده.

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

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

حلقهٔ چهارم: تصمیم و ثبت. نتیجه را ذخیره کنید و بر اساس آن حرکت کنید.

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

ساختار یک فراخوان

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

مقدارها نمونه‌اند. جزئیات هدر و کلید در مستندات است.

چهار پیامد، چهار رفتار

بعد از فراخوان، با یکی از این چهار روبه‌رو می‌شوید:

۱. بله. ثبت کنید و ادامه بدهید.

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

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

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

تلاش مجدد، فقط برای حالت چهارم

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

کلید ایدمپوتنسی

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

چه زمانی پاسخ قدیمی دیگر معتبر نیست

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

آنچه این خط لوله نمی‌کند

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

یک سناریوی فرضی: صف هزار ردیفی

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

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

همزمانی و نرخ

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

گزارش‌گیری: چه چیزی را بشمارید

برای اینکه خط لوله سالم بماند، چند عدد را روزانه ببینید:

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

این‌ها از جمله چیزهایی‌اند که فقط وقتی «خیر» را خطا نشمارید معنا دارند.

وقتی خط لوله را از نو می‌سازید

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

چند نکتهٔ پایانی دربارهٔ نگهداری

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

پیشنهاد من

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