Россия, Ижевск, Ижевский государственный технический университет имени А.Т. Калашникова, 2011 |
Особенности реализации платежных систем на основе пластиковых карт
Практически все электронные платежные системы с использованием пластиковых карт работают по схеме, представленной на рис. 9.1.
На первом этапе идет выбор товара или услуг, согласование цены, сроков и условий доставки. По завершении данного этапа продавец выставляет счет, который держатель карты оплачивает. В состав платежа входит два сообщения: одно содержит ордер заказа и предназначается продавцу, второе - платежные инструкции и предназначается платежному шлюзу. На этом же этапе происходит аутентификация продавца и (опционально) покупателя. Продавец, согласившись с условиями платежа, переправляет последний платежному шлюзу. Данный этап также характеризуется процессами аутентификации продавца и платежного шлюза. Осуществив платежные инструкции, платежный шлюз отсылает ответ продавцу, на основании которого тот осуществляет отгрузку товара или предоставление услуги.
При такой схеме организации взаимодействия возникают две проблемы. Первая связана с тем, что при осуществлении платежа пользователь должен передавать свои платежные реквизиты. Частично эта проблема решается при помощи сертификатов (как это делается в протоколе SET), однако, во-первых, сертификат также содержит реквизиты пользователя (в виде хеш-образа), а во-вторых, сертификат можно перехватить, тем самым скомпрометировав платежную систему. Вторая проблема связана с тем, что взаимодействие держателя карты и платежного шлюза осуществляется через продавца; возможна ситуация, когда продавец, получив уведомление о переводе средств на свой счет, просто не предоставит покупателю товар, ссылаясь на неполучение отзыва от платежного шлюза. Рассмотрим, как решаются обе эти проблемы в современных электронных платежных системах.
Один из вариантов обеспечения конфиденциальности платежных реквизитов держателя карты был приведен в "Электронные платежные системы на основе цифровых денег" при рассмотрении комбинированной архитектуры SET/SSL. В рассмотренном случае держатель карты аутентифицируется один раз на этапе регистрации, после чего его сертификат хранится в безопасном месте у посредника (фактически, в защищенной межбанковской сети), все последующие процедуры идентификации и аутентификации производятся при помощи SSL-сертификатов, которые, как было описано, привязаны исключительно к URL или платежной программе и не содержат никаких платежных реквизитов держателя карты (ни в открытом виде, ни в зашифрованном).
Еще один вариант обеспечения конфиденциальности предложен в системе NetBill. На этапе регистрации в системе и на начальных этапах платежных транзакций платежный шлюз выступает в роли центра сертификации. Безопасность информационного обмена основана на использовании схемы взаимодействия, схожей с протоколом Kerberos[3GPP TR 21.905: Vocabulary for 3GPP Specifications.]. Схема представлена на рис. 9.2.
Суть идеи состоит в том, чтобы при аутентификации держателя карты при совершении транзакции использовать не персональные данные (платежный реквизиты или сертификат), а сеансовый ключ.
При регистрации в системе держатель карты запрашивает сертификат платежного шлюза. После получения сертификата держатель карты извлекает из него открытый ключ платежного шлюза и формирует запрос идентификатора, представляющий собой зашифрованные на открытом ключе платежные реквизиты держателя карты. Данный запрос отправляется платежному шлюзу. Получив данный запрос, платежный шлюз извлекает из него реквизиты держателя карты, проверяет, зарегистрирован ли данный счет в системе, и в случае успешности последней операции высылает держателю карты идентификатор и ключ шифрования данных для организации защищенного взаимодействия с сервером выдачи разрешений. Безопасность процесса регистрации обеспечивается использованием протокола SSL.
Теперь при работе в системе держателю карты нет необходимости передавать свои платежные реквизиты. Каждый раз при входе в систему держатель предъявляет свой идентификатор и устанавливает защищенное соединение с центром выдачи мандатов. Мандат служит дополнительной защитой от атак перехвата.
При совершении платежной транзакции держатель карты запрашивает идентификатор продавца, после чего обращается в платежный шлюз для получения сеансового ключа взаимодействия с продавцом. В результате обеспечивается, во-первых, установка безопасного канала передачи данных между держателем карты и продавцом, а во-вторых, взаимная аутентификация держателя карты и продавца, ибо только зарегистрированные участники системы могут получить доступ к сеансовым ключам. В-третьих, держатель карты избавляется от необходимости передавать свои платежные реквизиты каждый раз при осуществлении транзакции.
Проблема возможного непредоставления оплаченных товаров или услуг также может решаться несколькими способами. Один из них - блокировка счета. Держатель карты переводит деньги на определенный счет, при этом обратно снять их уже не может. Продавец также видит, что деньги переведены на счет, однако не может их получить до тех пор, пока не осуществит поставку товара или предоставление услуги. После получения оплаченного товара или услуги держатель карты разблокирует счет, и продавец может получить свои деньги.
В ряде систем для решения проблемы привлекается платежный шлюз. На рис. 9.3 приведен пример платежной транзакции в системе First Virtual[EMV ICC Specification for Payment Systems.].
Данная система предназначена для продажи информации в электронном виде. На этапе регистрации пользователь помимо прочих реквизитов в обязательном порядке указывает адрес электронной почты. При осуществлении покупки держатель карты отправляет форму заказа и свой идентификатор IDC продавцу. Продавец пересылает платежному шлюзу идентификатор покупателя , свой идентификатор и счет-фактуру.
Шлюз проверяет наличие данного покупателя в системе и при положительном результате проверки высылает продавцу соответствующий ответ, а покупателю - отчет о заключении сделки на e-mail. Продавец, получив подтверждение существования данного покупателя, осуществляет отсылку информации. Перевод же средств будет осуществлен лишь после того, как покупатель подтвердит факт приема товара.
Еще одной проблемой, которую необходимо решить при создании системы на основе платежных карт, являются микроплатежи, чей номинал значительно меньше стоимости проведения транзакции при помощи платежной карты. Решение этой проблемы состоит в использовании внутри системы электронных кошельков ( рис. 9.4).
Суть подхода заключается в следующем. В состав платежной системы вводится электронный кошелек, поддерживающий жетоны определенного номинала. Пополнение электронного кошелька возможно как при помощи платежных карт (через специальные терминалы), так и путем перевода требуемой суммы с банковского счета или из другого электронного кошелька. При реализации стандартных платежных транзакций электронный кошелек может не использоваться. При реализации микроплатежей средства могут переводиться как с кошелька на кошелек, так и с кошелька на банковский счет.
В первом случае можно использовать как стандартные протоколы, обеспечивающие защищенное соединение, например SSL, так и специализированные, разработанные для осуществления микроплатежей. Оба типа протоколов обеспечивают взаимную аутентификацию кошельков и передачу информации о переводимой сумме в зашифрованном виде.
В случае перевода средств с электронного кошелька на банковский счет возможны две ситуации.
- Банки-участники поддерживают микроплатежи номинала жетонов электронного кошелька. В этом случае производится стандартный для электронных платежных систем перевод средств, при этом электронный кошелек выступает в роли эмитента.
- Банки участников не поддерживают микроплатежи либо не поддерживают номинал жетонов электронного кошелька. В этом случае перевод средств будет осуществляться при достижении в электронном кошельке суммы, поддерживаемой банками при реализации транзакций.
Как правило, все современные платежные системы имеют структуру, схожую с представленной на рис. 9.4. Такая структура системы позволяет осуществлять практически все виды удаленных платежей по банковским картам, в том числе и микроплатежи, поддерживать мультивалютность, а также обеспечивать многообразие способов ввода и вывода денежных средств соответственно в систему или из нее.