Как объединить эквайринг Альфа-Банка для 1000 компаний в одном интерфейсе на React.js

1. Вводная задача от заказчика, проблематика, цели

Эквайринг — это банковский сервис, позволяющий торгово-сервисным предприятиям принимать безналичную оплату по картам. Для Альфа-Банка это масштабное и высоконагруженное бизнес-направление: каждый день система обеспечивает обработку более 90 тысяч транзакций среди продавцов использующих эквайринг и платежные терминалы от Альфа Банка, а ежедневный финансовый оборот превышает 30 млн рублей.

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

Главная техническая проблема: из чего состоял хаос данных

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

• Контрагенты и Договоры. Юридические лица и официальные соглашения с ними, где зафиксированы индивидуальные условия сотрудничества и тарифы комиссий за прием платежей. Информация находилась в одной системе.
• Торговые точки и Терминалы. Адреса конкретных магазинов и привязанные к ним физические аппараты для считывания банковских карт. Данные велись в отдельной базе технического учета оборудования.
• Транзакции и Начисления.Поток сырых платежей от покупателей (кто, сколько и когда заплатил) и расчет чистой комиссии банка за каждую операцию. Эти массивы информации обрабатывались в платежном процессинге.
• Взаиморасчеты и Бухгалтерские проводки. Финальные переводы денег на расчетные счета магазинов по итогам дня и официальная фиксация этих операций в главном бухгалтерском балансе банка. Данные формировались внутри закрытого финансового контура.
• Отчетность. Сводные таблицы и аналитика, необходимые для проверки корректности расчетов и поиска ошибок. Отчеты создавались в отдельном сервисе.

К чему это приводило на практике

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

Такой формат работы порождал критические операционные риски:

• Потеря времени. При потоке свыше 90 тысяч транзакций в сутки ручной поиск информации, переключение между сервисами и ожидание загрузки разных интерфейсов парализовали оперативную работу подразделений. Специалисты тратили время на техническую рутину вместо быстрого закрытия инцидентов.
• Риск ошибок. Необходимость вручную сопоставлять и сверять данные из не связанных друг с другом окон в условиях ежедневного оборота более 30 млн рублей многократно увеличивала цену человеческого фактора. Любая опечатка приводила к расхождениям в отчетности.
• Затянутые расследования. Разбор спорных или подозрительной операций среди более чем 1000 подключенных компаний превращался в сложный процесс. Сквозной путь от конкретного клика по карте до финансового документа не визуализировался автоматически, что затягивало аналитику инцидентов.

Цель проекта — одно окно для контроля всех процессов

Требовалось спроектировать и разработать единый интерфейсный слой (Single Page Application) на React, который объединит все разрозненные данные в рамках одного рабочего пространства.

Интерфейс должен был решить следующие задачи:

• Консолидировать данные. Обеспечить бесшовную агрегацию и структурирование информации о договорах, терминалах, транзакциях и проводках, поступающей из независимых серверных (бэкенд) сервисов банка.
• Обеспечить сквозную навигацию.Настроить логические связи в архитектуре приложения так, чтобы пользователь мог мгновенно перемещаться между зависимыми объектами (например, из карточки физического терминала переходить к списку его операций или к родительскому договору) с полным сохранением контекста текущей сессии.
• Унифицировать поиск. Внедрить сквозной поиск и унифицированные фильтры, способные стабильно работать с массивами данных при ежедневном потоке транзакций.
• Обеспечить высокую производительность. Исключить зависания веб-приложения и снизить время отклика интерфейса при выполнении стандартных операций по обслуживанию подключенных торговых компаний.

2. Описание реализации кейса и творческого пути по поиску оптимального решения

Реализация проекта была разделена на два крупных этапа: проектирование логики взаимодействия (UX) и создание программного интерфейса на React. Главным инженерным вызовом стала необходимость упаковать сложные, независимые друг от друга финансовые процессы в одно легкое веб-приложение, работающее без перезагрузки страниц.

Этап 1. Проектирование единой информационной модели

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

На основе собранных данных была создана карта бизнес-процессов, которая позволила объединить девять изолированных направлений банка в понятную структуру:

• Контрагенты и договоры;
• Торговые точки и терминалы;
• Транзакции и начисления комиссии;
• Взаиморасчеты и бухгалтерские проводки;
• Отчетность.

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

состояния клиентской (фронтенд) части будущего приложения.

Этап 2. Создание дизайн-системы и библиотеки React-компонентов

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

Она включала в себя готовую библиотеку компонентов, переведенную в код:

• Стандартизированные фильтры и механизмы поиска для всех типов данных;
• Единые правила построения и верстки таблиц;
• Унифицированные карточки объектов и экранные формы;
• Систему цветового отображения финансовых статусов и показателей.
• Использование готовых компонентов позволило собирать новые экраны из готовых блоков, что ускорило дальнейшее развитие продукта.

Этап 3. Решение проблемы «тяжелых» таблиц и сохранения контекста

Самой сложной технической задачей этого этапа стала оптимизация работы с большими таблицами (миллионы транзакций и отчетов). Если отрендерить такой объем данных в браузере стандартным способом, интерфейс зависнет из-за перегрузки оперативной памяти.

Для решения этой проблемы на уровне фронтенд-разработки были применены следующие архитектурные паттерны:

• Принцип «список + боковая карточка»: В основу интерфейса положена логика, при которой детальная информация о договоре или транзакции открывается в виде шторки прямо на текущем экране, без перехода на отдельную страницу. Это исключило повторные тяжелые запросы к серверу и позволило сотруднику мгновенно возвращаться к общему списку без потери контекста.
• Оптимизация рендеринга данных: Вместо классического вывода строк была внедрена концепция программной виртуализации. Приложение не создает элементы интерфейса для всего объема операций одновременно. В каждый конкретный момент скроллинга в браузере рендерятся исключительно те строки, которые физически видны на экране пользователя. Это позволило удерживать стабильную скорость навигации и защитило компьютеры персонала от падения производительности.

Этап 4. Сборка клиентской (фронтенд) платформы и интеграция с программным интерфейсом приложения (API)

После фиксации всех интерфейсных решений была выполнена разработка пользовательской части платформы. Пользовательский (фронтенд) контур реализован на фреймворке React.

Поскольку разработка серверной части и расчетной логики выполнялась ИТ-департаментом Альфа-Банка, интеграция строилась на архитектуре разделения ответственности. Созданное React-приложение было бесшовно подключено к внутренним сервисам и готовым программными (API) методами банка. Интерфейс стал выступать в роли умного визуального агрегатора: он отправляет запросы в нужные контуры данных, мгновенно собирает ответы и выводит их сотруднику в одном окне с сохранением сквозной логики (от клика по транзакции до просмотра бухгалтерской проводки).

3. Результаты сотрудничества

Итогом проекта стал запуск единой внутренней платформы на React для сопровождения эквайрингового бизнеса Альфа-Банка. Интерфейс объединил разрозненные потоки информации в один инструмент, сделав финансовые процессы прозрачными и снизив нагрузку на операционные отделы.

Ключевые показатели системы:

• Масштаб визуальной агрегации: Разработанный интерфейсный слой обеспечивает сквозной сбор и структурирование данных из независимых банковских контуров для обслуживания более 1000 торгово-сервисных предприятий. Вся цепочка эквайринга — от параметров договоров до технических данных терминалов — выводится на одном экране.
• Пользовательский охват: Платформа успешно запущена в промышленную эксплуатацию и стала основным ежедневным рабочим инструментом для сотрудников операционных, финансовых и сервисных подразделений Альфа-Банка.
• Отказоустойчивость: Внедрение механизмов виртуализации списков и оптимизация рендеринга позволили табличным интерфейсам стабильно обрабатывать суточный поток свыше 90 тысяч транзакций и контролировать ежедневный оборот более 30 млн рублей без критического потребления ресурсов рабочих станций.
• Защита от технического долга: Архитектура клиентской части спроектирована по принципу разделения ответственности и полностью изолирована от серверной логики. Это позволяет ИТ-департаменту банка самостоятельно масштабировать систему, бесшовно подключать новые сервисы и программными (API) методы без необходимости переписывать базовый код пользовательского интерфейса.