قاعده تصمیم فروش اعتباری با استعلام چک برگشتی

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

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

سه لایه به‌جای یک قاعده

به نظر من قاعدهٔ خوب سه لایه دارد:

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

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

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

یک جدول تصمیم نمونه

این جدول فرضی است و آستانه‌هایش را باید با داده و ریسک خودتان تنظیم کنید:

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

استعلام را کجای جریان بگذاریم

دو جای رایج هست و هر کدام ضعف خودش را دارد.

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

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

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

ورودی و خطاهای رایج پیاده‌سازی

ورودی nationalCode و nationalityType است. اگر کاربر ایرانی است، نوع را نفرستید تا پیش‌فرض اعمال شود. رایج‌ترین مشکلات:

• کد ملی نامعتبر. رقم کنترل را در سمت خودتان بسنجید؛ ورودی نامعتبر در API هزینه ندارد ولی یک رفت‌وبرگشت بی‌دلیل است.
• صفر falsy. if (count) را ننویسید. صفر پاسخ سالم است.
• تفسیر not_found با HTTP ۲۰۰ به‌عنوان موفقیت. همیشه فیلد ok را بخوانید.

یک نمونه از شرط درست:

js if (!out.ok) return manualReview(out.requestId); const n = out.data.count; return n === 0 ? approve() : n <= 2 ? review() : cashOnly();

چه چیزی را ثبت کنید

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

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

ساختار پیکربندی قاعده

اگر جدول تصمیم را در پیکربندی می‌گذارید، شکل ساده‌ای مثل این کافی است:

json { "version": "2026-11-a", "rules": [ { "maxCount": 0, "maxAmount": "small", "action": "approve" }, { "maxCount": 2, "maxAmount": "small", "action": "review" }, { "maxCount": 999, "maxAmount": "any", "action": "cash_only" } ] }

مقدارها نمونه‌اند. نکتهٔ اصلی فیلد version است: هر تصمیم با نسخهٔ قاعده‌ای که اجرا شد ثبت می‌شود و بعداً می‌توانید بفهمید چرا یک مشتری در ماه آبان عبور کرد و در دی نه.

بازنگری قاعده با داده خودتان

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

تیم و مسئولیت

قاعده را یک نفر مسئول باشد، نه کل تیم. آن نفر باید بتواند بگوید چرا آستانه فلان است و بر چه اساسی تغییر می‌کند. بدون مالک، آستانه‌ها یا هرگز عوض نمی‌شوند یا هر بار پس از یک بحران، بیش از حد عوض می‌شوند.

نمونه از متن پیام به مشتری

وقتی قاعده شما را به «نقدی» می‌رساند، پیام مهم است. دو نسخه را مقایسه کنید.

نسخهٔ بد: «شما واجد شرایط پرداخت با چک نیستید.» این جمله سرد است و مشتری را متهم می‌کند.

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

از نشان‌دادن خود عدد به مشتری خودداری کنید. عدد داده‌ای شخصی و حساس است و لازم نیست در رابط عمومی بیاید.

ترکیب با اطلاعات داخلی

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

آنچه این قاعده نمی‌تواند

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

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

نکتهٔ آخر

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

برای شروع، صفحهٔ استعلام چک برگشتی نمونهٔ درخواست و پاسخ را دارد.