Покупець платить, закриває вкладку й пізніше запитує, куди поділася покупка. Інший покупець двічі повертається на сторінку успіху. Жодна з цих дій у браузері не повинна визначати, чи оплачено замовлення. Інтерфейс оформлення покупки — це розмова з клієнтом; облік платежів є окремою відповідальністю сервера. Для продажу доменів ця різниця особливо важлива: наступним кроком може бути передача активу, який не можна просто повернути до кошика. ПОЧИНАЙТЕ ІЗ ЗАМОВЛЕННЯ, А НЕ З КНОПКИ Перед відкриттям оплати створіть внутрішнє замовлення зі сталим ідентифікатором, покупцем, товаром, очікуваною сумою та валютою. Уявіть його як запечатаний конверт з описом угоди, яку ви готові прийняти. Коли надходить повідомлення про платіж, система має порівняти його із цим конвертом. Справжнє повідомлення про інше замовлення все одно є неправильним для поточної покупки. Доларовий платіж не повинен закривати замовлення в євро лише тому, що цифри збігаються. Практичний приклад: замовлення домену за €500. Збережіть суму як 50000 євроцентів, а не форматований рядок із символом валюти. Зафіксуйте знижку й остаточну суму при створенні замовлення. Подальша зміна ціни в каталозі не повинна непомітно переписувати наявну платіжну сесію. Окремо визначте, як покупець скасовує старе замовлення та створює нове. СПРАВЖНІСТЬ ПЕРЕД БІЗНЕС-ЛОГІКОЮ Stripe описує перевірку підпису за оригінальним тілом запиту, заголовком підпису та секретом endpoint. Офіційні бібліотеки виконують цю перевірку. Зберігайте секрет у серверній конфігурації, розділяйте тестове й бойове середовища та не передавайте його у frontend. Під час огляду реалізації простежте шлях запиту від мережевого входу до обробника. Де читається тіло? Яке middleware його розбирає? Чи змінює його проксі? Команда повинна показати точну межу перевірки. Не шукайте причину помилки, друкуючи секрети в журнал. Записуйте ідентифікатор запиту, середовище та очищену категорію збою. Відокремлюйте невдалу перевірку справжності від тимчасової недоступності бази: для них потрібні різні реакції та сповіщення. ОТРИМАННЯ НЕ ДОРІВНЮЄ ЗАВЕРШЕННЮ Stripe попереджає про повторні повідомлення та відсутність гарантованого порядку доставки. Інструкція з виконання замовлень враховує відкладені результати платежів. Це властивості доставки й оплати, а не доказ неправильного натискання покупця. Спроєктуйте сховище прийнятих повідомлень та окремий перехід стану замовлення. Унікальний ідентифікатор події допомагає не обробляти доставку двічі, але сама бізнес-операція також потребує захисту: вже виконане замовлення не повинно повторно передати домен. Уявіть двох працівників черги, які одночасно дісталися одного замовлення. Перехід має узгодити обмеження бази або транзакція, а не змінна браузера чи оптимістична умова «вже перевірили». Використовуйте зрозумілі стани: очікує оплати, платіж підтверджено, очікує виконання, виконано, потребує перевірки. Невдала або прострочена спроба має власну історію. Вона не повинна перекреслювати новіший успішний платіж через пізнє надходження старого повідомлення. ЩО ПЕРЕВІРИТИ ПЕРЕД ЗАПУСКОМ Складіть таблицю очікуваних результатів. Неправильний підпис не змінює замовлення. Повтор справжньої події не створює другої передачі. Справжній платіж із неочікуваною сумою, валютою або посиланням на сесію переходить на перевірку. Підтверджена оплата має з’явитися в кабінеті навіть із закритим браузером. Переривання роботи бази повинно залишати достатньо інформації для безпечного відновлення. Окремо перевірте відкладений успіх і відкладену відмову. Потім перевірте непомітний сценарій: повідомлення прийнято, але працівник виконання зупинився посеред операції. Відновлення має спиратися на збережений стан, а не на чиюсь пам’ять. Не передавайте реальний актив лише заради демонстрації зеленого екрана. ПОКАЖІТЬ НЕВИЗНАЧЕНІСТЬ Покупець повинен розрізняти «платіж підтверджено» та «передачу завершено». Покажіть номер замовлення і наступний крок; не оголошуйте успіх, поки сервер очікує. Для працівників створіть чергу перевірки з причинами та дією звіряння з авторитетним записом платежу. Це наша операційна рекомендація, а не обіцянка, що один webhook усуває всі інциденти. Доменний проєкт починається з назви, але надійна оплата теж формує досвід бренду. Перегляньте каталог DomainEvery: https://domainevery.com/uk/domains та закладіть перевірку, відновлення і виконання оплати в бюджет разом із дизайном. ДЖЕРЕЛА Stripe: webhooks: https://docs.stripe.com/webhooks Stripe: endpoint і перевірка підписів: https://docs.stripe.com/events/manage-webhook-endpoints Stripe: виконання замовлень hosted Checkout: https://docs.stripe.com/checkout/fulfillment.md?payment-ui=stripe-hosted