Какие данные проверяются при авторизации карточного платежа: полный разбор полей и логики принятия решения

При авторизации карточного платежа эмитент (банк, выпустивший карту) получает набор данных от торговца через платёжную систему (Visa, Mastercard, «Мир» и др.) и принимает решение: одобрить или отклонить транзакцию. Проверка происходит за доли секунды и охватывает как технические реквизиты карты, так и поведенческие, географические и риск-параметры. Понимание того, какие именно поля анализируются, помогает снизить процент отказов, правильно настроить интеграцию и объяснить клиенту причину отказа без обращения в поддержку.

Базовые реквизиты карты: что проверяется в первую очередь

Минимальный набор данных, который должен прийти в авторизационном запросе (ISO 8583 / ISO 20022), включает:

• PAN (Primary Account Number) — номер карты (13–19 цифр). Проверяется алгоритм Луна (mod 10), диапазон BIN/IIN (первые 6–8 цифр) на принадлежность к платёжной системе и эмитенту, формат и длина.
• Срок действия (Expiry Date) — месяц и год в формате MM/YY. Карта не должна быть просрочена на момент авторизации. Некоторые эмитенты блокируют карты за 1–2 месяца до официальной даты истечения.
• CVV2/CVC2/CVP2 — трёхзначный код на оборотной стороне (четырёхзначный для Amex). Проверяется только при card-not-present (CNP) транзакциях. Отсутствие или несовпадение — частая причина отказа с кодом «неверный CVV».
• Имя держателя (Cardholder Name) — передаётся не всегда и не всеми эмитентами проверяется на точное совпадение. Чаще используется для 3D Secure и ручной ревизии.

Если хоть одно из этих полей не проходит форматную валидацию или проверку на стороне эмитента, транзакция отклоняется на ранней стадии с кодом ответа вроде 14 (invalid card number), 54 (expired card) или 63 (security violation).

Дополнительные аутентификационные данные: 3D Secure, AVS и токенизация

Современные платежи почти всегда включают второй фактор или контекстные проверки:

• 3D Secure (3DS 2.x) — протокол аутентификации держателя. В запрос передаются: device fingerprint (IP, User-Agent, язык, таймзона, разрешение экрана), данные о предыдущих успешных аутентификациях, флаг «challenge» или «frictionless». Эмитент решает: пропустить без взаимодействия (frictionless) или вызвать challenge (SMS, push, биометрия, пароль). Результат возвращается в поле ECI (Electronic Commerce Indicator) и CAVV/AAV — криптограммы подтверждения аутентификации.
• AVS (Address Verification Service) — проверка адреса биллинга. Передаются: почтовый индекс (ZIP/postal code), номер дома/квартиры, иногда улица. Эмитент сравнивает с данными в анкете клиента. Результат возвращается кодом (Y, N, A, Z, U и др.). AVS обязателен в США/Канаде, в остальных регионах — по решению эмитента.
• Токенизация (Network Token / Merchant Token) — вместо PAN передаётся токен (DPAN/MPAN). Эмитент проверяет: токен валиден, не отозван, привязан к правильному устройству/мерчанту, криптограмма (dynamic cryptogram) соответствует ожидаемой. Токенизация снижает риск компрометации PAN и повышает конверсию.

Финансовые и лимитные проверки на стороне эмитента

После прохождения форматной и аутентификационной проверок эмитент оценивает финансовую возможность проведения операции:

• Доступный баланс / кредитный лимит — сумма авторизации не должна превышать доступные средства с учётом уже заблокированных (pending) сумм.
• Лимиты по типам операций — дневные/месячные лимиты на онлайн-покупки, бесконтактные платежи, снятие наличных, cross-border транзакции.
• Лимиты по MCC (Merchant Category Code) — эмитент может блокировать или ограничивать определённые категории: гемблинг, криптовалюты, взрослый контент, ПОК/ПОД (переводы физлицам), телемедицина и др.
• Валютные ограничения — для валютных карт проверяется соответствие валюты транзакции и карты, наличие мультивалютного баланса, курс конвертации и комиссии.
• Статус карты и счёта — активна, заблокирована, в стоп-листе, просрочена, перевыпущена, счёт закрыт, арест/обременение по решению суда/ФССП.

Отказы по финансовым причинам обычно возвращают коды 51 (недостаточно средств), 61 (превышен лимит), 57 (транзакция не разрешена для карты), 58 (транзакция не разрешена для терминала/мерчанта).

Поведенческие и контекстные проверки (антифрод эмитента)

Современные эмитентские антифрод-системы (ISS, FICO Falcon, SAS, встроенные в процессинг) анализируют сотни признаков в реальном времени. Ключевые группы:

• География и устройство — страна эмитента vs страна мерчанта vs страна IP vs страна телефона. Несоответствие (например, карта РФ, IP Нидерланды, мерчант США) повышает риск-скор.
• Скорость и частота (Velocity checks) — количество попыток за минуту/час/сутки, суммарный объём, уникальные мерчанты, уникальные карты с одного устройства/IP.
• Паттерны поведения держателя — типичные суммы, время суток, категории мерчантов, устройства, географии. Аномалия: внезапно крупная покупка в новой категории ночью с нового устройства.
• Репутация мерчанта и BIN — мерчанты с высоким chargeback ratio, в высокорисковых MCC, новые MID, BINы предоплаченных/виртуальных/карт для расходов (corporate expense cards) получают повышенный скрининг.
• Списки компрометации — карта в базе утечек (Visa CAMS, Mastercard ADC), устройство в базе ботнетов/прокси/VPN/TOR, email/телефон в базах фишинга.

Результат — риск-скор (0–999 или low/medium/high). При высоком скоре эмитент может: отклонить (код 59 — suspected fraud), запросить step-up аутентификацию (3DS challenge), одобрить с флагом «требует подтверждения» (для ручной ревизии мерчантом).

Параметры мерчанта и терминала, которые учитывает эмитент

Эмитент видит не только данные карты, но и контекст точки приёма:

• MID (Merchant ID) и TID (Terminal ID) — уникальные идентификаторы в системе эквайера.
• MCC (Merchant Category Code) — 4-значный код категории бизнеса. Влияет на интерчейндж, лимиты эмитента, требования к 3DS, возможность chargeback.
• POS Entry Mode / Wallet Indicator — как введён PAN: чип (EMV), магнитная полоса, NFC (contactless), ручной ввод (keyed), кошелёк (Apple Pay/Google Pay/Samsung Pay/Mir Pay), токенизированная карта в приложении мерчанта (COF — Credential on File). EMV и токенизированные кошельки дают лиабилити шифт (ответственность за фрод на эмитенте).
• Terminal Capability / Cardholder Present Data — флаги: PIN verified, signature, CVM (Cardholder Verification Method), attendance (attended/unattended).
• Данные о повторяющихся платежах (MIT — Merchant Initiated Transaction) — флаг recurring/installment/unscheduled, reference к первоначальной авторизации (scheme reference ID), согласие держателя (mandate). Без правильной разметки MIT эмитент может отклонить как «не авторизовано держателем».

Таблица: основные коды отказов и их связь с проверяемыми данными

Код (ISO 8583)	Название	Какая проверка не пройдена	Типичное действие
05	Do Not Honor	Общий отказ эмитента без уточнения причины (часто — антифрод или внутренние правила)	Попросить клиента связаться с банком, попробовать другую карту
14	Invalid Card Number	PAN не проходит Luhn или не найден в базе эмитента	Проверить ввод номера, срок действия, BIN
51	Insufficient Funds	Баланс/лимит < суммы авторизации + pending	Пополнить счёт, снизить сумму, разделить платеж
54	Expired Card	Срок действия истёк	Запросить новую карту или обновлённые реквизиты (token update)
57	Transaction Not Permitted — Card	MCC/тип операции запрещён для этой карты (настройки эмитента/держателя)	Уточнить у банка настройки карты, сменить способ оплаты
59	Suspected Fraud	Антифрод эмитента: высокий риск-скор, компрометация, аномалия	Клиент должен подтвердить легитимность в приложении банка/по телефону
61	Exceeds Withdrawal Limit	Превышен дневной/месячный лимит по сумме или количеству операций	Подождать сброса лимитов, запросить повышение в банке
63	Security Violation	Неверный CVV, неверная криптограмма 3DS/токена, подозрение на подделку	Повторить с верным CVV, пройти 3DS challenge, обновить токен
65	Exceeds Activity Limit	Превышен лимит по количеству транзакций за период (velocity)	Подождать, снизить частоту попыток
91	Issuer Unavailable	Эмитент не ответил в таймаут (stand-in processing может одобрить/отклонить по своим правилам)	Повторить попытку через минуту, проверить статус у эквайера
96	System Malfunction	Техническая ошибка на стороне эмитента/платёжной системы	Повторить позже, обратиться в поддержку эквайера

Специфические сценарии: что проверяется дополнительно

Повторяющиеся платежи (Subscriptions, MIT, COF)

Для последующих списаний без участия держателя (MIT) эмитент проверяет:

• Наличие валидного Scheme Reference ID (Mastercard Trace ID, Visa Transaction ID) от первой авторизации (CIT — Customer Initiated Transaction).
• Соответствие MCC и суммы (для installment — фиксированный график, для recurring — допустимый диапазон).
• Флаг recurring/installment/unscheduled в поле POS Entry Mode / MIT Indicator.
• Срок действия токена/карты на момент списания (эмитент может отклонить, если карта просрочена, даже если токен валиден — зависит от политики эмитента).
• Наличие действующего мандата (согласия держателя) — в некоторых юрисдикциях (SEPA, UK, Австралия) обязательно.

Кошельки и токенизированные платежи (Apple Pay, Google Pay, Mir Pay, Samsung Pay)

Здесь PAN не передаётся в открытом виде. Эмитент получает:

• DPAN (Device PAN) — токен, привязанный к конкретному устройству (Secure Element / TEE).
• Dynamic Cryptogram — разовый криптограмма, генерируемая безопасным элементом для каждой транзакции (EMV-режим).
• Device Attestation — подтверждение целостности ОС (не джейлбрейк/рут, актуальные патчи, биометрия включена).
• Wallet Provider Data — идентификатор кошелька, версия SDK, флаги аутентификации пользователя (FaceID/TouchID/PIN/пароль).

Проверка криптограммы и=device attestation заменяет проверку CVV и даёт лиабилити шифт на эмитента.

Cross-border и валютные транзакции

Дополнительные проверки:

• Соответствие страны эмитента (BIN country) и страны мерчанта (acquirer country) — флаг cross-border.
• Наличие у эмитента международного лицензирования (Visa International, Mastercard Worldwide) и корреспондентских связей.
• Валютный контроль (для РФ — 115-ФЗ, требования к коду валюты, основанию платежа, паспортным данным при превышении порогов).
• Санкционные списки (SDN, OFAC, EU, UK, РФ) — скрининг отправителя/получателя/мерчанта/БИК.

Почему один и тот же платёж может пройти или не пройти: факторы вариативности

Решение эмитента не детерминировано только набором полей в запросе. На результат влияют:

• Время суток и нагрузка на антифрод — в пиковые часы/праздники пороги могут быть уже.
• История конкретного держателя — новый клиент без истории получает более строгий скрининг.
• Версия 3DS — 3DS 1.0 (устарел, не поддерживается с октября 2022) vs 3DS 2.1/2.2/2.3 — разные данные в запросе, разная логика frictionless.
• Stand-in processing — если эмитент недоступен, платёжная система может принять решение сама по своим правилам (обычно консервативнее).
• Настройки мерчанта у эквайера — флаги force 3DS, игнорировать AVS, разрешить partial approval, retry logic.
• Регуляторные требования — PSD2 SCA (ЕС/UK), RBI (Индия), CBN (Нигерия), 115-ФЗ/161-ФЗ (РФ) — обязательные аутентификация и отчётность.

Что может проверить мерчант до отправки на авторизацию (pre-auth validation)

Снижение отказов на стороне эмитента начинается с качества запроса. Мерчант/эквайер/платёжный шлюз могут проверить:

1. Формат PAN (Luhn, длина, BIN в разрешенном диапазоне).
2. Срок действия: не просрочен, не истекает в текущем месяце (для подписок — минимум на период следующего списания).
3. CVV: присутствует для CNP, длина 3/4 символа, только цифры.
4. 3DS: инициализирован challenge/frictionless, получен валидный CAVV/AAV, ECI соответствует ожидаемому (05/02/06 для Visa, 02/01 для Mastercard).
5. AVS: передан ZIP и/или адрес, если мерчант в регионе с обязательным AVS.
6. Токен: не отозван, привязан к этому мерчанту/устройству, криптограмма свежая (не replay).
7. MCC: соответствует реальной деятельности мерчанта (неверный MCC — риск штрафов и отказов).
8. MIT: для повторных платежей — есть reference к CIT, верный флаг типа, мандат актуален.
9. Сумма и валюта: в допустимых пределах для данного MID/терминала, валюта поддерживается эквайером.
10. Идемпотентность: уникальный order_id / transaction_id для предотвращения двойных списаний при ретраях.

Типичные ошибки интеграции, приводящие к отказам

• Передача устаревшего PAN вместо токена при наличии токенизации — эмитент видит «сырой» номер, который может быть в базе компрометации, и повышает риск-скор.
• Отсутствие 3DS при обязательном SCA (ЕС, UK, РФ для определённых MCC/сумм) — автоматический отказ с кодом 65/57/05.
• Неверный MIT Indicator — повторное списание помечено как CIT (customer present) без 3DS — эмитент считает это попыткой обхода SCA.
• Повторная попытка с тем же order_id без отмены первой авторизации — дубль, отклоняется как duplicate transaction (код 94).
• Передача тестовых карт (BIN тестовых диапазонов) в продакшн — отклоняются эмитентом/платёжной системой.
• Игнорирование soft decline (код 1A/65 для 3DS) — мерчант не инициирует challenge, а просто повторяет запрос — бесконечный цикл отказов.
• Неактуальные BIN-таблицы — новые диапазоны (например, BIN 8-значные, новые BINы «Мир», токенизированные BINы) не распознаются, карта определяется как неизвестная/препайд/кредитная неверно.

Как интерпретировать код отказа и что делать дальше

Код ответа (Response Code / Auth Response Code) — главный ориентир. Алгоритм действий:

1. Коды 00, 08, 10, 11, 16 — одобрено (00 — полное одобрение, 08 — с подписью, 10 — частичное одобрение, 11 — VIP, 16 — частичное с VIP). Действие: зафиксировать авторизацию, выполнить capture/clearing в срок (обычно 7 календарных дней).
2. Коды 01, 02 (Refer to Issuer) — эмитент просит связаться голосово. На практике в e-com не используется. Действие: отклонить, попросить клиента позвонить в банк.
3. Коды 05, 57, 58, 59, 63 — жёсткий отказ (фрод, запрет карты/мерчанта, безопасность). Действие: не повторять без изменения параметров (новая карта, 3DS challenge, другой мерчант).
4. Коды 14, 54, 63 (CVV) — ошибка данных. Действие: попросить клиента проверить реквизиты, ввести заново.
5. Коды 51, 61, 65 — лимиты/баланс. Действие: клиент пополняет счёт/запрашивает повышение лимита/ждёт сброса суточного лимита. Можно предложить разделить платеж или отложенную оплату (BNPL).
6. Коды 91, 96, 98 — технические ошибки. Действие: повторить через 30–60 секунд (retry с экспоненциальным бэкофом), максимум 2–3 попытки. При повторении — логировать, алертить мониторинг.

Что проверить, если процент отказов вырос

Чек-лист для мерчанта/платежного менеджера:

• Сравнить распределение кодов отказов за неделю/месяц — выявить доминирующую причину.
• Сегментировать по BIN (эмитенты) — иногда один банк даёт 30% отказов 05/59 при нормальной конверсии по остальным.
• Проверить версию 3DS и процент frictionless vs challenge — резкий рост challenge может говорить о проблемах с device fingerprint или репутацией мерчанта.
• Аудит MIT/COF: все ли повторные платежи имеют валидный Scheme Reference ID и корректные флаги.
• Проверить актуальность BIN-таблиц у шлюза/эквайера (обновление минимум раз в месяц).
• Проанализировать AVS-результаты (если применимо) — высокий процент «N» (no match) может говорить о проблемах с формой ввода адреса.
• Проверить, не изменились ли MCC у мерчанта у эквайера без уведомления (например, после ребрендинга/смены деятельности).
• Связаться с ключевыми эмитентами через эквайера — запросить отчёт по отказам (issuer decline report) с детализацией по reason codes.

Резюме: главные принципы для повышения конверсии авторизации

Авторизация — это диалог мерчанта с эмиентом через платёжную систему. Качество переданных данных напрямую определяет решение. Главные правила:

• Передавайте максимум доступных полей: PAN/токен, срок, CVV (для CNP), 3DS-криптограмму, AVS-данные, корректный MCC, MIT-маркеры, device fingerprint.
• Используйте токенизацию (Network Tokens) — она повышает одобрения на 2–5% за счёт актуальности реквизитов и лиабилити шифта.
• Настройте 3DS 2.x с правильной логикой challenge/frictionless и обработкой soft decline (код 1A/65).
• Ведите BIN-базу в актуальном состоянии — это база для правильного роутинга, определения типа карты и лимитов.
• Монитьте коды отказов в реальном времени, сегментируйте по эмитентам, MCC, странам, типам карт.
• Для повторных платежей строго соблюдайте протокол MIT: reference к CIT, верные флаги, актуальные мандаты.
• Не повторяйте запрос без изменений после жёстких отказов (05, 57, 59, 63) — это ухудшает репутацию MID.

FAQ: частые вопросы о проверяемых данных

Проверяет ли эмитент имя держателя при онлайн-платеже?

Не всегда. Имя передаётся в поле Cardholder Name, но большинство эмитентов не сверяют его побуквенно с анкетой. Оно используется в 3DS (показывается держателю для подтверждения) и при ручной ревизии. Ошибка в имени редко бывает единственной причиной отказа.

Почему платёж проходит с неверным CVV?

Возможные причины: эмитент отключил проверку CVV для данного BIN/типа карты; используется токенизация (DPAN) с криптограммой, которая заменяет CVV; мерчант настроен на force 3DS, и эмитент одобрил по результатам 3DS, игнорируя CVV; технический сбой на стороне эмитента (редко). Не рассчитывайте на это — всегда передавайте верный CVV.

Что такое Scheme Reference ID и зачем он нужен?

Уникальный идентификатор первой авторизации (CIT), выданный платёжной системой (Visa Transaction ID, Mastercard Trace ID). Обязателен для всех последующих MIT (подписки, отложенные списания, unscheduled). Без него эмитент не может связать повторный платёж с исходным согласием держателя и часто отклоняет.

Влияет ли IP-адрес покупателя на авторизацию?

Да. IP передаётся в 3DS (device fingerprint) и может анализироваться антифродом эмитента/эквайера отдельно. VPN/прокси/хостинговые IP, несоответствие страны IP стране карты/мерчанта — повышают риск-скор и вероятность challenge или отказа.

Может ли эмитент отклонить платёж из-за MCC мерчанта?

Да. Эмитент настраивает правила: блокировать гемблинг (7995), крипту (6051), ПОД (6540), взрослый контент (5967) и др. Также возможны лимиты по MCC (например, не более 5000 руб/мес на такси 4121). MCC должен соответствовать реальной деятельности — неверный MCC ведёт к штрафам и повышенному скринингу.

Материал носит информационный характер и описывает общие принципы работы платёжных систем. Конкретные правила авторизации, коды отказов, лимиты и требования к полям зависят от эмитента, платёжной системы, юрисдикции, типа карты и настроек мерчанта у эквайера. Для решения вопросов по конкретным отказам или настройке интеграции обратитесь к технической поддержке вашего эквайера/платёжного шлюза и изучите актуальную документацию Visa, Mastercard, НСПК («Мир») и местного регулятора.