Как мы собрали платформу интернет-эквайринга для клиента с нуля
Как мы в Right line спроектировали архитектуру и кастомизировали Back Office для платежной платформы, обеспечив клиенту эквайринг, расчеты комиссий и экономику
Бизнес обратился в компанию Right line за комплексным решением для запуска интернет-эквайринга в странах СНГ. На старте у клиента не было собственной технологической инфраструктуры, а задача заключалась в том, чтобы обеспечить полный цикл интернет-платежей: от приема транзакций до расчетов по ним.
Отметим, что первоначально бизнес запросил только подключение Back Office — систему для расчетов комиссий с мерчантами и расчетов по эквайринговым операциям. Это решение у нас полностью готово и быстро интегрируется в IT-ландшафт заказчиков. Однако после серии обсуждений, оценив нашу экспертность и опыт разработки, мы определили с заказчиком объемы кастомизации бэк-офиса под индивидуальные требования клиента, а позже расширили проект до разработки всего комплекса:
- Onboarding-портал
- Платежный шлюз
- Back Office
- Мерчант-портал
Шаг 1. Анализ ТЗ и запуск проекта
Изначально заказчик передал нам техническое задание, которое описывало только часть будущего продукта. Закладывались ресурсы на интеграцию систем бэк-офиса.
Но после детального анализа и оценки текущих систем клиента стало очевидно, что для работы нужны единая модель данных, расширенный функционал Back Office, а также полноценный онлайн-контур.
В результате мы подготовили объемный пакет изменений первоначальных требований, который фактически с нуля описал архитектуру будущего решения.
Шаг 2. Сбор команды и проработка архитектуры
Мы уже рассказывали о том, как формируется команда разработчиков на других проектах. В этом случае мы тоже начали с формирования рабочей группы проекта внутри нашей продуктовой команды.
Продуктовый менеджер — человек, который переводил язык бизнеса в язык технологий. Он помогал заказчику сформулировать, что именно должно уметь решение, чтобы эквайринг действительно можно было запустить без проблем.
Архитектор, чей фокус — вся система целиком. Он разложил будущий продукт на логичные блоки: онлайн-шлюз, бэк-офис, личный кабинет для мерчантов, онбординг.
Системный аналитик. Он описывал бизнес-логику, API, схему базы данных, вплоть до самых мелких деталей: от маршрутизации по BIN-кодам карт до формул, по которым рассчитываются комиссии банкам и мерчантам.
Когда основные системы были выстроены, подключились разработчики и тестировщики. DevOps инженеры требовались для разворачивая и сопровождения тестовый среды и организации непрерывной доставки релизов клиенту.
Вся эта работа происходила параллельно с руководством проекта, которое держало процесс в рамках сроков и бюджета: в эквайринге легко уйти в «вечную разработку», если не ограничивать себя четкими контрольными точками.
Шаг 3. Техническое ядро: как мы построили систему, на которой держится эквайринг
Центральным элементом проекта стала система расчетов комиссий. Именно она определяет экономику эквайринга и позволяет платформе управлять маржинальностью. При этом важно понимать, что в современных платежных сервисах существует не один, а два взаимосвязанных контура комиссий.
- Комиссии в контуре «мерчант — PSP-платформа»
Когда к платформе приходит бизнес — будь то крупный сервис по доставке или интернет-магазин, — он ожидает понятных условий приема платежей. На этом уровне платежная платформа формирует стандартную оферту: например, комиссия в 3% от каждой транзакции.
Это то, что видит интернет-магазин, и то, что лежит на поверхности. Однако для самой платформы это лишь первый уровень экономики.
- Комиссии в контуре «PSP-платформа — поставщики»
Второй уровень — скрытая часть инфраструктуры. Чтобы провести транзакцию, платежная система взаимодействует с внешними поставщиками: банком-эквайером,
процессинговым центром, дополнительными агрегаторами.
Именно они обеспечивают проведение платежа и расчетно-кассовые операции. За это платформа сама выплачивает им комиссию — часто по разным ставкам, в зависимости от маршрута прохождения транзакции, BIN-кода карты и схемы взаимодействия.
Какое решение было разработано
Мы создали механизм, который позволяет платформе электронных платежей автоматически рассчитывать комиссии по обоим контурам. Система учитывает тарифы мерчантов, тарифы поставщиков, маршрутизацию по BIN-кодам карт, цепочки участников конкретной транзакции и правила распределения комиссий между ними.
Таким образом, каждая операция получает полный финансовый отчет — сколько заработано, сколько выплачено поставщикам и какой итоговый финансовый результат для PSP-платформы.
Это позволило клиенту перейти от ориентировочных оценок к точному управлению экономикой платежного сервиса и выявлению точек роста.
И только после этого мы перешли к подключение нашего Back Office решения для автоматизации расчетов, документооборота, генерации платежных поручений и проводок, закрытия обязательств.
После согласования архитектуры, разработки и подключения ключевых функциональностей финальное решение было передано в тестовый контур клиента. На этом этапе прошел полный цикл технической проверки системы.
В тестовой среде были выполнены:
- функциональные испытания отдельных модулей;
- интеграционные тесты с внешними поставщиками — банком-эквайером и процессинговым центром;
- верификация алгоритмов расчета комиссий для мерчантов и поставщиков;
- пилотирование на реальных транзакциях с ограниченным объемом операций.
Проведение пилота позволило заказчику увидеть работу системы в условиях, максимально приближенных к промышленным. На основе данных тестовой эксплуатации были выявлены дополнительные сценарии использования и возможности для оптимизации. Мы сформировали план развития решения, который стал основой для следующей итерации проекта.
Рубрики
Интересное:
Новости отрасли:
Все новости:
Публикация компании
Контакты
Социальные сети
Рубрики