وقتی خریدار از درگاه به فروشگاه برمی‌گردد و صفحهٔ خطا می‌بیند، نباید فوراً نتیجه بگیریم «پول پرداخت نشده است». ممکن است پرداخت واقعاً ناموفق باشد، ممکن است نتیجه هنوز به فروشگاه نرسیده باشد، یا ارتباط مرورگر درست پایان نیافته باشد. طراحی بازیابی پرداخت ناموفق در فروشگاه اینترنتی یعنی خریدار وضعیت قابل فهم، سفارش قابل پیگیری و مسیر امن برای ادامه داشته باشد؛ و فروشگاه پیش از ثبت دوبارهٔ پرداخت یا ارسال کالا، وضعیت تراکنش را از مسیر معتبر بررسی کند.
این موضوع با ساده‌کردن فرم خرید فرق دارد. خرید مهمان اصطکاک ورود به حساب را کم می‌کند؛ بازیابی پرداخت، پس از تلاش برای پرداخت، دربارهٔ قطع ارتباط، پاسخ نامعلوم و جلوگیری از سفارش تکراری است. راهکار خوب باید هم تجربهٔ کاربر و هم منطق پشت‌صحنه را پوشش دهد. یک دکمهٔ «تلاش مجدد» بدون نگهداری سفارش و کنترل نتیجه می‌تواند مسئله را بدتر کند.
سه وضعیت را با هم اشتباه نگیرید
برای طراحی صفحه و منطق سفارش، دست‌کم میان «پرداخت تأییدشده»، «پرداخت ناموفقِ تأییدشده» و «وضعیت نامعلوم یا در انتظار بررسی» فرق بگذارید. بازگشت مرورگر، بسته‌شدن تب یا خطای شبکه به‌تنهایی سند قطعی هیچ‌کدام نیست. وضعیت سفارش نیز جدا از وضعیت هر تلاش پرداخت است: یک سفارش می‌تواند ایجاد شده باشد و هنوز پرداخت معتبری نداشته باشد؛ ممکن است چند تلاش مرتبط با همان سفارش داشته باشد.
اگر درگاه شما وضعیت‌های دیگری مانند لغوشده، منقضی‌شده یا در حال پردازش دارد، آن‌ها را در مدل خود نگاشت کنید. نام و روش تأیید هر وضعیت به قرارداد همان ارائه‌دهنده بستگی دارد. از روی نمونهٔ یک درگاه، نتیجهٔ فنی دربارهٔ همهٔ درگاه‌ها نگیرید. در صفحهٔ عمومی نیز از عبارت‌های مطمئن‌نما مانند «مبلغی کسر نشده» فقط وقتی استفاده کنید که سامانه واقعاً آن را می‌داند؛ در حالت نامعلوم، صادقانه بگویید نتیجه در حال بررسی است.
نتیجهٔ پرداخت را در سرور معتبرسازی کنید
صفحهٔ بازگشت کاربر برای نمایش تجربه مهم است، اما نباید تنها منبع تغییر سفارش به «پرداخت‌شده» باشد. فروشگاه باید رخداد یا پاسخ معتبرِ درگاه را طبق قرارداد آن بررسی کند، شناسه‌ها و مبلغ را با سفارش تطبیق دهد و نتیجه را به‌صورت قابل حسابرسی ثبت کند. راهنمای رسمی Stripe برای رویدادهای پس از پرداخت نیز هشدار می‌دهد که تکیه بر صفحهٔ بازگشت برای انجام سفارش قابل اعتماد نیست و دریافت رویداد سمت سرور را توصیه می‌کند. این مستند، نمونهٔ یک ارائه‌دهنده است؛ جزئیات امنیتی و API درگاه مورد استفادهٔ شما باید جداگانه پیاده شود.
ثبت رویداد ورودی باید بتواند تکرار را تحمل کند. اگر همان پیام یا پاسخ بیش از یک بار رسید، نباید دو بار سفارش را قطعی کند، دو رسید بفرستد یا موجودی را دوباره کم کند. رویدادهای دیررس هم باید با وضعیت فعلی سفارش سنجیده شوند؛ یک پاسخ قدیمی نباید نتیجهٔ تأییدشدهٔ جدید را برگرداند. برای هر تغییر، شناسهٔ سفارش، شناسهٔ تلاش پرداخت، زمان، منبع و تصمیم اعمال‌شده را نگه دارید، بدون اینکه دادهٔ حساس کارت را در لاگ فروشگاه ذخیره کنید.
صفحهٔ خطا باید کار بعدی را روشن کند
متن صفحه را بر اساس وضعیت واقعی تغییر دهید. اگر ناموفق‌بودن تأیید شده، بگویید سفارش هنوز نهایی نشده و روش مناسب برای تلاش دوباره را نشان دهید. اگر نتیجه نامعلوم است، به جای نمایش دکمهٔ فوری برای پرداخت مجدد، وضعیت بررسی و زمان یا راه پیگیری را توضیح دهید. اگر پرداخت تأیید شده اما نمایش صفحه به خطا خورده، کاربر باید بتواند سفارش ثبت‌شده را ببیند، نه اینکه دوباره پرداخت کند.
شمارهٔ پیگیری سفارش یا شناسهٔ قابل ارائه به پشتیبانی را آشکار کنید، اما اطلاعات حساس یا شناسهٔ فنیِ قابل سوءاستفاده را در URL عمومی نگذارید. دکمه‌ها باید معنای دقیق داشته باشند: «بررسی وضعیت پرداخت»، «بازگشت به سفارش»، «تلاش دوباره پس از تأیید ناموفق‌بودن» و «تماس با پشتیبانی». پیام عمومیِ «خطایی رخ داد» بدون توضیح وضعیت و مسیر بعدی، کاربر را به تکرار کورکورانهٔ عملیات سوق می‌دهد.
برای خرید بدون حساب نیز پیگیری باید ممکن باشد. داشتن شماره سفارش و روش احراز مناسب برای مشاهدهٔ آن، بهتر از تحمیل ثبت‌نام پس از بروز خطاست. اما لینک عمومیِ بی‌حفاظ به سفارش نباید اطلاعات مشتری را افشا کند. طراحی دسترسی باید متناسب با حساسیت سفارش و سیاست همان کسب‌وکار باشد.
سبد و سفارش را حفظ کنید، اما قیمت را کورکورانه ثابت فرض نکنید
پس از تلاش ناموفق، خریدار نباید مجبور شود همهٔ کالاها و نشانی را از ابتدا وارد کند. سبد و پیش‌نویس سفارش باید برای بازگشت امن حفظ شوند. راهنمای ذخیرهٔ سبد خرید میان دستگاه‌ها به ماندگاری سبد می‌پردازد؛ در اینجا نکتهٔ اضافه، ارتباط سبد با یک سفارش و چند تلاش پرداخت است. باید مشخص باشد دکمهٔ تکرار، همان سفارش را ادامه می‌دهد یا سفارش تازه می‌سازد.
در عین حال، موجودی، مبلغ نهایی، هزینهٔ ارسال و اعتبار پیشنهاد ممکن است تغییر کرده باشند. پیش از تلاش دوباره، قواعد فروشگاه باید تعیین کنند چه چیزی برای همان سفارش محفوظ است و چه چیزی نیاز به تأیید دوبارهٔ مشتری دارد. اگر مبلغ تغییر کرده، آن را به‌وضوح نشان دهید و بدون اطلاع خریدار پرداخت جدید آغاز نکنید. نگهداری سبد به معنی تضمین بی‌قید موجودی یا قیمت نیست؛ سیاست رزرو باید در خود فرایند تعریف شود.
از سفارش و کسر وجه تکراری جلوگیری کنید
برای هر سفارش یک شناسهٔ پایدار داشته باشید و تلاش‌های پرداخت را زیر همان سفارش ثبت کنید. اقدام دوبارهٔ کاربر، تازه‌کردن صفحه یا تحویل تکراری رخداد نباید بدون بررسی وضعیت، سفارش تازه ایجاد کند. در نقاط حساس از سازوکارهای idempotency یا قید یکتایی متناسب با معماری و درگاه استفاده کنید. واژهٔ فنی مهم نیست؛ نتیجهٔ موردنیاز این است که یک اقدام تجاری فقط یک‌بار اثر کند، حتی اگر درخواست فنی تکرار شود.
اگر نتیجهٔ تلاش قبلی نامعلوم است، شروع تلاش بعدی باید محدود به قاعده‌ای روشن باشد. شاید لازم باشد ابتدا از درگاه استعلام کنید یا پرونده را برای بازبینی عملیاتی نگه دارید. اگر دو تلاش در نهایت موفق شدند، سامانه باید آن را به‌عنوان استثنا شناسایی و طبق سیاست بازگشت وجه رسیدگی کند؛ نباید صرفاً یکی از پاسخ‌ها را از نمایش پنهان کند. این مقاله دستورالعمل مالی یا قرارداد درگاه نیست؛ طرح فنی باید با مستندات ارائه‌دهنده و مسئول مالی سازمان تطبیق داده شود.
یک مثال واقعی‌نما: بازگشت بدون پاسخ قطعی
فرض کنید مشتری سبدی با دو کالا را تأیید می‌کند، به درگاه می‌رود و مرورگر هنگام بازگشت قطع می‌شود. سفارش در فروشگاه ایجاد شده، ولی هنوز نتیجهٔ معتبر ثبت نشده است. صفحهٔ سفارش باید وضعیت «در حال بررسی پرداخت» نشان دهد و گزینهٔ بررسی دوباره یا تماس با پشتیبانی بدهد. فروشگاه در پس‌زمینه از مسیر معتبر نتیجه را دریافت یا استعلام می‌کند. تا آن زمان نه پیام «پرداخت موفق» می‌فرستد و نه موجودی را طبق قاعدهٔ سفارش نهایی آزاد یا قطعی می‌کند.
اگر در ادامه ناموفق‌بودن تأیید شد، همان سفارش با سبد حفظ‌شده می‌تواند به مرحلهٔ تلاش بعدی برود، مشروط به بازبینی مبلغ و موجودی. اگر موفق‌بودن تأیید شد، صفحهٔ پیگیری باید نتیجه را نمایش دهد و ارسال یا ارائهٔ خدمت فقط یک‌بار آغاز شود. اگر پاسخ‌ها متناقض‌اند، پرونده برای بررسی انسانی جدا شود. این مثال یک الگوی تصمیم است، نه توصیف قطعی رفتار هر درگاه.
پشتیبانی و عملیات هم به صفحهٔ وضعیت نیاز دارند
کارشناس پشتیبانی باید بتواند با شناسهٔ سفارش ببیند چند تلاش انجام شده، آخرین وضعیت معتبر چیست، چه رخدادهایی دریافت شده و کدام اقدام هنوز مجاز است. نمایش اطلاعات کارت یا دادهٔ حساس پرداخت لازم نیست. راهنمای عملیاتی باید مشخص کند در وضعیت نامعلوم چه زمانی استعلام می‌شود، چه کسی با ارائه‌دهنده تماس می‌گیرد و چگونه نتیجه به مشتری اعلام می‌شود.
در پنل فروشگاه، وضعیت «پرداخت نامعلوم» را با «سفارش رهاشده» یکی نکنید. سفارش رهاشده ممکن است اصلاً به درگاه نرفته باشد؛ وضعیت نامعلوم نیازمند آشتی‌دادن رویدادهاست. گزارش‌های مدیریتی نیز باید تلاش پرداخت را از سفارش یکتا جدا کنند، وگرنه نرخ خطا یا تعداد فروش نادرست تفسیر می‌شود. طراحی صفحهٔ خطا بدون ابزار رسیدگی پشت‌صحنه، فقط بخشی از مسئله را حل می‌کند.
دسترس‌پذیری و پیام‌های قابل فهم
وضعیت را فقط با رنگ قرمز یا سبز نشان ندهید. متن روشن، عنوان مناسب و دکمهٔ مشخص لازم است. اگر وضعیت بدون بارگذاری دوباره به‌روزرسانی می‌شود، پیام تغییر باید برای فناوری کمکی هم قابل تشخیص باشد. راهنمای W3C برای پیام‌های وضعیت در WCAG توضیح می‌دهد که پیام‌های موفقیت، انتظار و خطا در صفحه باید به‌صورت برنامه‌پذیر قابل شناسایی باشند. در طراحی فارسی، ترتیب خواندن شماره سفارش، مبلغ و دکمه‌ها را روی موبایل و با صفحه‌کلید نیز بررسی کنید.
متن خطا باید از اصطلاحات مبهم درگاه فاصله بگیرد و بگوید کاربر اکنون چه کاری می‌تواند با اطمینان انجام دهد. «تراکنش ناموفق» وقتی هنوز پاسخ قطعی نیست، پیام دقیقی نیست. زمان‌بندیِ نمایش وضعیت را نیز بی‌پایان نگذارید: اگر نتیجه از حد انتظار گذشت، راه پیگیری انسانی و شناسهٔ سفارش باید در دسترس باشد.
آزمون پیش از انتشار
تنها مسیر موفق را تست نکنید. سناریوهای توقف کاربر در درگاه، بازگشت دیرهنگام، خطای شبکه، تکرار کلیک، تازه‌کردن صفحه، دریافت دو رویداد مشابه، رسیدن رویدادها با ترتیب متفاوت، تغییر قیمت یا موجودی و قطعی موقت سرویس را در محیط آزمایشی اجرا کنید. برای هر سناریو بررسی کنید چه چیزی به خریدار نشان داده می‌شود، چند سفارش و چند اقدام مالی/عملیاتی ثبت می‌شود و کارشناس پشتیبانی چه شواهدی می‌بیند.
شاخص‌های پس از انتشار می‌توانند تعداد وضعیت‌های نامعلومِ بازمانده، زمان رسیدگی، تلاش‌های تکراری، تماس‌های پشتیبانی و اختلاف میان سفارش و پرداخت باشند. این‌ها را برای کشف مشکل به کار ببرید، نه برای ادعای درصد بهبود بدون مبنای اندازه‌گیری. آستانهٔ هشدار باید با حجم واقعی فروشگاه و قرارداد درگاه تنظیم شود.
جمع‌بندی و گام بعدی
بازیابی پرداخت ناموفق، فقط طراحی یک صفحهٔ قرمز نیست. فروشگاه باید وضعیت قطعی و نامعلوم را جدا کند، سفارش و سبد را حفظ کند، نتیجه را از مسیر معتبرِ سمت سرور تأیید کند، اقدام تکراری را مهار کند و برای خریدار و پشتیبانی راه پیگیری بسازد. اجرای خوب هم اعتماد کاربر را حفظ می‌کند و هم جلوی تصمیم عملیاتی بر پایهٔ یک بازگشت ناقص مرورگر را می‌گیرد.
اگر فروشگاه شما در مرز پرداخت و ثبت سفارش ابهام دارد، جریان موجود و چند نمونهٔ خطا را آماده کنید. در خدمت طراحی سایت ایزی‌ساز می‌توان دامنهٔ تجربهٔ خرید و اتصال‌ها را بررسی کرد؛ برای طرح مسئلهٔ مشخص از صفحهٔ تماس ایزی‌ساز اقدام کنید.