Как подключить оплату картой на сайте в 2026 году

Разбираться, как подключить оплату картой на сайте, обычно начинают в последний момент: лендинг уже готов, а форма заказа просто пересылает заявку менеджеру в WhatsApp вместо того, чтобы списать деньги сразу. За практику я подключал приём карт и на Tilda, и в WooCommerce, и в кастомных сервисах на Laravel и Next.js, и разница между этими вариантами по деньгам и срокам оказывается больше, чем кажется на старте.

Какие способы принять оплату картой существуют в 2026 году

Вариантов на самом деле три, и они не взаимоисключающие.

Первый - прямой эквайринг от банка: сайт получает мерчант-аккаунт и API-ключи, деньги приходят на расчётный счёт за вычетом комиссии банка. Так работают T‑Bank Эквайринг, Сбербанк и Альфа-Банк.

Второй - платёжный агрегатор: ЮKassa, CloudPayments, Best2Pay, Payselection. Агрегатор берёт на себя связь с банками и платёжными системами, отдаёт готовый виджет или API, и часто быстрее в подключении для ИП и небольших компаний.

Третий - СБП, оплата по QR-коду или по ссылке прямо со счёта покупателя, без карты. Комиссия обычно ниже, чем у карточного эквайринга, но не все покупатели готовы платить через СБП по привычке.

Комиссия по картам на рынке обычно укладывается в 2,2-3,5% от суммы чека в зависимости от банка и оборота, у отдельных агрегаторов для новых клиентов бывают сниженные ставки на первые месяцы работы. СБП дешевле для продавца, обычно 0,4-0,7%, потому что платёж идёт напрямую со счёта, минуя карточные платёжные системы.

На итоговый процент комиссии в договоре влияет не платформа сайта, а профиль бизнеса: МСС-код магазина, среднемесячный оборот по эквайрингу и репутация компании у банка. Новый ИП без истории платежей почти всегда получает более высокую ставку, чем компания с оборотом в несколько миллионов в месяц, и это не зависит от того, стоит у неё Tilda или кастомная разработка.

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

Как подключить оплату картой в Tilda

В Tilda приём карт настраивается в разделе настроек сайта, блок «Платёжные системы». Там можно подключить ЮKassa, CloudPayments, Prodamus, T‑Bank и ещё десяток вариантов, для каждого нужны публичный и секретный ключ из личного кабинета банка или агрегатора. После подключения платёжная форма встраивается прямо в блок с товаром или в форму заказа, и покупатель платит не выходя с сайта.

Когда нужно не просто принять оплату, а связать её с CRM, автоматическим расчётом доставки СДЭК и учётом остатков, стандартных настроек уже не хватает, и приходится писать кастомный скрипт поверх Zero Block или JS API Тильды. У меня такая комплексная интеграция (CRM, эквайринг, СДЭК) стоит от 40 000 ₽, а точечная доработка вроде смены логики скидок или проверки промокода перед оплатой, от 3 000 ₽. Если нужна такая доработка, разумнее сразу заказать настройку и интеграцию под конкретный сайт, чем собирать решение самому методом проб и ошибок на рабочем сайте.

Тестовый и боевой режим оплаты

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

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

Как настроить приём карты в WordPress и WooCommerce

Для WooCommerce у большинства банков и агрегаторов есть готовый плагин: T‑Bank Эквайринг, ЮKassa, CloudPayments. Устанавливается через wp-admin, в настройках указываются API-ключи и адрес для вебхуков, после чего способ оплаты появляется на странице оформления заказа рядом с наличными и переводом.

На одном из проектов на WooCommerce ставил плагин T‑Bank Эквайринг, сама настройка заняла около часа, но пришлось донастроить хук woocommerce_order_status_changed, чтобы заказ помечался оплаченным только по вебхуку от банка, а не сразу после перехода покупателя на страницу оплаты. Это принципиальный момент: если человек закрыл вкладку до завершения платежа, а статус заказа уже стоит «Оплачен», склад отгрузит товар, за который никто не заплатил.

Логи вебхуков стоит хранить отдельно хотя бы неделю: если банк присылает уведомление, а обработчик падает с ошибкой, проще найти событие в логе и переотправить его вручную, чем объяснять клиенту, почему оплата прошла, а заказ до сих пор висит в статусе «Ожидает оплаты».

Проверка подписи вебхука обязательна, иначе кто угодно сможет отправить на ваш эндпоинт поддельное уведомление об оплате. Логика простая и переносится на любой бэкенд, будь то WordPress, Laravel или Node:

import hmac, hashlib, base64

def check_signature(raw_body: bytes, signature: str, secret: str) -> bool:
    digest = hmac.new(secret.encode(), raw_body, hashlib.sha256).digest()
    expected = base64.b64encode(digest).decode()
    return hmac.compare_digest(expected, signature)

Приём оплаты картой в интернет-магазине и кастомном сервисе

В интернет-магазине под ключ приём карты обычно закладывается сразу в архитектуру: каталог, корзина, оформление заказа и оплата собираются как единый поток, а не докручиваются потом отдельным плагином. Для SaaS или личного кабинета на Laravel или Next.js всё делается через прямое API эквайринга или агрегатора: создание платежа, редирект на страницу оплаты банка, приём вебхука об успехе или отказе, привязка к заказу по внутреннему id.

Отдельно стоит продумать, что происходит после успешной оплаты. Часто эту цепочку удобно собрать в n8n: вебхук от CloudPayments или ЮKassa прилетает в n8n, оттуда уходит уведомление в Telegram менеджеру, обновляется статус заказа в CRM и отправляется чек через онлайн-кассу. Так не приходится каждый раз писать интеграционный код руками, а логику видно целиком на одной схеме.

Если оплата нужна не на сайте, а прямо в Telegram-боте, например для цифровых товаров или разовых заказов без отдельного сайта, в aiogram это делается через send_invoice с provider_token, который выдаёт банк или агрегатор для приёма платежей в Telegram. Работает похоже на обычный эквайринг, только форма оплаты открывается внутри мессенджера.

Рекуррентные платежи и подписки

Для SaaS с ежемесячной оплатой одного платежа недостаточно, нужен рекуррентный платёж: клиент один раз вводит карту, а дальше списания идут автоматически по расписанию. У T‑Bank, ЮKassa и CloudPayments это отдельная функция поверх обычного эквайринга, со своим набором методов API и логикой обработки неудачных списаний, повторных попыток и уведомлений клиенту. В кастомном сервисе такую логику я обычно веду отдельным воркером, который раз в сутки проверяет, у кого подошла дата списания, и вызывает API рекуррентного платежа.

Сколько стоит подключение оплаты картой

Порядок цифр по моим проектам за 2025-2026 год.

Это цена именно разработки и интеграции. Комиссию за каждый платёж всё равно берёт банк или агрегатор, а не разработчик, и она не входит ни в одну из этих сумм.

Частые ошибки при подключении оплаты картой

• Заказ помечается оплаченным по факту перехода на страницу банка, а не по вебхуку, при обрыве связи или закрытой вкладке товар уходит без оплаты.
• Забывают про онлайн-кассу: по 54-ФЗ чек нужно пробить в момент оплаты, а не когда менеджер вспомнил об этом на следующий день.
• Хранят номера карт или CVV на своей стороне вместо того, чтобы отдавать ввод данных платёжной форме банка или агрегатора, это прямое нарушение требований PCI DSS.
• Не тестируют возврат денег заранее: при первом реальном возврате выясняется, что в личном кабинете нет нужных прав или API возврата не подключён.
• Складывают платёжные данные клиентов в Google Таблицы или зарубежный сервис вместо российского сервера, персональные данные по 152-ФЗ обязаны храниться на территории РФ.

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

Нужна ли онлайн-касса при приёме оплаты картой на сайте

Да, если продавец работает с физлицами. По 54-ФЗ чек формируется в момент оплаты, и большинство агрегаторов вроде ЮKassa или CloudPayments уже включают фискализацию в тариф, отдельную кассу покупать не нужно. При прямом эквайринге от банка кассу чаще всего приходится подключать отдельно.

Сколько по времени занимает подключение эквайринга

У платёжного агрегатора обычно 1-3 дня после подачи документов ИП или ООО. Прямой эквайринг у банка занимает дольше, от 5 до 15 рабочих дней, потому что банк отдельно проверяет сайт на соответствие требованиям платёжных систем и может попросить доработать оферту или карточку товара.

Можно ли принимать оплату картой без ИП или ООО

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

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

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