5 февраля, 2018, BIS Journal №4(27)/2017

MirAccept. Чтобы покупать с удовольствием!


Окулесский Василий

руководитель Департамента, кандидат технических наук (ООО «ЦИБИТ»)

Соловьев Евгений

эксперт (Департамент архитектуры и разработки программного обеспечения АО «НСПК»)

Введение в революцию платежных систем

Наш мир стал тотально мобильным. Это произошло незаметно – через недорогие и дорогие смартфоны и планшеты, низкие тарифы на интернет, навигаторы (спасибо, Яндекс), приложения сервисов такси, социальных сетей и мессенджеров, через сверхудобные мобильные приложения банков, электронные кошельки и т.д. и т.п. Мобильность захватила нас бесповоротно!

Мы сегодняшние – часть глобальной мобильности, элемент новой экосистемы потребления информации.

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

И слава богу, скажем мы, что дух мобильности проник в мир платежных систем! Потому что платежные системы, наконец, осознали, как необходимо догнать эту новую реальность, освоить ее, опередить конкурентов и – возглавить всеобщую мобилизацию!

Платежная система «Мир» - лидер этого движения, ее участники и поставщики программных решений активно готовятся к появлению в 2017 году нового поколения электронной коммерции под товарным знаком MirAccept. В основе нового MirAccept – спецификация EMVCo 3-D Secure, в которую платежной системой «Мир» внесены необыкновенно полезные уточнения и конкретизированы некоторые особенности реализации функций компонентов информационного обмена.

ЧТО ЭТО ТАКОЕ?

Когда мы говорим про MirAccept, то в первую очередь подразумеваем товарный знак или знак обслуживания, используемый платежной системой «Мир» для обозначения безопасной электронной коммерции (с надежной аутентификацией Держателя карты Эмитентом), когда Эмитент имеет возможность в процессе аутентификации Держателя карты принять на себя ответственность, в том числе и финансовую, за операцию Держателя карты (без обращения или с обращением к нему).

Чтобы подчеркнуть полное соответствие стандартов электронной коммерции ПС «Мир» спецификациям EMVCo применяется следующее обозначение: MirAccept (EMV 3-D Secure). Из него следует соответствие MirAccept (электронной коммерции платежной системы «Мир» с надежной аутентификацией) спецификациям EMVCo.

Товарным знаком MirAccept обозначаются:

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

ОБЩИЕ ПОЛОЖЕНИЯ

MirAccept (EMV 3-D Secure) основан на так называемой трехдоменной модели.

В этой модели домен Эквайрера и домен Эмитента связаны между собой доменом совместимости (или доменом платёжной системы) с целью обеспечения аутентификации Держателя карты «Мир» во время операции электронной коммерции на стадии проверки подлинности Держателя карты «Мир».

MirAccept (EMV 3-D Secure) поддерживает две возможности:

- Платёжную аутентификацию. Это такая проверка подлинности личности Держателя карты «Мир», которая выполняется во время операции оплаты товаров (работ, услуг) в сети Интернет (электронной коммерции).
- Неплатёжную аутентификацию. Проверка подлинности личности Держателя карты «Мир», не связанная с операциями оплаты товаров (работ, услуг) в сети Интернет (далее – операции электронной коммерции).

MirAccept (EMV 3-D Secure) должен быть доступен Держателю карты «Мир» через два клиентских интерфейса:

Клиентский интерфейс на основе загружаемого приложения ТСП. Аутентификация Держателя карты «Мир» начинается на его клиентском устройстве (смартфоне, планшете, компьютере и т.п.) во время операции электронной коммерции, в котором такую процедуру берет на себя компонент 3DS Requestor App (загружаемое приложение ТСП или иное загружаемое приложение, предоставляемое сертифицированным и зарегистрированным Платёжной системой «Мир» агентом, например, оператором электронного бумажника).
- Клиентский интерфейс на основе браузера. Аутентификация Держателя карты начинается на веб-сайте, доступ к которому Держателю карты «Мир» предоставляет браузер на его клиентском устройстве. Например, при завершении операции электронной коммерции (на стадии чекаута), на веб-сайте, открытом в браузере клиентского устройства (смартфоне, планшете, компьютере и т.п.) Держателя карты «Мир».

КРАТКИЙ ЭКСКУРС

В этой части статьи перечислены субъекты информационного обмена, необходимые для реализации протокола MirAccept (EMV 3-D Secure). Описание разделено на следующие домены:

- Домен эквайрера (Acquirer Domain) операции MirAccept (EMV 3-D Secure) начинаются в Домене эквайрера;
- Домен платёжной системы (interoperability domain) операции MirAccept (EMV 3-D Secure) маршрутизируются между доменом Эквайрера и доменом Эмитента;
- Домен Эмитента (issuer Domain). Операции MirAccept (EMV 3-D Secure) подвергаются проверке подлинности (аутентификации) в домене Эмитента.

На рисунке 1 изображено взаимодействие трех доменов и компонентов каждого из них.

Поскольку реализация информационной среды 3DS Requestor Environment может варьироваться, изображение на рисунке 1 не подразумевает какую-либо конкретную реализацию этих компонентов или порядка, в котором они взаимодействуют.

Например, в частности компонент 3DS Client может напрямую общаться с компонентом 3DS Server или компонент 3DS Server и компонент 3DS Requestor могут быть объединены в один компонент.

Внимание! Пунктирными стрелками на рисунке 1 (и на всех остальных рисунках) изображены процессы, не являющиеся частью MirAccept (EMV 3-D Secure). 3DS Requestor также не является его частью. Они приведены для большей ясности.

Рис. 1. Домены и компоненты информационного обмена MirAccept (EMV 3-D Secure)

Домен эквайрера

Домен Эквайрера состоит из следующих компонентов:

Среда 3DS Requestor Environment:

- 3DS Requestor,
- 3DS Client,
- 3DS Server;

3DS Integrator;
Acquirer (для платёжной аутентификации).

Домен платежной системы (Interoperability Domain)

Interoperability domain состоит из следующих компонентов:

- Directory Server (DS);
- Directory Server Certificate Authority (DS CA);
- Система авторизации.

Домен Эмитента

Домен Эмитента состоит из следующих компонентов:

- Держатели карт «Мир»;
- Клиентское устройство (умные часы, смартфон, планшет, ноутбук, компьютер, умный телевизор и т.п.);
Эмитент;
- Access Control Server (ACS).

КОМПОНЕНТЫ (субъекты информационного обмена) MirAccept

3DS Requestor

3DS Requestor – компонент, который инициирует сообщение AReq и который является каналом для данных MirAccept (EMV 3-D Secure), получаемых от клиентского устройства. Например, при платежной аутентификации, 3DS Requestor обычно представляет из себя веб-сервер магазина для онлайновых покупок.

3DS Requestor связан с компонентом 3DS Client через компонент 3DS Requestor App либо через метод 3DS Method / Browser на клиентском устройстве. Компонент 3DS Requestor имеет соединение с компонентом 3DS Server или же полностью интегрирован с ним.

Операция MirAccepr (EMV 3-D Secure) может быть выполнена:

- Через приложение (App-based) – компонент 3DS Requestor App интегрируется с компонентом 3DS SDK. 3DS SDK отображает пользовательский интерфейс (UI) для держателей карт.
- Через браузер (Browser-based) – компонент 3DS Requestor на основе браузера использует метод 3DS Method, чтобы собрать информацию о браузере / клиентском устройстве и предоставленную компонентом ACS страницу в формате HTML для отображения интерфейса Держателю в браузере, когда необходима Проверка (Challenge).

3DS Client

3DS Client – это компонент, расположенный на клиентском устройстве, который инициирует операцию аутентификации MirAccept (EMV 3-D Secure). Например, в операции платёжной аутентификации компонент 3DS Client интегрирован с системой чек-аута интернет-магазина, являясь для клиента частью процесса интернет-покупки.

Компонент 3DS Client может быть реализован в двух вариантах:

- Через приложение (app-based). Компонент 3DS Client фактически является компонентом 3DS SDK, который интегрирован с компонентом 3DS Requestor App и обеспечивает, таким образом, взаимодействие с держателем карты «Мир». Компонент 3DS SDK (1) собирает необходимую для протокола MirAccept (EMV 3-D Secure) информацию клиентского устройства (device information), (2) поддерживает взаимодействие с компонентом Access Control Server (ACS) для аутентификации, и (3) защищает поток данных аутентификации держателя карты «Мир».
- Через браузер (browser-based). В этом случае компонент 3DS Client –это метод 3DS Method, который интегрирован с веб-сайтом компонента 3DS Requestor и вызывается в браузере на клиентском устройстве. Метод 3DS method – это скриптовый вызов со стороны 3DS Integrator, который размещен на сайте, c которым держатель карты взаимодействует. Например, в платежной аутентификации он является страницей чек-аута интернет-магазина. Назначение метода 3DS Merthod – получить дополнительную информацию из браузера, чтобы помочь принятию решения на основе анализа рисков.

3DS Server

3DS Server – это компонент, который обеспечивает взаимодействие между средой 3DS Requestor Environment и компонентом Directory Server (DS). Компонент 3DS Server отвечает за:

- сбор необходимых данных для формирования сообщений протокола MirAccept (EMV 3-D Secure);
аутентификацию компонента DS;
- валидацию компонента DS, компонента 3DS SDK и компонента 3DS Requestor;
- обеспечение того, что содержание сообщений будет защищено.

Для того, чтобы инициировать транзакцию платежной аутентификации MirAccept (EMV 3-D Secure), компонент 3DS Server собирает необходимые элементы данных из любого или всех компонентов внутри 3DS Requestor Environment. Например, в операции платежной аутентификации информация о номере карты может быть введена держателем карточки в клиентском устройстве (смартфоне, планшете, ноутбуке, компьютере), или она может храниться в файле внутри 3DS Requestor Environment. Информация клиентского устройства (device information) захватывается компонентом 3DS Client и пересылается в компонент 3DS Server.

Вслед за платежной аутентификацией MirAccept (EMV 3-D Secure) в зависимости от конфигурации компонента 3DS Requestor, компонент 3DS Server может быть также соединен с Эквайрером и инициировать авторизационные запросы.

3DS Integrator (3DS Server и 3DS Client)

3DS Integrator – это логическая абстракция, роль которой обеспечивать функциональный интерфейс между информационными потоками сообщений среды 3DS Requestor Environment и информационными потоками сообщений MirAccept (EMV 3-D Secure).

Роль 3DS Integrator (1) представляет из себя логический комплекс из компонента 3DS Server и компонента 3DS Client, и (2) интегрирует функциональность MirAccept (EMV 3-D Secure) с бизнес функциональностью 3DS Requestor. 3DS Integrator имеет решающее значение для взаимодействия с компонентом DS и с компонентом ACS в рамках обмена аутентификационными сообщениями, а также выступает в качестве канала для результатов Проверки (Challenge), когда она выполняется.

3DS Integrator предоставляет одобренный платежной системой компонент 3DS SDK или метод 3DS Method для 3DS Requestor для интеграции в их 3DS Requestor App и / или в веб-сайт.

3DS Integrator отвечает за регистрацию ТСП (магазинов) в компоненте DS платежной системы «Мир» и, при необходимости, иных платежных систем.

После платежной аутентификации компонент 3DS Integrator может поддерживать на стороне Эквайрера возможность авторизации.

Эквайрер (для платежной авторизации)

Эквайрер является финансовым учреждением, которое:

- Заключает договоры с ТСП (магазинами) о приеме к оплате карт «Мир» и о расчетах по таким операциям;
- Определяет, будет ли ТСП принимать участие в сервисе MirAccept (EMV 3-D Secure).

После платежной аутентификации MirAccept (EMV 3-D Secure) Эквайрер выполняет свою традиционную роль:

- принимает запросы на авторизацию от ТСП;
- направляет их в систему ПС «Мир»;
- предоставляет авторизационные ответы ТСП;
- выполняет расчеты с платежной системой «Мир» и с ТСП.

Домен платежной системы (Interoperability Domain)

Interoperability domain состоит из следующих компонентов:

Directory Server (DS);
Directory Server Certificate Authority (DS CA);
Система авторизации.

Directory Server

Directory Server (DS) – компонент, который выполняет ряд следующих функций:

- Аутентификация компонента 3DS Server и компонента ACS;
- Маршрутизация сообщений между компонентом 3DS Server и компонентом ACS;
- Валидация компонента 3DS Server, компонента 3DS SDK, и компонента 3DS Requestor;
- Определение конкретных правила обработки операций (например, в частности, логотипы, таймауты и другие правила);
- Хранение данных обо всех компонентах 3DS Server и обо всех компонентах ACS;
- Контроль версий для компонента ACS и метода 3DS Method URL.

Directory Server Certificate Authority

Компонент Directory Server Certificate Authority (DS-CA) формирует открытый ключ для компонента DS, для компонента 3DS SDK и формирует сертификаты Transport Layer Security (TLS) для использования компонентами MirAccept (EMV 3-D Secure). Компонент DS CA управляется платежной системой «Мир» и обслуживает компонент DS платежной системы «Мир».

Сертификаты включают в себя:

- сертификаты TLS клиента и сервера, используемые в обмене данными между компонентом 3DS Server и компонентом DS, а также между компонентом DS и компонентом ACS;
- сертификаты, используемые для подписи сообщений, передаваемых из компонента ACS в компонент 3DS SDK.

Авторизационная система ПС «Мир» (ОПКЦ)

Авторизационная система ПС «Мир» (ОПКЦ) выполняет свою традиционную роль после платежной аутентификации, которая включает в себя следующее:

Получение авторизационных запросов от Эквайрера;
Маршрутизация авторизационных запросов Эмитенту;
Предоставление авторизационных ответов от Эмитента Эквайреру;
Выполнение клиринга и расчетов для Эмитентов и Эквайреров.

Домен Эмитента

Домен Эмитента состоит из следующих компонентов:

- Держатели карт «Мир»;
- Клиентское устройство (умные часы, смартфон, планшет, ноутбук, компьютер, умный телевизор и т.п.);
- Эмитент;
- Access Control Server (ACS).

Держатель карты «Мир»

Держатель карты «Мир» предоставляет платежную информацию через клиентское устройство. В случае необходимости Проверки (Challenge) держателю карты «Мир» будет предложено предоставить дополнительную информацию для подтверждения подлинности (аутентификации).

Клиентское устройство

Клиентское устройство имеет возможность запуска приложения (компонента 3DS Requestor App) или показа веб-сайта в своём браузере, который будет использоваться для аутентификации MirAccept (EMV 3-D Secure), когда это требуется.

Компоненты MirAccept (EMV 3-D Secure) среды 3DS Requestor Environment на клиентском устройстве зависят от модели:

- App-based (на основе приложения) – приложение 3DS Requestor App, в которое встроен компонент 3DS SDK;
- Browser-based (на основе браузера) – браузер, использующий  метод 3DS Method.

Эти компоненты имеют особую связь с компонентом 3DS Requestor и с компонентом 3DS Server.

Эмитент

Эмитент является финансовым учреждением, которое:

- Имеет договорные отношения с держателем карты «Мир» (одной или нескольких);
- определяет диапазоны номеров карт «Мир», имеющих право на участие в программе безопасной электронной коммерции MirAccept (EMV 3-D Secure);
- предоставляет данные о диапазонах номеров карт компоненту Directory Server (DS), для добавления.

Access Control Server (ACS)

Компонент ACS содержит правила аутентификации и контролируется эмитентом. Функции компонента ACS включают в себя:

- Проверка того, что данный номер карты имеет право на аутентификацию MirAccept (EMV 3-D Secure);
- Проверка того, что используемый тип клиентского устройства имеет право на аутентификацию MirAccept (EMV 3-D Secure);
- Аутентификация держателя карты «Мир» в конкретной операции.

В то время как перечисленные функции могут принадлежать к одному логическому компоненту ACS, их реализация может быть разделена по функциям и иным принципам (например, по диапазонам номеров карт) между несколькими физическими серверами.

СООБЩЕНИЯ MirAccept

Этот раздел знакомит с сообщениями, определенными в протоколе MirAccept (EMV 3-D Secure).

Сообщение Аутентификационный Запрос (AReq)

Сообщение Аутентификационный Запрос (AReq) является начальным сообщением в информационном потоке MirAccept (EMV 3-D Secure). Компонент 3DS Server формирует сообщение AReq в момент, когда запрашивается аутентификация держателя карты «Мир». Сообщение может содержать (а) информацию о держателе карты «Мир», (б) платежную информацию, а также (в) информацию клиентского устройства (device information) по данной конкретной операции. Для каждой операции MirAccept (EMV 3-D Secure) предусмотрено только одно сообщение AReq.

Сообщение Аутентификационный Ответ (ARes)

Сообщение Аутентификационный Ответ (ARes) является ответом компонента ACS Эмитента на сообщение AReq. Оно может указывать на то, что, (а) либо держатель карты был аутентифицирован, либо (б) что требуется взаимодействие с держателем карты для завершения аутентификации - Проверка (Challenge). Для каждой операции предусмотрено только одно сообщение ARes.

Сообщение Проверочный (challenge) Запрос (CReq)

Сообщение Проверочный (challenge) Запрос (CReq) дает старт взаимодействию с держателем карты в информационном потоке Проверки (Challenge) и может быть использовано для передачи результатов аутентификации держателя карты.

App-based (на основе приложения) – сообщение CReq посылается компонентом 3DS SDK. Для завершения Проверки (Challenge) может потребоваться два и даже более сообщений CReq, чтобы обеспечить информационный обмен компонента ACS с держателем карты в попытке его аутентифицировать.
Browser-based (на основе браузера) – сообщение CReq посылается компонентом 3DS Server. Для каждой Проверки (Challenge) предусмотрено только одно сообщение CReq.

Сообщение Проверочный (challenge) Ответ (CRes)

Сообщение Проверочный (challenge) Ответ (CRes) является ответом компоненту ACS на CReq. Сообщение CRes может содержать результат аутентификации держателя карты или, в случае операции на основе приложения (App-based), содержать указание на то, что, для аутентификации держателя карты нужны дополнительные действия.

App-based (на основе приложения) – Элементы данных сообщения CRes обеспечивают необходимые данные для компонента 3DS SDK, позволяющие создать и отобразить пользовательский интерфейс (UI) для Проверки (Challenge). Чтобы выполнить аутентификацию держателя карты, на одну операцию сообщений CRes может быть два или более.
Browser-based (на основе браузера) – сообщение CRes содержит результат аутентификации и завершает Проверку (Challenge) держателя карты. На одну операцию может быть только одно сообщение CRes.

Сообщение Результат-Запрос (RReq)

Сообщение Результат-Запрос (RReq) передает результат аутентификации. Сообщение направляется компонентом ACS через компонент Directory Server (DS) для компонента 3DS Server. Для каждой операции предусмотрено только одно сообщение RReq. Сообщение RReq присутствует только в том случае, если при выполнении аутентификации держателя карты требуется выполнить Проверку (Challange).

Сообщение Результат-Ответ (RRes)

Сообщение Результат-Ответ (RRes) подтверждает получение сообщения RReq. Оно направляется компонентом 3DS Server через компонент DS для компонента ACS. Для каждой операции предусмотрено только одно сообщение RRes. Сообщение RRes присутствует только в том случае, если при выполнении аутентификации держателя карты требуется выполнить Проверку (Challange).

Сообщение Подготовка-Запрос (PReq)

Сообщение Подготовка-Запрос (PReq) направляется компонентом 3DS Server компоненту DS для (а) запроса информации о версиях, поддерживаемых доступными компонентами ACS, и, (б) если хоть один из них существует, то и связанный 3DS Method URL. Сообщение Подготовка-Запрос (PReq) не является частью информационного потока аутентификации MirAccept (EMV 3-D Secure).

Сообщение Подготовка-Ответ (PRes)

Сообщение Подготовка-Ответ (PRes) является ответом компонента DS на сообщение PReq. Компонент 3DS Server может использовать сообщение PRes для сохранения информации о версиях, поддерживаемых доступными компонентами ACS, и, если хоть один таковой существует, сохранять информацию о соответствующем 3DS Method URL. Сообщение Подготовка-Ответ (PRes) не является частью информационного потока аутентификации MirAccept (EMV 3-D Secure).

Сообщение об ошибке

Это сообщение (error message) используется для предоставления дополнительной информации об ошибке, возникшей в процессе обработки сообщений между компонентами 3DS Server, DS и ACS.

ИНФОРМАЦИОННЫЕ ПОТОКИ MirAccept

В данном разделе статьи приводится обзор информационных потоков аутентификации, определенных в MirAccept (EMV 3-D Secure).

Информационный поток Frictionless Flow

Информационный поток Frictionless Flow начинает операцию MirAccept (EMV 3-D Secure) и состоит из сообщения AReq и из сообщения ARes.

Информационный поток Frictionless Flow не требует дальнейшего взаимодействия с держателем карты для успешной аутентификации и завершает процесс аутентификации MirAccept (EMV 3-D Secure).

Информационный поток Challenge Flow

В дополнение к сообщениям AReq и ARes, составляющим вместе информационный поток Frictionless Flow, информационный поток Challenge Flow состоит из сообщений CReq, CRes, RReq и RRes.

Если компонент ACS определяет, что требуется дальнейшее прямое взаимодействие с Держателем карты для завершения аутентификации, то информационный поток Frictionless flow переходит в информационный поток Challenge Flow. Например, Проверка (Challenge) может оказаться необходимой, если операция будет считаться высоко рискованной, то есть превышающей определенный порог, или требующей более надежного уровня аутентификации из-за требований законодательств определенных стран.

Компоненты 3DS Requestor решают, следует ли продолжить Проверку (Challenge) или следует прекратить процесс аутентификации MirAccept (EMV 3-D Secure).

Если проверка прекращается, то операция выходит из-под контроля MirAccept и продолжается как операция электронной коммерции с ответственностью на Эквайрере и магазине за ее финансовые и иные возможные последствия.

Если же проверка продолжается и выполняется успешно, то операция MirAccept, будучи успешно авторизованной, будет обеспечивать защиту Эквайреру и магазину.

Информационный поток Frictionless Flow. Пошаговое описание.

На рисунке 2 приведены шаги информационного потока.

Внимание! Пунктирными стрелками на рисунке 2 (и на всех остальных рисунках) изображены процессы, не являющиеся частью MirAccept (EMV 3-D Secure). Внимание! 3DS Requestor также не является его частью. Они приведены для большей ясности.

Рис. 2. Frictionless Flow

Поток Frictionless Flow содержит следующие шаги:

Старт: держатель карты. Держатель карты «Мир» инициирует операцию на клиентском устройстве. Держатель карты «Мир» предоставляет информацию, необходимую для аутентификации (ее либо вводит держатель карты, либо она уже присутствует в файле в системе ТСП).

(1) 3DS Requestor Environment. Компонентами среды 3DS Requestor Environment собирается cоответствующая необходимая MirAccept (EMV 3-D Secure) информация и предоставляется компоненту 3DS Server для включения в сообщение AReq.

Как предоставлена ​​эта информация, и от какого компонента она поступила, зависит от следующего

- Device Channel (канал) – App-based (на основе загружаемого приложения предприятия торговли/услуг) или Browser-based (на основе браузера в клиентском устройстве).
- Message Category (категория сообщения) – Payment (платежное) или Non-Payment (неплатежное).
- Реализации компонента 3DS Requestor.

(2) 3DS Server через DS к ACS.  Используя информацию, предоставленную держателем карты «Мир» и данные, полученные в 3DS Requestor Environment, компонент 3DS Server создает и отправляет сообщение AReq компоненту DS, который затем направляет сообщение в соответствующий компонент ACS.

(3) ACS через DS к 3DS Server. В ответ на сообщение AReq компонент ACS возвращает сообщение ARes компоненту DS, который затем передает его инициирующему MirAccept (EMV 3-D Secure) операцию компоненту 3DS Server.

Перед возвращением ответа ARes компонент ACS оценивает данные, представленные в сообщении AReq. В информационном потоке Frictionless Flow компонент ACS определяет, что дополнительного взаимодействия с держателем карты не требуется, чтобы завершить аутентификацию.

(4) 3DS Requestor Environment. Компонент 3DS Server передает результат сообщения ARes компоненту 3DS Requestor Environment, который затем информирует держателя карты «Мир».

Компонент 3DS Requestor определяет, каким образом реализуется взаимодействие между этими компонентами.

Примечание! Обработка операции по стандарту MirAccept (EMV 3-D Secure) заканчивается на этом шаге. Для платежной авторизации должны быть выполнены последующие шаги:

(5) ТСП и его Эквайрер. ТСП направляет авторизационный запрос банку Эквайреру. ТСП, Эквайрер или Процессор может направить авторизационное сообщение в ОПКЦ ПС «Мир», если это необходимо.

(6) Авторизация.  Эквайрер может обработать авторизацию, запросив об этом Эмитента и вернув после этого результат такой обработки в ТСП.

3DS Requestor Environment на основе приложений

Для модели, реализованной на основе приложений (App-based), информационный поток между компонентами 3DS SDK/3DS Requestor App и компонентами 3DS Server/3DS Requestor происходит с использованием API, которые доступны с компонентов 3DS Server/3DS Requestor.

Рис. 3. 3DS Requestor Environment-Frictionless Flow-реализация на основе приложений (App-based)

Основные функциональные особенности для Шага 1 и Шага 4 являются такими, как определено в предыдущем разделе, со следующими пояснениями:

Старт. Держатель карты «Мир» и компонент 3DS Requestor App. Держатель карты «Мир» инициирует операцию с использованием компонента 3DS Requestor App на клиентском устройстве.

(1) 3DS SDK и 3DS Server. Компонент 3DS SDK/3DS Requestor App связывается с компонентом 3DS Server/3DS Requestor. Чувствительная информация от клиентского устройства шифруется компонентом 3DS SDK перед отправкой в сообщении AReq компоненту DS.

(4) 3DS Server и 3DS SDK. Компонент 3DS Server/3DS Requestor передает результат в сообщении ARes компоненту 3DS SDK/3DS Requestor App, который затем информирует держателя карты.

3DS Requestor Environment на основе браузера

Для модели, реализованной на основе браузера (browser-based), информационный обмен между клиентским устройством и компонентом 3DS Server/3DS Requestor использует стандартное браузерное TLS соединение. Рисунок 4 отображает среду 3DS Requestor Environment.

Рис. 4. 3DS Requestor Environment-Frictionless Flow- реализация на основе браузера (browser-based)

Функционально для шагов Шаг 1 и Шаг 4, описанных ранее, приводятся следующие пояснения:

Старт: держатель карты. Держатель карты «Мир» инициирует операцию с помощью браузера, установленного на клиентское устройство, используя веб-сайт, который находится под управлением компонента 3DS Requestor.

(1.1) 3DS Requestor и 3DS Server. Компонент 3DS Requestor взаимодействует с компонентом 3DS Server. Компонент 3DS Server определяет версию компонента ACS (ACS Version) и, если возможно (в случае присутствия), получает 3DS Method URL для запрошенного диапазона номеров карт «Мир» и передает эту информацию компоненту 3DS Requestor. Эти данные (ACS Version и 3DS Method URL) были получены ранее компонентом 3DS Server посредством сообщения PRes.

(1.2) 3DS Method на 3DS Requestor веб-странице чек-аута. Страница чек-аута компонента 3DS Requestor загружает 3DS Method URL, если он присутствует, который позволяет компоненту ACS получить дополнительную браузерную информацию для принятия решения на основе анализа рисков.

(1.3) 3DS Requestor и 3DS Sever. Компонент 3DS Requestor обеспечивает передачу необходимой MirAccept (EMV 3-D Secure) информации, относящейся к операции, компоненту 3DS Server.

4. 3DS сервер и 3DS Requestor. Компонент 3DS Server передает результат сообщения ARes в компонент 3DS Requestor и завершает операцию. 3DS Integrator определяет, как реализовано взаимодействие между компонентами.

Информационный поток Challenge Flow. Пошаговое описание

Рисунок 5. отображает шаги информационного потока Challenge Flow

Внимание! Пунктирными стрелками на рисунке 5 (и на всех остальных рисунках) изображены процессы, не являющиеся частью MirAccept (EMV 3-D Secure).  Внимание! 3DS Requestor также не является частью MirAccept. Они приведены для большей ясности MirAccept..

Рис. 5. Информационный поток Challenge Flow

Поток стадии Challenge Flow содержит следующие шаги:

Старт: Держатель карты «Мир». Так же как и в случае Frictionless Flow.

(1.) 3DS Requestor Environment. Так же как и в случае Frictionless Flow.

(2.) от 3DS Server через DS к ACS. Так же как и в случае Frictionless Flow.

(3.) от ACS через DS на 3DS Server.  Так же как и в случае Frictionless Flow, за исключением сообщения ARes, которое указывает на то, что требуется дополнительное взаимодействие с держателем карты для завершения аутентификации.

(4.) от 3DS Server к 3DS Requestor Environment. Так же как и в случае Frictionless Flow, за исключением того, что требуется дополнительное взаимодействие с держателем карты для завершения аутентификации.

(5.) от 3DS Client к ACS. Компонент 3DS Client инициирует сообщение CReq используя информацию, которая была получена в сообщении ARes. Способ, при помощи которого это происходит, зависит от модели:

- Модель, ориентированная на приложение (app-based). Cообщение CReq формируется компонентом 3DS SDK и перенаправляется методом post по адресу ACS URL, полученному в сообщении ARes.
- Модель, ориентированная на браузер (browser-based). Cообщение CReq формируется компонентом 3DS Server и методом post через браузер держателя карты перенаправляется компонентом 3DS Requestor по адресу ACS URL, полученному в сообщении ARes.

(6.)  от ACS к 3DS Client – компонент ACS принимает сообщение CReq и взаимодействует с компонентом  3DS Client, чтобы поддержать интерфейс с держателем карты. Способ, при помощи которого это происходит, зависит от модели:

- Модель, ориентированная на приложение (app-based). Компонент ACS использует пары сообщений CReq и CRes для выполнения Проверки (Challenge). В ответ на полученное сообщение CReq компонент ACS формирует сообщение CRes, которое запрашивает держателя карты ввести данные для аутентификации, и направляется в компонент 3DS SDK.
- Модель, ориентированная на браузер (browser-based). Компонент ACS отправляет пользовательский интерфейс для аутентификации держателя карты в браузер его клиентского устройства. Держатель карты «Мир» вводит данные для аутентификации через браузер, которые должны быть проверены компонентом ACS. В ответ на полученное сообщение CReq компонент ACS формирует сообщение CRes и отправляет компоненту 3DS Server, чтобы сообщить результат аутентификации.

Внимание! Для модели app-based шаги 5 и 6, описанные выше, будут повторяться до тех пор, пока в компоненте ACS не появится определенное решение в отношении результатов аутентификации.

(7.) от ACS через DS к 3DS Server. Компонент ACS отправляет сообщение RReq компоненту  DS, которое может включать AV (Authentication Value), а компонент DS, в свою очередь, затем отправляет это сообщение соответствующему компоненту 3DS Server, используя адрес 3DS Server URL, полученный в сообщении AReq.

(8.) от 3DS Server через DS к ACS. Компонент 3DS Server получает сообщение RReq и отвечает на него сообщением RRes компоненту DS, который затем направляет это сообщение в соответствующий компонент  ACS.

Примечание: MirAccept (3-D Secure 2.0) обработка заканчивается здесь. Для оплаты товара, должны быть выполнены последующие шаги.

(9.) ТСП и Эквайрер. Так же как и в случае Frictionless Flow.

(10.) Авторизация. Так же как и в случае Frictionless Flow.

ЗАКЛЮЧЕНИЕ

Надеемся, что авторам удалось познакомить читателей с основами и базовыми идеями MirAccept (EMV 3-D Secure), дать стартовые знания для самостоятельного глубокого освоения этого предмета.

Пожалуйста, обращайтесь за подробностями к документам на сайте EMVCo по теме EMV 3-D Secure (http://www.emvco.com/specifications.aspx?id=299 )

- Protocol and Core Functions Specification
- SDK Specification
- SDK - Device Information
- SDK Technical Guide

Именно эти документы и были использованы автором для подготовки данного материала.

Уже очень скоро обновленный MirAccept станет частью нашей повседневной жизни. Мы с вами в роли держателей карт будем пользоваться им для оплаты товаров и услуг в интернете, для денежных переводов с карты «Мир» и на карту «Мир», для управления содержанием электронных бумажников.

Это будет удобно, просто и безопасно. Гораздо лучше, чем это было раньше.

Заинтересованность в широком применении MirAccept (EMV 3-D Secure) есть и у банков - участников платежной системы «Мир» и у предприятий торговли и услуг.

Именно поэтому всем участникам процесса важно понимать, как устроен MirAccept, какие преимущества он несет, какие возможности он открывает, чтобы его применение приносило удовольствие и пользу держателям карт «Мир», предприятиям торговли/услуг и Участникам платежной системы.

MirAccept – чтобы покупать с удовольствием!