Что важно знать перед интеграцией банковских продуктов: наш опыт автоматизации процессов на проекте Vetsy
Мы не ожидали, что автоматизация финансовых операций будет простой задачей. Но в процессе интеграции банковских продуктов стало ясно, что реальная сложность заключается в неочевидных ограничениях, которые проявляются только на практике.
Меня зовут Михаил Твердохлеб, я тимлид разработки в ITECH. В этой статье я разберу наш опыт интеграции сервисов интернет-эквайринга и номинального счёта от известного банка, расскажу, на какие грабли можно наступить, и почему моё каждое рабочее утро начинаются с «ручной автоматизации».
Последние полгода мы развиваем платформу Vetsy: за год проект вырос от сервиса онлайн-консультаций ветеринаров до полноценного агрегатора услуг. Если на старте с платформой работало несколько ветврачей, то сейчас — десятки специалистов и клиник. Владельцы животных находят нужного ветеринара и получают консультации онлайн, а специалисты — стабильный поток запросов.
По мере роста проекта, количества ветеринаров и консультаций возникла необходимость автоматизировать выплаты специалистам, сотрудничающим с платформой. Фактически речь шла о том, чтобы избавиться от ручного распределения платежей: отделять комиссию сервиса и правильно отправлять ветеринару его долю. И именно тут началась наша история о том, как «удобные» банковские решения превращаются в источник бесконечного ручного труда.
До автоматизации
Изначально у нас был настроен простой рабочий флоу:
- Владелец питомца выбирает ветеринара и записывается на консультацию.
- Оплачивает её и ждёт назначенного времени.
- Ветеринар проводит консультацию и отправляет отчёт.
- В конце периода бухгалтерия вручную собирает данные, сверяет суммы и перечисляет ветеринарным врачам оплату за вычетом лицензионного платежа.
Этот процесс работал хорошо, но только на маленьких объемах платежей. С увеличением количества транзакций было принято решение автоматизировать флоу распределения денег и сократить ручные операции до минимума.
Мы рассмотрели несколько вариантов банковских решений — в том числе продукты разных банков для работы с эквайрингом и распределением платежей — и в итоге остановились на номинальном счёте того же банка, где у клиента уже был подключен интернет-эквайринг. Мы рассчитывали, что единый банковский контур снизит сложность интеграции. На практике оказалось совсем не так.
Документация — не инструкция: почему наше первое проектирование ушло в корзину
На этапе проектирования мы ориентировались на официальную документацию банка. Она подробно описывала продукт, но не давала понимания, как номинальный счёт предполагается использовать в реальных сценариях расчётов.
Мы предложили схему распределения средств, которая выглядела корректной с точки зрения бизнес-логики и описаний в документации. Но в ходе обсуждения с банком обнаружилось расхождение между нашим пониманием сценария и тем, как этот процесс фактически реализуется со стороны банка. Ограничений оказалось больше, часть из них нигде не была описана. В итоге нашу первоначальную архитектуру пришлось перепроектировать полностью.
Уточняйте всё заранее, особенно то, что в документации не проговорено. Документация может быть формально корректной, но без описания схемы внедрения вы легко спроектируете процесс, который банк просто не сможет обслуживать.
Стык систем невозможно протестировать заранее: отладка в бою
Процесс разработки прошёл достаточно легко, мы реализовали все методы для взаимодействия с банком и подготовили сервис к работе.
Но на стыке интернет-эквайринга и номинального счёта остался большой пласт неизвестности: документация не давала ответов на вопросы, которые напрямую влияли на корректность расчётов.
Закрыть эти пробелы можно было только одним способом — тестированием в бою. Номинальный счёт не имеет тестового режима, работает только на реальных деньгах, и все особенности проявились уже после запуска. Мы столкнулись со следующими проблемами:
- Ожидаем сумму в копейках — приходит в рублях.
- Ждём данные по каждому платежу — эквайринг присылает единый реестр за вчерашний день.
- Рассчитываем на полную сумму платежа — она приходит уже с вычетом комиссии, причём комиссия может меняться.
- Мы предполагаем, что незавершённые платежи не должны влиять на расчёты — фактически списывается 1 рубль при попытке провести транзакцию.
В итоге для финансовой отчётности всё это оказывается максимально неудобным: суммы не совпадают, данные приходят в разном формате, а логика распределения денег требует ручных корректировок.
И даже после исправления всех ошибок — появляются новые. После внедрения и обкатки системы я, как человек, отвечающий за внедрение этой истории, каждое утро начинал с проверки корректности распределения денег за вчерашний день. И раз за разом что-то могло пойти не так. В такие моменты мы снова разбирали ситуацию вручную и исправляли данные уже своими силами, пока не понимали, в какой части цепочки появился новый нюанс.
Объективный вывод здесь один: значительная часть деталей банковских интеграций проявляется только в реальных транзакциях. К этому нужно быть готовыми и заранее закладывать время на доработки.
Что мы вынесли из этой истории
Автоматизация сложного финансового процесса — это всегда зона повышенной неопределённости. Проблемы начинаются не на уровне кода, а на уровне правил, нюансов, ограничений и того, как банк трактует операции внутри своих систем.
- Предварительное выяснение основных ограничений системы, которую мы будем подключать. Поиск контактного лица со стороны этой системы, которое может ответить на вопросы.
- Верхнеуровневое описание процесса взаимодействия систем — на базе документации, бизнес-требований и других документов.
- Согласование общего описания схемы взаимодействия со всеми участниками: бизнес-заказчик, представители сервиса, с которыми осуществляется интеграция — в нашем случае представители банка.
- Выяснение точечных ограничений системы, с которой предстоит интеграция. В нашем случае это уточнение формата передачи данных и отчётов по основным возникающим вопросам, которые не отражены в документации.
- Финальное проектирование, написание ТЗ на разработку, составление тест-кейсов и плана внедрения.
- Согласование сценариев тест-кейсов, плана внедрения и финальной схемы процесса с партнёром, с которым мы будем делать интеграцию.
- Реализация интеграции на тестовом контуре и первичная отладка.
- Внедрение на продуктив с тестированием всех возможных сценариев и длительным сроком отладки.
Нужно быть готовыми к тому, что всё что может пойти не так. И с большой вероятностью пойдёт, но если все предыдущие шаги были пройдены, то последствия будут легко решаемы :)
Каждый из данных шагов очень важен. Не уделив внимания какому-то из них, мы начнём собирать снежный ком, который скопится и заставит решать множество вопросов в спешке.
И самое главное — найти человека, который будет «на вашей стороне» при этой интеграции, что позволит лучше понять все ограничения и не остаться один на один с проблемами после внедрения системы.
На текущий момент все шаги мы прошли, и с момента внедрения прошло более 3-х месяцев — интеграция работает стабильно. 2 месяца я уже не вскакиваю по утрам с мыслями о необходимости проверить результаты сверок за вчерашний день. И самое главное — внедрение автоматизации позволило сократить огромный пласт ручной работы.
Напишите нам, мы ответим!
