Автоматизация зачисления безналичных платежей

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

• Webmoney Capitaller — 0,8% при переводе средств на расчетный счет черезАгентство Гарантий. Из-за крайне мутного назначения платежа «В счет оплаты покупки ценных бумаг по договору…» у банка могут возникать вопросы касательно источника данных средств, поэтому легальнее всего принимать Webmoney черезпроцессинг, когда Webmoney берет на себя функции агента по приему платежей. Для России это Paymaster и комиссия в таком случае составляет 2%, зато с ежедневными реестрами и легальным назначением платежа.
• Банковские карты (Интернет-эквайринг) — комиссия от 2% до 3%. В случаеТопвизор мы используем интернет-эквайринг от бана Тинькофф и комиссия для нас составляет 2,5%.
• Paypal — 3,9% + 10 руб.
• Яндекс.Деньги (Касса для бизнеса), QIWI и Robokassa — 5%.

Таким образом, получаем комиссию платежных систем от 2 до 5% против безналичного расчета — 0%. Вот почему крайне важной задачей было максимально упростить и автоматизировать процесс приема безналичных средств. Задачу разбили на несколько этапов:

1. Генерация счетов и договора (в случае необходимости).
2. Контроль поступления средств (не реже чем 1 раз в час).
3. Генерация закрывающих документов.

Генерация счетов

Необходимо запросить у клиента наименование и ИНН организации, № расчетного счета, БИК банка, юридический и почтовый адрес:

• Помимо номера БИК требуется наименование и корреспондентский счет банка, их можно автоматически получить через API Справочник БИК РФ.
• Почтовый адрес потребуется чтобы знать куда отправить оригиналы документов после поступления платежа.

Форма для ввода данных может быть такой:

Счет лучше всего генерировать в PDF формате. Мы изначально делали HTML вариант, но столкнулись с непониманием со стороны клиентов. Какой бы технологичной не была компания, но за обработку входящих счетов отвечают обычные бухгалтера (чаще всего на аутсорсе), поэтому им нужен привычный и удобный формат.

Утверждённой унифицированной формы Счёта на оплату товаров и услуг не существует. Форма может быть любая, на усмотрение компании. Пример нашего счета тут. Клиенту можно дать возможность сразу скачать счет, либо отправить его на электронную почту.Контроль поступления средств

Как оказалось самый сложный этап — банк с вменяемым api, обслуживающий юридических лиц удалось найти далеко не сразу. По теме удалось найти только обсуждения на banki.ru и ixbt.com, вопрос на toster.ru и обсуждение хотелки на сайте идей Альфа-Банка.

По результатам анализа всей этой информации нашелся только один банк с API — это СБ Банк, документация по интеграции тут https://www.sbank.ru/Page/Details/internetbank/bus...

С помощью функции GetLatestAdvices можно получать данные о платежах за текущий операционный день (мы делаем запрос 1 раз в час) и автоматически зачислять средства на баланс пользователя. Сверку за завершенный день целиком можно выполнить воспользовавшись функцией DownloadDailyDocumentsGetLatestAdvices мы можем увидеть не все платежи.

Идентифицировать платеж можно по ИНН, номеру счета или метке в назначении платежа.

Если API постоянно отдает ошибку и вы открывали офис не в Москве или Санкт-Петербурге, то скорее всего API не развернут для вашего региона, как это было у нас (мы стали первым клиентом, использующим api банка из Санкт-Петербурга). Этот вопрос можно решить со службой технической поддержи.

Чуть позже я узнал от менеджеров Альфа-Банка (когда закрывал счет) что у них тоже есть нечто подобное — канал интеграции 1С, но для его использования необходимо получить согласование.

Генерация закрывающих документов

При поступлении платежа на счет генерируем в PDF закрывающие бухгалтерские документы (в нашем случае это Акт выполненных услуг) и вместе с оригиналом счета отправляем на почтовый адрес клиента. Все.

Походов на почту при реализации 3-го пункта можно избежать вообще, если перейти на ЭДО (электронный документооборот). В России это вполне реально на основании 63-ФЗ «Об электронной подписи», Статья 6, пункт 1:

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

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

Оригинал моей статьи первоначально был размещен здесь http://habrahabr.ru/post/247979/