پیش از نام پلتفرم، یک سفارش واقعی را بنویسید
از نخستین جست‌وجوی کالا تا تحویل، مرجوعی و تسویه را برای یک خریدار نمونه دنبال کنید. مشخص کنید کدام قیمت عمومی است، چه کسی تخفیف را تأیید می‌کند و سفارش در کدام سامانه قطعی می‌شود. مثال فرضی: عمده‌فروش به نماینده قیمت قراردادی نشان می‌دهد، سفارش پیش‌نویس می‌گیرد و پس از تأیید اعتبار آن را به انبار می‌فرستد. این جریان با خرید مهمان و پرداخت فوری متفاوت است؛ هر دو را در یک عنوان مبهم «فروشگاه» پنهان نکنید.
- خروجی این مرحله: یک نمودار سفارش با نقش، وضعیت، مرجع داده و مسئول هر استثنا.
- برای هر الزام، روش اجرای فعلی و یک شاهد آزمون بنویسید؛ «پشتیبانی از B2B» معیار پذیرش نیست.
- نیازهای ضروری راه‌اندازی را از ایده‌های رشد جدا کنید تا گزینه‌های مناسب زود حذف نشوند.
منبع فنی این بخش: OWASP [۳]
گزینه‌ها را با مسئولیت و شکاف عملیاتی مقایسه کنید
سه الگوی زیر نقطه شروع ارزیابی‌اند و رتبه‌بندی قطعی نیستند. یک محصول آماده ممکن است با پیکربندی کافی باشد؛ راهکار اختصاصی هم ممکن است برای پرداخت یا کاتالوگ از سرویس بیرونی استفاده کند. در مقایسه پیشنهادی، معیار اصلی را اجرای جریان خرید و امکان نگهداری قرار دهید. از عرضه‌کننده بخواهید جریان مرحله قبل را نشان دهد و هر شکاف را به پیکربندی، افزونه، اتصال، تغییر فرایند یا کدنویسی نسبت دهد؛ سپس مسئول نگهداری آن را ثبت کنید.
| الگوی پیشنهادی برای بررسی | پرسش تصمیم | شاهدی که بخواهید |
|---|---|---|
| فروشگاه میزبانی‌شده و پیکربندی‌محور | قیمت، نقش‌ها و روش پرداخت شما در قرارداد و امکانات فعلی قابل اجراست؟ | اجرای سفارش نماینده و خروجی گرفتن از داده‌ها |
| پلتفرم قابل توسعه با افزونه یا اتصال | شکاف‌ها با تغییر محدود و قابل نگهداری پوشش می‌یابند؟ | فهرست افزونه‌ها، مالک نسخه‌ها و آزمون سازگاری |
| راهکار اختصاصی یا ترکیبی | کدام قاعده فروش ارزش هزینه ساخت و نگهداری را دارد؟ | نمونه همان قاعده، مرز اتصال‌ها و برنامه تحویل بهره‌برداری |
منبع فنی این بخش: Stripe [۱]OWASP [۳]
برای موجودی و قیمت، مرجع و زمان اعتبار تعیین کنید
برای هر فیلد، یک مرجع معتبر و مسیر اصلاح اختلاف تعریف کنید: کد کالا، موجودی قابل فروش، مالیات، قیمت قراردادی و هزینه ارسال. سپس رفتار هنگام قطع اتصال را انتخاب کنید. مثال فرضی: اگر موجودی انبار به‌روز نیست، فروشگاه سفارش را «نیازمند تأیید» نگه دارد یا خرید را متوقف کند؛ انتخاب به عملیات شما وابسته است. تأیید پرداخت و رزرو موجودی را دو رویداد مستقل ببینید و سناریوی موفقیت یکی و شکست دیگری را در پذیرش بیاورید.
- هم‌زمانی: دو خریدار برای آخرین واحد چه نتیجه‌ای می‌بینند؟
- قیمت: اگر قیمت میان افزودن به سبد و ثبت سفارش عوض شد، کدام قاعده اعمال و چگونه اطلاع‌رسانی می‌شود؟
- آشتی داده: سفارش دارای پرداخت قطعی و ثبت انبار ناموفق در کدام صف عملیاتی و با چه مالکیتی پیگیری می‌شود؟
منبع فنی این بخش: Stripe [۱]
پرداخت را با حالت‌های مبهم و رویداد تکراری آزمایش کنید
«بازگشت از درگاه» را تنها شاهد مالی قرار ندهید؛ وضعیت معتبر را طبق قرارداد و API درگاه منتخب در سمت سرور بررسی کنید. برای نمونه، مستندات Stripe می‌گویند رویدادها ممکن است تکراری یا خارج از ترتیب برسند و امضای پیام باید اعتبارسنجی شود. از این نمونه برای طرح سؤال استفاده کنید، نه فرض رفتار یکسان همه درگاه‌ها. وضعیت‌های در انتظار، موفق، ناموفق، لغوشده و بازپرداخت را با قواعد مجاز انتقال مشخص کنید؛ سفارش و تراکنش باید شناسه پیگیری جداگانه داشته باشند.
- معیار پذیرش: ارسال مجدد تأیید معتبر، سفارش یا ارسال کالا را دوباره ایجاد نکند؛ این رفتار را idempotency می‌نامند.
- اگر مشتری مرورگر را ببندد یا پیام دیر برسد، عملیات بتواند وضعیت واقعی را پیدا و با سفارش تطبیق دهد.
- پیام جعلی یا وضعیت نامعتبر باعث تحویل کالا نشود و خطا برای پیگیری بدون ثبت اطلاعات حساس گزارش شود.
منبع فنی این بخش: Stripe [۱]
قیمت و اختیار خرید B2B را در سطح درخواست کنترل کنید
ورود به حساب، به‌تنهایی مجوز دیدن قرارداد شرکت دیگر نیست. راهنمای OWASP بر حداقل دسترسی، رد پیش‌فرض و بررسی مجوز هر درخواست تأکید دارد. در پرتال پیشنهادی، رابطه کاربر با شرکت، شعبه، قرارداد و سقف اختیار را روشن کنید. مثال فرضی: کارشناس خرید سبد را می‌سازد، مدیر همان شرکت تأیید می‌کند و تیم فروش اجازه اصلاح قیمت را دارد. هر نقش باید فقط سفارش و داده مجاز را ببیند؛ پنهان کردن دکمه یا ستون، شاهد کافی کنترل دسترسی نیست.
- آزمون دو حساب از دو شرکت: تغییر شناسه سفارش یا فاکتور، داده شرکت دیگر را برنگرداند.
- آزمون نقش محدود: درخواست مستقیم تأیید سفارش یا تغییر قیمت رد شود.
- آزمون خروج کارمند: لغو عضویت و نشست‌های مرتبط مطابق سیاست سازمان اجرا و ثبت شود.
منبع فنی این بخش: OWASP [۳]
مهاجرت کاتالوگ و URL را جزو پروژه بدانید
پیش از انتخاب نهایی، خروجی واقعی کالا، تصویر، تنوع، دسته‌بندی و URLهای موجود را نمونه‌برداری کنید. راهنمای Google نشان می‌دهد چند URL برای محتوای یکسان یا پارامترهای نامحدود می‌توانند خزش را دچار مشکل کنند. در برنامه مهاجرت، مقصد URLهای قدیمی، صفحه مرجع هر محصول و رفتار فیلترها را مشخص کنید. برای محصول حذف‌شده یا جایگزین‌شده هم تصمیم مستقل بگیرید؛ تغییر پلتفرم نباید بدون تصمیم محتوایی، همه نشانی‌ها را به صفحه اصلی بفرستد.
- نمونه مهاجرت شامل یک محصول چندتنوعی، یک محصول ناموجود و یک دسته با فیلتر باشد.
- عنوان، توضیح، تصویر، قیمت و وضعیت موجودی پس از انتقال با مرجع داده تطبیق داده شوند.
- قبل از تغییر دامنه یا مسیر، فهرست URL و نقشه تغییر مسیر را بازبینی و چند مسیر مهم را از ورودی تا خرید آزمایش کنید.
منبع فنی این بخش: Google Search Central [۲]
تصمیم خرید را به پایلوت و اقلام تحویلی وصل کنید
پایلوت را روی یک بخش قابل مدیریت از کاتالوگ و یک گروه خریدار اجرا کنید. مالک فروش و عملیات باید پیش از شروع بدانند چه شواهدی برای ادامه لازم است؛ تعداد صفحه یا نصب افزونه معیار موفقیت کافی نیست. جدول زیر قالب پیشنهادی پذیرش است، نه نتیجه یک پروژه اجراشده. پس از آزمون، شکاف‌های باقی‌مانده، هزینه برآوردشده با فرض‌های روشن و مسئول پشتیبانی را کنار هم ببینید و درباره ادامه، اصلاح دامنه یا توقف تصمیم بگیرید.
| جریان | معیار پذیرش پیشنهادی | تحویل به عملیات |
|---|---|---|
| خرید و پرداخت | موفقیت، تأخیر، تکرار و شکست با وضعیت مالی صحیح پایان یابند | راهنمای تطبیق و پیگیری سفارش |
| موجودی و قیمت | اختلاف و قطع اتصال با قاعده توافق‌شده مدیریت شوند | مرجع داده و صف استثناها |
| فروش سازمانی | جداسازی شرکت‌ها و حدود اختیار با حساب‌های آزمون اثبات شود | ماتریس نقش و مسئول اعطای دسترسی |
| خروج از راهکار | نمونه خروجی داده و روش انتقال قابل استفاده باشند | مالک حساب‌ها، نسخه‌ها و مستند اتصال‌ها |
منبع فنی این بخش: Stripe [۱]OWASP [۳]Google Search Central [۲]