مبلغ، دامنه و افزونهٔ اتصال را در مسیر خرید آزمایش کنید

داده معامله را در یک منبع معتبر نگه دارید

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

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

موقعیت: افزونه پس از به‌روزرسانی متفاوت عمل می‌کند

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

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

بررسی‌های لازم پیش از انتشار تغییر نرم‌افزار

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

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

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