BNPL в магазине на Битрикс: Долями, Подели и аналоги

Покупатель складывает в корзину товар за 12 000 рублей, доходит до оплаты — и закрывает вкладку. Сумма для разового платежа психологически великовата, а полноценный кредит оформлять ради одной покупки не хочется. Ровно в этот момент помогает BNPL (buy now, pay later — «купи сейчас, плати потом»): оплата долями, когда стоимость заказа делится на несколько равных частей без процентов для покупателя. В российских магазинах на 1С-Битрикс это чаще всего сервисы «Долями», «Подели» и их аналоги.

Ниже — разбор оплаты долями с точки зрения владельца магазина: как BNPL устроен внутри, какие провайдеры есть на рынке, как способ влияет на конверсию и средний чек, где его правильно показывать в витрине и как всё это аккуратно завести в 1С-Битрикс с чеками по 54-ФЗ. Это выжимка из наших проектов по интеграции платёжных сервисов и внешних систем — с фокусом на то, что реально влияет на деньги, а не на маркетинговые лозунги.

Что такое BNPL и чем «долями» отличается от рассрочки

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

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

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

Важно не путать понятия для покупателя и для бизнеса. Покупатель видит «оплату долями» или «рассрочку без переплат» и воспринимает это как удобную опцию. Бизнес же должен смотреть на BNPL как на платёжный инструмент со своей экономикой: комиссия, лимиты, процент одобрений, правила возвратов и требования к фискализации. Дальше мы разберём каждый из этих аспектов.

Как устроена оплата долями изнутри

Чтобы подключать BNPL осознанно, полезно понимать, что происходит «под капотом» между магазином, сервисом и покупателем. С точки зрения потоков это цепочка из нескольких шагов, и на каждом есть свои нюансы интеграции.

1. Выбор способа. Покупатель на шаге оплаты выбирает «долями» — как один из способов оплаты наравне с картой и СБП. Магазин заранее проверяет, что сумма заказа попадает в лимит сервиса.
2. Переход в сервис. Покупателя перенаправляет на страницу или виджет провайдера, где он подтверждает личность и график платежей. Решение об одобрении принимается за секунды.
3. Первый платёж и подтверждение. Списывается первая доля, сервис фиксирует сделку и отправляет магазину подтверждение об успешной оплате заказа (колбэк на серверную часть сайта).
4. Зачисление магазину. Провайдер переводит магазину полную стоимость заказа за вычетом комиссии — по своему графику расчётов, обычно в течение одного-нескольких рабочих дней.
5. Сбор платежей с покупателя. Оставшиеся доли сервис списывает с покупателя сам по графику. Магазин в этом уже не участвует.
6. Возвраты и споры. При возврате товара магазин инициирует возврат через API или кабинет провайдера, а сервис пересчитывает график и возвращает покупателю внесённое.

Для интеграции важны два технических канала. Первый — инициация оплаты: магазин формирует заказ и передаёт сервису сумму, состав и идентификатор заказа, получая ссылку или виджет для покупателя. Второй — колбэк (webhook): сервис асинхронно уведомляет сайт о смене статуса — оплачено, отклонено, возвращено. Именно по колбэку заказ в 1С-Битрикс переводится в статус «оплачен», а не по факту редиректа покупателя обратно, потому что покупатель может закрыть вкладку до возврата на сайт.

Провайдеры: Долями, Подели и аналоги

Российский рынок BNPL сформировался вокруг экосистем крупных банков и маркетплейсов. Для магазина на 1С-Битрикс практический выбор чаще всего идёт между несколькими игроками, у каждого из которых своя аудитория, свои лимиты и своя механика подключения.

• «Долями» — сервис от Т-Банка (ранее Тинькофф). Классическая схема «оплата четырьмя долями» без процентов для покупателя, широкое покрытие аудитории, узнаваемый бренд и понятный виджет. Один из самых популярных вариантов для интернет-магазинов.
• «Подели» — BNPL-сервис от Сбера. Тоже деление платежа на равные части, встроенность в экосистему Сбера и большую пользовательскую базу. Часто идёт в паре с эквайрингом Сбера.
• «Плайт», «Мокка» (Mokka) и другие — независимые и банковские BNPL-сервисы, которые нередко предлагают более длинные сроки или гибкие графики. Их подключают как дополнение к основному провайдеру, чтобы повысить суммарный процент одобрений.
• BNPL от маркетплейсов и платёжных агрегаторов. Некоторые платёжные шлюзы и агрегаторы уже включают BNPL в свой набор способов оплаты — тогда «долями» появляется как ещё одна кнопка внутри знакомого платёжного модуля, без отдельной интеграции.

При выборе провайдера смотрите не на бренд, а на четыре практических параметра: размер комиссии магазина, минимальный и максимальный лимит суммы заказа, процент одобрения по вашей аудитории и качество интеграции с 1С-Битрикс (готовый модуль против самостоятельной разработки по API). Часто выгоднее начать с одного сервиса, чья аудитория ближе к вашей, а второго добавить позже, когда появятся собственные цифры по конверсии и одобрениям.

Сравнение способов оплаты в рассрочку

Чтобы не путать инструменты, полезно держать перед глазами их различия. BNPL, банковская рассрочка и POS-кредит решают похожую задачу «купить сейчас, заплатить потом», но экономика и ответственность у них разные.

Из таблицы видно, зачем магазины держат несколько инструментов одновременно. BNPL закрывает импульсные и средние по сумме покупки, где важна скорость и отсутствие бюрократии. Рассрочка и POS-кредит подключаются, когда средний чек высокий и покупателю нужен длинный срок. На витрине они не конфликтуют, а дополняют друг друга: способ подбирается под сумму заказа.

Влияние на конверсию и средний чек

Главный аргумент за BNPL — деньги, а не удобство ради удобства. Оплата долями влияет на воронку сразу в нескольких точках, и важно понимать, где именно вы выигрываете, а где стоит следить за экономикой.

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

Средний чек. Когда цена делится на доли, покупатель охотнее берёт более дорогую комплектацию или добавляет сопутствующий товар — «по 3 000 в месяц» воспринимается легче, чем «12 000 сразу». Поэтому магазины с BNPL часто фиксируют рост среднего чека и глубины корзины, а не только числа заказов.

Снижение брошенных корзин. BNPL работает как ещё один аргумент «здесь и сейчас». Виджет «оплатите долями по 3 000 ₽» прямо в карточке товара и корзине снимает возражение по цене до того, как покупатель уйдёт «подумать».

Обратная сторона — комиссия. BNPL дороже карточного эквайринга, поэтому нельзя смотреть только на рост числа заказов: считайте маржу с учётом комиссии сервиса. Правильная метрика — не «выросла ли конверсия», а «выросла ли валовая прибыль после вычета всех платёжных издержек». На практике на средних и высоких чеках прирост выручки и среднего чека с запасом перекрывает комиссию, но проверять это нужно на своих цифрах.

Где и как показывать BNPL в магазине

BNPL приносит эффект не столько фактом подключения, сколько тем, насколько заметно и вовремя покупатель видит опцию. Оплата долями должна появляться раньше корзины — тогда она работает как аргумент к покупке, а не как техническая деталь на последнем шаге.

• Карточка товара. Строка вида «или 4 платежа по 3 000 ₽» рядом с ценой — самый сильный по эффекту элемент. Она снимает возражение по цене в момент решения о покупке.
• Каталог и листинг. Иногда уместно показывать «долями от N ₽» прямо в карточках списка для дорогих категорий, но не перегружайте витрину — это должно помогать, а не шуметь.
• Корзина. Виджет с разбивкой платежа и логотипом сервиса подкрепляет решение и напоминает о способе перед оплатой.
• Шаг оплаты. Способ «Оплатить долями» в списке платёжных методов — обязательный минимум. Здесь важно показывать его только когда сумма заказа попадает в лимит сервиса.
• Отдельная посадочная / баннер. Промо-страница «Как оплатить долями» с ответами на вопросы снижает недоверие новых покупателей к незнакомому способу.

Технически расчёт «по N ₽ в платеже» удобно выводить готовым виджетом провайдера — он сам подставит корректную сумму долей и правовые формулировки. Если рисуете свой блок, следите за тем, чтобы деление платежа и условия совпадали с реальными правилами сервиса, иначе покупатель увидит одну сумму на витрине и другую в момент оплаты.

Риски, лимиты и подводные камни

BNPL выглядит как «бесплатный рост продаж», но у инструмента есть своя изнанка, которую стоит учесть до подключения. Риски здесь не катастрофические, но каждый из них способен незаметно съедать маржу или портить опыт покупателя.

• Комиссия выше эквайринга. Плата за BNPL — самый очевидный минус. На товарах с тонкой маржой оплата долями может обнулять прибыль с заказа, поэтому иногда способ ограничивают отдельными категориями.
• Лимиты по сумме. У каждого сервиса свой минимум и максимум. Заказы вне диапазона либо не поддерживаются, либо уводятся в другую механику — это надо учитывать в отображении способа.
• Процент одобрений. Не всем покупателям сервис одобрит оплату долями. Часть выберет способ и получит отказ — их важно мягко вернуть к оплате картой, а не терять.
• Возвраты и частичные возвраты. Логика возврата при BNPL сложнее, чем при карте: нужно корректно пересчитать оставшиеся доли и синхронизировать статус с заказом и учётной системой.
• Двойная фискализация. Если неверно распределить, кто пробивает чек — магазин или сервис, — можно задвоить чек по 54-ФЗ или, наоборот, не пробить его вовсе.
• Зависимость от провайдера. Сбой на стороне сервиса выключает способ оплаты. Резервный второй провайдер и корректный фолбэк на карту снижают этот риск.
• Репутация способа. Часть аудитории относится к «рассрочкам» настороженно. Понятные формулировки без мелкого шрифта и скрытых условий важны, чтобы способ не отпугивал.

Ни один из этих рисков не является причиной отказаться от BNPL — все они управляемы. Но их нужно проговорить на этапе внедрения: заложить в экономику комиссию, настроить лимиты и фолбэки, продумать возвраты и фискализацию. Тогда оплата долями станет управляемым инструментом, а не источником неожиданных проблем в отчётах.

Чеки 54-ФЗ, возвраты и бухгалтерия

Оплата долями не отменяет требований 54-ФЗ: для покупателя это обычная покупка, значит фискальный чек нужен так же, как при оплате картой. Тонкость в том, кто именно формирует чек и в какой момент, — и это зависит от модели интеграции с конкретным сервисом.

Обычно возможны два сценария. В первом BNPL-сервис выступает платёжным агентом и берёт фискализацию на себя — тогда чек пробивается на его стороне, а магазину важно не пробить свой второй чек на ту же сумму. Во втором сервис работает как платёжный шлюз, а чек формирует ваша онлайн-касса, привязанная к 1С-Битрикс, — тогда фискализация идёт через ваш модуль кассы по факту подтверждённой оплаты. Ошибка на этом стыке — самая частая и самая дорогая: она приводит либо к задвоению чеков, либо к их отсутствию.

Возврат при BNPL — это отдельная процедура. Магазин инициирует возврат в кабинете или по API провайдера, сервис отменяет или пересчитывает оставшиеся доли и возвращает покупателю уже внесённые суммы. На стороне 1С-Битрикс важно, чтобы заказ корректно переходил в статус возврата, формировался возвратный чек по 54-ФЗ и всё это синхронизировалось с учётной системой. Иначе бухгалтерия увидит одно, склад — другое, а сервис — третье.

Отдельно продумайте частичные возвраты и обмены. Если покупатель вернул один товар из заказа на несколько позиций, сумма к возврату и оставшийся график долей должны пересчитаться корректно. Это как раз тот случай, где ручная сверка не масштабируется, и логику стоит завязать на статусы заказа и обмен с 1С. Смежные сценарии предоплаты, депозита и зачёта аванса разбираем в материале про частичную оплату, предоплату и депозит в 1С-Битрикс.

Реализация в 1С-Битрикс

С точки зрения платформы BNPL добавляется как ещё одна платёжная система в модуле «Интернет-магазин». Механика та же, что у эквайринга или СБП: обработчик платёжной системы, настройки доступа к API провайдера, обработка колбэка и привязка к статусам заказа. Разберём по шагам.

1. Получите доступы у провайдера. Заключите договор с сервисом («Долями», «Подели» или аналог), получите тестовые и боевые ключи API, идентификатор магазина и адрес для колбэков. Уточните лимиты суммы и правила фискализации.
2. Добавьте платёжную систему. В разделе «Магазин → Настройки → Платёжные системы» создайте новую платёжную систему на базе готового модуля провайдера (если он есть в Маркетплейсе 1С-Битрикс) или на базе своего обработчика по API.
3. Настройте параметры. Пропишите ключи, режим (тест/бой), сопоставление валют и статусов. Задайте бизнес-значения обработчика: как формируется сумма, состав заказа и идентификатор для сервиса.
4. Настройте колбэк. Укажите провайдеру URL обработчика на вашем сайте, который принимает уведомления о статусе и переводит заказ в «оплачен» / «отклонён» / «возврат». Это серверная точка входа, не зависящая от возврата покупателя на сайт.
5. Ограничьте способ по сумме. В настройках платёжной системы или через ограничения способов оплаты задайте минимальную и максимальную сумму заказа, при которой BNPL доступен, чтобы не показывать способ вне лимитов.
6. Привяжите фискализацию. Настройте, кто пробивает чек: если это ваша касса — свяжите платёжную систему с модулем кассы 1С-Битрикс; если сервис — отключите свой чек на эту оплату, чтобы не задвоить.
7. Выведите виджет на витрину. Добавьте расчёт «оплатить долями по N ₽» в шаблон карточки товара и корзины — готовым скриптом провайдера или собственным блоком, синхронизированным с правилами сервиса.
8. Протестируйте сквозной сценарий. Проведите тестовые заказы: успешная оплата, отказ, возврат, частичный возврат. Проверьте статусы заказа, чеки 54-ФЗ и выгрузку в 1С.

Если магазин обменивается заказами с 1С, важно, чтобы способ оплаты, статус оплаты и данные по возвратам корректно выгружались в учётную систему. Обмен с 1С по заказам должен понимать новый способ оплаты, иначе бухгалтерия не увидит BNPL-платежи в привычном виде. Настройку платёжных систем, колбэков и обмена мы обычно делаем в рамках работ по интеграции 1С-Битрикс с платёжными и учётными системами.

Как это выглядит в админке 1С-Битрикс

Настройка BNPL живёт там же, где остальные способы оплаты — в списке платёжных систем модуля «Интернет-магазин». Схематично карточка платёжной системы выглядит так:

Несколько провайдеров и маршрутизация

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

Есть два подхода к отображению нескольких сервисов. Первый — явный выбор: покупатель видит в списке оплаты «Долями» и «Подели» как отдельные способы и решает сам. Просто в реализации, но перегружает интерфейс и путает часть аудитории. Второй — умная маршрутизация: покупатель видит один способ «Оплатить долями», а система под капотом выбирает провайдера по правилам (сумма заказа, категория, приоритет, доступность сервиса). Сложнее, но опыт покупателя чище.

При любом подходе заложите фолбэк. Если основной сервис недоступен или отказал в одобрении, покупателя нельзя оставлять в тупике — нужно мягко предложить второй BNPL-сервис или оплату картой. Тупик на шаге оплаты — это потерянный заказ, а не «клиент подумает и вернётся».

Метрики и аналитика BNPL

«BNPL работает» — субъективное ощущение. Чтобы управлять инструментом, за ним нужно следить по конкретным показателям. Вот метрики, которые стоит вывести в отчёт с первого месяца.

Практический смысл этих цифр — отделить эмоцию от экономики. Если доля BNPL растёт, средний чек по способу выше карточного, а комиссия к обороту в разумных пределах — инструмент окупается, и можно масштабировать (шире показывать виджеты, добавлять провайдеров). Если же процент одобрений низкий или возвраты по BNPL заметно выше среднего — это сигнал разобраться с аудиторией, лимитами или конкретным сервисом, а не наращивать объём.

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

• Показывают способ «долями» на заказах вне лимита суммы — покупатель выбирает его и получает отказ на финальном шаге.
• Переводят заказ в «оплачен» по редиректу покупателя, а не по колбэку сервиса — теряют оплаты тех, кто закрыл вкладку.
• Задваивают чек по 54-ФЗ или не пробивают его вовсе — не распределили заранее, кто фискализирует платёж.
• Не продумывают возвраты и частичные возвраты — статусы заказа, возвратный чек и данные в 1С расходятся с реальностью.
• Смотрят только на рост числа заказов и забывают про комиссию — на тонкой марже BNPL может обнулять прибыль с заказа.
• Прячут BNPL только на шаг оплаты — теряют главный эффект, ведь виджет в карточке и корзине снимает возражение по цене раньше.
• Не настраивают фолбэк при отказе или сбое сервиса — покупатель попадает в тупик и уходит без заказа.
• Не выгружают способ и статус оплаты в 1С — бухгалтерия не видит BNPL-платежи в привычном виде, сверки ломаются.

Чек-лист внедрения

Сведём всё в практический список, по которому удобно принимать готовность BNPL перед запуском:

1. Провайдер выбран. Заключён договор, известны комиссия, лимиты суммы, график расчётов и правила возвратов.
2. Экономика посчитана. Комиссия заложена в маржу; определены категории или суммы, на которых BNPL включён.
3. Платёжная система настроена. Обработчик добавлен, ключи API прописаны, режим переключён на боевой после тестов.
4. Колбэк работает. Заказ переходит в «оплачен» / «отклонён» / «возврат» по серверному уведомлению сервиса, а не по редиректу.
5. Лимиты заданы. Способ показывается только на заказах в пределах суммы провайдера; вне лимита — скрыт.
6. Фискализация распределена. Известно, кто пробивает чек; тестовый заказ даёт ровно один корректный чек 54-ФЗ, возвратный чек проверен.
7. Виджеты на витрине. Расчёт «долями по N ₽» выведен в карточке товара и корзине, суммы совпадают с реальными правилами сервиса.
8. Фолбэк настроен. При отказе или сбое покупателю предлагается второй сервис или оплата картой без тупика.
9. Обмен с 1С проверен. Способ, статус оплаты и возвраты корректно выгружаются в учётную систему.
10. Метрики выведены. В отчёте есть доля BNPL, процент одобрений, средний чек, конверсия, комиссия и возвраты.

Вывод

Оплата долями — это не «модная кнопка», а рабочий инструмент роста конверсии и среднего чека, у которого есть своя цена и своя механика. BNPL снимает барьер полной суммы, возвращает в воронку сомневающихся покупателей и переносит кредитный риск на сервис-провайдера. Взамен магазин платит повышенную комиссию и берёт на себя аккуратную интеграцию: показ способа в пределах лимитов, обработку колбэков, правильную фискализацию по 54-ФЗ, корректные возвраты и выгрузку в 1С. Сделайте эти вещи один раз и по-инженерному — и оплата долями станет предсказуемым драйвером продаж, а не источником сюрпризов в отчётах.