سفارش ثبت نمی شود؛ مشکل بازگشت از درگاه پرداخت را چطور پیدا کنیم؟

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

نشانه: پول رفته، سفارش نیومده

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

یه تشبیه ساده: مشتری پول رو توی صندوق بانک می ده و رسید می گیره، ولی رسید توی راه برگشت به پیشخوان فروشنده گم می شه. فروشنده نمی دونه پول اومده یا نه، برای همین فاکتور رو پرداخت نشده نگه می داره.

نشانه های رایجش اینا هستن:

• پیامک برداشت از بانک اومده ولی سفارش موفقی نیست.
• سفارش توی وضعیت «در انتظار پرداخت» مونده.
• بعد از برگشت از بانک، صفحه خطا، صفحه سفید یا پیام 403 و 500 می بینی.
• صفحه «پرداخت موفق» نمایش داده شده ولی وضعیت سفارش عوض نشده.
• مشتری بعد از برگشت لاگین نیست یا سبد خریدش خالی شده.

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

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

چرا بازگشت از درگاه پرداخت خراب می شه؟ از محتمل ترین شروع کن

این ترتیب از تجربه عمومی کار با درگاه های شاپرکی اومده. سایت تو ممکنه فرق داشته باشه، ولی از بالا شروع کنی معمولاً زودتر به نتیجه می رسی.

۱. آدرس بازگشت اشتباه یا قدیمی

شایع ترین علت همینه و کمتر از بقیه بهش شک می کنیم. دامنه عوض شده، سایت از http به https رفته، www اضافه یا حذف شده، یا آدرس تستی از زمان توسعه توی تنظیمات مونده. بیشتر درگاه ها انتظار دارن دامنه آدرس بازگشت با دامنه ثبت شده برای ترمینال یکی باشه، وگرنه یا درخواست رد می شه یا مشتری به آدرسی می رسه که وجود نداره.

چک کردنش ساده است: آدرسی که دقیقاً توی درخواست به درگاه می فرستی رو لاگ کن و توی مرورگر بازش کن. باید یه پاسخ بده، نه 404. یه استثنا هم هست: بعضی درگاه ها آدرس رو از پنل برمی دارن، نه از درخواست. اون وقت تغییر کد هیچ اثری نداره و باید هر دو جا رو چک کنی.

۲. ریدایرکت و مشکل SSL

فرض کن بانک با POST برمی گرده و سرور تو آدرس رو از http به https یا از بدون www به www ریدایرکت می کنه. بیشتر وقت ها با ریدایرکت 301 یا 302، POST به GET تبدیل می شه و پارامترهای بانک از بین می رن. سایت هم بدون هیچ خطای واضحی یه صفحه معمولی نشون می ده.

SSL هم همین طوره: گواهی منقضی، زنجیره ناقص یا نسخه قدیمی TLS باعث می شه مرورگر مشتری هشدار بده یا درخواست سرور به سرور رد بشه. راه حل اینه که آدرس بازگشت از همون اول شکل نهایی و https باشه و هیچ ریدایرکتی سر راهش نباشه. اجبار https روی کل سایت کار درستیه و برای سئو هم خوبه، فقط آدرس callback نباید به اون ریدایرکت وابسته باشه.

۳. فایروال، CSRF و کش

این سه تا شبیه همن چون هر کدوم درخواست بانک رو قبل از رسیدن به کد تو رد می کنن.

• فایروال و افزونه امنیتی: درخواست بانک از دید یه WAF مشکوکه، چون هدر عجیب داره و از IP ناشناخته میاد. محدودیت تعداد درخواست، مسدودسازی بر اساس کشور و صفحه چالش (مثل کپچا) هم همین اثر رو دارن، چون بانک نمی تونه کپچا حل کنه. ما مسیر بازگشت از درگاه رو از فایروال سایت و محدودیت های ورود جدا نگه می داریم تا بازگشت کاربر از بانک هیچ وقت مسدود نشه و پرداخت نیمه کاره نمونه.
• CSRF: فریم ورک ها POST بدون توکن رو با 419 یا 403 رد می کنن. مسیر callback باید از این بررسی مستثنا بشه. چون بانک توکن سایت تو رو نداره، امنیت این مسیر رو verify سمت سرور تامین می کنه.
• کش: اگه صفحه کش یا CDN آدرس callback رو کش کنه، پاسخ قدیمی برمی گرده و کد تو اصلاً اجرا نمی شه.

بده بستانش هم اینه که هر استثنا یه کم امنیت رو شل می کنه. جبرانش اینه که هیچ وضعیتی رو از پارامترهای ورودی باور نکنی و فقط به نتیجه verify اعتماد کنی.

۴. نشست و کوکی گم می شه

مشتری از بانک با درخواست cross-site برمی گرده. مرورگرها به خاطر تنظیم SameSite روی کوکی نشست، گاهی کوکی رو توی این برگشت نمی فرستن. نتیجه اینه که کاربر لاگین نیست و سبدش خالیه، پس کد نمی تونه بفهمه این پرداخت مال کدوم سفارشه. راه حلش اینه که شناسه سفارش و شناسه تراکنش رو قبل از ریدایرکت به بانک توی دیتابیس ذخیره کنی و سفارش رو با پارامترهای برگشتی پیدا کنی، نه با نشست.

۵. تایید نهایی شکست می خوره

callback درست رسیده ولی verify خطا می ده. دلیل های معمول:

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

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

۶. مشتری اصلاً برنگشته

مشتری تب رو بسته، اینترنت موبایلش قطع شده یا بین اپ بانک و مرورگر گم شده. پرداخت موفق بوده ولی callback اصلاً صدا زده نشده. این مورد با هیچ تنظیمی صفر نمی شه و فقط با یه مکانیزم تطبیق (reconciliation) پوشش داده می شه که پایین تر می گم.

اول لاگ رو بخون، بعد حدس بزن

با این ترتیب جلو برو:

1. از مشتری کد پیگیری یا شماره مرجع و زمان دقیق پرداخت رو از پیامک یا اپ بانکش بگیر.
2. توی پنل درگاه تراکنش رو پیدا کن. اگه موفق و تایید نشده است، مشکل بعد از پرداخته. اگه اصلاً نیست، مشکل قبل از پرداخت بوده.
3. آدرس بازگشت توی پنل رو با آدرس توی کد و تنظیمات مقایسه کن.
4. ریدایرکت و SSL رو از بیرون تست کن.
5. لاگ دسترسی وب سرور رو برای همون ساعت ببین.
6. لاگ خطای اپلیکیشن و دیتابیس رو بخون.

دستورهای مرحله ۴ و ۵ این شکلی هستن. مسیر لاگ بسته به وب سرور و هاست فرق می کنه، روی هاست اشتراکی معمولاً از پنل مدیریت هاست پیداش می کنی:

# آیا آدرس callback ریدایرکت می شه؟
curl -i -X POST "https://example.ir/payment/callback" -d "test=1"

# وضعیت گواهی و زنجیره SSL
openssl s_client -connect example.ir:443 -servername example.ir

# رد درخواست بانک توی لاگ دسترسی
grep "payment/callback" /var/log/nginx/access.log | tail -n 20

نتیجه رو این طوری بخون:

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

با تراکنش های گیرکرده چی کار کنیم؟

بعد از پیدا کردن علت، هنوز چند تا تراکنش معلق داری. سه راه داری و هر کدوم یه بده بستان:

• verify دستی و تکمیل سفارش: اگه تراکنش هنوز قابل تایید باشه، سریع ترین راهه و مشتری راضی می مونه. ریسکش اینه که بدون بررسی دقیق سفارش اشتباه تکمیل بشه.
• صبر برای برگشت خودکار وجه: بی خطره، ولی مشتری باید چند ساعت یا بیشتر منتظر بمونه. حتماً بهش پیامک یا تماس بزن و بگو چه خبره.
• پیگیری از پشتیبان درگاه: وقتی کد پیگیری داری ولی تراکنش توی سیستم عجیبه، این راه درسته. کندتره ولی تکلیف مالی رو روشن می کنه.

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

پیشگیری: که پرداخت نیمه کاره نمونه

• بعد از هر تغییر یه پرداخت واقعی با مبلغ کم بزن. تغییر دامنه، نصب SSL جدید، جابه جایی هاست و تغییر IP سرور یعنی احتمال شکستن callback. تست قبل از این که مشتری بفهمه، ارزانتره.
• مسیر callback رو جدا از فایروال و محدودیت ها نگه دار و بررسی امنیتیش رو روی verify بذار.
• سفارش و شناسه تراکنش رو قبل از رفتن به بانک ذخیره کن و به نشست تکیه نکن.
• verify رو طوری بنویس که اگه دو بار صدا زده شد، سفارش دو بار تکمیل نشه. مبلغ رو هم با واحد درست (تومان یا ریال) مقایسه کن.
• یه کار زمان بندی شده داشته باش که هر چند دقیقه سفارش های معلق رو از درگاه استعلام کنه، اگه درگاهت این قابلیت رو داره. هزینه اش پیچیدگی و بار اضافه است، ولی مشتری که برنگشته رو هم نجات می ده.
• صفحه بازگشت رو برای حالت نامشخص طراحی کن. به جای خطا بنویس «پرداختت در حال بررسیه»، کد پیگیری رو نشون بده و پیامک بفرست. مشتری آروم تر می شه و تعداد تماس ها کم می شه.
• مسیر callback رو مانیتور کن. افزایش ناگهانی 4xx و 5xx روی این آدرس یا سفارش های معلق قدیمی باید هشدار بدن. ما توی مانیتورینگ و پایداری دقیقاً همین هشدارها رو برای مسیرهای حساس تنظیم می کنیم.

انتخاب درگاه هم بی تاثیر نیست. روش بازگشت، امکان استعلام و کیفیت مستندات بین درگاه ها فرق دارن. اگه هنوز درگاه رو انتخاب نکردی، درگاه پرداخت شاپرکی برای سایت؛ تفاوت ها و نکته های انتخاب کمکت می کنه از اول چیز مناسبی بگیری.

سوالات متداول

اگه پول کم شده ولی سفارش ثبت نشده، پول مشتری گم می شه؟

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

فقط با کد پیگیری مشتری می تونم سفارش رو دستی تایید کنم؟

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

چرا فقط بعضی پرداخت ها گیر می کنن؟

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

بعد از تغییر هاست یا دامنه پرداخت قطع شد، چی چک کنم؟

اول IP جدید سرور رو چک کن که برای ترمینال درگاه ثبت شده باشه، چون بعضی درگاه ها این رو لازم دارن و تغییر کد کمکی نمی کنه. بعدش آدرس بازگشت توی پنل، دامنه ثبت شده برای ترمینال و SSL رو بررسی کن. در آخر یه پرداخت کم مبلغ بزن و لاگ رو دنبال کن.

قبل از تماس بعدی مشتری

مشکل بازگشت از درگاه پرداخت تقریباً هیچ وقت اسرارآمیز نیست. معمولاً یکی از این چهار جا خرابه: آدرس، ریدایرکت یا SSL، فایروال، یا verify. هر وقت پول رفته و سفارش نیومده، با کد پیگیری شروع کن، پنل درگاه رو ببین و بعد لاگ سرور رو بخون. و یه پرداخت تستی بعد از هر تغییر فنی رو فراموش نکن.