وقتی کاربر دکمه ثبت سفارش را می‌زند و spinner متوقف نمی‌شود، اولین اقدام نباید فشردن دوباره دکمه یا پاک کردن سفارش باشد. ممکن است سفارش یا تراکنش در backend ساخته شده باشد اما پاسخ Ajax، redirect یا JavaScript شکست خورده باشد. تکرار درخواست در این لحظه می‌تواند سفارش یا درخواست پرداخت دیگری ایجاد کند.
اقدام فوری: زمان، ایمیل/شناسه امن مشتری و مبلغ را ثبت کنید؛ در مدیریت ووکامرس و پنل درگاه بررسی کنید سفارش یا تراکنش ایجاد شده است یا نه. سپس request ثبت سفارش را در DevTools و logهای ووکامرس/PHP همان timestamp ببینید. قبل از هر retry وضعیت قبلی را تعیین تکلیف کنید و اطلاعات کارت یا secret را ثبت نکنید.
ابتدا از پرداخت یا سفارش تکراری جلوگیری کنید
- کاربر را از کلیک چندباره و refresh منع کنید.
- سفارش‌های جدید با مبلغ و زمان مشابه را بررسی کنید.
- تراکنش درگاه را با شناسه مرجع تطبیق دهید.
- موجودی یا coupon رزروشده را ثبت کنید.
- تا روشن شدن وضعیت، سفارش را حذف یا دوباره Paid نکنید.
اگر وجه کسر شده، وضعیت بانکی و callback باید مبنای reconciliation باشد؛ پیام spinner به‌تنهایی شکست پرداخت را ثابت نمی‌کند.
در Network چه چیزی ببینیم؟
DevTools را پیش از تکرار کنترل‌شده باز کنید و Preserve log را فعال کنید. request مربوط به Checkout را پیدا و این موارد را ثبت کنید:
- URL و method بدون token حساس
- status code و مدت انتظار
- response JSON یا HTML خطا
- redirect chain
- requestهای تکراری
- پیام Console و stack JavaScript
اگر response به‌جای JSON صفحه خطای HTML، login یا challenge امنیتی باشد، frontend ممکن است آن را parse نکند و spinner بماند.
سناریوهای رایج
| نشانه | علت محتمل | بررسی بعدی |
|---|---|---|
| HTTP 500 | Fatal PHP یا exception | PHP/error log و stack trace |
| 403 یا challenge | WAF، nonce یا rule امنیتی | شناسه rule و access log |
| Timeout/504 | API کند، Query، worker یا proxy | timeline لایه‌ها و process |
| 200 با HTML | redirect، warning یا صفحه غیرمنتظره | response body و route |
| سفارش ساخته، redirect نشده | درگاه یا JavaScript پس از ایجاد سفارش | order note، gateway log و Console |
| هیچ request ارسال نمی‌شود | validation یا خطای JS | Console، field و event handler |
خطای PHP و log ووکامرس
در WooCommerce Status بخش logها، فایل مربوط به درگاه و روز حادثه را بررسی کنید. PHP-FPM یا hosting error log ممکن است stack کامل‌تری داشته باشد. debug عمومی روی production می‌تواند مسیر و اطلاعات حساس را نمایش دهد؛ logging را محدود و نمایش خطا را خاموش نگه دارید. راهنمای debug.log وردپرس روش امن‌تری ارائه می‌دهد.
تداخل JavaScript
بهینه‌سازی فایل، delay/defer، قالب و افزونه validation ممکن است handler Checkout را خراب کنند. نخستین خطای Console را بررسی کنید؛ خطاهای بعدی ممکن است پیامد آن باشند. در staging با همان asset mode، افزونه‌های بهینه‌سازی را مرحله‌ای و با پاک‌سازی cache آزمون کنید. همه گزینه‌ها را یک‌جا خاموش نکنید چون علت قابل انتساب نمی‌ماند.
WAF، CDN و Cache
challenge یا cache روی endpoint dynamic می‌تواند response غیرمنتظره بسازد. rule و request ID را در log پیدا و استثنا را فقط برای route و رفتار لازم طراحی کنید. خاموش کردن کامل WAF یا امنیت CDN راه‌حل امن نیست. Checkout، cart و endpointهای وابسته باید از page cache عمومی bypass شوند.
درگاه پرداخت و Idempotency
ساخت درخواست، redirect، callback و webhook مراحل جدا هستند. timeout در پاسخ به معنی آن نیست که provider درخواست را دریافت نکرده است. retry باید از کلید یا شناسه یکتای مورد پشتیبانی درگاه استفاده کند؛ اگر افزونه چنین تضمینی ندارد، تکرار خودکار می‌تواند چند تراکنش بسازد. log را با order note و پنل provider تطبیق دهید.
Session، Cookie و HTTPS
دامنه ناهماهنگ، reverse proxy، cookie policy یا mixed HTTP/HTTPS می‌تواند session را بین نمایش و ثبت سفارش تغییر دهد. URL نهایی، headerهای proxy و cookie domain/secure را بررسی کنید. تغییر مستقیم home و siteurl بدون شناخت proxy ممکن است redirect loop یا خروج همه کاربران ایجاد کند.
Query، Lock و موجودی
ثبت سفارش writeهای متعددی دارد. job گزارش یا sync موجودی ممکن است lock طولانی بسازد. processlist، slow log و transaction را با timestamp request تطبیق دهید. process یا transaction را بدون شناخت عملیات terminate نکنید؛ ممکن است سفارش نیمه‌کاره و وضعیت نامشخص باقی بماند.
کمبود Worker و Timeout
اگر request در صف PHP منتظر است، بالا بردن timeout فقط انتظار را طولانی می‌کند. active worker، queue، CPU، RAM و وابستگی‌ها را بسنجید. اگر request داخل API خارجی متوقف است، افزایش worker می‌تواند درخواست‌های بیشتری را پشت همان سرویس جمع کند.
فرایند بازتولید امن
- clone نزدیک به production و backup قابل restore بسازید.
- ایمیل و webhook محیط آزمایش را به مقصد امن هدایت کنید.
- از sandbox درگاه یا روش پرداخت کنترل‌شده استفاده کنید.
- یک محصول، آدرس و روش ارسال ثابت انتخاب کنید.
- Network، Console، PHP و gateway log را هم‌زمان ثبت کنید.
- فقط یک مؤلفه را در هر مرحله تغییر دهید.
- پس از اصلاح، retry و دوبارکلیک را نیز آزمایش کنید.
بعد از رفع خطا چه چیزهایی را تأیید کنیم؟
- فقط یک سفارش و یک درخواست پرداخت ساخته می‌شود.
- total، مالیات، ارسال و موجودی صحیح‌اند.
- redirect و callback در زمان معقول کامل می‌شوند.
- وضعیت سفارش با نتیجه درگاه هماهنگ است.
- ایمیل، webhook و Action Scheduler سالم‌اند.
- خطای Console و PHP جدیدی ثبت نمی‌شود.
اشتباه‌های رایج
- کلیک مکرر روی ثبت سفارش
- حذف سفارش قبل از reconciliation پرداخت
- تغییر دستی وضعیت به Paid بدون مدرک درگاه
- خاموش کردن WAF یا TLS verification
- افزایش همه timeoutها
- آزمون درگاه واقعی بدون برنامه برگشت وجه
- restore دیتابیس قدیمی فروشگاه
ارتباط با کندی Checkout
اگر request در نهایت صحیح تمام می‌شود ولی طولانی است، راهنمای تشخیص کندی Checkout را اجرا کنید. اگر response 500 است، بررسی خطای 500 وردپرس برای یافتن لایه خطا مناسب‌تر است.
چه زمانی فوراً کمک تخصصی بگیریم؟
اگر وجه کسر شده ولی سفارش نامشخص است، سفارش‌های تکراری ایجاد می‌شوند یا خطا فقط زیر ترافیک واقعی رخ می‌دهد، آزمون بیشتر می‌تواند خسارت مالی بسازد. پشتیبانی فروشگاه ووکامرس می‌تواند تراکنش، callback، order note و logها را بدون حذف شواهد reconcile کند.
پرسش‌های متداول
اگر پول کسر شد دوباره پرداخت کنیم؟
خیر؛ ابتدا شناسه تراکنش و سفارش با پنل درگاه تطبیق داده شود.
چرا فقط یک روش پرداخت گیر می‌کند؟
تنظیمات، API، credential، callback و JavaScript همان درگاه را با روش سالم مقایسه کنید.
آیا پاک کردن Cache مشکل را حل می‌کند؟
ممکن است asset قدیمی را موقتاً حذف کند، اما علت PHP، درگاه یا session را حل نمی‌کند و تشخیص باید ادامه یابد.