Виртуальные номера карт

Идея виртуальной карты получила развитие в технологии виртуального номера карты (используются также термины pseudo card number и proxy card number). Суть этой технологии заключается в том, что при заполнении формы торгового предприятия во время операции ЭК владелец карты вместо реального номера карты сообщает Интернет-магазину некоторый случайный номер. После того как транзакция поступает в систему эмитента для авторизации, производится обратное преобразование виртуального номера карты в реальный номер. В результате при выполнении операций ЭК реальный номер карты никогда не передается в платежную сеть и остается в системе эмитента. Таким образом, вероятность компрометации реальных номеров карт, а также вероятность успешного совершения транзакции ЭК мошенником становятся близкими к нулю.

Технически идея виртуального номера карты может быть реализована следующим образом. Клиент для оплаты электронных покупок с помощью технологии виртуального номера карты должен установить на свой компьютер специальное ПО. После того как клиент получает от Интернет-магазина для заполнения форму, содержащую информацию о реквизитах карты, ПО клиента инициирует обращение к системе своего эмитента. Эмитент генерирует для клиента виртуальный номер карты и возвращает его клиенту. При этом эмитент контролирует в некотором смысле уникальность сгенерированного номера карты, а также принадлежность префикса карты к выделенному для эмитента диапазону значений BIN.

После этого транзакция выполняется обычным образом. Клиент направляет Интернет-магазину заполненную форму, в которой в качестве номера карты фигурирует виртуальный номер. В результате выполнения стандартных процедур обработки транзакции в системе обслуживающего банка и платежной системы из последней в систему эмитента поступает авторизационный запрос, содержащий виртуальный номер карты. Эмитент, получив авторизационный запрос, устанавливает соответствие между данными, сгенерированными при инициализации транзакции, и данными авторизационного запроса. Соответствие ищется по целому ряду параметров. Например, система MasterCard к обязательным параметрам относит номер карты, срок ее действия, имя магазина (Merchant Name), идентификатор магазина (Merchant ID), сумму транзакции и валюту транзакции. Эмитент определяет реальный номер карты, выполняя обратное преобразование, проводит с его использованием авторизацию транзакции и результат возвращает в платежную сеть, предварительно вновь подставив в авторизационный ответ виртуальный номер карты.

Если в платежной системе используется технология Single Message System (авторизационный запрос является одновременно и финансовым сообщением, требующим от эмитента возмещения средств), то процесс на этом завершается. В случае применения технологии Dual Message System (процедуры авторизации и расчетов разделены) система эмитента будет обязана также обработать клиринговое (финансовое) сообщение, связанное с рассматриваемой транзакцией. При обработке клирингового сообщения требуется выполнить необходимую подстановку реального номера карты вместо виртуального номера.

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

В то же время, идея виртуальных номеров карт имеет и ряд недостатков. Во-первых, как уже упоминалось, владелец карты должен установить на своем компьютере специальное ПО, называемое электронным кошельком. Обычно это делается путем «скачивания» кошелька с некоторого Web-сервера. Для некоторой категории клиентов такая процедура сама по себе представляет проблему. Во-вторых, эмитент должен предложить клиенту процедуру его аутентификации во время обращения клиента за виртуальным номером в систему эмитента. Как правило, используется система паролей — клиент в защищенной сессии с системой эмитента сообщает последней свой идентификатор и кодовое слово (пароль). Здесь существуют несколько подходов к решению задачи. Наиболее надежным является получение клиентом своих идентификатора и пароля непосредственно в банке (в крайнем случае письмом из банка, причем идентификаторы клиента должны распечатываться в PIN-конверте для того, чтобы сделать информацию закрытой для банковского персонала).

Этот подход является неудобным для клиента. Поэтому на практике находит применение другой, менее надежный метод. Клиент получает свои идентификаторы во время первой сессии с системой эмитента. Он идентифицирует себя, представляя эмитенту реквизиты карты, а также дополнительную информацию, запрашиваемую эмитентом (например, номер паспорта, девичью фамилию матери и т. п.). В ответ в случае положительного результата аутентификации клиент получает свой идентификатор и пароль. Весь обмен информацией между клиентом и системой эмитента происходит в защищенной сессии. Логическое соединение с системой эмитента обеспечивается кошельком клиента. Более низкая защищенность этого метода связана с тем, что в процессе идентификации клиента могут быть различные подставки со стороны мошенников, имитирующих работу эмитента.

В-третьих, помимо виртуального номера карты система эмитента в некоторых случаях должна в режиме реального времени генерировать значения CVC2/CVV2. Напомним, что в системе MasterCard использование CVC2 в транзакциях ЭК коммерции является обязательным.

Конечно, эмитент, применяющий технологию виртуальных номеров карт, может и не проверять значения CVC2. В этом случае в платежную сеть может направляться любое случайное значение CVC2. Однако при таком подходе эмитент лишается возможности использовать резервную авторизацию (авторизацию Stand-in), предоставляемую в его распоряжение многими платежными системами на случай отказа в работе системы эмитента. В режиме резервной авторизации платежная сеть от лица эмитента в соответствии с параметрами, установленными эмитентом, производит авторизацию транзакции. В системе резервной авторизации существует общий параметр для всех префиксов карт, определяющий действие эмитента на случай неверного значения CVC2/CVV2 — отклонить транзакцию сразу или продолжить другие проверки. Если такой параметр установить равным значению, означающему «не отклонять», то и по всем другим операциям и префиксам будет приниматься то же решение, что наверняка противоречит интересам эмитента.

В-четвертых, применение технологии виртуальных номеров карт повлечет за собой проблемы для тех Интернет-магазинов, которые сохраняют номера карт клиентов, уже однажды обращавшихся в торговое предприятие за услугами, чтобы не заставлять клиента набирать свои реквизиты при следующих обращениях в ТП. Очевидно, что при массовом применении технологии виртуальных номеров карт БД таких магазинов быстро переполнятся, что повлечет за собой операционные проблемы в их функционировании.

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

Наконец, использование виртуальных номеров карт влечет за собой и проблемы в системах эмитента. Необходимость хранения информации обо всех используемых номерах карт — одна из них.

Впервые идея виртуального номера карты в статическом варианте была реализована банком First Virtual, который предлагал своим клиентам для транзакций ЭК использовать идентификатор VirtualPIN. Этот идентификатор вводился клиентом вместо номера карты и Интернетмагазин передавал его на сервер First Virtual, который преобразовывал идентификатор в соответствующий номер, и дальше транзакция обрабатывалась стандартным способом. Таким образом, реализовывалась ограниченная защита номера карты от магазина-мошенника. В технологии First Virtual магазин не знает настоящего номера карты. При этом он может использовать идентификатор клиента для проведения транзакций ЭК из торговых предприятий, поддерживающих эту технологию.

Сегодня технология виртуальных номеров карт получила распространение среди ряда крупных банков. Например, четвертый по размеру американский эмитент пластиковых карт Discover предлагает 50 миллионам своих клиентов услугу Discover DeskShop. В основе Discover DeskShop лежит технология виртуальных карт в реализации ирландской компании Orbiscom (www.orbiscom.com). Решение этой компании O-power используется не только в Discover, но и в банках MBNA (система MBNA Shopsafe, создается для пользования 45 млн владельцев карт), HFC (английский филиал компании Household International) и Allied Irish Banks.

Система O-power для случая 16-цифрового номера карты и 6-цифрового BIN карты генерирует до 1 млрд различных значений виртуальных номеров карт (в терминах Orbiscom — Controlled Payment Number). Период повторного использования виртуального номера карты в системе — 9-12 месяцев.

Для банка Discover система O-power реализована на базе высокопроизводительных серверов Е450 компании Sun Microsystems, технологии Oracle и известного программного обеспечения для «свитча» платежной системы Oasis. Клиенту DeskShop достаточно ввести свой пароль для того, чтобы система эмитента заполнила для клиента платежную форму магазина (для этого необходимо, чтобы магазин участвовал в проекте Discover).

Компания Orbiscom не поставляет решений для электронного кошелька клиента. Внедрение технологии виртуальных номеров карт на стороне клиента остается задачей банка-эмитента. При этом может применяться уже используемый электронный кошелек.

Другое известное на рынке решение Nexus-1 предлагается американской компанией Appletix (филиал компании по разработке программных продуктов располагается в Израиле). Клиентами этой компании являются крупнейший канадский банк CIBC (4 млн владельцев карт на начало 2001 г.) и процессинговая компания VISA Israel Credit Cards. Решение Nexus-1 предлагает двухфакторную аутентификацию клиента — аутентификацию клиента по его паролю и аутентификацию компьютера клиента по некоторому специальному алгоритму.

Решение на основе виртуальных номеров карт предлагает также компания Cyota (www.cyota.com). В конце первого квартала 2001 г. платежная система Maestro (оператор дебетовых карт Maestro) объявила о том, что банки, эмитирующие эти дебетовые карты, могут использовать для реализации систем ЭК технологию виртуальных номеров карт (е-Wallet Maestro solution). Карты Maestro начнут приниматься некоторыми наиболее известными Интернет-магазинами начиная с третьего квартала 2001 г.

Требования к технологии виртуальных номеров карт при использовании карт Maestro состоят в следующем. Эмитент должен генерировать 16-цифровые номера карт (при этом виртуальный номер карты может совпадать с реальным номером карты), а также проверять соответствие между данными, сгенерированными при инициализации транзакции, и данными авторизационного запроса. Как указывалось ранее, соответствие ищется как минимум по номеру карты, сроку ее действия, имени магазина (Merchant Name), идентификатору магазина (Merchant ID), сумме транзакции и валюте транзакции.

Отличительная особенность решения для карт Maestro заключается в том, что владелец карты не должен устанавливать на своем компьютере никакого специального ПО (электронного бумажника). Транзакция выполняется следующим образом. После того как владелец карты сообщил ТП о готовности платить с использованием карты Maestro, Интернет-магазин отправляет на сервер эмитента (e-Wallet в терминах Maestro), хранящий информацию о реквизитах своих карт, специальное сообщение. Это сообщение содержит информацию о ТП (Merchant Name, Merchant ID), о сумме и валюте покупки, идентификатор транзакции в системе ТП и т. п. Одновременно сервер магазина переключает владельца карты на сервер эмитента.

Сервер эмитента устанавливает с владельцем карты защищенное соединение и направляет клиенту форму для проведения его аутентификации. Например, эмитент может запросить у владельца карты ранее предоставленные ему идентификатор и пароль.

После того как владелец карты аутентифицирован сервером эмитента, последний формирует запрос на сервер ТП, содержащий сгенерированный эмитентом виртуальный номер карты. Далее транзакция производится способом, описанным в начале этого параграфа.

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

Второй вопрос связан с необходимостью определения спецификации интерфейса между ТП и сервером эмитента. Речь идет о семантике и синтаксисе сообщений, которыми обмениваются ТП и сервер эмитента.

Распределение ответственности при возникновении диспута по транзакции ЭК ничем не отличается от того, каким образом оно производится при использовании модели трех доменов.