Платежи: 7 типов оплаты, выписки 8 банков, 6 онлайн-шлюзов
Платёж в AIERP — единая запись для любых оплат сети: 7 типов (наличные, карта, онлайн, безнал, кредит, рассрочка, сертификат), 5 статусов (ожидание → успех или ошибка → возврат или отмена), частичные возвраты с прослеживаемой историей и контролем остатка к возврату, прямая связь с исходным документом (заказ, акт и так далее). Поверх — карточка расчётного счёта с защищённым хранением банковских токенов, поддержкой восьми банков (Сбербанк, Тинькофф, Альфа-Банк, Модульбанк, ВТБ, Райффайзенбанк, Открытие, Газпромбанк) и любого другого банка через свой формат, расписанием импорта от ручного до еженедельного. Excel-выписки разбираются автоматически по готовым шаблонам — Сбербанк (формат «Рублёвый счёт»), Тинькофф, Альфа, универсальный. Онлайн-эквайринг — 6 шлюзов в одном интерфейсе: PayMaster, Робокасса, ЮKassa, CloudPayments, Тинькофф, Сбербанк (плюс свой при необходимости).
Что получает бизнес от модуля
7 типов оплаты и 5 статусов
Семь типов: наличные, картой, онлайн, безнал, кредит, рассрочка, сертификат. Пять статусов: ожидание, успешно, ошибка, отменено, возврат. Чек можно отправить клиенту в бумажном или электронном виде. На одном чеке допустима комбинация — например, карта 70% и бонусы 30%, каждая часть пишется в свою запись платежа.
Частичные возвраты с историей
Возврат — это отдельная запись, связанная с исходным платежом. Видны все возвраты по исходному платежу, контролируется остаток к возврату — нельзя вернуть больше, чем было оплачено. Запрещено возвращать возврат. Когда остаток к возврату по платежу обнуляется, исходная запись помечается как полностью возвращённая.
Защищённое хранение банковских токенов
Токены и ключи доступа к банкам и платёжным шлюзам хранятся в базе данных в зашифрованном виде. Расшифровка происходит на лету, в логи попадают только маскированные значения. Если ключ системы был сменён и расшифровать токен невозможно — система не падает, а спокойно показывает «требуется ввести токен заново». Даже при утечке базы токены банков остаются нечитаемыми.
Разбор Excel-выписок по шаблону
Импорт банковской выписки в Excel — автоматический. Шаблон задаёт: как отличить транзакции от итоговых строк, сколько строк-заголовков и итогов пропустить, как сопоставить колонки с полями (дата, сумма, описание, ИНН и КПП контрагента). Тип операции (приход или расход) определяется по знаку суммы или по колонкам «дебет / кредит». В комплекте — готовые шаблоны для Сбербанка (формат «Рублёвый счёт»), Тинькофф, Альфы и универсальный. Свой формат настраивается под клиента.
8 банков плюс свой формат
Из коробки настроены подключения: Сбербанк, Тинькофф, Альфа-Банк, Модульбанк, ВТБ, Райффайзенбанк, Открытие, Газпромбанк. Для любого другого банка можно настроить собственный шаблон разбора выписки. У каждого банка свои особенности — система их учитывает: например, шаблон Сбербанка читает все 70+ колонок «Рублёвого счёта», Тинькофф и Альфа — более простые форматы.
Расписание импорта на выбор
Импорт выписок настраивается по расписанию: вручную, каждый час, ежедневно или еженедельно. По выбранному расписанию запускается фоновая задача. На карточке расчётного счёта — журнал импортов: время последнего запуска, статус (успех, ошибка, в процессе), сообщение и количество загруженных операций. По каждому запуску видна длительность в читаемом формате — «3 мин 24 с».
6 онлайн-шлюзов в одном интерфейсе
Поддерживаются PayMaster, Робокасса, ЮKassa, CloudPayments, Тинькофф Эквайринг, Сбербанк Эквайринг — плюс возможность подключить свой. Все шлюзы работают через единый интерфейс: создание платежа, проверка статуса, приём callback от шлюза, проверка подписи, возврат. Подключение нового шлюза — несколько дней работы, без переписывания основной логики.
Создание ссылки на оплату и callback
Сервис онлайн-оплаты создаёт платёж в выбранном шлюзе: проверяет остаток к оплате по заказу, подбирает нужный шлюз (явно или автоматически), формирует ссылку на оплату и сохраняет платёж в статусе «ожидание». Клиент переходит по ссылке, шлюз присылает callback с результатом, система проверяет подпись и обновляет статус платежа.
Автофискализация по типу платежа и шлюзу
Для каждой пары «магазин + способ оплаты» вы выбираете, фискализировать ли платёж автоматически. Можно настроить отдельно по каждому онлайн-шлюзу: например, у магазина три шлюза — ЮKassa печатает чек автоматически, CloudPayments требует ручного подтверждения. Если нужно фискализировать платёж принудительно, есть отдельная пометка «принудительный чек».
Что входит в Платежи
- 01
Карточка платежа — всё в одном месте
Каждый платёж хранит: уникальный номер, связь с возвратами, ссылку на исходный документ (заказ или другое), юрлицо, магазин, кассира, тип и статус, ссылку на оплату для онлайн, идентификатор в шлюзе, тип шлюза, ссылку и реквизиты документа, смену кассы, сумму, фактически принятую сумму (может отличаться, если приняли меньше), описание, фискальные реквизиты для чека, переключатели «принята», «отменена», «принудительный чек», тип чека (бумажный или электронный), почту клиента. Удаление мягкое.
- 02
Дерево возвратов по платежу
У одного исходного платежа может быть несколько частичных возвратов — все связаны с родителем. На карточке платежа видно дерево: «исходный → возврат 1 с датой и суммой → возврат 2». Возврат возврата запрещён, отличить возврат от исходного платежа можно по отрицательной фактической сумме. По всем возвратам считается общая сумма «уже возвращено».
- 03
Контроль остатка к возврату
Остаток к возврату по платежу считается автоматически: фактически принято минус сумма всех уже сделанных возвратов. Если в карточке остаток нулевой — платёж помечается как полностью возвращённый. При попытке создать ещё один возврат на сумму больше остатка операция отклоняется — кассир не сможет вернуть больше, чем приходило.
- 04
Возврат через тот же канал
Сервис возврата проверяет, что возврат вообще возможен (платёж принят, не отменён, не возврат возврата, есть остаток). Сумма не должна превышать остаток к возврату. Если платёж был через онлайн-шлюз, по умолчанию возврат уходит обратно через тот же шлюз. Создаётся отдельная запись возврата, связанная с исходным, и при необходимости — связь с товарным возвратом.
- 05
Принята, отменена, принудительный чек
Три отдельные пометки. «Принята» — кассир подтвердил оплату. «Отменена» — после принятия можно отменить до закрытия смены. «Принудительный чек» — фискализировать обязательно, даже если для этого способа оплаты автофискализация отключена. Вместе со статусом дают полный жизненный цикл платежа.
- 06
Фискальные реквизиты в карточке
После успешной фискализации в карточку платежа подтягиваются: номер фискального документа, фискальный признак, расширенный фискальный признак и QR-код чека. Также — тип чека (бумажный или электронный), почта клиента, отметка «чек отправлен». Каждый платёж связан с одним фискальным чеком, возврат генерирует чек «возврат прихода».
- 07
Карточка расчётного счёта
У организации может быть несколько счетов. По каждому хранится: банк, номер счёта, БИК, корреспондентский счёт, активен ли счёт, тип подключения к банку, URL и токены доступа (зашифрованы), конфигурация подключения, шаблон разбора Excel-выписки под клиентский формат, признак автоматического импорта и расписание. Тут же — журнал последних запусков с временем, статусом и количеством загруженных операций.
- 08
Маскирование номера счёта
Номер расчётного счёта показывается в маскированном виде «40702****1234» — первые четыре и последние четыре цифры, остальное скрыто. Так номер не утечёт в логи целиком и не попадёт в кадр, если сотрудник фотографирует экран.
- 09
Готовность счёта к импорту
Карточка расчётного счёта подсвечивает свой статус: «готов» — активен, заполнены все нужные настройки и токены; «требует настройки» — не хватает ключевых полей; «отключён» — счёт деактивирован. Импорт запускается только для «готовых» счетов — не уйдёт в ошибку из-за полусобранной конфигурации.
- 10
Разбор Excel-выписки построчно
При импорте каждая строка проходит через шаблон: сначала определяется тип строки (заголовок, транзакция, итог), затем нужные колонки превращаются в поля операции (дата, сумма, описание, контрагент, ИНН, КПП), затем считается тип (приход или расход). Каждой операции присваивается стабильный идентификатор — повторный импорт того же файла не даст повторов. Ошибки разбора отдельной строки не валят весь импорт.
- 11
Готовые шаблоны для Сбербанка, Тинькофф, Альфы
Шаблоны лежат в конфигурации. Шаблон Сбербанка под формат «Рублёвый счёт» читает все нужные колонки: дату, дебет, кредит, назначение платежа, контрагента, ИНН и КПП. Шаблоны Тинькофф и Альфы — упрощённые форматы. Универсальный шаблон — основа для настройки под любой банк, у которого свой нестандартный формат выгрузки.
- 12
Фоновый импорт с уведомлением
Импорт выписки — фоновая задача: запускается, читает файл, превращает строки в кандидаты финансовых операций, проверяет повторы и сохраняет результат. По завершении пользователь получает уведомление с итогами: загружено / пропущено / в ошибке. На большие выписки импорт можно ставить в очередь и продолжать работу.
- 13
Журнал импортов
По каждому расчётному счёту хранится история запусков: время старта и финиша, статус (успех, ошибка, в процессе), количество загруженных операций, сообщение об ошибке (если была). На карточке счёта журнал отображается таблицей с длительностью в читаемом формате — «3 мин 24 с». Видно, когда последний раз тянули выписку и что именно пришло.
- 14
Карточка платёжного шлюза
По каждому шлюзу хранится: юрлицо, тип шлюза, название, статус активности, переключатель тестового режима, разрешение на ручное связывание платежей с заказами, идентификатор магазина в шлюзе, ключи доступа (зашифрованы), адреса успешного и неудачного возврата, конфигурация шлюза, процент комиссии, счётчики (всего платежей, общая сумма, время последнего платежа, состояние последней синхронизации). Деактивированный шлюз не удаляется физически — история сохраняется.
- 15
Единый интерфейс для всех шлюзов
Любой подключаемый шлюз отвечает за один и тот же набор операций: настройка под конкретное юрлицо, создание платежа и выдача ссылки на оплату, проверка статуса, обработка callback от шлюза, проверка криптоподписи запроса, возврат (полный или частичный), имя для журналов, поддерживает ли шлюз возвраты в принципе. Это и позволяет подключить новый шлюз быстро — без переписывания основной логики.
- 16
Сверка с шлюзом и ручная привязка
На карточке шлюза доступны: запуск сверки за период (тянет операции из шлюза и сопоставляет с локальными платежами), просмотр результата последней сверки, ручная привязка платежа к заказу (когда автоматическая не сработала), проверка соединения со шлюзом, повторная проверка статуса конкретного платежа, ручное изменение локального статуса (при рассинхронизации с шлюзом), поиск заказа по поставщику.
- 17
Автофискализация по типу платежа и шлюзу
Для каждой пары «магазин + способ оплаты + юрлицо» вы выбираете, фискализировать ли платёж автоматически. У онлайн-оплат можно настроить отдельное правило для каждого шлюза — для одного магазина три шлюза могут вести себя по-разному. Если правила по шлюзу нет, берётся общее по способу оплаты. Если автофискализация включена и платёж успешный — чек уйдёт автоматически.
- 18
Список платежей и страница возврата клиента
В системе — экран со списком платежей и фильтрами по периоду, магазину, юрлицу, типу, статусу, шлюзу. Карточка платежа открывается из списка. Для онлайн-оплат настроены адреса успешного и неудачного возврата клиента — после оплаты он видит понятную страницу подтверждения, без технических деталей. Поддерживаются callback от шлюзов через публичные адреса для каждого типа.
Как это выглядит в системе
Частые вопросы
Какие типы оплаты поддерживаются?
Семь: наличные, картой, онлайн (через эквайринг-шлюз), безнал (расчётный счёт), кредит, рассрочка, сертификат. На одном чеке допустима комбинация — например, карта 70% и бонусы 30%. Каждая часть пишется в свою запись платежа, в фискальном чеке разносится по соответствующим полям.
Какие статусы платежа?
Пять: ожидание (ждём ответа от шлюза), успешно, ошибка, отменено, возврат. Обычный жизненный цикл: ожидание → успешно → при необходимости возврат. Ошибка и отмена — конечные статусы для неудачных платежей.
Как устроен частичный возврат?
Возврат создаётся как отдельная запись, связанная с исходным платежом, с отрицательной фактической суммой. Перед созданием проверяется: исходный платёж принят, не отменён, это не возврат возврата, есть остаток к возврату. Остаток считается как фактически принятая сумма минус все ранее сделанные возвраты — с защитой от отрицательного значения.
Можно ли возвращать частями?
Да. У одной исходной оплаты может быть несколько возвратов. Например, заказ на 10 000 ₽ оплачен картой, потом возврат 3 000 ₽, потом ещё 2 000 ₽, потом 5 000 ₽. После каждого остаток к возврату уменьшается. Когда остаток обнулится, платёж помечается как полностью возвращённый. Возврат возврата запрещён системно.
Какие банки можно подключить для импорта выписок?
Восемь готовых: Сбербанк, Тинькофф, Альфа-Банк, Модульбанк, ВТБ, Райффайзенбанк, Открытие, Газпромбанк — с готовыми шаблонами разбора выписок (Сбербанк, Тинькофф, Альфа, универсальный). Плюс «свой» — для любого другого банка можно настроить собственный шаблон разбора Excel-выписки под нестандартный формат.
Как импортируется банковская выписка?
На карточке расчётного счёта хранятся URL и токены доступа к банку (зашифрованы), расписание импорта (вручную, каждый час, ежедневно или еженедельно) и шаблон разбора. По расписанию запускается фоновая задача, которая читает файл, превращает строки в кандидаты финансовых операций. Каждой операции присваивается стабильный идентификатор — повторный импорт того же файла не даёт повторов.
Что задаётся в шаблоне разбора Excel?
Три блока. Как отличить транзакции от итоговых строк (по пустым или заполненным колонкам). Сколько строк-заголовков и итогов пропустить сверху и снизу. Как сопоставить колонки с полями: для каждого поля указывается номер колонки, тип данных (дата, число, строка), формат (например, дата как Excel-число), обязательность. Тип операции (приход или расход) считается автоматически по знаку суммы или по колонкам «дебет / кредит».
Что в шаблоне для Сбербанка?
Шаблон Сбербанка под формат «Рублёвый счёт» пропускает строку заголовка и сопоставляет 9 полей: дата (Excel-число), дебет, кредит, назначение платежа, контрагент, ИНН и КПП контрагента. Итоговые строки распознаются по пустой колонке-маркеру. Шаблон работает «из коробки» — выгрузка из интернет-банка Сбербанка попадает в систему без ручной настройки.
Защищены ли токены в базе данных?
Да. Все банковские токены и ключи доступа к шлюзам хранятся в зашифрованном виде. Шифрование и расшифровка происходят прозрачно для пользователя. Если расшифровать токен невозможно (например, после смены ключа системы) — система не падает, а пишет в журнал ошибок и спокойно показывает «требуется ввести токен заново». Даже при утечке базы данных токены банков остаются нечитаемыми без ключа системы.
Какие онлайн-шлюзы интегрированы?
Шесть: PayMaster, Робокасса, ЮKassa (бывшая Яндекс.Касса), CloudPayments, Тинькофф Эквайринг, Сбербанк Эквайринг — плюс «свой» при необходимости. Все работают через единый интерфейс. На сегодня в системе реализованы прямые интеграции с PayMaster и ЮKassa, остальные доступны через адаптеры под тот же контракт и подключаются под клиента за несколько дней.
Как создаётся ссылка на оплату?
Сервис онлайн-оплаты принимает заказ, сумму и шлюз. Шаги: проверка заказа и юрлица, проверка, что сумма больше нуля и не превышает остаток к оплате по заказу, подбор шлюза (явно или автоматически из настроек юрлица), создание платежа в шлюзе с передачей суммы, описания, контактов клиента. Сохраняется запись платежа в статусе «ожидание» со ссылкой на оплату и идентификатором в шлюзе.
Что делать с callback от шлюза?
Шлюз вызывает специальный публичный адрес. Сервис проверяет криптоподпись запроса, находит заказ и обновляет статус платежа. Если оплата успешна — ставится отметка «принято». Если шлюз сообщает о возврате — создаётся связанная запись возврата. Если у платежа стояла пометка «принудительный чек» — запускается фискализация.
Что такое ручная привязка платежа?
Отдельная пометка на платёжном шлюзе. Если включена — на карточке шлюза появляется кнопка «связать платёж вручную». Полезно для случаев, когда автоматическая привязка не сработала (например, клиент указал неверный номер заказа в назначении платежа). Если выключена — связь только автоматическая.
Поддерживается ли тестовый режим шлюза?
Да. У каждого подключения есть переключатель «тестовый режим». В списках можно отфильтровать только продакшен-шлюзы. Тестовое подключение в названии показывается с пометкой «(Тест)» — кассир видит сразу, что это не боевая касса. В тестовом режиме реальные деньги не списываются — удобно для отладки интеграции.
Как сверяются эквайринговые операции?
На карточке шлюза есть запуск сверки за период — тянет операции из шлюза и сопоставляет с локальными платежами по идентификатору, помечает расхождения. Хранится журнал последних синхронизаций: время, статус, сообщение, список платежей, общее количество. На экране аналитики финансов есть срез «по способу оплаты» — онлайн-выручка с разбивкой по шлюзам.
Где задаются способы оплаты на магазине?
В отдельном справочнике «способы оплаты на магазине». Для пары «магазин + юрлицо + способ оплаты» — одна или несколько записей. Для онлайн-оплат — несколько, по одной на каждый шлюз. По каждой записи задаются: название способа (наличные / банковской картой / онлайн / безнал / кредит / рассрочка), код терминала, комиссия, активность, автофискализация, привязка к конкретному платёжному шлюзу.
Как работает автофискализация?
Для каждого способа оплаты на магазине вы выбираете, фискализировать ли его автоматически. Для онлайн-оплат настройка делается отдельно по каждому шлюзу. Когда платёж переходит в успешный статус и автофискализация включена — чек уходит автоматически. Если правила для конкретного шлюза нет, берётся общее правило по способу оплаты.
Есть ли поддержка СБП?
Прямой интеграции с НСПК Платформа СБП в этом релизе нет — это отдельная разработка. Платёж через Систему быстрых платежей можно провести как онлайн-оплату через шлюз, который сам поддерживает СБП внутри (например, ЮKassa), либо как безнал с последующим импортом из выписки.
Поддерживаются ли отчёты маркетплейсов?
Через импорт выписок с расчётных счетов — да, любые зачисления от Ozon, Wildberries и других маркетплейсов попадают в систему как обычные банковские операции. Прямой интеграции с API маркетплейсов (с отдельным учётом удержаний за рекламу, логистику и комиссии) в финансовом модуле нет — отчёты маркетплейсов разносятся вручную или через универсальный Excel-импорт.
Где видно, кто и когда менял платёж?
У каждого платежа фиксируются: время создания и изменения, автор. Изменения статуса пишутся в отдельный журнал. Полный аудит изменений (кто, что, когда поправил) настраивается через ролевую модель — подробнее на странице «Роли и права».
Что меняется на реальной сети
- Было
- Сверка эквайринга велась вручную: финансист выгружал отчёт банка, открывал список платежей, искал расхождения. Найти «потерянную» транзакцию (когда чек прошёл, а в банке нет) занимало 1–2 дня.
- Сделали
- Включили ежедневную сверку с каждым шлюзом. Сервис тянет операции из шлюза, сопоставляет с локальными платежами и помечает расхождения. Счётчик в шапке системы показывает, сколько ждёт разбора.
- Стало
- Расхождения подсвечиваются на следующий день. Финансист видит, сколько нужно разобрать, открывает каждый случай через повторную проверку статуса или ручную привязку.
- Было
- Банковские выписки скачивались бухгалтером вручную из 4 банков (Сбер, Тинькофф, Альфа, Модульбанк), парсились в Excel формулами. Любое изменение формата выписки ломало разбор.
- Сделали
- Подключили расчётный счёт для каждого банка с автоимпортом каждый час. Используем готовые шаблоны для Сбербанка, Тинькофф и Альфы. Для Модульбанка настроили собственный шаблон разбора на основе универсального.
- Стало
- Выписки приходят ежечасно автоматически. Журнал импортов показывает историю с длительностью и статусом. Финансист просто разносит загруженные операции по заказам — система подсказывает кандидатов по ИНН.
- Было
- Частичные возвраты вели в Excel — кассир сам считал, сколько осталось вернуть с конкретной карты. Случались ошибки: возвращали больше, чем приходил исходный платёж.
- Сделали
- Включили встроенный частичный возврат с историей. На карточке платежа кнопка «Вернуть» доступна только когда возврат вообще возможен, поле «Сумма» ограничено остатком к возврату. Системно превысить нельзя.
- Стало
- Кассиры не считают вручную, система не даёт ошибиться. Дерево возвратов прозрачно — «исходный → возврат 1 → возврат 2» с датами.
- Было
- Подключение нового онлайн-шлюза занимало 2–3 недели разработки. Каждый раз — свой код интеграции, свой формат callback, свои тесты.
- Сделали
- Использовали единый интерфейс для всех шлюзов. Добавили ЮKassa через адаптер: создание платежа, обработка callback, проверка подписи, возврат. Подключение нового шлюза сводится к реализации стандартного набора операций.
- Стало
- Новый шлюз подключается за 3–5 дней. Логика онлайн-оплаты и фискализации общая, не дублируется. Тестовый режим позволяет отлаживать без реальных денег.
- Было
- У одного магазина — три способа онлайн-оплаты (ЮKassa, CloudPayments, Сбер). Для каждого нужна своя автофискализация. Кассир-ассистент не знал, какой шлюз отметить как фискализированный, а какой нет.
- Сделали
- Завели правило для каждой пары «магазин + шлюз» со своим включателем автофискализации. Система при платеже ищет конкретное правило по шлюзу. Если для шлюза автофискализация выключена — чек не печатается автоматически.
- Стало
- Каждый шлюз ведёт себя предсказуемо. Кассир не выбирает руками, система знает: ЮKassa — авто-чек, CloudPayments — ручное подтверждение.
- Было
- Зашифрованные банковские токены терялись при смене сервера или копировании базы данных на тестовый стенд — пытались расшифровать с другим ключом системы, и приложение падало.
- Сделали
- Внедрили «безопасную расшифровку»: при невозможности расшифровать токен система пишет в журнал ошибок и спокойно возвращает пусто, приложение не падает. Админ видит в интерфейсе «требуется ввести токен заново», вводит — токены сохраняются с новым шифрованием.
- Стало
- Смена сервера или копирование базы на тестовый стенд не ломают приложение. Видно явно, что нужно ввести заново — без молчаливых ошибок.
Как модуль помогает розничной сети
Платежи розничной сети — единая модель для 7 типов
Платёж в AIERP — единая запись для всех каналов: кассы, эквайринга, онлайн-оплаты, безнала, кредитов, рассрочек и сертификатов. Семь типов оплаты (наличные, картой, онлайн, безнал, кредит, рассрочка, сертификат) дают полную палитру розничных платежей. На одном чеке допустима комбинация — карта 70% и бонусы 30%, кредит 50% и наличные 50%. Каждая часть пишется в свою запись с общей ссылкой на исходный документ, в фискальном чеке разносится по соответствующим полям (наличные, карта, предоплата, кредит).
Жизненный цикл проходит через пять статусов: ожидание (ждём ответа от шлюза), успешно (принято), ошибка (шлюз или банк отказали), отменено (отменили до закрытия смены), возврат (вернули клиенту). Три отдельные пометки дополняют картину: «принято» (кассир подтвердил), «отменено» (после принятия можно отменить до закрытия смены), «принудительный чек» (фискализировать обязательно, даже если автофискализация выключена). После успешной фискализации в карточку платежа подтягиваются фискальные реквизиты: номер фискального документа, фискальный признак, расширенный фискальный признак, QR-код чека.
Частичные возвраты с прослеживаемой историей
Возврат в AIERP — это отдельная запись, связанная с исходным платежом, с отрицательной фактической суммой. Это даёт древовидную структуру: один исходный платёж может иметь несколько возвратов, у каждого возврата есть ссылка на исходный. Перед созданием возврата проверяются четыре условия: исходный платёж принят, не отменён, это не возврат возврата, есть остаток к возврату.
Остаток к возврату считается автоматически: фактически принято минус сумма всех уже сделанных возвратов, с защитой от отрицательного значения. Когда остаток обнулится, исходный платёж помечается как полностью возвращённый. На карточке платежа видно дерево «исходный → возврат 1 (сумма X, дата Y) → возврат 2». Сервис возврата проверяет возможность возврата, валидирует сумму, при возврате через шлюз отправляет команду в шлюз, создаёт связанную запись возврата и обновляет статус исходного платежа.
Импорт банковских выписок: 8 банков и свой
Карточка расчётного счёта — это банк, на счёт которого приходят и с которого уходят деньги. Тип подключения выбирается из восьми готовых: Сбербанк, Тинькофф, Альфа-Банк, Модульбанк, ВТБ, Райффайзенбанк, Открытие, Газпромбанк — плюс «свой» для любого другого банка. У каждого банка свои особенности — система их учитывает. Токены и ключи доступа хранятся в зашифрованном виде, расшифровка происходит на лету. При невозможности расшифровать (например, после смены ключа системы) — система не падает, а спокойно показывает «требуется ввести токен заново».
Excel-выписки разбираются по шаблону. Готовые шаблоны для Сбербанка (формат «Рублёвый счёт»), Тинькофф, Альфы и универсальный — лежат в комплекте. Свой формат настраивается под клиента. Структура шаблона: как отличить транзакции от итоговых строк (по пустым или заполненным колонкам), сколько строк-заголовков и итогов пропустить, как сопоставить колонки с полями (дата, сумма, описание, контрагент, ИНН, КПП). Тип операции (приход или расход) считается по знаку суммы или по колонкам «дебет / кредит». Каждой операции присваивается стабильный идентификатор — повторный импорт того же файла не даёт повторов.
Расписание импорта и журнал запусков
Расписание импорта выбирается из четырёх вариантов: вручную, каждый час, ежедневно или еженедельно. По выбранному расписанию запускается фоновая задача: читает файл, превращает строки в кандидаты финансовых операций, проверяет повторы, по завершении отправляет пользователю уведомление с итогами.
По каждому расчётному счёту хранится журнал запусков: время старта и финиша, статус (успех, ошибка, в процессе), количество загруженных операций, сообщение об ошибке (если была). Длительность отображается в читаемом формате — «3 мин 24 с». На самой карточке счёта — быстрый снимок последнего запуска: время, статус, сообщение, число операций. Видно, когда последний раз тянули выписку и что именно пришло.
6 онлайн-шлюзов через единый интерфейс
Карточка платёжного шлюза — это подключение к эквайрингу или онлайн-оплате. Тип шлюза выбирается из шести: PayMaster, Робокасса, ЮKassa, CloudPayments, Тинькофф Эквайринг, Сбербанк Эквайринг — плюс «свой». Каждый шлюз отвечает за единый набор операций: настройка под юрлицо, создание платежа и выдача ссылки, проверка статуса, обработка callback, проверка криптоподписи, возврат (полный или частичный). На сегодня в системе реализованы прямые интеграции с PayMaster и ЮKassa — остальные подключаются через адаптеры под тот же контракт.
Сервис онлайн-оплаты — точка входа для создания ссылки на оплату. Проверяет остаток к оплате по заказу, подбирает нужный шлюз (явно или автоматически из настроек юрлица), создаёт платёж в шлюзе с передачей суммы, описания, контактов клиента. Возвращает идентификатор платежа, ссылку на оплату и внешний идентификатор в шлюзе. Клиент переходит по ссылке, шлюз вызывает callback с результатом, система проверяет подпись и обновляет статус.
Привязка способов оплаты к магазинам
Способы оплаты на магазине — отдельный справочник. Для каждой пары «магазин + юрлицо + способ оплаты» одна или несколько записей. Для онлайн-оплат записей несколько — по одной на каждый шлюз. По каждой записи задаётся: название способа (наличные / банковской картой / онлайн / безнал / кредит / рассрочка), код терминала, комиссия, активность, переключатель автофискализации.
Автофискализация — критичная настройка для розницы. Когда платёж становится успешным, система ищет правило по конкретному магазину, юрлицу, способу оплаты — и для онлайн-оплат уточняет по шлюзу. Если правило по шлюзу не найдено, берётся общее правило для способа оплаты. Если автофискализация включена — чек уходит автоматически. Это даёт разное поведение разных шлюзов на одном магазине: ЮKassa печатает чек автоматически, CloudPayments требует ручного подтверждения.
Безопасность: зашифрованные ключи, аудит
Все банковские и платёжные ключи доступа хранятся в базе данных зашифрованно. Шифрование и расшифровка происходят прозрачно для пользователя. При невозможности расшифровать (после смены ключа системы или переноса базы данных без ключа) — система пишет в журнал ошибок и спокойно показывает «требуется ввести токен заново». Приложение не падает, админ видит проблему явно.
Все операции с платежами пишутся в отдельный журнал. Полный аудит изменений (кто, что, когда, с какого IP) настраивается через ролевую модель из раздела «Роли и права». Подключения способов оплаты и платёжные шлюзы удаляются мягко — деактивированный шлюз не удаляется физически, история платежей через него остаётся целостной. Разрешение на ручную привязку платежа к заказу полезно для аномальных случаев — например, когда клиент указал неверный номер заказа в назначении платежа.
Готовы автоматизировать?
Покажем модуль на ваших данных и подключим за 1–2 недели.