پرداخت اینترنتی و درگاه: درخواست، بازگشت، تأیید، خطا، برگشت و اختلاف

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

وضعیت تلاش پرداخت

وضعیت Payment	مفهوم کاربردی	اقدام صحیح
created	درخواست تراکنش ساخته شده	تأیید وجه نیست؛ نتیجه یا انقضا را دنبال کنید
redirected	کاربر به درگاه فرستاده شده	بازگشت کاربر به سایت به‌تنهایی موفقیت نیست
paid	نتیجه موفق در مسیر معتبر ثبت شده	شماره مرجع، مبلغ و سفارش را تطبیق دهید
failed	تلاش ناموفق	علت را از وضعیت درگاه و لاگ غیرحساس پیدا کنید
reversing	برگشت وجه در جریان است	پرداخت یا refund مستقل دوباره ایجاد نکنید
reversed	بازگشت وجه در مسیر مربوط ثبت شده	با بانک/درگاه و پرونده سفارش تطبیق دهید

Order.payment_status یک خلاصه از وضعیت دریافت سفارش است و ممکن است یکی از «پرداخت نشده»، «فیش در انتظار بررسی»، «پرداخت شده» یا «فیش رد شده» باشد. این دو فیلد را جایگزین هم نکنید.

چه فیلدهایی را در فهرست پرداخت بخوانیم؟

شماره سفارش: مرجع تجاری وجه. روش/درگاه (gateway): محل شروع دریافت. مبلغ: باید با سهم پرداخت مربوط مطابقت داشته باشد، نه لزوماً با قیمت ناخالص همه ردیف‌ها. authority: شناسه درخواست/ارجاع به درگاه. ref_id: شناسه مرجع پاسخ موفق، اگر ارائه شده باشد. زمان ساخت و وضعیت: زمان هر تلاش را از پرداخت‌های دیگر تفکیک می‌کند. provider_response ممکن است جزئیات حساس داشته باشد و نباید در صفحه عمومی یا پیام پشتیبانی کپی شود.

مشتری می‌گوید پول کم شده، سایت خطا داده

۱. شماره سفارش و مبلغ اعلام‌شده را ثبت کنید. ۲. تلاش‌های Payment آن سفارش را به ترتیب زمان بخوانید. ۳. مرجع غیرحساس provider را با نتیجه معتبر درگاه تطبیق دهید. ۴. وضعیت‌های برگشت خودکار یا در انتظار مشخص‌شدن را بررسی کنید. ۵. تا روشن‌شدن نتیجه، تراکنش را با «پرداخت دستی» موفق جلوه ندهید؛ این کار می‌تواند موجودی رزروشده را قطعی و گزارش را نادرست کند. ۶. پس از روشن‌شدن وضعیت، مشتری را با متن دقیق راهنمایی کنید؛ زمان برگشت بانک را حدس نزنید.

بازگشت مرورگر با تأیید سرور تفاوت دارد

کاربر ممکن است بعد از پرداخت، صفحه نتیجه را ببیند ولی درخواست callback دیر برسد، چند بار ارسال شود یا ارتباط قطع شود. منبع قابل اتکا وضعیت ثبت‌شده پس از بررسی معتبر ارائه‌دهنده است، نه صرف نمایش URL موفقیت. چند بار فراخوانی callback نباید چند سند پرداخت یا چند برداشت موجودی بسازد؛ این یک انتظار مهم از منطق idempotency است و باید در تست‌های production بررسی شود.

ارتباط پرداخت با موجودی و ارسال

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

اختلاف پرداخت (Dispute/Chargeback)

اختلافی که provider اعلام می‌کند، با بازپرداخت داوطلبانه فروشگاه فرق دارد. یک پرونده اختلاف ممکن است وضعیت تجاری و وضعیت مالی مستقل داشته باشد. مثلاً نتیجه اعتراض ممکن است «برد» باشد اما اثر بدهکار/بستانکار مربوط هنوز نیاز به بررسی داشته باشد. قبل از آغاز هر refund، پرونده‌های dispute، تسویه و بازپرداخت همان سفارش را بخوانید؛ پرداخت دوم به مشتری ممکن است زیان مالی واقعی ایجاد کند. بازپرداخت و کنترل تکرار را ببینید.

رعایت امنیت

در یادداشت سفارش هرگز CVV2، رمز پویا، PAN کامل یا پاسخ خام درگاه را نگذارید. برای پشتیبانی معمولاً شماره سفارش، زمان، مبلغ، شناسه غیرحساس و وضعیت کافی است. بررسی درگاه و دسترسی به secrets فقط برای نقش مجاز انجام شود. اتصال درگاه در تنظیمات فروشگاه با پردازش حسابداری پرداخت یک چیز نیست.

نمونه با چند تلاش

سفارشی ۱٬۲۵۰٬۰۰۰ تومان قابل پرداخت است. تلاش اول failed، تلاش دوم redirected و تلاش سوم paid شده است. گزارش دریافتی نباید جمع مبلغ هر سه تلاش یعنی ۳٬۷۵۰٬۰۰۰ تومان باشد. تنها نتیجه معتبر در کنار هر برگشت/بازپرداخت مرتبط قابل محاسبه است. اگر مشتری مدعی دوبار برداشت شد، هر دو مرجع را از ارائه‌دهنده کنترل کنید؛ به‌جای ساخت بازپرداخت از روی حدس، مسیر رسمی اختلاف یا برگشت را پیگیری کنید.

مطلب مرتبط: مبالغ سفارش، پرداخت دستی، تطبیق بانکی.