Интернет-магазин с рассрочкой уже не редкость только у крупных сетей вроде re:Store или Эльдорадо. Мебель, бытовая техника, стройматериалы, спортивный инвентарь, стоматологические услуги, я подключал рассрочку клиентам с самыми разными нишами: на Tilda, на WooCommerce и на сайтах с собственным бэкендом. Для покупателя это просто ещё одна кнопка на кассе, для магазина за кулисами это интеграция с эквайрингом, вебхуки и правильная логика статусов заказа.
Как работает рассрочка для покупателя и продавца
Рассрочка для покупателя выглядит как оплата без переплаты: он платит несколько равных частей, а разницу между полной ценой товара и суммой платежей закрывает банк или сервис рассрочки, а не магазин. Магазин при этом получает всю сумму заказа сразу, как при обычной оплате картой, за вычетом комиссии эквайринга. Размер этой комиссии, минимальную сумму покупки и срок рассрочки каждый провайдер устанавливает сам и периодически пересматривает, поэтому я не привожу конкретные проценты, актуальные условия смотрю в личном кабинете эквайринга перед тем, как включать рассрочку клиенту.
Юридически рассрочка не имеет отношения к кредитному договору между магазином и покупателем. Магазин не проверяет платёжеспособность, не хранит паспортные данные и не отвечает за одобрение или отказ, это делает банк или МФО на своей стороне. Роль магазина в этой схеме техническая: показать способ оплаты, передать сумму заказа и получить обратно статус.
Какие сервисы рассрочки можно подключить
На практике на российском рынке чаще всего встречаются несколько крупных вариантов, но список и условия у банков меняются, поэтому перед подключением стоит свериться с актуальным перечнем в личном кабинете вашего эквайринга.
- Рассрочка от Т‑Банка доступна как способ оплаты внутри того же виджета, что и обычная оплата картой, если эквайринг уже подключен через Т‑Банк
- Рассрочка от Совкомбанка через сервисы вроде «Халвы» обычно требует отдельного подключения через партнёрскую программу банка
- Рассрочка через СБП-эквайринг некоторых банков, где часть суммы списывается сразу, а остаток разбивается на платежи
- Собственная рассрочка магазина без банка, когда деньги от покупателя магазин получает частями сам, это редкость из-за кассовой дисциплины и рисков просрочки
Кому вообще имеет смысл подключать рассрочку
Рассрочка лучше всего работает на товарах ощутимой стоимости: мебель, техника, стройматериалы, спортивное оборудование, оптика, отчасти услуги вроде стоматологии или ремонта. На чеке в пределах пары тысяч рублей банки часто просто отказывают в рассрочке из-за минимальной суммы покупки, которую устанавливает сам провайдер, а не магазин. Перед подключением стоит посмотреть на средний чек магазина и понять, попадает ли он в диапазон, который поддерживает выбранный банк, иначе виджет рассрочки провисит на сайте без реальных заказов через него.
Подключение рассрочки на Tilda
Тильда не проводит платежи сама, она передаёт покупателя в тот эквайринг, который подключен в настройках платёжных систем сайта. Если у эквайринга, например у Т‑Банка, в личном кабинете включена рассрочка как способ оплаты, она появляется в том же окне оплаты автоматически, без доработки на стороне самой Тильды, потому что это функциональность банка, а не блока Тильды.
Сложности начинаются, когда нужно нестандартное поведение: показать калькулятор рассрочки прямо на карточке товара, скрыть рассрочку для отдельных категорий, например для товаров дешевле определённой суммы, или синхронизировать статус оплаты с CRM и остатками. Тильда даёт свой API и обмен через CommerceML для синхронизации товаров и заказов, но логику вида «если сумма заказа больше определённого порога, показать виджет рассрочки» приходится добавлять кастомным кодом в блок или скриптом на странице оплаты. На таких задачах у меня обычно получается комплексная интеграция эквайринга и CRM для Тильды, потому что рассрочка редко идёт отдельно от остальной платёжной логики магазина.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Подключение рассрочки в WooCommerce
В WooCommerce рассрочка обычно приходит вместе с официальным плагином эквайринга: у Т‑Банка есть плагин для приёма платежей, который регистрируется как отдельный способ оплаты в стандартных настройках WooCommerce, и если в личном кабинете банка включена рассрочка, она показывается покупателю тем же способом оплаты, без отдельного плагина под неё.
Дальше начинается стандартная для WooCommerce история с вебхуками: банк присылает уведомление об изменении статуса платежа на отдельный урл, плагин обрабатывает его и переводит заказ в WooCommerce в статус «Оплачен» или «Обрабатывается». Для этого урла обязателен нормальный SSL-сертификат, а не самоподписанный, иначе банк не сможет достучаться до сайта. Обработка вебхука это обычный PHP-скрипт, который проверяет подпись запроса и обновляет запись в базе MySQL, отдельный сервер под это не нужен, хостинга, на котором уже стоит WordPress, достаточно.
Что видит покупатель на сайте
После выбора рассрочки покупатель обычно уходит на страницу банка, там заполняет короткую форму, например телефон и паспортные данные по требованию банка, получает решение почти сразу и возвращается на сайт магазина. Дальше заказ либо сразу получает статус оплаченного, либо остаётся в статусе ожидания, пока не придёт вебхук с подтверждением, это уже вопрос технической реализации на стороне сайта, а не решение банка.
| Формат показа рассрочки | Где встречается | Что делает покупатель |
|---|---|---|
| Способ оплаты в окне эквайринга | Касса, шаг оплаты заказа | Выбирает «рассрочку» вместо карты, попадает на короткую форму банка |
| Виджет-калькулятор на карточке товара | Страница товара, рядом с ценой | Видит примерную сумму ежемесячного платежа ещё до перехода в корзину |
| Пометка в каталоге | Список товаров, бейдж на карточке | Понимает, что рассрочка вообще доступна, до открытия карточки |
Технические нюансы, о которые обычно спотыкаются
Самая частая ошибка, которую я вижу на чужих проектах, это доверие только редиректу браузера обратно на сайт. Покупатель может закрыть вкладку раньше, чем редирект сработает, или у него оборвётся связь, и тогда заказ формально остаётся неоплаченным, хотя банк платёж уже провёл. Правильная логика такая: статус заказа меняется только по серверному вебхуку от банка, а редирект браузера используется исключительно чтобы показать покупателю страницу «Спасибо за заказ».
На одном из проектов на WooCommerce я сталкивался с ситуацией, когда рассрочка технически была подключена и работала, но заказ в статусе ожидания висел часами, потому что вебхук банка попадал на урл, закрытый плагином защиты от ботов, и просто не доходил до WooCommerce. Внешне всё выглядело так, будто банк не отвечает, хотя платёж проходил в первые секунды. Решилось добавлением исключения для урла вебхука в правилах защиты, но нашли это только когда сверили логи банка с логами сайта.
Второй момент это идемпотентность: банк может прислать один и тот же вебхук дважды, например при повторной попытке доставки уведомления, обработчик должен проверять, не обновлял ли он уже этот заказ, иначе можно случайно отправить письмо о заказе или списать товар со склада дважды. Обычно для этого достаточно уникального индекса на номер платежа в таблице MySQL и транзакции при обновлении статуса, отдельная база вроде Postgres здесь не нужна, для одного магазина PHP и MySQL на обычном хостинге справляются с этой задачей без проблем.
Третий момент это подпись запроса: у каждого банка свой формат подписи вебхука, обычно это HMAC на секретном ключе из личного кабинета, и обработчик обязан её проверять, иначе кто угодно сможет обратиться на этот урл и подделать статус оплаты.
Перед тем как включать рассрочку по-настоящему, большинство банков дают тестовый режим или отдельный набор тестовых карт и вебхуков, стоит прогнать через него весь сценарий: от нажатия кнопки оплаты до прихода вебхука и смены статуса заказа. Это дешевле, чем ловить проблему на первом живом заказе, когда клиент уже написал в поддержку.
Отдельно стоит подумать про уведомления. Когда вебхук от банка приходит на сервер, магазину полезно сразу узнать об этом не только через смену статуса в админке WooCommerce или в CRM, а ещё и отдельным сообщением, например в Telegram-канал менеджеров, чтобы не пропустить сбой в цепочке, если сам вебхук почему-то не дошёл.
Сколько стоит подключение и доработка
Если магазин на Tilda или WooCommerce уже подключен к эквайрингу и в личном кабинете банка есть рассрочка, включение занимает буквально пару кликов в настройках банка, доработка на стороне сайта не нужна. Стоимость появляется там, где нужна нестандартная логика.
| Задача | Что нужно сделать | Услуга и цена |
|---|---|---|
| Калькулятор рассрочки на карточке товара для Tilda | Вставить и адаптировать скрипт банка под блок | Кастомный скрипт для Tilda: от 3 000 ₽ |
| Комплексная синхронизация оплаты, CRM и остатков на Tilda | Настроить API, CommerceML и обработку статусов | Комплексная интеграция для Tilda: от 40 000 ₽ |
| Свой обработчик вебхуков для сайта без готовой CMS | Написать серверную логику приёма и проверки подписи | API или бэкенд на Laravel: от 100 000 ₽ |
| Магазин под ключ сразу с рассрочкой на кассе | Спроектировать и собрать магазин с эквайрингом с нуля | Интернет-магазин под ключ: от 80 000 ₽ |
Если поддерживать эту логику самому не хочется, дешевле сразу заложить в бюджет техподдержку сайта, от 15 000 ₽ в месяц, чем потом разбираться постфактум, почему часть заказов зависла в статусе ожидания.
Рынок рассрочки в России ощутимо перестраивается: банки то расширяют список категорий, то ограничивают их, поэтому раз в несколько месяцев стоит заново открывать личный кабинет эквайринга и смотреть, что изменилось в условиях, а не полагаться на настройки, сделанные год назад.
Частые вопросы
Можно ли подключить рассрочку без эквайринга
Нет, рассрочка технически идёт как один из способов оплаты внутри уже подключенного эквайринга банка, отдельно от карты и СБП её не добавить. Сначала нужен договор с эквайрингом, и только потом в личном кабинете банка включается рассрочка как отдельная опция оплаты.
Заполняет ли покупатель анкету на сайте магазина
Нет, анкету и решение по рассрочке покупатель проходит на стороне банка после редиректа со страницы оплаты. Магазин получает только результат: заказ оплачен или отменён, паспортные данные и решение по одобрению на сайт магазина не передаются.
Что если покупатель ушёл со страницы оплаты раньше времени
Если статус заказа завязан только на редирект браузера, заказ может остаться неоплаченным в базе, даже если банк деньги провёл. Обработчик должен ориентироваться на серверный вебхук от банка, а не на то, вернулся ли покупатель на сайт вручную.
Можно ли показать рассрочку не только на кассе, но и в каталоге
Да, часть банков даёт отдельный виджет-калькулятор рассрочки, который можно вставить на карточку товара и в каталог, он показывает примерный ежемесячный платёж ещё до перехода в корзину. Это отдельная функция от способа оплаты на кассе, подключается по инструкции конкретного банка.