Обороты, остатки и операции приходят напрямую из банка в вашу базу, а платёжные поручения формируются из вашей программы — без ручной выгрузки, копирования и сверки в интернет-банке. Это не пересказ документации: у нас работает промышленный контур Сбербанка, и ниже мы показываем, что там реально получается, а что нет.
Пока операций десять в месяц, выгрузка файла и сверка глазами — нормально. Проблема появляется, когда считать и сверять нужно каждый день.
Перечисляем только то, что проверено на живом контуре или прямо следует из документации банка. Ничего «теоретически возможного» в списке нет.
Операции по счёту приходят за любой день, остатки и обороты — на начало и конец дня. Данные сразу попадают в вашу базу в удобном виде, а не в файл, который надо разобрать руками.
Ключ записи — банковский идентификатор операции, а не наш счётчик. Поэтому повторная загрузка того же дня не создаёт дублей, а обновляет существующие записи, если банк что-то уточнил.
Платёжка формируется из вашей системы: получатель, сумма, назначение. Документ уходит в банк и дальше живёт по обычным правилам — со статусами, контролем исполнения и историей.
Карточка организации, список счетов, корреспондентские счета, справочники банка. Это убирает ручной ввод реквизитов и связанные с ним ошибки в платежах.
Операции из банка сопоставляются со счетами, заказами, договорами и лицевыми счетами клиентов. Это то, ради чего интеграцию обычно и затевают: не «получить выписку», а закрыть сверку автоматически.
Загрузка выписок запускается по таймеру — например, каждый час или раз в день после закрытия операционного дня. Данные в базе всегда актуальны, без ручных действий.
Это главное, что нужно понять до начала работ. У платежа через API есть два пути, и оба требуют решения на вашей стороне:
Отсюда практический вывод: если в компании подписание устроено через СМС-пароли, «безлюдных» платежей не будет, пока не выпущен сертификат. А первичный выпуск сертификата требует личного присутствия в отделении банка — дистанционно выпускается только перевыпуск действующего. Это не наша особенность, это порядок банка, и мы предупреждаем о нём заранее, чтобы он не стал неожиданностью в конце проекта.
Отдельно про безопасность: автоматический платёж означает, что связка «токен доступа + ключ подписи на сервере» двигает деньги без единого подтверждения. Если такой сценарий нужен, мы обсуждаем ограничения: лимиты, белый список получателей, отдельный сервис под платежи и полный журнал действий. Мы против схемы, где доступ к серверу равен доступу к счёту без границ.
Доступ к API банк открывает по заявлению, которое подписывает руководитель или доверенное лицо. Набор доступных операций закрепляется в договоре.
После создания сервис нужно активировать в личном кабинете банка. Пока он не активирован, рабочий контур недоступен.
Для защищённого канала нужен отдельный сертификат шифрования, для платежей — сертификат электронной подписи. Сроки выпуска — на стороне банка.
Нужно, чтобы у ответственных сотрудников были роли для работы в личном кабинете, иначе выпустить сертификаты и забрать настройки не получится.
Раздел для тех, кому важно понимать, что именно появится в инфраструктуре. Если технические детали не нужны — можно переходить к вопросам ниже.
Закрытый канал (mTLS). Работа с банком идёт не «просто по HTTPS»: банк требует встречный клиентский сертификат. Без него сервер отвечает отказом ещё до проверки логина и пароля — то есть без сертификата не поможет ни один правильный пароль. Это первое, что нужно получить.
Авторизация по OAuth 2.0. Доступ выдаётся на конкретного сотрудника банка, а не на компанию «вообще». Токен доступа живёт час, токен обновления — до полугода, поэтому продление автоматизируется и незаметно для работы.
Нулевое доверие к ручному вводу. Реквизиты, названия и счета программа забирает у банка, а не берёт из того, что кто-то ввёл руками. Так исчезает целый класс ошибок в платежах.
У каждой операции банк отдаёт свои идентификаторы. Мы храним их как есть и делаем ключом записи — именно поэтому догрузка не создаёт дублей и не путает операции между днями.
| Что отдаёт банк | Для чего используем |
|---|---|
operationId |
Ключ записи в базе. Именно по нему повторная загрузка обновляет операцию, а не создаёт вторую. |
uuid |
Дополнительный идентификатор операции, тоже сохраняем — для сверки с выписками банка. |
hashAbc |
Хеш операции. Храним как контрольное значение, чтобы можно было доказать неизменность данных. |
number, documentDate |
Номер и дата документа. Только как атрибут: номер уникален внутри дня, но повторяется в других днях. |
Кроме разобранных по полям данных мы сохраняем исходный ответ банка по каждой операции. Это значит, что при появлении новой задачи не нужно заново ходить в банк и перезагружать историю — нужные поля уже лежат в базе.
Сама интеграция пишется и отлаживается за несколько дней — быстрее, если считать только выписки, дольше, если добавляются платежи и сопоставление с учётом. Основное время уходит на процедуры банка: заявление, активация сервиса, выпуск сертификатов. Мы называем срок честно после того, как посмотрим ваш случай, а не «среднюю цифру по рынку».
Список не для скромности, а чтобы потом не было разочарований.
С любым банком, у которого есть открытый API для юридических лиц и ИП. Проверенная интеграция у нас — Сбербанк: там работает промышленный контур, мы получаем выписки, остатки и формируем платёжные поручения. У других банков набор возможностей и требования отличаются, поэтому первым шагом мы смотрим, что именно банк отдаёт через API, и говорим честно, что технически возможно, а что нет.
Да, и это первое, что нужно сделать. Доступ к API банк даёт только по заявлению, которое подписывает единоличный исполнительный орган или доверенное лицо. Подписание заявления, активация сервиса и выпуск сертификатов — на стороне банка и клиента; наша часть начинается с полученных доступов и заканчивается работающей интеграцией.
Технически да, если у подписанта профиль с типом защиты «электронный ключ» и есть сертификат электронной подписи. Но решение об этом принимает клиент, и мы прямо говорим о риске: автоматический платёж означает, что один токен и ключ на сервере двигают деньги без единого подтверждения. Мы обычно ограничиваем такие схемы лимитами, белым списком получателей и отдельным сервисом под платежи.
Тогда платёж всё равно можно сформировать, но он ляжет черновиком и будет обработан только после того, как его подпишут в интернет-банке. Автоматической отправки без подписи не получится: подпись является обязательным условием обработки. Первичный выпуск сертификата требует личного присутствия в отделении банка, дистанционно выпускается только перевыпуск действующего.
Обычно интеграция разворачивается на сервере клиента, и база операций остаётся внутри его контура. Если у клиента нет своей инфраструктуры, мы обсуждаем размещение отдельно и показываем, где физически будут лежать данные, прежде чем начинать.
Сам код интеграции пишется и отлаживается в тестовом контуре банка за несколько дней. Но срок в основном зависит не от нас: подписание заявления, активация сервиса и выпуск сертификатов занимают существенно больше времени, а первичный выпуск электронной подписи требует визита в отделение банка.
Если штатный обмен вас устраивает, интеграция не нужна. Она нужна, когда требуются свои правила обработки: сопоставление поступлений с заказами и договорами, несколько счетов в одной базе, свои отчёты, контроль исполнения платежей или загрузка чаще, чем удобно делать руками.
Документы каждого дела — в своей папке, с поиском по словам и номерам, реестром доказательств и справкой для передачи дела. С разбором того, куда уходят данные.
Материалы дела индексируются по смыслу и по номерам, ответы строятся по загруженным документам со ссылкой на источник. Принимает PDF, DOCX, таблицы, сканы и фото.
ИИ-агенты, автоматизация процессов, интеграции и сервисы под задачу. Если не уверены, какое решение нужно — начните отсюда.
Скажите, какой у вас банк и что нужно автоматизировать: только выписки и остатки в свою базу, или ещё и платежи. Мы посмотрим документацию вашего банка и ответим прямо, что реально сделать, что потребуется от вас и сколько это займёт — бесплатно и без обязательств.