Как работает платежный шлюз
Интеграции с банками и провайдерами — только в одном месте. Добавление/замена провайдера происходит в шлюзе, а внешние системы не меняют свою логику.
Остальные системы создают платеж в одном контуре. Например, чекаут передает данные заказа и оплаты, а платежный сервис выполняет работу с провайдером и возвращает статус операции.
Шлюз стандартизирует обмен. Внутренние контракты едины: один формат запроса/результата, меньше разночтений и ручных корректировок.
Единый стандарт для разных систем-инициаторов. Независимо от источника заказа, сервис работает через единые объекты платежей, уведомлений и возвратов, чтобы результат был согласован между контурами.
Итог для клиента и синхронизация для бизнеса. Шлюз приводит оплату к единому статусу и затем уведомляет нужные системы (например, сайт и 1С) для согласованной картины.
Логика платежного шлюза
От создания платежа до подтверждения результата
Создание платежа
Внешняя система передает данные платежа и заказа через API/интеграционный контур.
Выбор провайдера внутри шлюза
Шлюз подбирает подключенный провайдер и выполняет банковскую обработку в своем контуре.
Единый статус результата
Шлюз переводит итог к унифицированному формату статуса оплаты, чтобы внешние системы работали одинаково.
Уведомление нужных систем
Оплата и ее результат синхронно/последовательно доходят до всех задействованных контуров (например, сайт и 1С).
Ключевые возможности
Подключение платежных систем
Единое управление подключениями к провайдерам и типами платежных систем.
Платежи и статусы
Учет платежных операций: привязка к заказу, суммы, статусы и ответы провайдера.
Возвраты и уведомления
Обработка возвратов и входящих webhook-уведомлений от платежных провайдеров.
Логи и внешний контекст
Логи запросов/ответов к провайдерам и привязка операций к внешним системам-инициаторам.
Оценка затрат: собственная разработка vs лицензия vs подписка
Ниже — иллюстративная модель первого года для платежного шлюза: подключения провайдеров, статусы/уведомления, возвраты, логи и базовая админка.
| Статья | Своя разработка | Лицензия (on-prem) | Подписка (SaaS) |
|---|---|---|---|
| Запуск / внедрение | 1 500 000 ₽ | 380 000 ₽ | 220 000 ₽ |
| Разработка/доработки ядра | 3 000 000 ₽ | 520 000 ₽ | 300 000 ₽ |
| Поддержка и обновления (год) | 1 300 000 ₽ | 650 000 ₽ | включено в подписку |
| Лицензия / подписка (год) | — | 980 000 ₽ | 1 260 000 ₽ |
| Итого за 1-й год | ~5 800 000 ₽ | ~2 530 000 ₽ | ~1 780 000 ₽ |
| Типичный срок запуска | 6–8 мес | 2–4 мес | 2–8 недель |
| Вывод по модели: | |||
| • Подписка обычно обеспечивает самый быстрый go-live и минимальные капитальные затраты. | |||
| • Лицензия on-prem подходит при требованиях к размещению, контролю и безопасности контура. | |||
| • Своя разработка оправдана при необходимости полностью кастомной платежной логики и долгосрочной стратегии владения продуктом. |