Почему банки отклоняют платежи: decline rate и как его уменьшить

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

В онлайн-платежах проблема усугубляется. Decline rate (показатель отказов) в e-commerce выше, чем в офлайне, и напрямую влияет на конверсию. Пользователь редко пробует второй раз — одна ошибка оплаты часто означает потерянную продажу.

Полностью убрать declines нельзя. Но часть отказов можно превратить в успешные платежи, если понимать, где они возникают и как на это влиять. Ниже подробный разбор, из чего складывается decline rate и как снизить этот показатель.

Decline rate (уровень отказов / отклонений) — это процент отклонённых платежей от общего числа попыток оплаты. Метрика показывает, как часто банк-эмитент или платёжная инфраструктура (эквайер, платёжный шлюз) не одобряют транзакцию. Высокий показатель (например, выше 10%) означает потерю выручки и указывает на проблемы в платёжной логике, антифроде или маршрутизации.

Проще говоря, если 100 пользователей попытались оплатить покупку, а 10 транзакций были отклонены, decline rate — 10%.

Особенно decline rate важен в сферах, где оплата происходит онлайн и напрямую влияет на выручку.

• В электронной коммерции (e-commerce) и онлайн-сервисах он определяет конверсию на этапе оплаты. Интернет-магазины, SaaS-платформы, мобильные приложения и сервисы с card-not-present платежами теряют пользователей именно в момент авторизации транзакции.
• В финтехе (fintech) и банкинге decline rate используют для анализа транзакций: оценки работы банка-эмитента, антифрод-систем (fraud detection), выявления подозрительных операций и сбоев в процессинге.
• В подписочной модели (recurring payments, MIT — merchant initiated transactions) decline rate напрямую связан с удержанием. Если автоматические списания (Netflix, Spotify, Яндекс Плюс) не проходят, бизнес теряет не только текущий платёж, но и пользователя.

Бенчмарки различаются по сегментам: для SaaS-сервисов «приемлемый» уровень — 2–8%, для high-risk категорий — до 30%. По данным Chargebacks911, авторизационный коэффициент для цифровых товаров составляет 85–92%, а для высокорискованных сегментов — 70–80%.

На практике для большинства онлайн-сервисов ориентир остаётся 2–8%. Значения выше указывают на системную проблему: в платёжной логике, антифроде или работе с банками.

Важно разделять два типа отказов.

• Hard declines — окончательные отклонения: карта закрыта, заблокирована, реквизиты невалидны. В таких случаях повторная попытка оплаты не имеет смысла — платёж не пройдёт без замены карты или данных.
• Soft declines — временные отказы. Они составляют 80–90% всех отклонений и возникают из-за недостатка средств, превышения лимитов, сбоев у эмитента или незавершённой аутентификации. Именно они формируют основной резерв роста, потому что часть этих транзакций можно провести через повторную попытку оплаты или изменение маршрута платежа.

Soft declines — это деньги, уже находящиеся на этапе оплаты, но теряющиеся на последнем шаге. При корректной логике повторных попыток удаётся вернуть 60–70% таких транзакций, а в сценариях с недостатком средств — до 80%.

Например, у вас 100 отклонённых платежей по $10 — это $1 000 потенциальной выручки. Из них 80–90 — это soft declines. При правильной логике можно вернуть $600–700, а в случае недостатка средств до $800.

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

Причины отказов лежат в нескольких зонах: пользователь, банк, платёжная инфраструктура и сценарий оплаты.

Первая и самая массовая причина — недостаток средств. По агрегированным данным платёжных систем, до 44% отказов связаны именно с этим фактором. То есть когда у пользователя просто нет денег на карте.

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

Третья причина — решения банка-эмитента. Часть отказов возвращается с универсальными кодами без объяснения причины. Это «чёрный ящик»: банк отклоняет операцию, и у бизнеса нет прямого способа повлиять на это решение.

Четвёртая — ошибки данных и настроек карты. Неверный CVC, адрес, устаревшие реквизиты, ограничения по географии или MCC — всё это приводит к отказам. Формально они считаются техническими, но на практике связаны с качеством платёжных данных и инфраструктуры.

Сюда же относятся настройки карты: региональные ограничения, лимиты онлайн-платежей, отсутствие или некорректная работа 3D Secure.

Пятая — ошибки 3D Secure и сценария аутентификации. Даже если пользователь готов заплатить, платёж может не пройти из-за сбоя, незавершённой аутентификации или некорректно реализованного сценария.

3D Secure — отдельный элемент в платёжной цепочке, который напрямую влияет на decline rate, поэтому его стоит рассмотреть отдельно.

3D Secure — это дополнительный шаг проверки перед оплатой. Банк хочет убедиться, что платит именно владелец карты, и просит подтвердить операцию: ввести код, пройти проверку в приложении или другим способом.

На этом этапе появляется отдельный сегмент отказов:

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

Формально это не отказ банка — операция не отклонена, а не завершена. Но для бизнеса результат тот же: транзакция не состоялась.

При этом 3D Secure снижает часть отказов со стороны банков: успешная аутентификация повышает доверие к операции и вероятность одобрения. В этом и есть противоречие: 3D Secure одновременно уменьшает часть declines и создаёт новые точки потери платежей.

Дальше, как с этим работать и снижать количество отказов.

Если вы занимаетесь оптимизацией платежей в своём сервисе или приложении, важно понимать: decline rate нельзя «починить» одной настройкой. Это всегда работа на нескольких уровнях.

Плюс есть факторы, на которые вы не влияете: решения банка-эмитента, правила платёжных систем и требования аутентификации (SCA), включая обязательный 3D Secure в ряде сценариев.

Но есть и то, чем можно управлять — и именно здесь находится основной потенциал для роста.

1. Логика платежей. Повторные попытки (retries) с учётом причины отказа, корректная обработка soft declines и статуса «требуется аутентификация» возвращают значительную часть транзакций. Ключевое — не делать слепые повторы, а менять параметры: время, маршрут, сценарий 3DS.

2. Антифрод. Жёсткие фильтры увеличивают долю ложных отказов. Динамический скоринг с учётом устройства, геолокации, истории пользователя и поведенческих паттернов точнее отделяет риск от нормальных операций.

Routing и cascading (перенаправление транзакций на альтернативные банки) позволяют возвращать 10–15% soft declines и увеличивать общий success rate на 4–6%.

3. Данные и токенизация. Ошибки в реквизитах и устаревшие данные — частая причина отказов. Автоматическое обновление карт (lifecycle updater) и network tokenization снижают такие declines за счёт актуальных данных и корректной передачи параметров транзакции — до 35% ложных отказов.

4. BIN и география. Эмитент оценивает транзакцию с учётом страны карты, валюты и мерчанта. Кросс-бордер операции чаще попадают в риск. Локальные BIN и соответствие географии платежа повышают approval rate на 5–15 процентных пунктов.

5. Маршрутизация. Один и тот же платёж может быть отклонён одним банком и одобрен другим. Smart routing распределяет транзакции между банками и провайдерами с учётом их текущего approve rate, MCC и региона, увеличивая долю успешных оплат.
Дальше можно либо выстраивать архитектуру и оптимизацию самостоятельно, либо использовать готовое решение с разным уровнем кастомизации и контролем над платёжным потоком — например, интегрировать в сервис виртуальные карты.

Выпуск виртуальных карт через API помогает снизить decline rate за счёт контроля над картами, BIN-географией, лимитами и логикой платежей. Для арбитражных команд это особенно важно: карта должна выпускаться быстро, привязываться к конкретному кабинету или связке, получать понятный лимит и выводиться из работы при бане или просадке.

Через API карта становится частью вашей внутренней системы, а не внешним инструментом. Можно автоматически выпускать карты под новые рекламные кабинеты, распределять их между байерами, задавать лимиты по связкам, отслеживать статусы и быстро менять параметры без ручной операционки.

В API-модели появляется возможность управлять процессом глубже:

• выпускать карты массово и автоматически;
• закреплять карты за байерами, кабинетами, связками и проектами;
• настраивать лимиты и правила на уровне карты;
• обрабатывать события и статусы в реальном времени;
• блокировать, замораживать и перевыпускать карты по заданным условиям;
• выстраивать собственные сценарии retries и 3DS.

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

• approval rate по банкам;
• типы карт;
• BIN и географию;

и направляет платёж по маршруту с более высокой вероятностью одобрения.

Дополнительно влияет сценарий аутентификации. Если карты поддерживают «бесшовное» подтверждение и корректную работу с 3D Secure, снижается риск потери платежа на этапе проверки. Для арбитража это важно: чем меньше ручных шагов и сбоев на авторизации, тем стабильнее проходит оплата рекламных кабинетов.

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

Если говорить о снижении decline rate через виртуальные карты, всё зависит от ваших задач и текущего состояния платёжного потока.

Дальше — API-интеграция.

Если задача — глубже управлять платежами, снижать потери и работать с авторизацией, данными, настройкой карт и routing, выбирайте API-модель. Она даёт доступ к платёжной логике, но требует разработки и технической команды.

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

Даже на базовом уровне виртуальные карты позволяют снижать decline rate за счёт управления BIN, лимитами и сценариями платежей. При правильной архитектуре и настройке платёжного потока можно вернуть значительную часть ранее потерянных транзакций и повысить approve rate.

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