интернет эквайринг для приложения — Для быстрого запуска оплаты в приложении выбирайте платёжную страницу провайдера; для встроенного платёжного интерфейса — SDK. В обоих вариантах сервер бизнеса управляет заказом и подтверждает результат платежа. Кассу подключают отдельно от приёма денег, а для цифрового контента сначала определяют, разрешена ли внешняя оплата правилами магазина приложений.
До сравнения тарифов опишите четыре события: оформление заказа, получение денег, передачу товара или оказание услуги, возврат. Так вы определите, нужны ли предоплата, холдирование, регулярные списания и несколько кассовых документов.
При оплате заказа до доставки предусмотрите предоплату и окончательный расчёт с её зачётом, если для расчётов обязательна ККТ. Проверьте, как система обработает замену товара, изменение веса и возврат одной позиции.
Если итоговую сумму определяют после сборки, рассмотрите двухстадийную оплату: сначала банк резервирует деньги, затем продавец подтверждает списание. Запросите срок действия резерва, возможность списать меньшую сумму и порядок освобождения остатка. Резервирование денег не равно полученной оплате.
При оплате курьеру нужна отдельная кассовая схема. Пункт 5.6 статьи 1.2 54-ФЗ предусматривает применение ККТ вне места расчёта, в частности при разносной торговле и дистанционной продаже товаров; способы исполнения обязанности по передаче чека для таких случаев описаны в пункте 5.7. До запуска закрепите конкретный способ передачи чека покупателю и проверьте его на устройстве курьера.
Для платной записи выберите предоплату либо резервирование денег. В первом случае настройте получение денег, зачёт при оказании услуги и возврат при отмене; во втором — подтверждение списания или отмену резерва. Условия отмены покажите клиенту до оплаты.
Для доступа к видео, функциям приложения или электронной библиотеке сначала выберите допустимый платёжный механизм. Встроенные покупки магазина и внешний эквайринг — разные интеграции: наличие у провайдера SDK не означает, что магазин разрешает его использовать для любого товара.
Пример выбора: приложение из App Store продаёт пользователям в России месячный доступ к видеокурсу, который смотрят внутри приложения. Базовая ветка проектирования для такого цифрового доступа — встроенная покупка по разделу 3.1.1 App Review Guidelines. Внешний эквайринг не выбирают только потому, что он дешевле: сначала требуется установить применимое исключение или специальное разрешение для данного приложения и витрины. Если встроенная покупка недоступна, это само по себе не разрешает заменить её внешней формой.
Для аналогичного приложения в Google Play используйте правила Google Play о платежах: отдельно установите, применимы ли требования Play Billing и доступна ли программа альтернативного биллинга для выбранного рынка. Согласование с одной площадкой не переносится на другую.
Дата контрольной проверки для выпуска — 18.10.2026. Фактическая проверка редакций правил площадок на эту дату в рамках подготовки текста не выполнена, поэтому приведённый пример — проектная схема, а не подтверждение доступности платежей в указанном регионе. Перед релизом сохраните применимый пункт правил, дату проверки и основание выбора платёжного механизма.
Не смешивайте способы оплаты в техническом задании: карточный эквайринг, СБП и встроенные покупки имеют собственные статусы, возвраты и ограничения. Даже если их предлагает один провайдер, тестируйте каждый способ отдельно.
Отправьте кандидатам одинаковые вводные: вид деятельности, платформы приложения, средний чек, плановый оборот, долю возвратов и необходимость подписок. Сначала получите подтверждение подключения вашего бизнеса, затем сравнивайте функции и стоимость.
| Критерий | Что запросить | Как проверить | Когда критично |
|---|---|---|---|
| Интеграция | Платформы и версии SDK, платёжная страница, серверный API, тестовая среда | Оплатить тестовый заказ на целевых устройствах и восстановить его после закрытия приложения | Для любого приложения |
| Подтверждение платежа | Статусы, защита уведомлений, повторная доставка, запрос статуса через API | Смоделировать задержку и повтор события | При автоматической выдаче заказа или доступа |
| Холдирование | Срок резерва, списание меньшей суммы, отмена | Подтвердить часть суммы и проверить освобождение остатка | При сборке заказа и бронировании |
| Подписки | Токенизация, рекуррентные платежи, ограничения и отключение списаний | Проверить продление, отказ банка и отмену следующего списания | Для регулярных услуг и разрешённых внешних подписок |
| Возвраты | Полный и частичный возврат, сроки, ограничения, конечные статусы | Вернуть одну позицию и сверить доступный остаток | Для доставки, торговли и услуг |
| Фискализация | Совместимые кассы, позиции заказа, предоплата, зачёт, возврат, статусы чеков | Сопоставить заказ, платёж и кассовые документы | Когда обязательна ККТ |
| Полная стоимость | Комиссии, фиксированные платежи, условия возврата комиссии, расходы на ККТ, ФН и ОФД | Рассчитать расходы на своей структуре платежей | При сравнении предложений |
| Зачисления и поддержка | График перечислений, удержания, порядок споров и эскалации | Получить условия договора и контакт для платёжных инцидентов | Для контроля оборотных средств |
Считайте расходы по формуле: комиссии за операции плюс фиксированные платежи, фискализация и расходы при возвратах. Для каждого предложения отмечайте, включены ли касса, фискальный накопитель и ОФД: название тарифа этого не подтверждает.
Один из вариантов подключения разобран в материале о приёме платежей через ЮKassa. Используйте его как пример интеграции, а не как замену сравнению условий.
Рабочая цепочка: приложение → сервер бизнеса → платёжный провайдер → подтверждение статуса → исполнение заказа. Кассовые события запускаются в предусмотренный для соответствующего расчёта момент, а не после произвольной задержки.
Рассчитывайте сумму и состав заказа на сервере. Связывайте заказ с идентификатором платежа, проверяйте сумму, валюту и получателя. Секретные ключи не помещайте в приложение.
Проверяйте подлинность уведомлений способом из документации провайдера. Если достоверность события не установлена, запрашивайте статус через авторизованный API. Обрабатывайте повторные события идемпотентно: одно подтверждение не должно повторно выдавать заказ или создавать дубликат чека.
Для внешней страницы настройте deep link возврата и восстановление заказа после перезапуска приложения. Экран успеха сообщает пользователю результат интерфейса, но основанием для исполнения заказа служит подтверждённый сервером статус списания.
Эквайринг не заменяет онлайн-кассу. Для ИП и организаций, принимающих оплату от физических лиц за товары или услуги, исходная схема — применение ККТ, если закон не предусматривает освобождение для соответствующих расчётов. Оплата картой, через СБП или только через интернет сама по себе не освобождает от кассы.
Определить обязанность применять ККТ поможет материал «Онлайн-касса и 54-ФЗ: кому нужна ККТ и как запустить». После этого используйте руководство по выбору онлайн-кассы по 54-ФЗ.
Правовая основа — Федеральный закон № 54-ФЗ: статья 1.2 регулирует применение ККТ, статья 2 содержит особенности и исключения, статья 4.7 устанавливает требования к чеку. Профильные материалы, реестры и разъяснения собраны в разделе ФНС «Новый порядок применения контрольно-кассовой техники».
Назначьте ответственных за регистрацию и работу ККТ, фискальный накопитель, договор с ОФД, передачу товарных данных и отправку чека. В договоре с поставщиком решения зафиксируйте границы ответственности: кто поддерживает оборудование, кто исправляет данные заказа и кто разбирает неотправленные документы.
До интернет-оплаты получите телефон или электронную почту покупателя для направления электронного чека. Передавайте в кассу фактические наименования, количество, цены со скидками, суммы, применимые налоговые реквизиты и признаки расчёта. Строка «Оплата заказа» не заменяет состав покупки.
В базе храните отдельные статусы заказа, платежа и фискализации. Это позволяет найти расчёты без чека, не смешивая кассовую ошибку с банковским отказом. Очередь повторной отправки нужна для восстановления обработки, но не отменяет установленных законом обязанностей.
По вопросам кассовой части приложения можно обратиться в «Интернет Касса». Не считайте такое обращение подключением эквайринга или передачей ответственности за ККТ: поставщик кассы, исполнитель интеграции и состав обслуживания должны быть прямо указаны в предложении и договоре. Подтверждённых условий, позволяющих обещать в этой статье конкретный пакет работ бренда, нет.
Нет, эквайринг принимает оплату, а ККТ формирует фискальные документы. Если ваши расчёты требуют ККТ по 54-ФЗ, подключите кассу отдельно или в составе решения с согласованной фискализацией.
Да, используйте платёжную страницу провайдера. Для цифрового контента внешняя оплата должна быть разрешена правилами площадки для вашего товара и региона; серверная обработка результата нужна и без SDK.
Да, если провайдер поддерживает рекуррентные платежи и пользователь согласился на регулярные списания. Для цифровой подписки в приложении внешний платёж также должен быть разрешён правилами магазина для выбранного товара и региона. Зафиксируйте сумму или порядок её определения, периодичность и отмену, затем настройте необходимые чеки.
Да, если правила магазина разрешают внешний платёж для вашего товара и региона. Если площадка требует встроенных покупок и применимого исключения нет, используйте её платёжный механизм, а не внешний эквайринг.
Нет, сам возврат в приложение не подтверждает оплату. Основанием для выдачи служит серверное подтверждение списания; статус резервирования при двухстадийной оплате его не заменяет.
Нужно определить границы кассовой интеграции? Направьте запрос в «Интернет Касса»: укажите товар или услугу, платформы приложения, провайдера платежей, момент списания и исполнения заказа. Попросите в ответе подтвердить, какую часть кассовой схемы сервис готов обеспечить, какие данные потребуются от разработчика и какие работы войдут в предложение. Такой запрос не предполагает обещания сроков, тарифа или состава подключения до согласования.