اتصال درگاه پرداخت به سایت؛ تأیید امن و جلوگیری از سفارش تکراری

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

مبلغ و شناسه را روی سرور بسازید

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

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

پرداخت را ماشین وضعیت ببینید

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

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

اثر درخواست تکراری را کنترل کنید

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

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

مثال فرضی: پرداخت انجام شده و اینترنت قطع می‌شود

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

چک لیست آزمون اتصال

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

تحویل فنی را قابل بررسی کنید

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