Как организовать прием платежей в России: юрлицо, счет, эквайринг, касса и договоры
Как организовать прием платежей в России: кто принимает деньги, расчетный счет, интернет-эквайринг, СБП, онлайн-касса, договоры и что передать разработчикам.
Прием онлайн-платежей — это не только подключение формы «Оплатить» на сайте. До интеграции с платежным сервисом бизнесу нужно определить, кто принимает деньги, на какой счет они поступают, каким способом клиент платит, как оформляется расчет и какие документы получает покупатель.
Для разных моделей бизнеса схема будет отличаться. Интернет-магазину, SaaS-сервису, онлайн-школе и B2B-платформе могут понадобиться разные способы оплаты, документы и технические интеграции.
В этой статье разберем, как организовать прием платежей в России с точки зрения бизнеса: от выбора формы деятельности и расчетного счета до эквайринга, СБП, кассы, договоров и передачи данных разработчикам.
Материал носит информационный характер. Конкретные требования зависят от вида деятельности, статуса продавца и покупателя, системы налогообложения и способа расчета. Перед запуском платежей юридическую и налоговую схему стоит проверить с бухгалтером или юристом.
1. С чего начинается организация приема платежей
Ошибка — начинать с вопроса:
«Какой платежный сервис подключить?»
Сначала нужно определить саму схему продаж. Ответьте на пять вопросов.
Кто продает?
ООО, ИП или самозанятый.
Кто покупатель?
- физическое лицо;
- ИП;
- юридическое лицо.
Что продается?
- физический товар;
- услуга;
- цифровой контент;
- подписка;
- доступ к SaaS;
- билет или бронирование;
- корпоративная услуга.
Где происходит оплата?
- на сайте;
- в мобильном приложении;
- в Telegram Mini App;
- через платежную ссылку;
- по QR-коду;
- по счету.
Что должно произойти после оплаты?
Например:
Оплата → заказ подтвержден → чек сформирован → товар передан в доставку
или:
Оплата → подписка активирована → доступ открыт
От ответов на эти вопросы зависит вся дальнейшая схема.
2. Кто может принимать оплату от клиентов
На практике для бизнеса чаще всего встречаются три варианта.
ООО
Подходит для компаний, которые работают с большим количеством клиентов, юридическими лицами, сотрудниками, инвесторами или сложной корпоративной структурой.
Для приема безналичных платежей используется банковский счет организации.
ИП
Подходит предпринимателям, которые ведут деятельность самостоятельно или с командой.
ИП также может подключать интернет-эквайринг, СБП и другие способы приема платежей, если они доступны для конкретной модели бизнеса.
Самозанятый
Для плательщиков НПД действует отдельный порядок.
Самозанятые освобождены от применения ККТ, но при получении дохода должны формировать чек через «Мой налог» либо предусмотренный законом уполномоченный сервис. ФНС отдельно разъясняет эту обязанность для расчетов с клиентами, включая организации и ИП.
Поэтому схема самозанятого отличается от схемы ООО или ИП с онлайн-кассой.
3. Расчетный счет: куда поступают деньги
Следующий элемент — банковский счет, на который бизнес получает выручку.
Условно схема выглядит так:
Клиент → платежный сервис / банк → счет бизнеса
Но важно не путать два понятия:
- расчетный счет — куда зачисляются деньги;
- эквайринг — сервис, который позволяет принять оплату определенным способом, например банковской картой.
Сам по себе расчетный счет не означает, что клиент сможет оплатить товар картой на сайте.
Для этого требуется отдельный платежный инструмент и договор с банком или платежным сервисом.
4. Какой способ оплаты выбрать
Наиболее распространенные варианты для российского рынка:
| Способ | Когда подходит |
|---|---|
| Банковские карты | Интернет-магазины, сервисы, большинство B2C-продуктов |
| СБП | Оплата через QR и другие сценарии СБП |
| Платежная ссылка | Продажи через менеджеров, соцсети, мессенджеры |
| Банковский перевод по счету | B2B |
| Рекуррентные платежи | Подписки и регулярные услуги |
| Платежи через магазины приложений | Цифровые покупки в мобильных приложениях |
| Цифровой рубль | Для бизнеса, попадающего под установленные законом критерии |
Не обязательно подключать все способы сразу.
Например, для небольшого B2C-сервиса на старте может быть достаточно карты + СБП. Для B2B-сервиса основным способом останется оплата по счету, а платежная ссылка или эквайринг могут быть дополнительными. Для SaaS с подпиской понадобится отдельная логика регулярных списаний.
Как выбрать провайдера и встроить оплату в продукт технически, разбираем в статье «Как интегрировать онлайн-платежи в приложение или на сайт».
5. Интернет-эквайринг
Интернет-эквайринг позволяет принимать оплату банковскими картами через сайт или приложение.
Упрощенно схема выглядит так:
Сайт → Backend → Платежный сервис → Банк → Результат платежа
Чтобы подключить эквайринг, бизнесу обычно необходимо:
- иметь оформленную деятельность;
- иметь банковский счет;
- заключить договор с банком или платежным сервисом;
- согласовать необходимые условия приема платежей;
- получить доступ к технической интеграции;
- настроить платежный сценарий;
- организовать работу с чеками и возвратами в соответствии с применимыми требованиями.
На стороне разработки появляются уже другие задачи:
- создание платежа;
- передача суммы;
- получение статуса;
- webhooks;
- возвраты;
- обработка ошибок;
- связь платежа с заказом.
Поэтому договор с эквайером и техническая интеграция — два разных этапа, хотя они связаны между собой. Backend-контур, статусы и webhooks — часть веб-разработки.
6. СБП
Система быстрых платежей может использоваться как отдельный способ приема оплаты.
Для бизнеса возможны сценарии с QR-кодом и другими форматами, которые поддерживает конкретный банк или платежное решение.
По информации НСПК, отдельное соглашение непосредственно с НСПК и Банком России для подключения бизнеса к СБП не требуется: взаимодействие организуется через банк — участника системы. НСПК также указывает максимальную комиссию для бизнеса за прием безналичной оплаты через СБП на уровне 0,7% в зависимости от категории операции.
При этом фактические условия подключения и тарифы нужно проверять у конкретного банка.
С технической точки зрения СБП может быть встроена непосредственно в пользовательский сценарий:
Заказ → выбор СБП → QR / платежный сценарий → подтверждение → статус платежа → заказ «Оплачен»
Важно, чтобы бизнес не ориентировался только на экран пользователя. Статус операции должен подтверждаться через предусмотренный платежный контур.
7. Онлайн-касса и чеки
Это один из вопросов, который чаще всего возникает при запуске онлайн-оплаты:
«Если деньги уже пришли на счет, зачем еще касса?»
Потому что банковская операция и кассовый учет — разные процессы.
ККТ применяется по правилам Федерального закона № 54-ФЗ, причем необходимость ее использования зависит в том числе от того, кто покупатель и каким способом производится расчет. Например, при расчетах организации с физическими лицами ФНС указывает на применение ККТ при безналичных расчетах, а для расчетов между организациями и ИП правила зависят от формы безналичного расчета.
Поэтому нельзя делать универсальный вывод:
«При оплате на сайте всегда нужна касса».
И нельзя делать обратный вывод:
«При безналичной оплате касса никогда не нужна».
Нужно смотреть конкретную схему.
Что происходит в типовом B2C-сценарии
Например:
Клиент оформляет заказ → оплачивает картой → платеж проходит → формируется кассовый чек → клиент получает чек → заказ подтверждается
В технической части необходимо заранее определить, кто и каким образом формирует чек и как платежная система взаимодействует с кассовой инфраструктурой.
А что с самозанятыми?
У плательщиков НПД отдельный режим: ККТ им не требуется, но они обязаны формировать чеки по полученным доходам.
Поэтому схема:
Самозанятый → «Мой налог» → чек
отличается от типичной схемы организации с ККТ.
8. Какие договоры и документы нужны
Прием платежей — это не только техническая интеграция.
В зависимости от бизнес-модели могут понадобиться разные документы.
Договор с банком или платежным сервисом
Нужен для подключения соответствующего платежного инструмента.
В нем определяются условия обслуживания, комиссии, порядок расчетов, возвратов и другие условия.
Договор с клиентом
Для B2C-продаж это может быть публичная оферта.
Для B2B обычно заключается отдельный договор между компаниями.
Условия возврата
Клиент должен понимать, в каких случаях и каким образом можно вернуть деньги.
Для подписочных сервисов также нужно определить правила отмены подписки и прекращения списаний.
Политика обработки персональных данных
Если сайт или приложение собирает персональные данные, соответствующие требования необходимо учитывать отдельно.
Другие документы
В зависимости от продукта могут понадобиться:
- счета;
- акты;
- накладные;
- лицензии;
- согласия;
- правила использования сервиса;
- документы для конкретного вида деятельности.
То есть набор документов определяется не самим фактом подключения эквайринга, а моделью бизнеса.
9. B2C и B2B: в чем разница
Схемы приема платежей от физического лица и от компании могут сильно отличаться.
B2C
Типичный сценарий:
Клиент → сайт → заказ → онлайн-оплата → чек → товар / услуга
Пользователю важно быстро оплатить покупку, получить подтверждение и при необходимости оформить возврат.
Для бизнеса важны:
- эквайринг;
- СБП;
- ККТ;
- чек;
- возвраты;
- конверсия в оплату;
- удобный пользовательский сценарий.
B2B
Типичный сценарий:
Компания-клиент → договор → счет → оплата → подтверждение → закрывающие документы
Здесь платеж может проходить обычным банковским переводом по счету, без использования интернет-эквайринга.
Для цифрового продукта можно автоматизировать этот процесс. Например:
Менеджер создает счет → клиент оплачивает → система получает информацию о платеже → заказ автоматически переводится в статус «Оплачен» → услуга активируется
Если компания работает с большим количеством корпоративных клиентов, такая автоматизация может существенно сократить ручную работу. Часто это связка с ERP или CRM: счет, статус оплаты и закрывающие документы живут в одной системе.
10. Что меняется для подписок
Если бизнес продает подписку, недостаточно просто один раз принять платеж.
Нужно заранее определить:
- тариф;
- стоимость;
- период;
- дату следующего списания;
- автопродление;
- отмену;
- неуспешные платежи;
- повторные попытки;
- возвраты;
- изменение тарифа;
- момент отключения доступа.
Например:
Первый платеж → подписка активна → наступила дата продления → повторное списание → подписка продлена
Но если списание не прошло:
Платеж не прошел → повторная попытка → уведомление клиента → ограничение доступа при необходимости
Поэтому подписка требует не только договора с платежным сервисом, но и отдельной бизнес-логики в продукте. Техническую сторону рекуррентных платежей разбираем в разделе «Если нужна подписка».
11. Что нужно передать разработчикам
Когда организационная схема определена, ее нужно превратить в понятное техническое задание.
Разработчикам понадобятся ответы минимум на следующие вопросы.
Кто принимает деньги?
ООО, ИП, самозанятый.
Кто платит?
Физическое лицо, ИП или юридическое лицо.
Как платит?
Карта, СБП, счет, платежная ссылка, магазин приложений и т. д.
Через кого проходит платеж?
Банк, платежный агрегатор или другой провайдер.
Куда зачисляются деньги?
На какой счет и по какой схеме происходит расчет.
Что происходит после оплаты?
Например:
Платеж успешен → заказ оплачен → чек сформирован → CRM обновлена → товар отправлен.
Что происходит при ошибке?
- платеж отклонен;
- пользователь закрыл форму;
- деньги списались, но ответ не пришел;
- произошел повторный запрос;
- требуется возврат.
Что нужно автоматизировать?
- изменение статуса заказа;
- отправку уведомления;
- формирование чека;
- передачу данных в CRM;
- активацию подписки;
- открытие доступа к продукту.
Чем точнее эта схема определена заранее, тем меньше вероятность, что разработчики будут переделывать платежную логику уже после интеграции. Типичные срывы на старте продукта мы разбирали в статье «Самые частые ошибки при запуске продукта».
12. Чек-лист перед запуском
Перед подключением онлайн-платежей проверьте:
Организация
- Определен продавец: ООО, ИП или самозанятый.
- Определен расчетный счет.
- Понятно, кто является покупателем.
- Определен вид товара или услуги.
- Проверены требования к конкретному виду деятельности.
Платежи
- Выбраны способы оплаты.
- Выбран банк или платежный сервис.
- Заключен необходимый договор.
- Проверены комиссии и условия зачисления.
- Продуманы возвраты.
Касса и документы
- Определено, нужна ли ККТ.
- Определен порядок формирования чека.
- Понятно, кто отвечает за фискализацию.
- Подготовлена оферта или договор с клиентом.
- Подготовлены необходимые документы для конкретной модели бизнеса.
Разработка
- Описан платежный сценарий.
- Backend получает и проверяет статус платежа.
- Настроены webhooks, если они предусмотрены.
- Продумана обработка повторных запросов.
- Реализованы возвраты.
- Предусмотрены ошибки и неуспешные платежи.
- При необходимости настроена интеграция с CRM/ERP.
Мобильное приложение
- Определено, что именно покупает пользователь.
- Проверены требования App Store / Google Play.
- Выбран допустимый платежный сценарий.
Для цифровых покупок внутри приложения правила магазинов лучше закладывать еще на этапе заказа разработки, а не на модерации.
13. Что изменилось в 2026 году: цифровой рубль
Для бизнеса в 2026 году появился еще один вопрос, который стоит учитывать при планировании платежной инфраструктуры.
Банк России указывает поэтапные сроки, в которые отдельные продавцы должны обеспечить возможность оплаты цифровыми рублями. Для первой категории — продавцов с выручкой за предыдущий календарный год свыше 120 млн рублей и при выполнении установленных законом условий — срок наступил 1 сентября 2026 года. Далее предусмотрены этапы для других категорий бизнеса. Компании с совокупной годовой выручкой менее 20 млн рублей в соответствующем случае не обязаны подключать прием цифровых рублей.
Принимать цифровые рубли можно в том числе через сайты и приложения. Банк России также указывает, что торгово-сервисные предприятия, уже принимающие СБП, могут использовать существующие онлайн-каналы и терминалы для приема цифровых рублей — специальное оборудование для этого не требуется.
Поэтому для крупного бизнеса платежную архитектуру в 2026 году стоит проектировать с учетом не только карт и СБП, но и применимости цифрового рубля.
Куда идти дальше
Эта статья — про организационную схему. Если нужно перейти к разработке, каналам или связанным системам:
Интеграция онлайн-платежей
Технический чек-лист: backend, webhooks, возвраты, подписки и что проверить перед запуском.
Веб-разработка
Сайт, личный кабинет, backend и интеграции с платежными системами.
Мобильные приложения
iOS и Android, публикация в магазинах и платежные сценарии внутри приложения.
Telegram Mini App
Оплата внутри Telegram: Telegram Payments, ЮKassa, Stripe и другие провайдеры.
Как заказать мобильное приложение
От идеи и Discovery до MVP, тестирования и публикации в App Store, Google Play, RuStore и AppGallery.
ERP для компании
Как связать оплату, счета и статусы заказов с учетной системой.
Из реализованных платежных продуктов можно посмотреть PayQin — e-wallet и цифровые платежи, Invohub — B2B-инвойсы и онлайн-оплата, и FindSport — бронирование площадок со встроенной оплатой. Все проекты — в разделе «Кейсы».
Из чего складывается бюджет IT-проекта, включая платежный контур, — в статье «Сколько стоит разработка».
Как 2people IT подключает платежи в цифровых продуктах
В 2people IT мы рассматриваем прием платежей как часть общей архитектуры продукта.
Сначала разбираем бизнес-сценарий:
- кто платит;
- за что платит;
- где происходит оплата;
- какие способы нужны;
- кто принимает деньги;
- как подтверждается платеж;
- как формируется заказ;
- нужен ли чек;
- как работают возвраты;
- нужны ли подписки;
- какие системы уже используются.
После этого определяем техническую схему:
Frontend → Backend → Платежный сервис → Банк
и связываем ее с остальной инфраструктурой:
Платеж → Заказ → CRM / ERP → Чек → Уведомление → Выдача товара или доступ
Если у бизнеса уже есть сайт, CRM, ERP или мобильное приложение, платежную систему можно интегрировать в существующий контур, а не создавать отдельную систему с нуля.
Отдельно прорабатываем нестандартные сценарии: повторную оплату, неуспешный платеж, задержку подтверждения, возврат, подписку и синхронизацию с внутренними системами.
Вывод
Организация приема платежей начинается не с выбора платежного сервиса.
Сначала бизнесу нужно определить: кто продает → кто покупает → что продается → куда поступают деньги → каким способом производится расчет → какие документы и чеки нужны → что должно произойти после оплаты.
После этого можно выбрать эквайринг, СБП или другое платежное решение, заключить необходимые договоры и передать разработчикам понятную схему интеграции.
При этом эквайринг, расчетный счет, касса и договор с клиентом — разные элементы одной системы. Наличие одного из них не заменяет остальные.
Для простого B2C-продукта схема может выглядеть достаточно компактно:
ООО/ИП → расчетный счет → эквайринг + СБП → ККТ → сайт → оплата → чек → заказ
Для B2B:
ООО/ИП → расчетный счет → договор → счет → банковский перевод → подтверждение → документы
А для SaaS:
ООО/ИП → расчетный счет → платежный сервис → первый платеж → подписка → рекуррентные платежи → возвраты → управление доступом
Именно поэтому платежную инфраструктуру лучше проектировать одновременно с бизнес-процессом и цифровым продуктом, а не подключать в самом конце.
Часто задаваемые вопросы
Планируете организовать прием платежей?
Поможем разобраться с платежным сценарием и встроить его в цифровой продукт: сайт, мобильное приложение, SaaS или внутреннюю систему.
Проектируем архитектуру, интегрируем платежный сервис, backend, webhooks, возвраты, подписки, CRM/ERP и другие необходимые компоненты.
Оставьте заявку — разберем вашу модель приема платежей и определим, что потребуется для запуска.
