Приём онлайн-оплаты в 2026 году: карты, СБП, SberPay и что теперь ставить на сайт
Узнайте, какие способы оплаты выбирают покупатели в 2026 году и почему карты больше не главный способ. Актуальная статистика и рекомендации для вашего сайт

Клиент довёл заказ до корзины, нажал «Оплатить» и увидел форму, где просят номер карты и код из SMS. Он уже второй месяц платит по QR через приложение банка, потому что так быстрее и без комиссии за перевод. Форма его раздражает, он закрывает вкладку. Для владельца магазина это выглядит как «сайт работает нормально», а по факту — потерянный заказ.
По нашей оценке и по общему тренду платёжного рынка, доля обычных банковских карт в обороте розничных онлайн-платежей в России опустилась примерно до 44%. Оставшуюся часть забирают Система быстрых платежей (СБП), SberPay и оплата через привязанные кошельки. Точную цифру по своей нише лучше смотреть в отчётности своего эквайера или платёжного агрегатора — у розницы, услуг и подписок пропорции разные. Но направление одно: карта перестала быть способом оплаты по умолчанию, а стала одним из нескольких.
Почему бизнес до сих пор держится за одну карту
Обычно дело не в убеждениях, а в инерции. Три-четыре года назад сайт подключали к эквайрингу того банка, где у компании расчётный счёт, и на этом успокаивались. Форма работала, деньги приходили, вопрос закрыли.
Дальше рынок поменялся быстрее, чем сайты. У людей появилась привычка платить по QR — без ввода номера карты, без риска, что платёж отклонит банк по формальному поводу. У части клиентов, юридических лиц или тех, кто работает с иностранными картами, обычный эквайринг вообще не срабатывает. И каждый раз, когда покупатель не находит на сайте привычного способа, он либо ищет обходной путь, либо уходит к конкуренту, у которого QR уже стоит на видном месте.
Добавлять новые способы оплаты по одному, когда «наболело», — рабочий, но не самый дешёвый путь. Каждая новая интеграция — это отдельная настройка, отдельное тестирование, отдельный риск что-то сломать в уже работающей форме. Разумнее сразу спроектировать приём платежей так, чтобы новый канал подключался как модуль, а не как переделка с нуля.
СБП: низкая комиссия и привычка, к которой уже все пришли
Система быстрых платежей — перевод по QR-коду напрямую со счёта покупателя на счёт продавца, в обход карточных платёжных систем. Для бизнеса это означает комиссию заметно ниже карточного эквайринга: платёж идёт по тарифам СБП, которые Банк России держит существенно ниже привычных 1,5–2,5% за эквайринг. Для клиента — минимум действий: открыл приложение банка, отсканировал или нажал по ссылке, подтвердил, готово.
Технически подключение СБП идёт либо через банк-эквайер, либо через платёжный агрегатор, который уже настроил канал с несколькими банками сразу. Разница ощутима: прямая интеграция с API одного банка требует вникать в его документацию, тестовый контур часто работает нестабильнее боевого, а любое изменение логики оплаты — это созвон с банковской поддержкой и ожидание правок. Агрегатор берёт эту сложность на себя и отдаёт разработчику один понятный интерфейс.
Мы сталкивались с этим напрямую на проекте кастингового портала «ТОП-сцена» — сайта детского продюсерского центра с формой регистрации на конкурс чтецов и приёмом оплаты за участие. Изначально рассматривали интеграцию через Альфа-Банк, но для неё требовался отдельный доступ к API-платформе банка, а тестирование заняло бы больше времени, чем сам проект. В итоге перешли на ЮKassa: заявки с формы конкурса уходят в Telegram-бота в чат заказчика, а оплата проходит через готовый модуль без долгой возни с банковским API. Решение сократило разработку этого блока в разы.
SberPay: канал, который нельзя игнорировать из-за доли аудитории
SberPay — оплата в один клик через привязанную карту Сбербанка, без ручного ввода реквизитов на сайте продавца. Для покупателя это быстрее обычной карточной формы, для продавца — дополнительная точка входа, которая закрывает большую часть аудитории, привыкшей к экосистеме Сбербанка.
Отдельно подключать SberPay через прямую интеграцию с банком имеет смысл только при большом обороте, иначе выгоднее подключить его через того же платёжного агрегатора, который уже поддерживает и карты, и СБП, и SberPay в одном личном кабинете. Тогда бухгалтерии не приходится сверять три разных отчёта из трёх разных систем.
ЮKassa и похожие агрегаторы: один модуль вместо трёх интеграций
Логика агрегатора простая: подключаетесь один раз, а дальше покупатель на кассе выбирает сам — карта, СБП, SberPay или что там ещё поддерживает провайдер. Разработчику не нужно тянуть три независимых API, бухгалтеру — сводить три ленты платежей, а бизнесу — договариваться с тремя банками отдельно.
Плата за удобство — комиссия агрегатора обычно на полпроцента-процент выше, чем прямой эквайринг у банка на больших оборотах. Для среднего и небольшого бизнеса разница обычно не критична, а экономия времени на разработку и поддержку окупает её быстро.
Мы регулярно закладываем в проекты именно такую схему: модуль оплаты через ЮKassa, CloudPayments или Robokassa как один блок, который можно расширить новым способом без переписывания формы. По ТЗ того же проекта «ТОП-сцена» логика была построена так, что анкета участника уходит на почту заказчику только после подтверждённой оплаты — платёж и бизнес-процесс завязаны в одну цепочку, а не в два независимых куска кода.
Приём оплаты в рознице: касса, лояльность и 1С должны сходиться
Онлайн-оплата на сайте — только часть картины. У розницы платёж чаще идёт через кассу в торговой точке, и здесь на первый план выходит не выбор способа оплаты, а то, попадает ли этот платёж туда, где его ждёт бухгалтерия и программа лояльности.
На проекте мобильного приложения для розничной сети мясокомбината «Хоту-Ас» ключевым узлом стала интеграция кассового оборудования АТОЛ с 1С 7.7: баллы клиента начисляются и списываются в момент покупки, и все транзакции сразу попадают в учётную систему без ручного переноса. Похожая логика была в проекте для сети «Главпиво»: карта лояльности интегрирована с Apple Wallet, а транзакции синхронизируются с кассовым контуром, чтобы у бизнеса была одна цифра по продажам, а не три разных отчёта из кассы, приложения и Excel.
Правильный способ приёма оплаты не решает задачу сам по себе. Если платёж на кассе или в приложении не связан с 1С, руководитель всё равно будет сверять данные вручную — просто вместо одной таблицы у него появится три.
Персональные данные при оплате: короткое, но обязательное напоминание
Как только на сайте появляется форма оплаты, вместе с ней появляется номер телефона, а иногда и email покупателя — для чека, для СБП, для уведомления об оплате. Это уже персональные данные в смысле 152-ФЗ «О персональных данных», и хранить их, передавать сторонним сервисам или использовать для рассылок без согласия клиента нельзя. Отдельный юридический аудит под конкретный проект стоит заказывать у юриста, который знает вашу схему хранения данных. Мы не берёмся заявлять полное соответствие требованиям без разбора конкретной инфраструктуры клиента, и любой подрядчик, который обещает это голословно, скорее всего, не проверял вопрос всерьёз.
Сравнение способов оплаты: что выбрать под свою задачу
| Способ | Ориентировочная комиссия* | Скорость зачисления | Что нужно для подключения |
|---|---|---|---|
| Карта через банк-эквайер | 1,5–2,7% | 1–3 рабочих дня | договор с банком, юрлицо/ИП, доступ к API банка |
| СБП | около 0,4–0,7% | мгновенно или день в день | договор с банком-участником СБП или агрегатором |
| SberPay | сопоставимо с картой | 1–3 рабочих дня | подключение через банк или агрегатора |
| Агрегатор (ЮKassa и аналоги) | 2–3,5% в зависимости от набора методов | 1–3 рабочих дня | один договор, один личный кабинет на все способы |
*Диапазоны ориентировочные и рыночные, точный тариф зависит от банка, оборота компании и сегмента бизнеса; уточняйте у своего эквайера или агрегатора перед подписанием договора.
Что делать, если на сайте до сих пор одна форма оплаты
Первый шаг — не переписывать сайт целиком, а посмотреть, через что клиенты пытаются платить сейчас и на каком шаге отваливаются. Если корзины бросают именно на форме оплаты, проблема почти наверняка в наборе способов, а не в дизайне кнопки.
Дальше выбор между прямой интеграцией с банком и агрегатором зависит от оборота и от того, сколько способов оплаты нужно сразу. Для небольшого магазина или сайта с формой оплаты разово агрегатор почти всегда быстрее и дешевле в разработке. Для крупного бизнеса с большим оборотом прямой эквайринг у банка может выйти дешевле в пересчёте на комиссию, но потребует больше времени на интеграцию и тестирование.
По нашим стартовым ориентирам разработка сайта с модулем оплаты укладывается в диапазон от 120 000 ₽ и от 3 недель, интернет-магазин с полноценной корзиной, каталогом и оплатой — от 200 000 ₽ и от 4 недель. Точная цена и срок фиксируются в договоре уже после разбора конкретной задачи: набор способов оплаты, интеграция с 1С и объём каталога сильно влияют на смету. Для проектов, где нужно только добавить новый способ оплаты к уже работающему сайту, обычно достаточно тарифа технической поддержки — от 25 000 ₽ в месяц за 10 часов работы, без пересборки всего сайта заново.
Частые вопросы
Сколько стоит подключить СБП или SberPay на уже работающий сайт? Зависит от того, как сейчас устроен приём оплаты. Если сайт уже работает через агрегатора вроде ЮKassa, добавление нового способа — это чаще всего настройка в личном кабинете и небольшая доработка формы, укладывающаяся в тариф технической поддержки. Если оплата зашита напрямую в API конкретного банка, потребуется отдельная интеграция — точную оценку даём после разбора текущей архитектуры.
Можно ли подключить сразу несколько способов оплаты без интеграции с каждым банком отдельно? Да, для этого и существуют агрегаторы вроде ЮKassa, CloudPayments или Robokassa — один договор и один программный модуль закрывают карты, СБП и SberPay сразу. Мы обычно рекомендуем этот путь малому и среднему бизнесу именно из-за экономии времени на разработку и поддержку.
Что потребуется от нас, если закажем интеграцию оплаты у вас? Обычно нужны реквизиты юрлица или ИП для оформления договора с платёжным провайдером, доступ к серверу или хостингу сайта и, если оплата привязана к товарному учёту, доступ к базе 1С или кассовому оборудованию. Договор с самим платёжным провайдером (ЮKassa, банком-эквайером) заказчик обычно заключает от своего юрлица напрямую — мы настраиваем техническую часть.
Что будет, если оставить только карточный эквайринг и ничего не менять? Технически сайт продолжит работать и принимать оплату. Риск в другом: часть покупателей, привыкших платить по QR, будет уходить с корзины на этапе оплаты либо искать альтернативный способ связаться с продавцом напрямую, что увеличивает нагрузку на менеджеров и снижает долю завершённых заказов.
Может ли рост доли СБП со временем изменить экономику эквайринга нашего бизнеса? Да, и в большинстве случаев в плюс: комиссия по СБП заметно ниже карточного эквайринга, поэтому чем больше клиентов платят через QR, тем меньше бизнес отдаёт платёжному провайдеру с оборота. Но полностью убирать карту не стоит — часть аудитории пока платит только ей.
Если на сайте или в приложении до сих пор одна форма оплаты и хочется понять, что добавить в первую очередь, — опишите задачу в Telegram @alexnc_ai, разберём конкретную ситуацию и посчитаем, что нужно.