В ленте увидел пост о продукте «Супер Сплит» от Яндекс Банка: автор оплатил рассрочку в 21:15, через 15 минут после прописанного в договоре дедлайна 21:00, — и получил аннулирование льготного периода, пересчёт графика на 24 месяца и ставку 58,223% годовых, итого около 15 000 ₽ переплаты. И сделал вывод, что это сознательно спроектированный dark pattern, и банк закладывает невнимательных пользователей в unit-экономику продукта. 

Теперь разберем, что там под капотом на самом деле

Что происходит в 21:00

Утверждение «в 99% банков операционный день заканчивается в 23:59» неверно. 

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

Между ними стоит клиринг — банк-эквайер консолидирует платежи за последний час и зачисляем их одним платежом на счёт получателя. У крупных эквайеров последний клиринг проходит вечером — где-то в 21:00, где-то в 22:00. Всё, что списано с карты после этого времени, зачисляется на расчётный счёт уже следующими сутками.

Для бухгалтерского учёта датой платежа считается дата зачисления на р/с, а не дата списания с карты клиента. Это требование 402-ФЗ и базовая логика учёта по кассовому методу, а не намеренное изменение правил со стороны продукта.

Почему 21:00, а не 23:59

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

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

То же самое работает у МФО: если клиент платит картой стороннего банка через эквайринг, мы видим успех списания, но в учёте проводим зачисление по дате прихода денег на р/с. Это не наша хотелка, это бухгалтерия.

Где автор прав, а где нет

Прав в том, что коммуникация недостаточно точная. Если продукт знает, что 21:00 — операционный дедлайн, обусловленный клирингом, задача продакта и UX — донести это до пользователя: пуш-напоминание в 18:00, явный таймер в приложении, предупреждающий экран при попытке оплатить в 20:50, человеческий язык в условиях вместо «п. 6.7 Общих условий».

В чём не прав: 16 минут опоздания → пересчёт на 24 месяца под 58% годовых выглядит эмоционально несправедливо, но граница между льготным периодом и стандартным кредитным продуктом существует всегда и где-то должна быть проведена. Хоть в 21:00, хоть в 23:59, хоть в 03:00 следующих суток — всё равно найдётся клиент, опоздавший на 15 минут.

Дискретный переход — это природа продукта. BNPL с льготным периодом устроен так: пока клиент в графике, комиссию платит мерчант, ставка для клиента 0%; как только клиент выпадает из графика, продукт переходит в режим обычного потребкредита с ПСК по 353-ФЗ. Это два разных продукта с разной экономикой, и переключение между ними не может быть «плавным» — оно регуляторно и договорно дискретно. Промежуточные градации приведут к созданию третьего гибридного продукта со своим договором, ставкой и расчётом ПСК. Никто не будет это делать ради 0,5% клиентов, опоздавших на час.

Про монетизацию на невнимательности

Тезис: «бизнес зарабатывает на том, что люди не ставят будильники на 20:55». 

Сомнительно. 

Инсайдов по unit-экономике «Супер Сплита» у меня нет, но по аналогичным BNPL-продуктам доля клиентов, опаздывающих на 15–60 минут в дату платежа, — доли процента. Это не та цифра, на которой строят монетизацию продукта с миллионной базой. Деньги в BNPL — это комиссия мерчанта (3–7% от чека) плюс конверсия в обычные кредитные продукты.

Чтобы утверждать «dark pattern», нужно показать одно из двух: либо что банк намеренно скрывает дедлайн в 21:00 (а он есть в условиях, в графике платежей, в push-уведомлениях — претензия скорее к их громкости, чем к факту), либо что выручка от штрафных пересчётов существенна в P&L продукта. Без этих данных dark pattern — эмоциональная атрибуция, а не вывод. Бритва Хэнлона работает и в продуктовом дизайне: не приписывайте злому умыслу то, что объясняется техническим долгом, ленью продакта и наследием регуляторки.

Где проходит граница

Хороший вопрос: где граница между «соблюдаем договор» и «спроектировали ловушку»?

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

Если граница между двумя продуктами дискретна (льготный период → стандартный кредит) — это не плохой дизайн, это юридическая и экономическая природа продукта. Граница должна быть проведена где-то, и любая её точка будет казаться несправедливой тем, кто опоздал на 15 минут.

Если продукт активно прячет ограничение (мелкий шрифт, отсутствие предупреждений, коммуникация только постфактум) — это уже dark pattern, и здесь нужны конкретные доказательства, а не презумпция вины.

Проблема в посте описана реальная, но это не монетизация на невнимательности, а недоработка в UX на фоне технических ограничений. Лечится нормальными напоминаниями, человеческим интерфейсом и понятной коммуникацией дедлайнов.