Пациент дошёл до кнопки «Оплатить» в приложении клиники — и тут выбор способа приёма платежа решает, закончится ли запись оплаченным визитом или брошенной корзиной. В приложении клиники работают три модели оплаты: эквайринг по карте, СБП и платёжная ссылка или инвойс. Какую подключить — зависит от объёма онлайн-записи, регуляторики 54-ФЗ и 152-ФЗ и того, есть ли в клинике МИС, к которой нужно привязать чек. Ниже — архитектура выбора именно для мобильного приложения, а не для сайта или ресепшена: если вы проектируете разработку и поддержку мобильного приложения клиники, эти решения принимаются на этапе технического задания, а не после релиза.
Какие способы оплаты доступны в приложении клиники
В мобильном приложении клиники реально работают три сценария приёма денег, и у каждого своя техническая цена интеграции.
Оплата картой (эквайринг/SDK)
Классический эквайринг встраивается через mobile SDK банка или платёжного агрегатора: пациент вводит данные карты прямо в приложении, деньги списываются мгновенно. Это самый привычный пациенту способ, но SDK нужно поддерживать под iOS и Android отдельно, а часть банков ограничивает варианты 3-D Secure для мобильных экранов.
СБП (QR/кнопка/ссылка внутри приложения)
Система быстрых платежей встраивается как кнопка перехода в банковское приложение или как QR-код на экране счёта. Комиссия по СБП для бизнеса ниже эквайринга, а подключение не требует полноценного SDK — достаточно API платёжного провайдера, который генерирует ссылку или QR под конкретный счёт.
Платёжная ссылка и инвойс (для предоплаты/рассрочки)
Для депозитов и рассрочки удобнее не привязываться к моменту визита, а выставлять пациенту ссылку на оплату — по SMS, push-уведомлению или прямо в личном кабинете приложения. Ссылка не требует хранения платёжных данных на стороне клиники и подходит для сценариев, где сумма определяется не сразу (например, после консультации).
Банк-эквайринг или платёжный агрегатор — что подключить к приложению
Для мобильного приложения выбор чаще падает на агрегатора, а не на прямой банк-эквайринг — из-за готового SDK и единого API для карт и СБП.
| Параметр | Банк-эквайринг | Платёжный агрегатор |
|---|---|---|
| Скорость подключения | 2–4 недели, юрлицо + договор с банком | 1–5 дней, онлайн-регистрация |
| Готовый mobile SDK | не у всех банков | как правило есть под iOS/Android |
| Поддержка СБП | отдельный договор | обычно включена в тот же контракт |
| Тарифы | ниже при большом обороте | выше, но прозрачнее для старта |
Для клиники с одним филиалом и небольшим потоком онлайн-оплат агрегатор окупает разницу в тарифе скоростью запуска. Сеть клиник с оборотом от нескольких миллионов в месяц обычно выигрывает на прямом банк-эквайринге, но держит агрегатор как резервный канал для СБП.
Оплата ОМС и ДМС в приложении — в чём разница с коммерческим приёмом
По ОМС пациент в приложении ничего не платит: платёжный модуль вообще не должен показываться на этом сценарии записи, а факт визита передаётся в МИС и дальше в ЕГИСЗ без денежной транзакции. По ДМС приложение чаще всего тоже не принимает оплату напрямую — страховая компенсирует клинике по акту, поэтому в приложении отображается статус «покрыто страховой» вместо кнопки оплаты. Реальные деньги через платёжный модуль приложения проходят только при коммерческом приёме или при доплате сверх страхового лимита — и здесь важно, чтобы логика приложения различала эти три ветки ещё на этапе записи, а не в момент оплаты.
Нужен ли эквайринг, если пациенты и так платят на ресепшене?
Да, если хотя бы часть записей идёт через приложение без физического визита в кассу. Оплата на ресепшене работает, пока пациент физически приходит к администратору — но депозит за онлайн-запись, предоплату за телемедицинскую консультацию или рассрочку за курс процедур собрать оффлайн не получится. Приложение без встроенной оплаты теряет часть сценариев, ради которых его вообще делали: удалённую предоплату и снижение неявок за счёт депозита.
Как оплата в приложении стыкуется с МИС и 54-ФЗ
Технически связка выглядит так: приложение инициирует платёж через API провайдера → провайдер (или онлайн-касса на его стороне) формирует и пробивает фискальный чек по 54-ФЗ → статус оплаты возвращается в приложение и параллельно пишется в МИС как оплаченная услуга. Кто именно фискализирует чек — банк-эквайер, агрегатор или отдельная касса клиники — определяется договором с провайдером, и это первый вопрос, который стоит закрыть на этапе выбора решения, а не постфактум. Персональные данные пациента, которые обрабатываются в связке с платежом, подпадают под требования 152-ФЗ — подробный разбор специальных категорий и уровней защищённости есть в статье «152-ФЗ и медицинские данные: что нужно знать разработчику». Если приложение проектируется одновременно с общей архитектурой мобильных сервисов клиники, разумно сразу заложить и разработку мобильных приложений под единый API-слой, а не собирать платёжный модуль изолированно от остального продукта.
Безопасность платежей: PCI DSS и защита данных пациента
Приложение клиники не должно хранить номера карт и CVV — эта ответственность лежит на провайдере эквайринга, сертифицированном по PCI DSS. Правильная архитектура прокидывает пациента на защищённую форму ввода карты внутри SDK провайдера или на его hosted-страницу, а сама клиника видит только статус транзакции и токен для повторных списаний. Отдельно стоит проверить, что логи приложения не пишут в открытом виде параметры платежа и что антифрод-правила провайдера покрывают сценарий разовых крупных предоплат — они чаще попадают под ручную проверку банка.
Депозиты, предоплата и рассрочка — как настроить под медицинскую специфику
Депозит за онлайн-запись обычно составляет фиксированную сумму или процент от стоимости приёма и списывается автоматически при неявке — это условие нужно явно показать пациенту в приложении до подтверждения записи. Предоплата за курс процедур (например, физиотерапии) удобнее оформляется через платёжную ссылку с привязкой к абонементу в МИС, а не разовыми платежами. Рассрочку в медицинских услугах предоставляют через партнёрские сервисы рассрочки, интегрированные тем же API, что и обычная оплата картой — с точки зрения приложения это ещё один способ оплаты в том же списке, а не отдельный модуль.
Какой способ оплаты выбрать для приложения клиники?
Небольшой клинике с одним филиалом достаточно платёжного агрегатора с готовым SDK, поддержкой СБП и платёжных ссылок — это закрывает 90% сценариев без отдельного договора с банком. Сети клиник с высоким оборотом онлайн-оплат стоит держать прямой банк-эквайринг как основной канал и агрегатора как резерв для СБП и рассрочки. В обоих случаях стартовый набор одинаковый: карта через SDK, СБП и платёжная ссылка для депозитов — различается только то, кто именно эти способы обслуживает технически.
Чек-лист выбора провайдера для оплаты в приложении
- Есть готовый mobile SDK под iOS и Android, а не только веб-виджет.
- Поддержка СБП включена в тот же договор, что и карты.
- Тарифы на карты и СБП указаны раздельно, без «средней» ставки.
- Провайдер сертифицирован по PCI DSS и не передаёт данные карт на сторону клиники.
- Понятная скорость выплат клинике (T+1, T+3) и есть тестовая песочница для интеграции.
- Провайдер соответствует требованиям 115-ФЗ по комплаенсу и не блокирует медицинские MCC-коды.
- Есть готовый механизм привязки статуса оплаты к МИС через webhook или API.
Типичные ошибки при подключении оплаты в приложении клиники
- Хранение номеров карт или CVV на своей стороне «для удобства повторной оплаты» — прямое нарушение PCI DSS.
- Отсутствие разделения ОМС/ДМС/коммерция в логике оплаты — платёжный модуль пытается выставить счёт там, где пациент ничего не должен.
- Один провайдер без резервного канала — при технических работах на его стороне приложение вообще не может принять оплату.
- Фискальный чек формируется с задержкой в несколько дней вместо момента оплаты — риск по 54-ФЗ при проверке.
- Депозит списывается без явного согласия пациента, показанного на экране до подтверждения записи.
Частые вопросы
Можно ли принимать оплату по ОМС через приложение? Нет, по ОМС пациент не платит — приложение фиксирует визит и передаёт данные в МИС и ЕГИСЗ без денежной транзакции.
Нужна ли отдельная касса для оплаты в приложении? Отдельная физическая касса не нужна, если фискализацию берёт на себя провайдер эквайринга или его онлайн-касса по договору — это стандартная практика для мобильных платежей.
Что делать при возврате оплаты за отменённую запись? Возврат оформляется через тот же провайдер, через который прошёл платёж, с формированием чека коррекции — логику возврата нужно предусмотреть в приложении заранее, а не достраивать по факту первого обращения.
Сколько стоит подключить эквайринг к приложению клиники? У агрегаторов подключение обычно бесплатное или символическое, комиссия берётся с оборота (около 2–3,5% в зависимости от способа оплаты); у банков может быть фиксированная плата за интеграцию SDK.
Обязательно ли поддерживать СБП, если уже есть эквайринг картой? Формально нет, но СБП снижает комиссию и упрощает оплату с телефона без ввода номера карты — для мобильного приложения это логичное дополнение, а не замена.
