# Приймання оформлення замовлення в інтернет-магазині

MAX SITE · 10.09.2026 · операційний чекліст, не юридичний договір.

Заповнюйте для конкретного релізу. Відмітка означає пройдений сценарій із доказом, а не наявність кнопки. Тести оплати проводьте у дозволеному тестовому режимі; реальна оплата, повернення грошей і зміни залишків потребують окремого погодження власника.

## Паспорт і дані

1. [ ] Записати домен, середовище, реліз, дату, виконавця та відповідального за приймання: ___.
2. [ ] Узгодити тестові SKU, ціну, валюту, доступну кількість і спосіб повернення тестових змін: ___.
3. [ ] Вибрати приклади: звичайний товар, варіант кольору/розміру, відсутній товар і останній доступний екземпляр.
4. [ ] Назвати джерело залишків, частоту оновлення, момент резерву та правило його звільнення: ___.
5. [ ] Визначити, яка система підтверджує оплату, яка зберігає замовлення і хто отримує помилки інтеграцій.

## Кошик і доставка

6. [ ] Змінити варіант: фото, SKU, ціна й кількість у кошику відповідають саме обраному товару.
7. [ ] Змінити кількість, видалити товар, повернутися з оформлення: підсумок і склад кошика узгоджені.
8. [ ] Перевірити нульовий залишок; товар не стає доступним через залишок іншого варіанту.
9. [ ] Перевірити паралельне замовлення останнього екземпляра; сервер повторно перевіряє наявність за погодженим правилом.
10. [ ] Вибрати різні погоджені способи доставки, місто й відділення; зміна міста скидає несумісне відділення.
11. [ ] Перевірити недоступну доставку та відмову сервісу відділень; немає вигаданої вартості або помилкового підтвердження.
12. [ ] Перевірити коректний, прострочений і непридатний промокод; знижки, доставка й підсумок збігаються у клієнта та сервера.

## Оплата, помилка й повтор

13. [ ] Успішний дозволений тест: звірити ідентифікатор, суму, валюту та статус у магазині й платіжному провайдері.
14. [ ] Відхилена оплата не позначається як оплачена; покупець розуміє стан замовлення й наступну дію.
15. [ ] Закрити вікно оплати або імітувати тайм-аут: система перевіряє реальний статус, а не створює новий платіж навмання.
16. [ ] Повторити клієнтський запит і повідомлення провайдера в тестовому середовищі: одна операція не створює дубль замовлення чи повторне списання.
17. [ ] Відкрити сторінку підтвердження напряму й перезавантажити її: сам URL не є доказом оплати.
18. [ ] Перевірити недоступну CRM: платіжний статус зберігається; помилка передачі не приховується за хибним «усе доставлено».

## Повернення, вимірювання й приймання

19. [ ] Пройти погоджений тест скасування або повернення: сума, статус і резерв узгоджені між системами. Не робити реальне повернення без дозволу.
20. [ ] Для обміну варіанту перевірити конкретні старий і новий SKU; загальна кількість моделі не підміняє облік розміру.
21. [ ] Звірити аналітичну подію з погодженим бізнес-статусом, transaction_id, сумою й товарами; повтор не створює ще одну покупку.
22. [ ] Перевірити відсутність імені, телефона, адреси, email та довільного коментаря в URL і параметрах аналітики.
23. [ ] Зберегти докази для телефона й комп’ютера, відкриті дефекти, рішення про запуск і відповідального. Непройдене позначити BLOCKED, не PASS.

## Журнал

| № сценарію | Очікування | Факт | PASS / FAIL / BLOCKED | Доказ без персональних даних | Відповідальний / повтор |
|---|---|---|---|---|---|
| ___ | ___ | ___ | ___ | ___ | ___ |

Джерело практичного контексту: [каталог одягу й обсяг MVP](https://maxsite.com.ua/blog/yak-pidhotuvaty-kataloh-odyahu-dlya-internet-mahazynu/) · [склад розробки магазину](https://maxsite.com.ua/blog/shcho-vhodyt-u-stvorennya-internet-magazynu-pid-klyuch/).
