Оплата счетов через API банка: как это устроено и что нужно малому бизнесу

Коротко: оплата счетов через API банка — это когда система, в которой вы обрабатываете входящие счета, сама передаёт в банк готовое платёжное поручение, а обратно получает выписку и статус платежа. Человек при этом остаётся в цепочке только там, где он действительно нужен, — на подписи. Для малого бизнеса правильная схема почти всегда одна: система создаёт черновик, руководитель подписывает его одним действием, выписка сама закрывает счёт как оплаченный.

В большинстве небольших компаний автоматизация обрывается на самом дорогом месте. Счета уже приходят в один ящик, их распознаёт сервис, их согласовывает руководитель — и всё это заканчивается тем, что бухгалтер открывает интернет-банк и вручную вбивает получателя, ИНН, счёт, сумму и назначение. Одна опечатка в номере счёта — и деньги ушли не туда, а возвращать их приходится неделями.

Банковский API закрывает этот разрыв: данные, которые уже проверены, идут в банк без перепечатки. Подключение бывает разным — от готового коннектора в сервисе обработки счетов до собственного интеграционного шлюза, если банков несколько или процесс нестандартный. Такие связки «учётная система — банк — CRM» проектирует, например, команда YuSMP Group. Ниже — как устроен обмен, чем API отличается от ДиректБанка и H2H, какие права выдавать и как запустить всё без риска для денег.

Что такое API банка простыми словами

API банка — это программный вход в ваш расчётный счёт, которым пользуется не человек, а другая система. Через него можно сделать почти всё, что бухгалтер делает в интернет-банке: посмотреть остаток, выгрузить выписку, создать платёжное поручение, узнать его статус. Разница в том, что вместо кликов система отправляет запрос с данными, а банк отвечает структурированным результатом.

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

Как проходит оплата счёта через API: путь платежа по шагам

Если убрать технические детали, путь одного счёта выглядит так:

• 1. Счёт попадает в систему. Из почты, кабинета поставщика или ЭДО. Сервис распознаёт реквизиты: получателя, ИНН, КПП, расчётный счёт, БИК, сумму, НДС, назначение.
• 2. Проверка. Реквизиты сверяются со справочником контрагента, ищутся дубли, проверяется, совпадает ли сумма с заказом или договором.
• 3. Согласование. Счёт проходит маршрут: инициатор закупки, руководитель, при крупной сумме — второй согласующий.
• 4. Формирование платёжки. Система собирает платёжное поручение из уже проверенных данных и отправляет его в банк запросом через API.
• 5. Подпись. В типичной схеме платёжка появляется в интернет-банке как черновик, и руководитель подписывает её — одну или пачкой — в веб-версии или мобильном приложении банка.
• 6. Исполнение и выписка. Банк проводит платёж, система забирает выписку через тот же API и по номеру документа и сумме отмечает счёт как оплаченный.
• 7. Учёт. Платёж и закрытый счёт выгружаются в 1С — без повторного ввода.

Ручной труд остаётся в двух точках: согласование и подпись. Это не недоработка, а осознанный выбор: решение «платить или нет» должен принимать человек.

Черновик или автоматическая отправка: кто подписывает платёж

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

• Черновик с подписью в банке. Система только создаёт платёжку, подписывает её уполномоченный человек своей электронной подписью или подтверждением в приложении. Самый безопасный вариант и стандарт для малого бизнеса.
• Отправка с подписью из системы. Платёж подписывается и уходит без захода в интернет-банк. Удобно для массовых регулярных выплат, но требует жёстких лимитов, отдельного технического пользователя и аудита — иначе ошибка в системе превращается в ошибку в деньгах.

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

API, 1С:ДиректБанк или H2H: что выбрать

Связать учёт с банком можно тремя способами, и путают их постоянно.

• Выгрузка файла (клиент-банк). Бухгалтер выгружает из 1С файл с платёжками и загружает его в интернет-банк, выписку — обратно. Бесплатно и работает везде, но это всё ещё ручная операция, и файлы легко загрузить дважды.
• 1С:ДиректБанк. Готовый прямой обмен 1С с банком: платёжки отправляются из 1С кнопкой, выписка приходит сама. Ничего программировать не нужно, но работает только из 1С и только с банками, которые поддерживают эту технологию.
• API банка. Универсальный интерфейс для любой системы: сервиса обработки счетов, CRM, собственного кабинета. Нужна интеграция, зато платёж можно создавать там, где счёт реально обрабатывается, а не только в учётной базе.
• H2H (host-to-host). Прямой канал между сервером компании и банком, обычно с потоковым обменом и отдельным договором. Это решение для крупного бизнеса с тысячами платежей, малому бизнесу оно, как правило, избыточно.

Практическое правило: если счета живут в 1С от начала до конца, начните с ДиректБанка. Если счета принимаются, распознаются и согласуются в отдельном сервисе, а 1С получает уже итог, — нужен API, иначе в цепочке останется ручной перенос. О том, как выстроить сам обмен с учётной системой, мы подробно писали в материале про выгрузку счетов в 1С.

Что нужно, чтобы подключить API банка

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

• Расчётный счёт в банке с открытым API. Уточните, какие методы доступны на вашем тарифе: создание платёжек, выписки, статусы, вебхуки о поступлениях.
• Выпуск доступа. Обычно это делается в интернет-банке: создаётся приложение или токен, выбираются права и счета. У части банков дополнительно нужен сертификат или регистрация IP-адреса сервера.
• Песочница. Тестовая среда банка, где можно отправлять запросы без реальных денег. Без прогона в ней в бой не выходят.
• Справочник контрагентов в порядке. API честно отправит платёж по тем реквизитам, которые ему дали. Дубли и устаревшие счета в справочнике станут ошибочными платежами.
• Назначенный ответственный. Кто выпускает и отзывает доступы, кто подписывает, кто разбирает ошибки, если платёж отклонён банком.

Как защитить деньги при оплате через API

Интеграция с банком — это доступ к деньгам компании, и проектировать её нужно с этой мыслью. Минимальный набор мер:

• Минимальные права. Сервису обработки счетов достаточно читать выписки и создавать черновики. Право подписи ему не нужно.
• Отдельная проверка новых реквизитов. Подмена расчётного счёта в письме «от поставщика» — самый распространённый сценарий мошенничества с оплатой счетов. Если реквизиты получателя изменились, платёж не должен уходить в банк без отдельного подтверждения человеком.
• Защита от двойной оплаты. Один и тот же счёт не должен порождать две платёжки — даже если его загрузили дважды. Как ловить такие случаи до оплаты, мы разбирали в статье о том, какие ошибки в счетах ловятся автоматически.
• Хранение токенов на сервере. Ключи доступа к банку не должны лежать в браузере, таблице или общей папке. Срок жизни токена — ограниченный, отзыв — в один клик.
• Журнал действий. Кто создал платёжку, кто изменил сумму, кто подписал — с датой и временем. Это нужно и для разбора ошибок, и для аудиторов.
• Лимиты. Суточный лимит на платежи через API и отдельный порог суммы, выше которого нужен второй согласующий.

Сверка: как оплаченный счёт закрывается сам

Половина пользы от API — не в отправке, а в обратном потоке. Когда система регулярно забирает выписку, она может сопоставить списание с исходным счётом и закрыть его без участия бухгалтера. Сопоставление идёт по идентификатору платёжки, а если платёж ушёл мимо системы — по сумме, ИНН получателя и номеру счёта в назначении.

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

Какие ошибки чаще всего ломают оплату через API

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

• Нет обработки отказов. Банк вернул ошибку — неверный БИК, закрытый счёт получателя, нехватка средств, — а система молча считает платёж отправленным. Каждый ответ банка должен менять статус счёта, а отказ — попадать к человеку с понятной причиной.
• Повторная отправка при обрыве связи. Запрос ушёл, ответ не пришёл, система отправила его ещё раз — и в банке два черновика. Защищаются уникальным идентификатором платежа: повторный запрос с тем же идентификатором банк или сама система не должны превращать в новую платёжку.
• Истёкший токен. Доступ выдан на ограниченный срок, через несколько месяцев он перестаёт работать, и платежи тихо останавливаются. Нужен мониторинг и напоминание ответственному заранее.
• Назначение платежа «как получится». Без номера и даты счёта по шаблону сверка не сможет закрыть оплату автоматически, и бухгалтер снова будет сопоставлять выписку руками.
• Изменения в API банка. Банки обновляют методы и форматы, старые версии со временем отключают. Интеграцию, которую никто не сопровождает, рано или поздно придётся чинить в спешке.

Все пять пунктов закрываются на этапе проектирования и тестов в песочнице — переделывать их после запуска дороже.

Сколько стоит интеграция с банком

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

• Готовый коннектор в сервисе. Вы выбираете банк в настройках, выдаёте доступ — и всё. Стоимость входит в подписку, запуск занимает день-два. Ограничение — только поддерживаемые банки и стандартный сценарий.
• Доработка вокруг готового решения. Нужен свой маршрут согласования, отдельные правила лимитов или выгрузка в нестандартную конфигурацию 1С. Обычно это несколько недель работы.
• Собственный интеграционный шлюз. Несколько банков, единый формат платежей и выписок, связка с CRM, кабинетом поставщика и учётом. Это уже отдельный проект с архитектурой, тестами в песочницах всех банков и документацией. Оправдан, когда платежей много или финансовый процесс — часть продукта компании.

Как запустить оплату через API без риска: план на месяц

• Неделя 1. Опишите текущий путь счёта от получения до выписки и отметьте, где данные вводятся вручную. Почистите справочник контрагентов.
• Неделя 2. Выпустите тестовый доступ, прогоните в песочнице создание черновика, получение выписки и обработку ошибок — например, неверный БИК или нехватку средств.
• Неделя 3. Включите боевой режим только на черновиках и только для 5–10 постоянных поставщиков. Руководитель подписывает пачкой, бухгалтер сверяет результат с прежним процессом.
• Неделя 4. Подключите автоматическую сверку по выписке, расширьте круг поставщиков, зафиксируйте лимиты и правила для новых реквизитов.

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

Частые вопросы

Может ли система оплатить счёт через API без участия человека? Технически у части банков это возможно, но для малого бизнеса так делать не стоит. Безопаснее, когда система создаёт черновик, а руководитель подписывает его в интернет-банке или приложении. Автоматическую отправку разумно оставлять только для регулярных платежей с жёстким лимитом.

Чем API банка отличается от 1С:ДиректБанк? ДиректБанк — готовый обмен между 1С и банком без программирования. API — универсальный интерфейс для любой системы: сервиса обработки счетов, CRM, собственного кабинета. Если вся работа идёт в 1С, часто хватает ДиректБанка; если счета обрабатываются вне 1С, нужен API.

Сколько стоит подключить API банка? Сам доступ чаще всего бесплатный или входит в тариф. Платить приходится за интеграцию: готовый коннектор входит в подписку сервиса, собственная разработка — от нескольких недель работы до отдельного проекта, если банков несколько.

Что делать, если у компании счета в двух-трёх банках? Нужен слой, который приводит разные API к единому виду: один формат платёжки на выходе и одна структура выписки на входе. Его берут в готовом сервисе-агрегаторе или делают своим интеграционным шлюзом.

Безопасно ли давать сервису доступ к банковскому счёту? Да, если права ограничены чтением выписок и созданием черновиков, без права подписи. Токены хранятся на сервере, доступ отзывается в интернет-банке в любой момент, а смена реквизитов получателя проверяется отдельно.