علت ثبت نشدن سفارش در ووکامرس؛ تشخیص مشکل سبد، ارسال و پرداخت

«سفارش ثبت نمی‌شود» دقیقاً کدام وضعیت است؟

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

از مشتری نخواهید برای اثبات خطا چند بار مبلغ بپردازد. اطلاعات غیرحساس مثل زمان تقریبی، نشانی صفحه و متن پیام برای شروع کافی است. تصویر خطا باید از داده شخصی پاک شود. اگر سفارش در مدیریت وجود دارد، یادداشت و وضعیت آن را بخوانید. صرف مشاهده رسید یا پیام «موفق» در یک بخش، هماهنگی همه سامانه‌ها را ثابت نمی‌کند؛ وضعیت تراکنش را از مسیر مجاز ارائه‌دهنده نیز بررسی کنید.

یک سناریوی تکرارپذیر و امن بسازید

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

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

سبد و صفحه تسویه را قبل از درگاه بررسی کنید

اگر محصول وارد سبد نمی‌شود، موجودی، تنوع انتخاب‌شده و محدودیت خرید را بررسی کنید. محصول متغیر ممکن است به انتخاب ویژگی نیاز داشته باشد. افزونه حداقل سفارش یا محدودیت نقش کاربر نیز می‌تواند رفتار خرید را تغییر دهد. با حساب آزمایشی و مرورگر تازه همان مرحله را انجام دهید. نتیجه حساب مدیر را به مشتری تعمیم ندهید؛ مدیر ممکن است از محدودیت‌ها عبور کند یا نسخه متفاوتی از صفحه ببیند.

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

وقتی روش ارسال نمایش داده نمی‌شود

نشانی تست را با مناطق ارسال و روش‌های فعال مقایسه کنید. اگر کشور یا استان انتخاب‌شده با منطقه تعریف‌شده نمی‌خواند، ممکن است روش مورد انتظار نمایش داده نشود. مقدار سبد و شرط ارسال رایگان، کلاس حمل محصول و محدودیت افزونه را نیز بررسی کنید. راهنمای رسمی عیب‌یابی ارسال ووکامرس بررسی نشانی، سبد و منطقه را در محیط آزمایشی توضیح می‌دهد.

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

درگاه، بازگشت پرداخت و وضعیت سفارش را جدا بررسی کنید

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

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

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

تداخل و تغییر اخیر را با کنترل بررسی کنید

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

اگر با محیط پایه و بدون افزونه مشکوک مشکل رفع شد، همان افزونه را همراه شرایط دقیق بررسی کنید؛ ممکن است تعارض میان دو ابزار باشد. نسخه وردپرس، ووکامرس، PHP و قالب را در گزارش ثبت کنید. یادداشت سفارش و گزارش‌های ووکامرس می‌توانند سرنخ بدهند، اما لاگ‌ها را بدون پاک‌سازی داده حساس به دیگران نفرستید. خطا را با مسیر تکرار و زمان مشخص به پشتیبانی مرتبط ارائه کنید.

برای پشتیبانی چه اطلاعاتی آماده کنیم؟

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

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

پس از اصلاح، فقط همان دکمه را تست نکنید

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

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