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