پرداخت موفق اما سفارش در انتظار پرداخت در ووکامرس؛ چه چیزی را بررسی کنیم؟

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

نویسنده: سجاد · انتشار: ۲۰۲۶/۱۰/۰۹

«در انتظار پرداخت» چه معنایی دارد؟

در وضعیت‌های استاندارد ووکامرس، Pending payment یعنی سفارش دریافت شده و پرداخت آن هنوز ثبت نشده است. Processing برای سفارش پرداخت‌شده‌ای است که منتظر انجام عملیات است؛ Completed پایان انجام سفارش را نشان می‌دهد. On hold نیز می‌تواند برای انتظار تأیید پرداخت استفاده شود. جزئیات هر روش را با مستند وضعیت سفارش‌ها و مستند همان درگاه بررسی کنید.

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

اول این پنج مورد را جمع کنید

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

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

مسیر تشخیص: مشکل در کدام مرحله است؟

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

1. درگاه نتیجهٔ قطعی ندارد: طبق امکانات استعلام سرویس پیگیری کنید. قطع ارتباط فروشگاه را با رد قطعی تراکنش یکی نگیرید.
2. نتیجهٔ معتبر وجود دارد، پیام به فروشگاه نرسیده: مسیر بازگشت یا اعلان، پاسخ HTTP، ریدایرکت و قواعد دسترسی سرور بررسی شوند. تنظیمات کش یا فایروال را فقط برای مسیر مستند و پس از تشخیص اصلاح کنید.
3. پیام رسیده، تأیید اجرا نشده: خطای اجرای افزونه، ارتباط خروجی، احراز هویت سرویس و تطبیق شناسه‌ها را بررسی کنید.
4. تأیید انجام شده، سفارش تغییر نکرده: سابقهٔ ذخیرهٔ نتیجه و خطای مرحلهٔ نهایی‌سازی را بررسی کنید؛ موفقیت درخواست بیرونی و موفقیت ثبت داخلی دو شاهد جدا هستند.
5. سفارش تغییر کرده، عملیات بعدی ناقص است: پیامک، انبار یا حسابداری را با سابقهٔ مستقل خودشان پیگیری کنید. ایجاد سفارش تازه برای رفع این نقص، مسیر اصلاح مناسبی نیست.

اعلان پرداخت درگاه را با وبهوک خروجی سفارش ووکامرس اشتباه نگیرید؛ اولی دربارهٔ نتیجهٔ پرداخت به فروشگاه خبر می‌دهد و دومی می‌تواند تغییر سفارش را به سامانهٔ دیگر اعلام کند. راهنمای وبهوک و API دوره‌ای تصمیم اتصال سامانه‌های بیرونی را جدا توضیح می‌دهد.

در توسعهٔ افزونه، تأیید را به تغییر وضعیت تقلیل ندهید

راهنمای رسمی توسعهٔ درگاه ووکامرس برای پرداخت تأییدشده استفاده از $order->payment_complete() را توصیه می‌کند تا وضعیت مناسب و اثر موجودی از مسیر استاندارد انجام شوند. نوشتن مستقیم Processing یا Completed جای این مسیر را نمی‌گیرد. رسیدگی به callback نیز باید در افزونه پیاده‌سازی شود. مرجع Payment Gateway API مبنای این بخش است.

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

مثال فرضی: یک سفارش، دو پیام برگشت

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

در فرایند پیشنهادی، هر تلاش پرداخت به سفارش خودش متصل است، نتیجهٔ تأیید ثبت می‌شود و اجرای هم‌زمانِ نهایی‌سازی کنترل دارد. «اگر سفارش پرداخت‌شده نیست، آن را پرداخت‌شده کن» بدون کنترل هم‌زمانی کافی نیست؛ دو اجرا ممکن است هر دو همان وضعیت اولیه را بخوانند. ابزار کنترل به معماری افزونه وابسته است و باید با آزمون هم‌زمان اثبات شود.

اثرهای بیرونی نیز شناسه و سابقهٔ مستقل داشته باشند تا شکست ارسال پیامک باعث تکرار تأیید مالی نشود. برای عملیات مالی بعد از سفارش، مسیر اتصال حسابداری و برای اعلان مشتری، راهنمای پیامک سفارش را ببینید.

اگر سفارش پیش از رسیدن تأیید لغو شده باشد

در برخی سفارش‌های واجد شرایط، تنظیم Hold Stock می‌تواند پس از مهلت تعیین‌شده سفارش Pending payment را لغو کند. رفتار دقیق به تنظیمات و جریان پرداخت وابسته است. بنابراین باید تأیید دیرهنگام را جدا آزمایش کنید؛ مستند وضعیت سفارش‌ها این مسیر را توضیح می‌دهد.

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

آیا مشتری باید دوباره پرداخت کند؟

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

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

چه زمانی اصلاح افزونه لازم است؟

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

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

پنج آزمون پذیرش برای اصلاح مسیر پرداخت

آزمون‌های زیر پیشنهادی‌اند و گزارش نتیجهٔ پروژه نیستند. آن‌ها را در محیط آزمایشی با روش مورد تأیید درگاه اجرا و نتیجه را ثبت کنید.

1. بازگشت ناقص مشتری: مسیر تأیید مستند سرویس بدون اتکا به نمایش صفحهٔ تشکر بررسی شود و نتیجهٔ نامشخص قابل پیگیری باشد.
2. پیام تکراری و هم‌زمان: یک تراکنش معتبر فقط یک نهایی‌سازی منطقی و یک اثر مورد انتظار در هر سامانه بسازد.
3. مغایرت مبلغ یا شناسه: پیام نامنطبق سفارش دیگری را پرداخت‌شده نکند و علت بررسی ثبت شود.
4. قطع ارتباط در تأیید: وضعیت نامشخص محفوظ بماند؛ ادامهٔ کار به استعلام یا بررسی مجاز وابسته باشد.
5. تأیید پس از لغو: نتیجهٔ مالی گم نشود و تحویل کالا به بررسی موجودی و تصمیم مسئول وابسته باشد.

ورودی، نسخه‌ها، نتیجهٔ مورد انتظار و مشاهده‌شده را در مدارک تحویل افزونه نگه دارید. برای ترکیب HPOS و نوع تسویه‌حساب، چک‌لیست سازگاری ووکامرس هم لازم است.

منابع و محدودهٔ راهنما

مستندات رسمی وضعیت سفارش، Payment Gateway API و پرداخت سفارش در ۹ اکتبر ۲۰۲۶ بررسی شدند. قواعد تشخیص، کنترل تکرار و آزمون‌ها پیشنهاد طراحی‌اند؛ قرارداد تأیید و استعلام باید با سرویس واقعی تطبیق یابد. مثال و تصویر مفهومی‌اند و نتیجهٔ مشتری یا تضمین رفع همهٔ خطاهای پرداخت را نشان نمی‌دهند.