برای رفع پرداخت اینترنتی ناموفق، ابتدا وضعیت تراکنش را از وضعیت سفارش جدا کنید. خطا ممکن است هنگام اتصال به درگاه، ورود اطلاعات پرداخت، بازگشت به فروشگاه یا تأیید نتیجه رخ داده باشد. پیام روی صفحه به‌تنهایی مشخص نمی‌کند که پرداخت انجام شده است یا نه؛ فروشگاه باید نتیجه را از مسیر معتبرِ ارائه‌دهنده بررسی کند.
این بررسی برای مدیر فروشگاه، تیم پشتیبانی و برنامه‌نویس، نقطهٔ شروع مشترکی دارد: کدام سفارش، در چه زمانی و در کدام مرحله متوقف شده است؟ با همین اطلاعات می‌توان پیگیری را از محل درست شروع کرد و احتمال پرداخت یا ارسال تکراری را کاهش داد.
اگر مبلغ کم شده، اما سفارش ثبت نشده است چه کنیم؟
مشتری بهتر است ابتدا تاریخچهٔ سفارش و گردش حساب خود را بررسی کند و تا روشن‌شدن نتیجه، برای همان خرید پشت‌سرهم پرداخت تازه نسازد. پیامک برداشت یا تصویر رسید را همراه با وضعیت سفارش پیگیری کنید؛ تأیید نهاییِ ارتباط آن تراکنش با سفارش، بر عهدهٔ فروشگاه و ارائه‌دهندهٔ پرداخت است.
- شمارهٔ سفارش، مبلغ و زمان تقریبی را نگه دارید. اگر شمارهٔ پیگیری دارید، آن را در کانال رسمی پشتیبانی فروشگاه ارائه کنید.
- از فروشگاه بخواهید وضعیت تراکنش را تطبیق دهد. نتیجهٔ تأیید پرداخت و سابقهٔ سفارش باید کنار هم بررسی شوند.
- اگر مغایرت باقی ماند، از مسیر رسمی پیگیری کنید. بانک صادرکنندهٔ کارت یا ارائه‌دهندهٔ پرداخت، متناسب با نوع مشکل، مرجع بررسی وضعیت وجه هستند.
- رمز، CVV2 و تصویر کامل کارت را ارسال نکنید. در اسکرین‌شات، موجودی و سایر اطلاعات شخصیِ نامرتبط را بپوشانید.
برای زمان رفع مغایرت یا برگشت وجه، عدد واحدی به همهٔ تراکنش‌ها تعمیم ندهید. نوع تراکنش و نتیجهٔ بررسی اهمیت دارد؛ پاسخ رسمیِ مربوط به همان مورد را ملاک قرار دهید. زمان تسویهٔ وجه با پذیرنده نیز با وضعیت خرید مشتری یکسان نیست.
سه وضعیت پرداخت که اقدام متفاوت می‌خواهند
| وضعیت بررسی‌شده | معنای آن برای فروشگاه | اقدام بعدی |
|---|---|---|
| رد یا لغو پرداخت، طبق پاسخ معتبر | پرداخت موفق برای این تلاش تأیید نشده است | نمایش علت قابل فهم و فراهم‌کردن تلاش مجددِ کنترل‌شده |
| نتیجهٔ نامشخص یا پاسخ دریافت‌نشده | هنوز برای اعلام موفق یا ناموفق شواهد کافی نداریم | استعلام یا تطبیق مجدد و نمایش «در انتظار بررسی» |
| پرداخت تأییدشده، سفارش به‌روز نشده | مغایرت در ثبت یا پردازش سفارش وجود دارد | اتصال تراکنش به سفارش و تکمیل پردازش بدون دریافت دوبارهٔ وجه |
نام وضعیت‌ها در پنل‌های مختلف فرق می‌کند. مدیر فروشگاه باید بداند هر عنوان به چه معناست و چه شواهدی آن را تغییر می‌دهد. قرارگرفتن همهٔ موارد در وضعیت «ناموفق»، پیگیری مغایرت‌ها را دشوار می‌کند.
مسیر پرداخت را از ابتدا تا تأیید دنبال کنید
فروشگاه مبلغ سفارش را محاسبه می‌کند، درخواست پرداخت می‌سازد و کاربر را به درگاه می‌فرستد. پس از اقدام مشتری، نتیجه باید طبق سازوکار همان درگاه بررسی و در سفارش ثبت شود. «بازگشت» یا callback به مسیری گفته می‌شود که مرورگر یا سرویس پرداخت، نتیجهٔ اولیه را به فروشگاه می‌رساند.
امکانات ارائه‌دهنده‌ها یکسان نیست: ممکن است تأیید تراکنش، استعلام وضعیت یا اعلان مستقیم سرور داشته باشند. برای نمونه، SDK رسمی زرین‌پال عملیات تأیید و استعلام را جدا معرفی می‌کند. تیم فنی باید بداند هر عملیات چه زمانی اجرا می‌شود و پاسخ آن چگونه به همان تلاش پرداخت متصل خواهد شد.
دلایل رایج خطای پرداخت و روش بررسی آن‌ها
۱. مبلغ، واحد پول یا اطلاعات سفارش هماهنگ نیست
مبلغی که برای پرداخت ارسال می‌شود باید با مبلغ ثبت‌شدهٔ همان سفارش تطبیق داشته باشد. قیمت کالا، تخفیف و ارسال را سرور محاسبه کند. واحد پول را هم در تنظیمات فروشگاه و مستندات درگاه بررسی کنید؛ نمایش تومان در سایت، واحد مورد انتظار API را تعیین نمی‌کند.
برای تشخیص، یک سفارش آزمایشی با تخفیف و هزینهٔ ارسال بسازید. مبلغ ثبت‌شده، مبلغ درخواست و مبلغ مرحلهٔ تأیید را کنار هم بگذارید. اگر سبد پس از شروع پرداخت تغییر می‌کند، مشخص باشد هر تراکنش مربوط به کدام نسخه و مبلغ سفارش است.
۲. تنظیمات درگاه یا مسیر بازگشت نادرست است
آدرس محیط آزمایشی، شناسهٔ پذیرنده، نشانی بازگشت و الزامات اتصال را با راهنمای رسمی همان درگاه مقایسه کنید. پس از تغییر دامنه، انتقال هاست یا نصب افزونهٔ جدید، این بخش‌ها ارزش بررسی دارند. پیام خطای اعتبارسنجی درگاه را دقیق بخوانید؛ هر کد الزاماً به خرابی شبکه مربوط نیست.
تیم فنی باید دسترسی به مسیر بازگشت، HTTPS و پاسخ سرور را بررسی کند. برای رفع اتصال، اعتبارسنجی گواهی امنیتی را خاموش نکنید. کلید دسترسی و شناسه‌های محرمانه هم نباید در صفحهٔ خطا، گزارش عمومی یا کد قابل مشاهدهٔ مرورگر قرار بگیرند.
۳. ارتباط قطع شده و نتیجه به فروشگاه نرسیده است
قطع اینترنت مشتری با قطع ارتباط سرور فروشگاه و درگاه دو رخداد متفاوت است. در حالت timeout، یک طرف در زمان مقرر پاسخ نگرفته است؛ ممکن است عملیات سمت دیگر انجام شده باشد. برای همین، ساخت فوری یک پرداخت تازه می‌تواند پیگیری را پیچیده کند.
ابتدا شناسهٔ همان تلاش را پیدا کنید و از روش مجاز ارائه‌دهنده برای تعیین وضعیت استفاده کنید. تکرار درخواست فقط طبق قواعد همان API انجام شود. زمان پاسخ و مرحلهٔ قطع ارتباط را ثبت کنید تا روشن شود مشکل پیش از ایجاد تراکنش بوده یا هنگام دریافت و تأیید نتیجه.
۴. مشتری از درگاه برگشته، اما نشست یا صفحه درست کار نمی‌کند
بسته‌شدن تب، جابه‌جایی بین برنامه‌ها یا مشکل مرورگر ممکن است بازگشت را ناقص کند. مستندات Stripe هم توضیح می‌دهد که مشتری می‌تواند پرداخت موفق داشته باشد، اما به صفحهٔ نتیجه نرسد. راهکار هر درگاه باید با امکانات واقعی آن، از جمله تأیید یا استعلام سمت سرور، طراحی شود.
در آزمون موبایل، مسیر را از مرورگر معمولی و مرورگر داخلی شبکه‌های اجتماعی بررسی کنید. سفارش باید با شناسهٔ معتبر و کنترل دسترسی پیدا شود؛ وابستگی کامل به یک نشست موقت، بازیابی نتیجه را دشوار می‌کند. صفحهٔ نتیجه نیز باید برای مشتریِ صاحب سفارش قابل پیگیری بماند.
۵. پرداخت تأیید شده، اما ثبت سفارش کامل نشده است
ممکن است تأیید درگاه دریافت شده باشد، اما خطای پایگاه داده، توقف برنامه یا اشکال در اجرای کار بعدی، سفارش را در وضعیت قبلی نگه دارد. زمان تأیید را با زمان تغییر وضعیت سفارش و خطاهای همان بازه مقایسه کنید.
برای یک آزمون فنی، پس از تأیید پرداخت، خرابیِ کنترل‌شده در ارسال پیامک را شبیه‌سازی کنید. ناموفق‌بودن پیامک نباید پرداخت معتبر را ناموفق نشان دهد یا دریافت وجه تازه‌ای بسازد. وضعیت مالی، آماده‌سازی سفارش و اطلاع‌رسانی باید قابل تشخیص و پیگیری باشند.
۶. درخواست یا اعلان نتیجه چند بار پردازش می‌شود
رفرش صفحه، دوبار لمس دکمه یا تکرار اعلان می‌تواند اجرای چندباره ایجاد کند. پردازش idempotent یعنی تکرار همان عملیات، اثر تازه‌ای مثل ارسال دوبارهٔ کالا نسازد. غیرفعال‌کردن موقت دکمه مفید است، اما این کنترل باید در سرور هم وجود داشته باشد.
در محیط آزمایشی، نتیجهٔ یک تراکنش را دو بار و سپس هم‌زمان پردازش کنید. باید فقط یک ثبت معتبر برای پرداخت و یک عملیات آماده‌سازی سفارش داشته باشید. اگر درگاه کلید جلوگیری از تکرار ارائه می‌کند، نحوهٔ استفاده و محدودهٔ اعتبارش را از مستندات خودش بگیرید؛ این قابلیت در همهٔ سرویس‌ها یکسان نیست.
در فروشگاه ووکامرسی چه چیزهایی را بررسی کنیم؟
از سفارشِ دارای مشکل شروع کنید: درگاه استفاده‌شده، یادداشت‌های سفارش و زمان تغییر وضعیت را ببینید. راهنمای رسمی WooCommerce پیشنهاد می‌کند اگر این یادداشت‌ها کافی نبودند، لاگ همان درگاه را در بخش «وضعیت ← گزارش‌ها» بررسی کنید. گزارش‌گیری تازه، رخدادهای گذشته‌ای را که ثبت نشده‌اند بازسازی نمی‌کند.
اگر مشکل پس از تغییر افزونه یا قالب شروع شده، ناسازگاری را در نسخهٔ آزمایشیِ جدا از فروشگاه اصلی بررسی کنید. در آن نسخه، پرداخت و پیام‌رسانی واقعی را فعال نگذارید. تغییر چند افزونه به‌طور هم‌زمان یا دست‌کاری مستقیم وضعیت سفارش‌ها، تشخیص علت را دشوار می‌کند.
بعد از خطا، به مشتری چه پیامی نشان دهیم؟
پیام باید با نتیجهٔ بررسی هماهنگ باشد و قدم بعدی را روشن کند. راهنمای W3C بر بازخورد کوتاه، قابل فهم و قابل اقدام تأکید دارد. جزئیات داخلی برنامه و پاسخ خام سرویس پرداخت برای مشتری مناسب نیستند.
اگر نتیجه هنوز مشخص نیست، پیامی مانند «وضعیت پرداخت این سفارش در حال بررسی است؛ نتیجه را از بخش سفارش‌ها پیگیری کنید» مناسب‌تر از اعلام قطعی شکست است. چنین پیامی فقط وقتی درست است که فروشگاه واقعاً مسیر بررسی و پیگیری داشته باشد. در حالت ردِ تأییدشده هم علت قابل ارائه و امکان تلاش دوباره را روشن کنید.
برای عیب‌یابی، چه اطلاعاتی ثبت کنیم؟
زمان رخداد با منطقهٔ زمانی مشخص، شناسهٔ داخلی سفارش، شناسهٔ تلاش پرداخت، نام مرحله، کد پاسخ و نتیجهٔ تأیید معمولاً نقطهٔ شروع مناسبی هستند. برای اتصال رخدادهای مرتبط می‌توان یک شناسهٔ پیگیری داخلی مشترک داشت. دسترسی به این گزارش‌ها و مدت نگهداری آن‌ها باید مشخص باشد.
رمز، CVV2، شمارهٔ کامل کارت، کلید API و توکن دسترسی را در لاگ ثبت نکنید. پاسخ خام درخواست‌ها ممکن است دادهٔ حساس داشته باشد؛ فقط فیلدهای لازم و مجاز را نگه دارید. راهنمای ثبت رخداد OWASP دربارهٔ حذف یا پوشاندن همین داده‌ها توضیح می‌دهد.
چک‌لیست آزمون پیش از انتشار اصلاحات
- پرداخت موفق در محیط آزمایشی، سفارش را دقیقاً یک بار به وضعیت درست برساند.
- انصراف مشتری و ردِ پرداخت، پیام و وضعیت قابل فهم داشته باشند.
- قطع ارتباط یا تأخیر، مسیر بررسی نتیجه را فعال کند و شکست قطعی فرض نشود.
- بسته‌شدن مرورگر، امکان بازیابی وضعیت سفارش را از بین نبرد.
- دریافت تکراری یا هم‌زمانِ نتیجه، پرداخت یا ارسال تازه نسازد.
- خرابی پیامک و ایمیل، ثبت مالیِ تأییدشده را تغییر ندهد.
پس از انتشار، تعداد تلاش‌های پرداختِ تأییدشده، موارد نامشخص و مغایرت سفارش را با تعریف ثابت دنبال کنید. فقط کم‌شدن پیام‌های خطا کافی نیست؛ بررسی کنید سفارش‌های پرداخت‌شده درست ثبت و قابل پیگیری شده‌اند.
برای بازبینی وضعیت‌های پرداخت، ارتباط با درگاه یا خطاهای تکرارشونده، صفحهٔ مشاوره و پشتیبانی نرم‌افزار داپا را ببینید. در طراحی فروشگاه و وب‌اپلیکیشن نیز سناریوهای خطای پرداخت باید از ابتدا مشخص شوند. موانع پیش از ورود به درگاه را در مقالهٔ دلایل رها کردن سبد خرید بررسی کرده‌ایم.
پرسش‌های متداول
آیا پیام برداشت از حساب برای تأیید سفارش کافی است؟
فروشگاه باید تراکنش را از مسیر معتبر ارائه‌دهنده بررسی و با سفارش تطبیق دهد. پیام برداشت، جای این بررسی فنی را نمی‌گیرد.
آیا تغییر درگاه همهٔ خطاها را برطرف می‌کند؟
خیر. اگر مشکل در مبلغ، ثبت سفارش یا پردازش تکراری باشد، اتصال درگاه تازه هم می‌تواند همان ایراد را داشته باشد. ابتدا محل توقف را مشخص کنید.
چرا پرداخت فقط برای بعضی کاربران موبایل مشکل دارد؟
نوع مرورگر، مسیر بازگشت، وضعیت نشست و جابه‌جایی میان برنامه‌ها را بررسی کنید. سناریو را با همان شرایط و اطلاعات ساختگی در محیط تست بازسازی کنید.
وجه تراکنش ناموفق چه زمانی برمی‌گردد؟
ابتدا باید وضعیت واقعی تراکنش روشن شود. زمان رسیدگی یا برگشت وجه را از بانک یا ارائه‌دهندهٔ مربوط به همان تراکنش بگیرید؛ برای همهٔ موارد زمان یکسان اعلام نکنید.
