Эквайринг: Авторизация по банковской карте, протоколы и узлы обмена. Часть 1, «POS to HOST»

Введение

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

Рассматриваться будут отнюдь не модели терминалов (например, Ingenico/Verifone/Castles и т.д.) и не их классификация по типам связи (например, Ethernet/GPRS/Wi-Fi и т.д.). Таких материалов в Сети на данный момент много. Мы коснемся именно «внутренней составляющей» платежного оборудования, т.е. того ракурса, под которым POS-терминалы видят Платежные системы и EMVCo.

Терминология

Авторизация — процесс обмена данными между участниками операции по банковской карте или другому платежному средству (например, мобильному кошельку и т.д.). Стандартная цепочка обмена выглядит следующим образом: Эквайрер (см. ниже) отправляет авторизационный запрос в ПС, ПС - эмитенту. Эмитент выполняет все необходимые проверки, такие как проверки безопасности, проверки доступности средств на карточном счете и другие, на основании которых отправляется ответ (положительный или отрицательный) на авторизационный запрос. Ответ на авторизационный запрос отправляется обратным маршрутом. То есть, сначала в ПС а затем эквайреру.

POS-терминал (POS - Point Of Service) — устройство, обеспечивающее техническую возможность обслуживания карт и других платежных средств.

Эмитент — финансовый институт (банк или иная финансовая организация), выпустивший (эмитировавший) карту.

Эквайрер — финансовый институт (банк или иная финансовая организация), обеспечивающий обслуживание карт мерчантом.

Мерчант — торгово-сервисное предприятие (далее ТСП), имеющее техническую возможность принимать карты.

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

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

Другое относительно распространенное наименование ПЦ — «Банковский хост», или просто «хост» (от англ. Host - букв. «хозяин»). То есть узел, играющий роль сервера в рамках классической клиент-серверной архитектуры. Далее по тексту мы будем использовать как аббревиатуру ПЦ, так и термин «хост» с его производными.

Протокол ISO 8583, основные положения

ISO 8583 - протокол, стандартизирующий онлайн-обмен финансовыми сообщениями при использовании банковских карт и иных платежных средств. Фактически, является базовым протоколом в этой области.

Поскольку протокол ISO 8583 достаточно известен, не будем останавливаться на его подробном рассмотрении, а интересующиеся могут почитать, например, вот здесь, а также поискать в Интернете.

Основные моменты следующие:

1) Идентификатор типа сообщения (Message Type Identifier (MTI)) — значение из четырех цифр. Каждая цифра функциональна, и содержит в себе информацию о версии протокола (1-я цифра), классе сообщения (2-я цифра), функциональном назначении (3-я цифра) и инициаторе операции (4-я цифра). Например, MTI=0110, где:

• Первая цифра 0 — версия протокола 1987 г. (реально используются две версии: 0 = версия 1987 г., 1 = версия 1993 г. При этом ПС Mastercard, Visa, Union Pay и НСПК работают на версии 1987 г., ПС American Express - на версии 1993 г.).
• Вторая цифра 1 — класс сообщения (основные возможные значения: 1 = авторизация, 2 = финансовое, 3 = действие с файлами данных, 4 = отмена, 5 = реконсиляция (выгрузка/сверка), 6 = административное, 8 = управление сетью).
• Третья цифра 1 = ответ (основные возможные значения: 0 = запрос, 1 = ответ, 2 = эдвайс (уведомление), 3 = ответ на эдвайс).
• Четвертая цифра 0 = обмен инициирован эквайрером (основные возможные значения: 0 = обмен инициирован эквайрером, 1 = репит от эквайрера (повторное сообщение, инициированное эквайрером), 2 = обмен инициирован эмитентом, 3 = репит от эмитента (повторное сообщение, инициированное эмитентом), 4 = обмен инициирован ПС, 5 = репит от ПС (повторное сообщение, инициированное ПС)).

2) Битовые карты (так называемые «Bitmap»). Всего их три:

• First Bitmap - может включать в себя элементы данных (они же «поля») с 1 по 64.
• Second Bitmap - может включать в себя поля 65 - 128.
• Third Bitmap - может включать в себя поля 129 - 192.

3) Элементы данных. Элементы данных, т.е., поля и различные их комбинации позволяют всем участникам расчетов однозначно идентифицировать тот или иной тип сообщения. При этом одним из ключевых элементов является Поле 3 (Processing Code), а точнее, первые две его позиции (Тип транзакции, Transaction Type). Их наполнение может варьироваться в зависимости от онлайн-интерфейса (т.е. спецификации) той или иной ПС. Однако основные значения таковы:

• 00 - Покупка.
• 01 - Выдача наличных в банкомате.
• 02 - Дебетование по кредитовой операции, отправленной ранее.
• 09 - Покупка с выдачей наличных.
• 20 - Возврат.
• 30 - Запрос баланса.

То есть, допустим, если эмитент получил сообщение с MTI 0100, в котором первые 2 элемента Поля 3 = 00, то он идентифицирует его как Покупку; если Поле 3 = 09, то как Покупку с выдачей наличных, и т.д.

Приведенного выше должно быть достаточно для составления базового представления о принципах работы протокола ISO 8583. Структурное наполнение полей, повторим, является уникальным для каждого типа операции и для каждой ПС, и их рассмотрение выходит за рамки данного материала.

Авторизация: Структура обмена

Процесс авторизации структурно делится на две составляющие:

1. Обмен данными между POS-терминалом и хостом (ПЦ) эквайрера (POS to Host, или P2H).
2. Обмен данными между эквайрером, ПС и эмитентом (Host to Host, H2H).

Ниже рассмотрим первый из описанных этапов.

P2H (POS to HOST)

Информационные обмен между POS-терминалом и ПЦ. Именно он инициирует всю информационную цепочку в рамках эквайринга.

P2H может выполнятся как по внутренним протоколам конкретного эквайрингового хоста, так и базироваться на протоколе ISO 8583. В этом случае подразумевается кастомизация данного протокола, одной из характерных особенностей которой является использование отсутствующего в спецификациях ПС Поля 24 (Код функции, Function Code), анализируя которое хост «понимает», как именно следует обработать данный-конкретный запрос. Заполнение Поля 24 зависит от спецификации вендора (разрабочика/поставщика) того или иного ПЦ, поэтому опишем лишь общий принцип.

Допустим, POS отправил сообщение 0200, в котором Поле 3 = 00x и Поле 24 = 200. Хост «поймет», что это операция Покупки и отправит его на обработку в соответствии с прочими условиями, такими как принадлежность карты (On-Us/Off-Us, т.е. карта «наша» (On-Us) либо стороннего эмитента(Off-Us)), ПС и т.д.

Другой пример: POS прислал сообщение 0200, в котором Поле 3 = 20x и Поле 24 = 200. Хост идентифицирует данную операцию как Возврат.

Либо: POS прислал сообщение 0400, Поле 3 = 00x, Поле 24 = 400 - это Reversal (Отмена) на полную сумму покупки. Если 0400 + Поле 3 = 00x, Поле 24 = 401 - это Reversal на часть суммы покупки. Несмотря на условность приведенных данных, полагаем что сам принцип понятен.

Другой характерной особенностью является кастомизация ряда полей протокола ISO 8583, например ранее упоминавшегося Поля 3, в котором становится допустимым использование других значений, отличающихся от таковых на онлайн-интерфейсах ПС. Тоже самое может касаться и Полей 47 и/или 48, использование которых в рамках P2H несет иную функциональность, нежели чем в спецификациях ПС. Аналогичное справедливо и относительно ряда других полей протокола ISO 8583.

Таким образом, важный момент, который следует принять во внимание, заключается в том что P2H-диалект протокола ISO 8583 НЕ ОБЯЗАН быть тождественным диалекту той или иной ПС. То есть, допустим, при обработке POS-терминалом карты Visa набор элементов в p2h-сообщении совершенно не обязательно будет соответствовать спецификации ПС Visa. При этом обмен данными с ПС в рамках Host to Host обязан выполнятся в точном соответствии с требованиями той или иной Платежной системы.

Основные типы сообщений, которые так или иначе используются всеми ПЦ, базирующимися на ISO 8583, версии 1987 г.:

• 0100 - Авторизационное сообщение.
• 0101 - Авторизационное сообщение, репит (Повтор).
• 0200 - Финансовое сообщение.
• 0201 - Финансовое сообщение, репит (Повтор)
• 0300 - Передача файлов данных (например, при выгрузке документов из журнала POS-терминала).
• 0400 - Отмена.
• 0401 - Отмена, репит (Повтор).
• 0500 - Реконсиляция (Выгрузка/Сверка итогов).
• 0800 - Тест связи. При этом ряд ПЦ использует сообщения с MTI 08xx для операции Загрузки/Смены криптографических ключей. В этом случае применяется характерный Function Code (Поле 24).

Основные типы сообщений, которые так или иначе используются всеми ПЦ, базирующимися на ISO 8583, версии 1987 г.:

• 1100 - Авторизационное сообщение.
• 1101 - Авторизационное сообщение, репит (Повтор).
• 1200 - Финансовое сообщение.
• 1201 - Финансовое сообщение, репит (Повтор)
• 1400 - Отмена.
• 1401 - Отмена, репит (Повтор).
• 1500 - Реконсиляция (Выгрузка/Сверка итогов).
• 0804 - Тест связи.

Транзакционные схемы

Ряд ПЦ и, соответственно, взаимодействующих с ними POS-терминалов допускает использование нескольких транзакционных схем. Наиболее распространенными из них являются схемы 0100/0110 и 0200/02x0.

1. Транзакционная схема 0100/0110 подразумевает, что POS-терминал отправляет на хост сообщение с MTI 0100 (Авторизация), и получает в ответ сообщение 0110 (Ответ на авторизацию). Затем, в рамках процедуры Закрытия дня у мерчанта, POS-терминал отправляет 0500-е сообщение (Сверка итогов), которое, в свою очередь, инициирует потранзакционные сообщения с MTI 03xx (Передача файлов). Уже на основании 0300-х сообщений хост формирует финансовые сообщения с MTI 02xx (Финансовые), которые записываются в Базу данных (БД) Процессингового центра. Несмотря на то, что многие эквайреры используют данную схему до сего времени, следует сказать что ее практическая необходимость заключается только в поддержке выгрузки оффлайн-транзакций (т.е., транзакций, одобренных без обращения на хост эмитента) на устройствах с необходимой конфигурацией и соответствующим Terminal Type (например, на POS с Типом 22). Во всех прочих случаях она не имеет смысла.

2. Транзакционная схема 0200/02x0 подразумевает, что POS-терминал отправляет на хост сообщение 0200 (Финансовое). При этом отпадает необходимость в отправке сообщения 0500 (Сверка), поскольку финансовое сообщение в БД уже записано в режиме реального времени. Недостаток схемы заключается в том, что в ее рамках поддержка оффлайн-операций становится полностью невозможной. Однако, если не планируется использовать оффлайн (который, напомним, в РФ и так фактически отсутствует), то схема 0200/02x0 является гораздо более надежной и предпочтительной, так как исключается риск потери журнала транзакций POS-терминала при выходе его из строя до Закрытия дня.

Таковы основные моменты в рамках обмена по P2H.

Следующая часть будет посвящена вопросам информационного обмена эквайрера с ПС и эмитентом.

Наши платежные решения