Кошик і оформлення замовлення в Україні — це LiqPay, Fondy, WayForPay, Plata by mono, Нова Пошта, Укрпошта, інколи Rozetka Delivery, і ПРРО (Checkbox тощо). Не ставлю ЮKassa/СДЭК як дефолт цієї мови. Не приймаю номер картки на вашому сервері.

Входить: правила кошика, промокоди, кроки оформлення, статуси, листи, тестовий контур, ТТН за API служби. Покинутий кошик — штатними засобами платформи. Оплата в месенджері — допоміжно, боти, джерело замовлення — магазин.

Закладаємо повтор вебхука, оновлення «дякуємо» й нуль залишку посеред сесії.

Окремо перевіряємо: LiqPay сказав «успіх», а замовлення в CMS не створилось; як менеджер бачить ТТН; хто ініціює повернення. Віджет Нової Пошти без договору малює тариф, який ви не підтвердите. Мінімальне замовлення, габарит і накладений платіж описуємо в брифі, інакше це випливе на прийманні. ПРРО тестуємо на staging чеками, не в перший чорний день розпродажів.

Приймання каси: тестовий платіж, скасування, лист клієнту, статус менеджеру. Приймання доставки: відділення, кур’єр, накладений платіж. Не малюємо фейковий тариф Нової Пошти без договору. ПРРО перевіряємо чеком на staging. Мінімальне замовлення й габарит — у брифі, не «як вийде на проді». Накладений платіж і передоплата — різні статуси замовлення, їх не змішуємо в одній кнопці без правил. Повідомлення клієнту після оплати не має розголошувати внутрішні id каси. Повторний клік «оплатити» не створює другий заказ: ідемпотентність ключа платежу перевіряємо на staging. Служба доставки не повинна бути єдиною точкою відмови: Якщо API Нової Пошти лежить, замовлення все одно зберігається. Менеджер бачить чергу «відправити ТТН пізніше», а не втрачений заказ. Повернення товару має окремий статус, не «скасовано» без причини. Це частина приймання каси.