Как подготовить магазин к онлайн-оплате

Сначала определите бизнес-сценарий

Магазин может принимать оплату сразу после оформления или после подтверждения наличия. Возможны разные правила резерва и изменения заказа. Выберите процесс до интеграции: в какой момент сумма окончательная, кто подтверждает состав и что происходит при отказе. Эти решения определяют интерфейс и серверные состояния.

Сохраните заказ отдельно от платёжной попытки. У одного заказа может быть неуспешная попытка и последующая успешная, но это не обязательно два заказа. Укажите устойчивые идентификаторы и связь между ними. Не используйте текст назначения как единственный способ сопоставления: он может измениться или оказаться неуникальным.

Разделите состояния

Документация ЮKassa различает процесс и статусы платежа, включая особенности двухстадийного проведения. У других провайдеров контракт может отличаться. Выбирайте состояние успеха по используемой схеме, не перенося названия механически. Техническая интеграция не заменяет отдельное согласование чеков, документов и условий торговли для конкретного бизнеса.

Подтверждайте результат на сервере

Покупатель может закрыть вкладку, вернуться по старой ссылке или потерять соединение. Поэтому открытая страница благодарности не является доказательством оплаты. Используйте предусмотренный провайдером способ получения и проверки фактического состояния, сопоставляя заказ, сумму и валюту. Не доверяйте значению успеха, переданному браузером без проверки.

Правила входящих уведомлений ЮKassa описывают обработку событий конкретного API. Учитывайте повтор и задержку доставки, подтверждайте источник и актуальное состояние предусмотренным способом. Webhook — сообщение о событии, а не автоматическое основание выполнить любое действие из его текста.

Защитите повторные действия

Двойной клик, повтор сети и повторное событие не должны приводить к нежелательному второму эффекту. Определите ключ операции и поведение при уже обработанном результате. Защита от дублей требует серверного контракта, а не только отключённой кнопки. Для нового содержимого заказа старый ключ нельзя использовать без предусмотренного правила.

Если сумма или наличие изменились до оплаты, покажите новые условия и необходимое подтверждение. Не принимайте стоимость из скрытого поля браузера как окончательную. Расчёт и допустимость операции проверяются по актуальному заказу. Сценарий оформления подробно разобран в материале о покупке.

Подготовьте неопределённые состояния

Иногда ответ потерян, а платёж уже выполнен. Интерфейс должен сообщать, что результат уточняется, и давать безопасный путь проверки. Не предлагайте немедленно повторить списание с новым идентификатором без выяснения состояния. Сотруднику нужен список операций, требующих сверки, с минимумом необходимых диагностических данных.

Отказ оплаты не должен уничтожать корзину без причины. Покажите доступное повторение или другой разрешённый способ. Если заказ истёк, объясните, что нужно проверить заново. Возврат и отмена тоже имеют отдельные состояния; их нельзя моделировать простым удалением записи о платеже.

Учебная репетиция оплаты

В тестовом контуре покупатель создаёт заказ, начинает оплату и закрывает вкладку. Сервер получает подтверждённое событие, обновляет одну запись и показывает корректный результат при повторном входе. Затем команда проверяет отказ, повтор уведомления и несовпадение суммы. Никакие реальные деньги для такой редакционной модели не списываются.

Перед запуском сверяют интерфейс покупателя, данные сотрудника и состояние провайдера. Приёмка магазина включает платёж как часть всей покупки. Готовность означает согласованные состояния и проверяемое восстановление после ожидаемых сбоев, а не единственный успешный клик в демонстрации. Зафиксируйте ответственного за разбор спорных операций и доступный ему журнал событий.

Как разобрать оплату, которая завершилась после отмены заказа

В учебном сценарии магазин отменил неоплаченный заказ по своему сроку ожидания, но подтверждение операции пришло позднее. Обработчик не должен автоматически возвращать заказ к продаже без проверки наличия и бизнес-правил. Сопоставьте ID заказа, платёж, сумму, валюту и фактическое состояние операции.

Заранее определите путь такого исключения: ручная проверка, восстановление допустимого заказа или согласованная процедура возврата. Посетителю нужно понятное сообщение и контакт поддержки; оператору — история переходов. Повтор уведомления не должен запускать повторный возврат. Конкретные статусы и проверку уведомлений сверяйте с документацией платёжного провайдера, а правила исполнения заказа закрепляйте в собственной модели магазина.