Заказ и платёж являются разными объектами
Заказ описывает, что пользователь намерен получить, а платёж — попытку и результат расчёта. У одного заказа могут быть неуспешная попытка и последующая успешная. Если смешать эти сущности, повторное нажатие кнопки способно создать путаницу в статусах и исполнении. Заранее определите состояния: создан, ожидает оплаты, оплачен, отменён и другие необходимые для конкретной системы. Переход должен иметь основание. Нельзя считать заказ оплаченным только по параметру в адресной строке, который вернул браузер. Сумму, валюту и связь с заказом проверяют по доверенному серверному результату в соответствии с документацией провайдера.
Уведомления могут приходить позже и повторно
Некоторые способы расчёта завершаются асинхронно. Провайдер сообщает об изменении через webhook или другой предусмотренный механизм, а приложение проверяет подлинность уведомления. Точные правила подписи зависят от сервиса; их нельзя заменять предположением, что запрос выглядит правдоподобно. Обработчик должен учитывать повторную доставку. Если одно подтверждение пришло дважды, товар не должен выдаваться дважды. Для этого связывают событие с уже выполненным действием и проектируют устойчивую обработку повторов. Идемпотентность создания запроса и защита от повторной обработки уведомления являются связанными, но не одинаковыми задачами.
Ошибка не всегда означает, что оплаты не было
Если ответ потерялся из-за сети, результат операции может быть неизвестен. Немедленное создание новой попытки без сверки способно привести к повторному действию. Сначала проверяют состояние по идентификатору и правила безопасного повтора. Пользователю показывают понятное ожидание, а не ложный окончательный отказ. Тестирование должно включать успех, отказ, задержку, повтор уведомления и закрытие вкладки после оплаты. Логи сохраняют необходимые идентификаторы и статусы, но не секреты и лишние платёжные данные. Для реальной интеграции предпочтительны предусмотренные провайдером безопасные компоненты и тестовая среда. Наличие красивого экрана оплаты не подтверждает корректность всего процесса.
Попробуйте на практике
Нарисуйте схему оплаты вымышленного заказа на цифровую открытку. Никакие реальные деньги, карты и аккаунты не используются.
- Создайте карточки заказа и попытки платежа с разными условными идентификаторами. Укажите сумму и валюту как учебные данные.
- Покажите переход от ожидания к оплате только после проверенного серверного подтверждения, а не после открытия страницы успеха.
- Добавьте два одинаковых уведомления и объясните, почему действие выдачи выполняется один раз.
- Смоделируйте потерю ответа. Запишите шаг проверки состояния перед повтором и сообщение пользователю, которое честно отражает неопределённость.
Как проверить результат. Схема различает заказ и попытку платежа, выдерживает дубли уведомлений и не создаёт новую оплату вслепую при сетевой ошибке.
Частые вопросы
Страница успеха гарантирует подтверждённую оплату?
Не сама по себе. Приложение должно опираться на доверенный результат провайдера и проверять соответствие заказу.
Можно ли считать webhook одноразовым?
Нет. Интеграция должна учитывать возможные повторы и обрабатывать их без повторной выдачи или другого лишнего действия.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.