PayFlow Enterprise: B2B-платежи на Java

Исходная задача

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

Что проработали

Для PayFlow Enterprise подготовили микросервисную архитектуру на Java 21 и Spring Boot 3.2. API Gateway принимает запросы от корпоративных систем; сервисы платежей, транзакций и комплаенса отвечают за свои части процесса. Kafka передает события на асинхронную обработку, а адаптеры связывают платформу с банками и ERP. PostgreSQL хранит операционные данные, Redis ускоряет повторяющиеся операции, ClickHouse предусмотрен для аналитики. Отдельные контуры отвечают за уведомления, мониторинг и аудит.

Результат проработки

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

Как проходит корпоративный платеж

• Компания формирует платеж в ERP; запрос поступает через API Gateway и проходит проверку данных и прав доступа.
• Платежный и транзакционный сервисы проверяют лимиты, создают операцию и фиксируют ее уникальный идентификатор.
• Событие в Kafka передает операцию на обработку и выбор платежного маршрута.
• Адаптер банка отправляет платеж во внешнюю систему и возвращает статус обработки.
• Сервисы уведомлений, аналитики и аудита обновляют состояние операции для участников и сотрудников.

Почему архитектура разделена на сервисы

• Gateway централизует авторизацию, ограничения запросов и доступ корпоративных клиентов к API.
• Платежный, транзакционный и комплаенс-сервисы развиваются независимо, не смешивая расчеты с проверками.
• Асинхронная очередь снижает зависимость приема запроса от скорости банка или внешней ERP.
• Отдельные хранилища для операций и аналитики позволяют не нагружать транзакционную базу отчетами.
• Наблюдаемость и журнал событий помогают разбирать задержки, повторы и ошибки интеграций.

Надежность и контроль

• При проектировании учтены проверки AML/KYC и требования 115-ФЗ; защита платежных данных рассматривается с учетом PCI DSS и PSD2.
• Для критичных операций предусмотрены идентификаторы транзакций, аудит, управление доступом и обработка повторных запросов.
• В техническом контуре описаны Resilience4j, мониторинг Prometheus и Grafana, трассировка OpenTelemetry и централизованные логи.

По теме

• Разработка fintech и платежных платформ
• Платежи в веб-сервисе
• Очереди и фоновые задачи
• Мониторинг веб-сервиса