Как интеграция оплаты ломает бизнес — и как её построить правильно в России

Habr-ecommerce пишет, что вебхуки от платёжных сервисов приходят с ошибками, дублируются или не совпадают по подписи — и это ломает работу интернет-магазина. Это не редкость, а часть архитектуры, которую многие игнорируют.

Вебхук пришёл — а статус не изменился

Когда клиент оплачивает заказ, деньги списываются, но статус на сайте остаётся «Ожидает оплаты». Это не сбой, а следствие разрыва между двумя системами: платёжным сервисом и учётом. Вебхук пришёл, но не был обработан — или обработан с ошибкой. Результат: клиент ждёт, менеджер не видит заказа, а вы — разбираетесь, куда пропали данные. Это не просто техническая неполадка. Это потеря продаж, конфликты с клиентами, ручная проверка каждого платежа. Я считаю, что для бизнеса это критично: если система не синхронизируется, она не работает. Даже если всё «вроде бы» работает, каждый сбой — это рост нагрузки на команду и риск ухода клиента.

Как работает интеграция оплаты

После нажатия «Оплатить» создаётся заказ, генерируется order_id, затем идёт запрос к платёжному сервису с его payment_id. После авторизации платёжный сервис отправляет вебхук на ваш сайт. Сайт его принимает, проверяет подпись, обновляет статус. Если вебхук пришёл трижды — система должна не обновлять статус трижды. Если подписи не совпадают — это не ошибка, а попытка подделки. В документации провайдеров о таких сценариях почти не пишут. А в реальности они — норма. Система должна быть спроектирована так, чтобы справляться с неидеальными условиями. Это не про «красивый код» — это про устойчивость.

Раньше было проще, теперь сложнее

Раньше интернет-магазины принимали платежи через простые формы, и сбои были редкими. Теперь всё связано: платёжный сервис, касса, CRM, склад. Каждый элемент — отдельная система. И каждый может дать сбой. Раньше всё происходило в одной среде. Сейчас — в разных. И если не настроить обмен данными, то даже успешный платёж не приведёт к заказу. Раньше можно было «вручную» проверить статус. Теперь — при 100 заказах в день — это невозможно. Система должна работать без вмешательства. Иначе бизнес не масштабируется.

Кто в зоне риска — и как понять

Всех, кто принимает оплату через сайт. Особенно тех, кто не использует готовые решения, а интегрирует API вручную. Если вы видите, что статусы заказов не обновляются после оплаты, если клиенты жалуются, что «платили, но не получили подтверждение», — это про вас. Если вы проверяете платежи вручную, если у вас есть «дубли» в учёте — вы на грани. Система, которая не синхронизируется, не работает. Это не «технический момент» — это фундаментальный риск для бизнеса.

Что делать — порядок действий

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

Что мы с этим делаем

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

Это часть нашей работы — Внедрение. Установка готовых решений и программных продуктов. Или подготовка разработанного сайта к запуску. Внедрение

Автор: Святослав Семенов из Cetera Labs

Новость для бизнеса в Ярославле, Россия