نتیجهٔ تراکنش را از طریق سرور تأیید کنید

بازگشت کاربر به سایت، به‌تنهایی اثبات پرداخت نیست.

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

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

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

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

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

از یک موقعیت ساده شروع کنیم

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

تصمیم دربارهٔ ثبت نتیجهٔ مالی را در سرور کسب‌وکار بگیرید

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

پرونده آموزشی: بازگشت موفق، سفارش اشتباه

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

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

آزمون‌های پذیرش پیشنهادی

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

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

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