Определение
Authorization Rate (часто сокращают до Auth Rate) — это доля платёжных запросов, которые банк-эмитент покупателя одобрил, от общего числа попыток оплаты. Простыми словами: сколько из 100 клиентов, нажавших «Оплатить», реально получили зелёную галочку от банка, а не отказ.
Это не то же самое, что конверсия в оплату (CR). Auth Rate измеряет только один этап — момент, когда транзакция уходит в платёжный шлюз и возвращается с ответом approved или declined. Если клиент дошёл до кассы, ввёл карту, но получил «Отклонено» — это удар по Auth Rate. Если он ушёл с пустой корзиной раньше — это уже не про авторизацию.
Для DTC-бренда в России и на экспортных рынках Auth Rate — один из самых недооценённых показателей. Его почти никогда не видно в стандартной админке Shopify или Tilda, но именно он тихо съедает от 5% до 25% выручки.
Аналогия
Представьте фейс-контроль в клубе. Вы стоите в очереди (чекаут), у вас есть билет (деньги на карте), вы выглядите прилично (валидные данные). Но охранник (банк-эмитент) решает, пустить вас или нет. Auth Rate — это процент людей из очереди, кого реально пустили внутрь. Остальные стоят у входа и не понимают, почему их не пускают: билет вроде есть, но охраннику что-то не понравилось — подозрительный паттерн, плохая история, лимиты, антифрод.
При этом «охранник» — это не ваш платёжный провайдер. Это банк, выпустивший карту клиента. Ваш провайдер лишь передаёт запрос и получает ответ. Поэтому «починить» Auth Rate только на своей стороне невозможно — нужно работать в связке с эквайером и эмитентом.
Формула
Authorization Rate = (Одобренные транзакции / Всего попыток авторизации) × 100%
Важно считать именно попытки, а не уникальных клиентов. Один клиент может попробовать три раза: первая карта не прошла, вторая не прошла, третья прошла. В знаменателе — 3, в числителе — 1. Auth Rate = 33%. Если считать по клиентам, получится 100% — и вы потеряете всю картину.
Дополнительно считают Auth Rate по BIN (первые 6 цифр карты) и по эмитенту — это показывает, какие банки вас «не любят».
Сравнение метрик
| Метрика | Что измеряет | Типичный бенчмарк для DTC | Кто влияет |
|---|---|---|---|
| Authorization Rate | Доля одобренных запросов | 85–92% (карты), 70–80% (локальные методы) | Эмитент, антифрод, эквайер |
| Conversion Rate (CR) | Доля посетителей, совершивших покупку | 1.5–3.5% | Весь путь клиента |
| Payment Success Rate | Доля успешных списаний после авторизации | 95–98% | Эквайер, 3DS, капча |
| Chargeback Rate | Доля оспоренных платежей | <0.5% (порог риска) | Клиент, поддержка, доставка |
| Decline Rate | Доля отклонённых запросов | 8–15% | Зеркало Auth Rate |
Auth Rate и Decline Rate — это две стороны одной монеты: Auth Rate + Decline Rate = 100% (если не учитывать технические ошибки и таймауты).
Где это критично
1. Высокий AOV и импульсные покупки. Если средний чек 8 000 ₽, а клиент покупает эмоционально — каждая отклонённая транзакция почти наверняка потеряна. Он не вернётся через час. Потеря 10% авторизаций при выручке 5 млн ₽/мес — это 500 000 ₽ упущенного дохода ежемесячно.
2. Подписочные модели (subscription). Здесь Auth Rate напрямую определяет LTV. Если рекуррентный платёж отклоняется на 3-й месяц, вы теряете не одну оплату, а всю будущую ценность клиента. По данным Recurly, восстановление отклонённых рекуррентов через dunning-логику поднимает выручку на 9–12%.
3. Экспорт на новые рынки. При выходе на рынок Бразилии, Индии или Индонезии Auth Rate может падать до 60–70% из-за локальных методов оплаты (Pix, UPI, банковские переводы) и строгих антифрод-правил эмитентов. Без локального эквайера вы теряете больше трети заказов.
4. Пиковые нагрузки. В Чёрную пятницу банки-эмитенты чаще отклоняют транзакции из-за подозрительной активности. Auth Rate в эти дни может проседать на 5–8 п.п. Заранее предупредите эквайера о промо — это снижает ложные отказы.
5. 3DS и SCA. В Европе и Великобритании обязательна Strong Customer Authentication. Если 3DS настроен криво (слишком агрессивно или, наоборот, не проходит), Auth Rate падает. Правильная настройка exempt-правил и risk-based 3DS даёт +3–7 п.п. к авторизации.
Частые ошибки
Ошибка 1: Считать Auth Rate по уникальным клиентам. Как в примере выше — это завышает метрику и скрывает проблему. Считайте по попыткам.
Ошибка 2: Валить всё на «плохой банк». Прежде чем обвинять эмитента, проверьте: не блокирует ли ваш антифрод легитимные транзакции, не устарел ли BIN-справочник, не отправляете ли вы неполные данные (AVS, CVV, billing address).
Ошибка 3: Игнорировать retry-логику. Клиент с достаточным балансом получил отказ из-за таймаута. Если не предложить повторную попытку через другой шлюз или через 15 минут — вы теряете платёж. Умный retry повышает итоговую авторизацию на 2–5%.
Ошибка 4: Не сегментировать по BIN и гео. Общий Auth Rate 88% может скрывать, что по картам одного банка он 60%, а по другому — 97%. Без сегментации вы не поймёте, где чинить.
Ошибка 5: Путать Auth Rate с Payment Success Rate. Авторизация прошла, но списание не случилось (например, клиент отменил до capture). Это разные этапы, и метрики нужно считать отдельно.
Ошибка 6: Не тестировать новые рынки с локальным эквайером. Один глобальный провайдер даёт 65–75% на развивающихся рынках, локальный — 85–90%. Разница окупает интеграцию за недели.
Связанные термины
- Decline Rate — доля отклонённых транзакций, зеркальная метрика
- Payment Success Rate — доля успешно завершённых платежей после авторизации
- Chargeback Rate — доля оспоренных платежей, влияет на риск-скоринг
- 3DS / SCA — протоколы аутентификации, влияющие на авторизацию
- Dunning — логика повторных попыток для рекуррентных платежей
- BIN-справочник — база данных банков-эмитентов по первым цифрам карты
- Smart Retry — автоматический повтор отклонённых транзакций через оптимальные интервалы
- AVS / CVV Check — проверки адреса и кода карты, влияющие на решение эмитента
- Acquirer — банк-эквайер, через который проходит запрос авторизации
- Issuer — банк-эмитент, выпустивший карту клиента