💳 Healthcare IT · Платежи · Эквайринг · Реконсиляция

Интеграция платёжных шлюзов

Приём членских взносов и других платежей в платформе медассоциации с надёжной архитектурой мульти-эквайринга и сверкой до копейки - часть медицинской IT-платформы.

Интеграция платёжных шлюзов - это единый платёжный слой ассоциации с мульти-эквайрингом, рекуррентными платежами, обработкой возвратов, идемпотентностью транзакций и ежедневной реконсиляцией с провайдерами и банковской выпиской. Финансовая операция должна сходиться до копейки, а не «приблизительно проходить» - платформа строится с этой нормой как с дизайн-требованием, а не операционной идеей.

🧭 Контекст

Почему платёжный слой - критическая инфраструктура ассоциации

Десятки тысяч членов платят взносы и оплачивают услуги - это сотни тысяч транзакций в год. Без надёжной интеграции платёжного слоя ассоциация либо теряет деньги на ошибках сверки, либо тонет в ручной разборке несоответствий. Финансы - не «примерно», каждый рубль должен быть проведён, отражён и доступен для аудита.

Поток платежей

Сотни тысяч транзакций в год - взносы, конференции, дополнительные услуги. Объём, который ручная обработка не выдерживает в принципе.

Мульти-эквайринг

Один провайдер недоступен - платежи переходят на резервного. Зависимость от единственного эквайера - критический риск для финансов ассоциации.

До копейки или никак

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

⚠️ Боль

Что обычно ломается в платёжной интеграции

⚠️

Двойные списания

Без идемпотентности дребезг кнопки «оплатить», повторные callback от провайдера, ретраи cron-задач приводят к двойному списанию. Возвращать деньги клиенту - дорогая и репутационно болезненная процедура.

🏦

Расхождения с банком

На сайте показано «оплачено», на счёт ассоциации не пришло. Бухгалтерия в конце месяца разбирает сотни таких кейсов вручную - пока система не сводит платформу с банковской выпиской автоматически.

💔

Провайдер упал - все ждут

Когда вся платёжная логика жёстко привязана к одному провайдеру, его недоступность означает остановку всех платежей. Член ассоциации не может оплатить взнос - техподдержка ничего не может сделать.

🔁

Рекуррент-катастрофа

Cron-задача отработала дважды или подвисла на половине списка - половине членов списано дважды, половине не списано вообще. Без идемпотентности и контроля статусов исправлять это руками - недели работы.

⚙️ Подход

Архитектура платёжного слоя

Платёжный слой - это абстракция «единого шлюза» над несколькими провайдерами с идемпотентностью на уровне БД, асинхронным workflow для рекуррентных списаний и реконсиляцией со всеми источниками истины каждый день.

1. Единый интерфейс шлюза

Ядро платформы общается с абстрактным шлюзом через стабильный контракт: создать платёж, проверить статус, оформить возврат. За интерфейсом - конкретные адаптеры провайдеров.

2. Идемпотентность

Каждый платёж имеет уникальный ключ операции. Повторные вызовы с тем же ключом дают один и тот же результат. БД защищает unique-constraint, приложение проверяет статус до отправки в провайдер.

3. Рекуррент через очереди

Списания по подписке формируются в очередь раз в день, воркер берёт записи пакетами с идемпотентными ключами и retry на временные ошибки.

4. Webhook + опрос статуса

Провайдеры отправляют callback при изменении статуса. Платформа принимает webhook, проверяет подпись, обновляет статус. Параллельно фоновый воркер опрашивает «зависшие» статусы, чтобы потеря callback не оставила транзакции в неопределённости.

5. Ежедневная реконсиляция

Каждое утро платформа забирает выгрузку от провайдеров и сравнивает с внутренней БД. Расхождения попадают в очередь администратора. Параллельно - сверка с банковской выпиской.

6. Отчёты для бухгалтерии

Реестры платежей и возвратов, отчёты по комиссиям провайдеров, спорным операциям, прогноз поступлений, выгрузки в формате 1С/SAP. Бухгалтерия не перенабивает данные.

📊 Доказательство в production

Как это работает на десятках тысяч плательщиков

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

40K+

Плательщиков членских взносов

Мульти-эквайринг

Отказоустойчивость через несколько провайдеров с автоматическим failover

19 лет

Непрерывной эксплуатации модуля без переписывания

Открыть раздел кейсов

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

Частые вопросы о платёжных шлюзах

Какие платёжные сценарии поддерживает платформа?

Разовые платежи (ежегодный взнос, конференция, доп-услуги), рекуррентные (автосписание взноса в годовщину), распределённые (один платёж по нескольким проводкам: общий взнос, региональный, секционный), возвраты (пропорциональный при выходе из ассоциации, полный при отказе от рекуррента в окне). Все связаны с модулем членства и взносов.

Какие платёжные провайдеры интегрируются?

Архитектура спроектирована под мульти-эквайринг: одновременно работают несколько провайдеров, выбор для конкретного платежа зависит от страны, типа карты, доступности. Типичный набор: эквайринг крупных банков, СБП, Apple Pay/Google Pay через эквайера, международные провайдеры для зарубежных членов. Добавление нового провайдера - отдельный модуль через единый интерфейс шлюза.

Как обеспечивается идемпотентность платежей?

Каждый платёж имеет идемпотентный ключ (уникальный идентификатор операции). Если пользователь дважды нажал «оплатить», или браузер потерял соединение и повторил запрос, или провайдер прислал двойной callback - система выполнит ровно одну транзакцию. Реализовано на уровне БД через unique-constraints и на уровне приложения через проверки до отправки в провайдер.

Как проводятся возвраты средств?

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

Как сверяются данные платформы с банковской выпиской?

Ежедневно платформа получает выгрузки от провайдеров с детализацией всех транзакций. Модуль реконсиляции сопоставляет каждую запись с внутренней БД. Расхождения попадают в очередь администратора: «провайдер показал платёж, у нас нет», «у нас есть платёж, провайдер не подтвердил». Сверка с банковской выпиской - поверх сверки с провайдером: что упало на счёт ассоциации, действительно ли соответствует комиссионным расчётам.

Какие отчёты доступны бухгалтерии?

Стандартный комплект: реестр платежей за период с разбивкой по типам и плательщикам, реестр возвратов, отчёт по комиссиям провайдеров, по нераспределённым и спорным платежам, помесячная динамика поступлений, прогноз поступлений. Выгрузки в форматы 1С/SAP, чтобы бухгалтерия загрузила проводки в учётную систему без ручного перенабора.

🔗 Связанные направления

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

💳

Членство и взносы

Главный потребитель платёжного шлюза - модуль приёма годовых взносов с категориями членства и dunning-workflow.

Подробнее

🔒

Защита персональных данных

Платёжные данные - отдельная категория с особыми требованиями к хранению, маскированию и обработке.

Подробнее

🔑

SSO и ролевая модель

Кто из администраторов имеет право инициировать возвраты и видеть финансовые отчёты - через ролевую модель.

Подробнее

Нужен надёжный платёжный слой для вашей медорганизации?

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

Обсудить проект Обзор медицинских IT-платформ