Когда покупатель вводит данные своей банковской карты на сайте магазина, запускается цепочка взаимодействий между несколькими участниками платёжной экосистемы. Цель этого процесса — убедиться, что карта действительна, на счёте достаточно средств и транзакция не выглядит подозрительной. Если авторизация прошла успешно, магазин позже может захватить (capture) средства и завершить расчёт (settlement). Ниже описано, что происходит на каждом этапе, какие факторы влияют на результат и что стоит учитывать обе стороны сделки.
- Основные участники авторизации
- Последовательность шагов авторизации
- Что происходит после успешной авторизации
- Роль 3‑D Secure и токенизации
- Типичные причины отказа авторизации
- Что должен проверять продавец
- Что должен учитывать покупатель
- Типичные ошибки и как их избегать
- Для продавцов
- Для покупателей
- Сценарии «если …, то …»
- Практический следующий шаг
Основные участники авторизации
В типичной схеме задействованы четыре стороны:
- Покупатель (держатель карты) — вводит реквизиты карты на странице оплаты.
- Интернет‑магазин (торговец) — получает данные и передаёт их платёжному шлюзу.
- Платёжный шлюз и процессор (acquirer) — шифрует информацию, формирует запрос авторизации и отправляет его в платёжную сеть.
- Банк‑эмитент (выпустивший карту) — проверяет доступность средств, действует ли карта и не отмечена ли она как подозрительная, затем возвращает ответ (одобрено/отклонено).
Иногда в цепочке появляется дополнительный слой — сервис 3‑D Secure (например, Verified by Visa, Mastercard SecureCode), который добавляет аутентификацию держателя карты через пароль, SMS‑код или биометрию.
Последовательность шагов авторизации
- Ввод данных покупателем. На странице оформления заказа покупатель указывает номер карты, дату окончания действия, код CVV/CVC и, при необходимости, имя держателя. Современные шлюзы часто используют токенизацию: вместо реального номера карты в системе магазина сохраняется уникальный токен, а сам номер никогда не попадает на серверы торговца.
- Передача в платёжный шлюз. Магазин отправляет зашифрованный блок данных (обычно через TLS) своему платёжному провайдеру. Шлюз добавляет идентификатор торговца и формирует запрос в соответствии со стандартом ISO 8583.
- Обращение к платёжной сети. Шлюз направляет запрос adquirеру (банку‑эквайеру), который в свою очередь пересылает его в платёжную сеть Visa, Mastercard, МИР или другую, в зависимости от логотипа на карте.
- Запрос в банк‑эмитент. Платёжная сеть идентифицирует банк‑эмитент по первым шести цифрам номера карты (BIN/IIN) и передаёт запрос авторизации ему.
- Проверка и формирование ответа. Банк‑эмитент проверяет:
- соответствие формата и контрольных сумм номера карты;
- не заблокирована ли карта (утеря, кража, подозрение на мошенничество);
- доступность достаточного баланса или кредитного лимита;
- соответствие лимитам по операциям и географии (если настроены);
- проходит ли транзакция проверку на подозрительность (например, система антифрод).
- Возврат ответа через цепочку обратно. Ответ проходит обратно через платёжную сеть, adquirер и шлюз до магазина. Если ответ положительный, магазин получает авторизационный код и может считать, что резерв средств на карте сделан. Если ответ отрицательный, транзакция прерывается и покупатель получает сообщение об отказе.
На основе этих проверок банк формирует ответный код: «00» — одобрено, либо один из кодов отказа (например, 05 — не honour, 51 — недостаточно средств, 54 — просроченная карта, 62 — ограниченная карта и т.д.).
Что происходит после успешной авторизации
Авторизация сама по себе не списывает деньги с карты, а лишь блокирует (резервирует) необходимую сумму до момента окончательного расчёта. Фактическое списание происходит позже в два этапа:
- Capture (захват). Магазин отправляет запрос на захватывание авторизованной суммы. Это может быть сделано сразу после авторизации (автоматический capture) или отложено, например, когда товар готов к отгрузке.
- Settlement (расчёт). После захвата средства переводятся от банка‑эмитент через платёжную сеть и adquirер на счёт торговца. Время settlement обычно составляет от одного до трёх рабочих дней, в зависимости от правил платёжных систем и банков.
Роль 3‑D Secure и токенизации
Для снижения риска мошенничества многие банки и платёжные системы требуют дополнительной аутентификации держателя карты. Протокол 3‑D Secure версии 2 (3DS2) позволяет передавать больше данных о устройстве и поведении пользователя, что улучшает шансы на бесшовную аутентификацию (например, push‑уведомление в банковском приложении) и уменьшает количество отказов из‑за ложных срабатываний антифрод.
Токенизация заменяет реальный номер карты на уникальный идентификатор, который бесполезен для злоумышленников даже если его перехватят. Это особенно важно для магазинов, которые хранят данные карт для регулярных платежей (подписки). Токен привязан к конкретному торговцу и не может быть использован elsewhere.
Типичные причины отказа авторизации
Отказ может быть вызван как действиями держателя карты, так и техническими или политическими ограничениями. Наиболее частые причины:
- Недостаточно средств или превышение кредитного лимита.
- Карта просрочена, заблокирована или отмечена как украденная.
- Неправильно введён код CVV/CVC или дата окончания действия.
- Транзакция отклонена системой антифрод из‑за необычного места, суммы или частоты операций.
- Ограничения по типу карты (например, только для внутренних операций) или по Merchant Category Code (MCC).
- Технические сбои в коммуникации между шлюзом и банком‑эмитентом (таймауты, ошибки формата).
При получении кода отказа продавец может посмотреть его значение в документации платёжного шлюза и, при необходимости, предложить покупателю другой способ оплаты или уточнить данные карты.
Что должен проверять продавец
Для минимизации числа отказов и мошеннических транзакций торговец может:
- Использовать проверенный платёжный шлюз, поддерживающий токенизацию и 3DS2.
- Настраивать правила антифрод (например, лимиты по сумме, количеству попыток, географии) в соответствии с профилем своего бизнеса.
- Сохранять только токены, а не полные номера карт, и обеспечивать соответствие требованиям PCI DSS (хотя бы на уровне SAQ A-EP, если данные не попадают на свои серверы).
- Отслеживать процент успешных авторизаций и анализировать причины отказов, чтобы своевременно корректировать настройки.
- Чётко информировать покупателя о том, какие данные нужны и почему может потребоваться дополнительная аутентификация (SMS‑код, push‑уведомление).
Что должен учитывать покупатель
Покупатель может повысить вероятность успешной оплаты, следя за следующими моментами:
- Убедиться, что карта не просрочена и на счёте достаточно средств (или доступный кредитный лимит).
- Вводить данные внимательно: проверять номер, дату и CVV/CVC.
- Если банк требует дополнительной аутентификации, быть готовым подтвердить операцию через SMS, push‑уведомление или код из приложения.
- При повторных отказах проверить, не установлены ли лимиты на онлайн‑транзакции в банковском приложении или не активирован ли режим блокировки международных платежей (если покупка делается за рубежом).
- Следить за уведомлениями банка о подозрительных операциях — иногда банк сам блокирует подозрительную транзакцию и присылает запрос на подтверждение.
Типичные ошибки и как их избегать
Ниже перечислены ситуации, которые часто приводят к проблемам, и способы их предотвращения.
Для продавцов
- Хранение полных номеров карт. Нарушает PCI DSS и увеличивает риск утечки. Решение: использовать токенизацию и не сохранять PAN.
- Отсутствие поддержки 3DS2. Может привести к большому числу отказов из‑за срабатывания антифрод. Решение: подключить шлюз, поддерживающий актуальную версию 3DS.
- Неправильная обработка кодов отказа. Если магазин считает любой отказ как техническую ошибку и повторяет запрос без анализа, это может привести к блокировке карты эмитентом. Решение: логировать коды отказа и при определённых кодах (например, 05, 51) предлагать альтернативный способ оплаты.
Для покупателей
- Повторные попытки с теми же данными после отказа. Если отказ связан с недостатком средств или блокировкой карты, повторные запросы лишь усугубят ситуацию. Решение: проверить баланс или связаться с банком перед повторной попыткой.
- Ввод данных на ненадёжном сайте. Фишинговые страницы могут захватить реквизиты карты. Решение: проверять наличие HTTPS, домен магазина и репутацию ресурса.
- Игнорирование уведомлений о необходимости аутентификации. Некоторые банки требуют подтверждения через приложение; если покупатель пропустит уведомление, транзакция будет отклонена. Решение: держать телефон под рукой и включать уведомления от банка.
Сценарии «если …, то …»
Ниже представлены типовые ситуации и рекомендации действий.
| Ситуация | Что проверить | Что делать |
|---|---|---|
| Получен код отказа 51 (недостаточно средств) | Баланс на карте или кредитный лимит | Попросить покупателя использовать другую карту или способ оплаты (например, банковский перевод) |
| Получен код отказа 05 (не honour) | Статус карты (не заблокирована ли, не отмечена ли как мошенническая) | Связаться с банком‑эмитентом для уточнения; предложить альтернативный платёж |
| Требуется дополнительная аутентификация (3DS), но покупатель не видит запрос | Настройки браузера (блокировка pop‑up, отключённый JavaScript) | Попросить покупателя проверить всплывающее окно или включить скрипты; при необходимости предложить оплату через другой канал |
| Авторизация прошла, но захват не выполнен в течение нескольких дней | Настройки шлюза (автоматический vs ручной capture) | Убедиться, что захват настроен правильно; если товар ещё не отгружен, можно оставить авторизацию активной (обычно до 7‑10 дней) и затем выполнить захват |
Практический следующий шаг
Если вы — владелец интернет‑магазина и хотите настроить приём карт:
- Выберите платёжного провайдера, поддерживающего токенизацию и 3DS2, и изучите его документацию по интеграции (API или готовый плагин для вашей CMS).
- Настройте тестовый режим (sandbox) и выполните несколько пробных платежей с тестовыми картами, предоставляемыми провайдером, чтобы убедиться, что авторизация, захват и возврат работают корректно.
- Включите логирование кодов ответа и настройте оповещения о высоком проценте отказов, чтобы быстро реагировать на изменения в работе банка‑эмитента или антифрод‑систем.
- Проведите внутренний аудит соответствия требованиям PCI DSS (минимальный уровень SAQ A‑EP, если вы не храните PAN).
- Оформите 명확ную страницу помощи для покупателей, где описано, что делать при получении кода отказа или при запросе дополнительной аутентификации.
Если вы — покупатель и столкнулись с отказом при оплате:
- Запишите код отказа, если он показан (обычно отображается в сообщении шлюза).
- Проверьте баланс/лимит карты, срок действия и правильность введённых данных.
- Если причина неясна, свяжитесь с банком‑эмитентом и уточните, есть ли блокировки или лимиты на онлайн‑транзакции.
- При необходимости используйте другую карту или альтернативный способ оплаты (например, электронный кошелёк или банковский перевод).
Материал носит информационный характер и не является индивидуальной финансовой консультацией. При принятии решений, связанных с платежными операциями, рекомендуется уточнять актуальные условия у вашего банка или платёжного провайдера.
