Результат интеллектуальной деятельности: ИСПОЛЬЗОВАНИЕ УЛУЧШЕННОГО ТОКЕНА АУТЕНТИФИКАЦИИ ВЛАДЕЛЬЦА КАРТЫ

ПЕРЕКРЕСТНАЯ ССЫЛКА НА РОДСТВЕННЫЕ ЗАЯВКИ

По настоящей заявке испрашивается приоритет согласно и преимущество даты подачи заявки США с серийным номером № 14/883,835, поданной 15 октября 2015 г., полное содержание которой включено в настоящий документ посредством ссылки.

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

УРОВЕНЬ ТЕХНИКИ

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

Платежные транзакции на основе карт сейчас обычно выполняются по множеству каналов торговли. Например, платежные транзакции на основе карт могут выполняться лично в розничном магазине (как описано выше), через компьютер, соединенный с Интернетом (онлайновая транзакция) или другой сетью, через мобильный телефон и/или через контактный центр в компании (например, номер 1-800 для рассылочной компании). Эти различные типы транзакций производятся различными способами, и, таким образом, каждый тип транзакции ассоциирован с разным уровнем риска мошенничества. Дополнительно, транзакции по платежных картам в общем случае требуют, чтобы потребитель имел свою платежную карту в доступе, чтобы либо представить кассиру в среде розничной торговли, либо ввести запрошенную информацию (такую как шестнадцатизначный номер счета платежной карты, дату истечения и число проверочного кода кредитной карты (CVV)) через веб-обозреватель для онлайновой или Интернет-транзакции, и/или чтобы обеспечить запрошенную информацию по телефону.

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

С возникновением онлайновой торговли и m-коммерции (мобильной коммерции) потребители все чаще используют персональные компьютеры и/или портативные или мобильные устройства с возможностью платежа (такие как интеллектуальные телефоны, планшетные компьютеры, "цифровые помощники" (PDA), ноутбуки и/или цифровые музыкальные проигрыватели), чтобы осуществлять покупки CNP посредством веб-сайтов продавцов через интернет. Как следствие, развились различные методики, которые обеспечивают возможность защищенного платежа за товары и/или услуги, заказанные онлайн потребителями или владельцами карт, с использованием их счетов платежных карт.

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

Например, MasterCard International Incorporated обеспечивает услугу MasterCard SecureCode, которая является 3-D-защищенным осуществлением и которая включает в себя решения аутентификации владельца карты, которые задействуют универсальный стандарт, называемый универсальным полем аутентификации владельца карты (UCAF). Услуга SecureCode используется финансовыми учреждениями (FI)-членами (эмитентами), такими как банками-эмитентами, а также продавцами, FI продавцов и MasterCard, чтобы собрать и передать данные аутентификации владельца счета, генерируемые решениями защиты эмитента и владельца счета. Таким образом, UCAF выполнено с возможностью быть независимым от схемы защиты и, соответственно, предлагает стандартизованные поля и сообщения для использования продавцами и членскими финансовыми учреждениями MasterCard. Будучи собранной продавцом и FI-эквайером продавца, информация аутентификации владельца карты передается к FI-эмитенту в запросе авторизации платежа и обеспечивает явные доказательства, что транзакция (такая как покупочная транзакция) была инициирована владельцем счета или владельцем карты. UCAF поддерживает множество различных подходов защиты эмитента и аутентификации, включающих в себя использование алгоритма защищенного протокола (SPA), серверов эмитента, интеллектуальной карты и другого. В некоторых осуществлениях токен, генерируемый SPA, включает в себя базовое указание (или по меньшей мере некоторые доказательства), что аутентификация владельца карты произошла.

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Признаки и преимущества некоторых вариантов осуществления настоящего раскрытия и способ, которым они выполняются, станет более ясен по рассмотрении последующего подробного описания, воспринимаемого в сочетании с сопроводительными чертежами, которые изображают примерные варианты осуществления и которые не обязательно нарисованы в масштабе, причем:

фиг.1 изображает структурную схему системы транзакций, чтобы проиллюстрировать стандартный процесс 3-D-защищенной аутентификации;

фиг.2 изображает структурную схему системы покупочных транзакций, иллюстрирующую поток данных аутентификации владельца карты в соответствии с новыми процессами раскрытия;

фиг.3 изображает таблицу, иллюстрирующую пример формата для управляющего байта усовершенствованной переменной аутентификации владельца счета (AAV) алгоритма защищенного протокола (SPA) и для полей способа аутентификации и описания в соответствии с процессами раскрытия;

фиг.4 изображает блок-схему, иллюстрирующую способ покупочной транзакции продавца в соответствии с вариантами осуществления раскрытия; и

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

ПОДРОБНОЕ ОПИСАНИЕ

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

Здесь будет использовано некоторое количество терминов. Использование таких терминов не предполагается как ограничивающее, а используется для удобности и простоты объяснения. Например, используемый здесь термин "владелец карты" может быть использован взаимозаменяемым образом с термином "потребитель" и используются здесь для ссылки на потребителя, человека, индивида, предприятие или другой объект, который владеет (или авторизован использовать) финансовым счетом, таким как счет платежной карты (такой как счет кредитной карты или счет дебетовой карты). Дополнительно, термин "счет платежной карты" может включать в себя счет кредитной карты, счет дебетовой карты, счет карты постоянного покупателя и/или депозитный счет или финансовый счет другого типа, к которому владелец счета или владелец карты может осуществлять доступ или задействовать для транзакций. Термин "номер счета платежной карты" включает в себя номер, который идентифицирует счет в системе платежных карт, или номер, переносимый платежной картой, и/или номер, который используется, чтобы осуществлять маршрутизацию транзакции в платежной системе, которая проводит транзакции дебетовых карт и/или кредитных карт и т. п. Кроме того, используемые здесь термины "система платежных карт" и/или "платежная система" и/или "платежная сеть" ссылаются на систему и/или сеть для обработки и/или проведения покупочных транзакций и/или родственных транзакций, которой может оперировать оператор системы платежных карт, такой как MasterCard International Incorporated, или подобная система. В некоторых вариантах осуществления термин "система платежных карт" может ограничиваться системами, в которых членские финансовые учреждения (такие как банки) выпускают счета платежных карт индивидам, предприятиям и/или другим объектам или организациям. Дополнительно, термины "данные транзакции платежной системы", и/или "данные транзакции платежной сети", или "данные транзакции платежной карты", или "данные транзакции сети платежных карт" ссылаются на данные транзакции, ассоциированные с платежными транзакциями и/или покупочными транзакциями, которые были обработаны через платежную сеть или платежную систему. Например, данные транзакции платежной системы могут включать в себя некоторое количество записей данных, ассоциированных с отдельными платежными транзакциями (или покупочными транзакциями) потребителей, которые были обработаны через систему платежных карт или сеть платежных карт. В некоторых вариантах осуществления данные транзакции платежной системы могут включать в себя информацию, которая идентифицирует владельца карты, платежное устройство владельца карты или платежный счет, дату и время транзакции, сумму транзакции, товары или услуги, которые были куплены, и информацию, идентифицирующую продавца и/или категорию продавца. Дополнительные детали транзакции могут также быть доступны в некоторых вариантах осуществления.

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

Фиг.1 изображает структурную схему стандартной системы 100 транзакций, чтобы проиллюстрировать пример 3-D-защищенного протокола или службы аутентификации. Служба аутентификации обеспечивает процесс аутентификации, который обычно включает в себя некоторое количество участников и сообщений для того, чтобы аутентифицировать владельца карты для транзакции. Для того чтобы использовать службу аутентификации, потребитель или владелец карты должен сначала зачислиться или зарегистрироваться, обычно путем посещения веб-сайта зачисления финансового учреждения (FI)-эмитента (такого как веб-сайт банка-эмитента), и обеспечить данные зачисления эмитента, чтобы подтвердить свою личность. Если надлежащие ответы обеспечены, владелец карты считается аутентифицированным и ему разрешается установить личный код для связывания с его номером счета платежной карты и/или первичным учетным номером (PAN) (который связан, например, со счетом кредитной карты или счетом дебетовой карты). Личный код связан со счетом платежной карты владельца карты и сохраняется FI-эмитентом для дальнейшего или последующего использования в течение онлайновых покупок на веб-сайтах участвующих продавцов.

Со ссылкой на фиг.1, владелец карты, желающий купить товары и/или услуги через Интернет (онлайн), оперирует устройством 102 потребителя, которое может быть персональным компьютером или мобильным устройством (таким как интеллектуальный телефон, планшетный компьютер, ноутбук, цифровой музыкальный проигрыватель и т. п.) и использует Интернет-обозреватель (не показан) для связи с серверным компьютером 106 продавца, чтобы осуществить покупки на веб-сайте продавца. В некоторых осуществлениях сервер 106 продавца включает в себя приложение 108 плагина продавца ("MPI"), которое будет объяснено ниже. После выбора товаров и/или услуг и добавления этих предметов на веб-страницу онлайновой "корзины оформления заказа" продавца, чтобы инициировать покупочную транзакцию, владелец карты предоставляет информацию счета платежной карты (которая может включать в себя первичный учетный номер ("PAN"), дату истечения, проверочное значение владельца карты (или значение "CVV"), информацию адреса выставления счета и т. п.). Данные счета платежной карты затем обычно передаются через соединение 101 уровня защищенных сокетов ("SSL") от компьютера 102 владельца карты к серверному компьютеру 106 продавца.

Серверный компьютер 106 веб-сайта продавца принимает данные, предоставленные потребителем, через соединение 101 SSL, и приложение 108 плагина продавца (MPI) затем генерирует и посылает сообщение запроса проверки и сообщение ответа проверки через соединение 103 SSL к серверному компьютеру 110 службы каталогов (например, серверный компьютер 110 службы каталогов может быть службой каталогов MasterCard™, оперируемой MasterCard International Incorporated). В некоторых осуществлениях серверный компьютер 110 службы каталогов использует банковский идентификационный номер (BIN), который является частью PAN владельца карты, чтобы проверить соответствие диапазона платежной карты требованиям для службы аутентификации и чтобы идентифицировать соответствующее финансовое учреждение (FI)-эмитент. Если установленный PAN находится в соответствующем требованиям диапазоне платежной карты для службы аутентификации, то данные передаются через другое соединение 105 SSL на сервер 112 управления доступом (ACS) эмитента, который определяет, является ли конкретный номер счета зачисленным в список и активным для участия в службе аутентификации. Если владелец карты зачислен в список как участник, ACS 112 эмитента устанавливает защищенный сеанс через соединение 107 с серверным компьютером 106 продавца, и MPI 108 создает сообщение запроса аутентификации плательщика, которое передается обратно к ACS 112 посредством защищенного сеанса через соединение 107. Когда ACS 112 принимает сообщение запроса аутентификации плательщика, он обеспечивает инициирование диалога аутентификации через соединение 109 с устройством 102 потребителя. В некоторых вариантах осуществления диалог аутентификации включает в себя обеспечения появления отдельного окна аутентификации в обозревателе владельца карты, запущенном на устройстве владельца карты (которое может быть, например, мобильным устройством потребителя, таким как интеллектуальный телефон). Окно аутентификации, которое обычно представляется на экране дисплея устройства 102 потребителя в течение процесса оформления заказа потребителя, подсказывает владельцу карты ввести свой личный код. В этот момент процесса потребитель вводит личный код, и обозреватель владельца карты затем перенаправляет или передает информацию личного кода через соединение 109 к ACS 112 для аутентификации. Если личный код верен или совпадает с сохраненным личным кодом, ассоциированным с владельцем карты, то ACS 112 аутентифицирует владельца карты и генерирует переменную аутентификации владельца счета ("AAV"). AAV затем передается посредством ACS 112 через соединение 107 к MPI 108 сервера 106 продавца, и окно аутентификации владельца карты на экране дисплея устройства 102 потребителя исчезает.

AAV является токеном, который генерируется с использованием алгоритма защищенного протокола (SPA) MasterCard™. Этот токен передается в универсальном поле аутентификации владельца карты (UCAF) для переноса внутри сообщения авторизации. UCAF используется, чтобы осуществлять передачу информации аутентификации между различными заинтересованными сторонами в транзакции (т. е. FI-эмитентом и/или продавцом). Соответственно, в этот момент процесса владелец карты был аутентифицирован с использованием 3-D-защищенного протокола, и сервер 106 продавца передает AAV через соединение 111 к системе 114 шлюза/эквайера в составе запроса авторизации покупки. Далее система 114 шлюза/эквайера посылает запрос авторизации покупки через защищенное соединение 113 к платежной сети 116, которая перенаправляет 115 сообщение запроса авторизации к надлежащему серверному компьютеру 118 эмитента для обработки авторизации покупочной транзакции. В частности, FI-эмитент 118 задействует информацию в принятом запросе авторизации, чтобы осуществить определение, авторизовать ли покупочную транзакцию для этого владельца карты. Например, FI-эмитент может задействовать один или несколько критериев авторизации и/или деловых правил, чтобы определить, когда конкретная покупочная транзакция должна быть авторизована или в ней должно быть отказано. Например, FI-эмитент может авторизовать транзакцию и генерировать сообщение авторизации ответа, если истинно следующее: сумма транзакции ниже предварительно определенного предела, владелец карты был аутентифицирован посредством процесса службы аутентификации, и счет кредитной карты владельца карты имеет достаточный кредитный лимит, чтобы покрыть стоимость для покупочной транзакции (разумеется, другие деловые правила и/или критерии могут также задействоваться FI-эмитентом).

Когда онлайновая покупочная транзакция авторизована, FI-эмитент передает через соединение 115 сообщение ответа авторизации покупочной транзакции в платежную сеть 114, которая перенаправляет его в финансовое учреждение-эквайер продавца (не показано) для платежа. Платежная сеть 114 также передает сообщение авторизации транзакции ответа через соединение 113 в систему 114 шлюза для перенаправления через соединение 111 на сервер 104 продавца, чтобы завершить покупочную транзакцию. Таким образом, при приеме авторизации покупочной транзакции продавец стандартно передает сообщение завершения покупки устройству потребителя и/или отображает сообщение подтверждения покупки на веб-странице оформления заказа продавца, чтобы уведомить владельца карты, что покупка была завершена. Такие 3-D-защищенные процессы аутентификации были выполнены с возможностью обеспечивать более высокий уровень аутентификации владельца карты в течение удаленных или онлайновых транзакций и уменьшить отзывы платежа ввиду "неавторизованной транзакции" для продавцов.

Фиг.2 изображает структурную схему системы 200 покупочных транзакций, чтобы проиллюстрировать поток данных аутентификации владельца карты в соответствии с новыми процессами, описанными здесь. В частности, будет описан поток данных аутентификации владельца карты от сервера 112 управления доступом (ACS), который может размещаться сторонним поставщиком платежных услуг (PSP), в систему 202 бэк-офиса (операционно-учетного подразделения) эмитента. Следует понимать, что сторонний PSP отвечает за аутентификацию владельцев карт от имени FI-эмитентов и обычно осуществляет схему или процесс аутентификации владельца карты, как диктуется FI-эмитентом владельца карты (в соответствии с правилами аутентификации и/или критериями аутентификации, требуемыми FI-эмитентом). Также следует понимать, что некоторые из различных компонентов, изображенных на фиг.2, могут быть поднабором большей системы или систем и/или что больше или меньше компонентов и/или устройств может задействоваться. Например, хотя только один сервер 106 продавца, один серверный компьютер 206 платежного шлюза, один серверный компьютер 208 эквайера продавца и один серверный компьютер 118 FI-эмитента изображены, в практических вариантах осуществления множество таких компонентов может задействоваться. Дополнительно, один или несколько из компонентов, изображенных на фиг.2, может быть специализированным компьютером, сконфигурированным с возможностью функционировать в соответствии с одним или несколькими процессами, описанными здесь.

Хотя здесь описаны конкретные варианты осуществления, следует понимать, что фиг.2 представляется только в иллюстративных целях и что различные компоненты и/или конфигурации могут быть использованы без выхода за пределы сущности и объема этого раскрытия. Таким образом, в соответствии с 3-D-защищенным протоколом (и в некоторых случаях в ответ на то, что владелец карты обеспечивает запрошенные идентификационные данные владельца карты) ACS 112 системы 200 покупочных транзакций сконфигурирован с возможностью генерировать усовершенствованную переменную аутентификации владельца счета (усовершенствованную "AAV") с использованием SPA, который включает в себя улучшенные или усовершенствованные указатели аутентификации в качестве доказательства аутентификации. В частности, в составе AAV поле управляющего байта в первой позиции (байт 1) UCAF (подробно объяснено ниже) используется, чтобы указывать характер аутентификации в сочетании со способом аутентификации, задействуемым для транзакции.

Фиг.3 изображает таблицу 300, иллюстрирующую формат для управляющего байта усовершенствованной AAV SPA и способ аутентификации полей в соответствии с процессами, раскрываемыми здесь. Таблица 300 включает в себя столбец 302 управляющего байта UCAF (позиция 1), столбец 304 способа аутентификации (позиция 11), столбец 306 описания аутентификации и столбец 308 примера описания AAV (причем в некоторых вариантах осуществления AAV будет в шестнадцатеричном или "16-ричном" формате и/или "64-ричном" формате). Как упомянуто ранее, в текущий момент используются различные типы 3-D-защищенных методик. В одном примерном варианте осуществления шестнадцатеричное значение "86" в байте 1 в UCAF, или 64-ричное значение "h" (см. столбец 302 строки 310), и ноль ("0") в позиции 11 (или байте 11) UCAF (см. столбец 304 строки 310) обеспечивает способ аутентификации, указывающий, что владелец карты не был аутентифицирован, для ACS эмитента с использованием обработки попытки (столбец 306 строки 310). В частности, поскольку в строке 310 значение ноль ("0") возникает в байте 11 (см. столбец 304; что действительно только для значения управляющего байта "86"), аутентификация владельца карты не была получается. В этом случае AAV генерируется либо в шестнадцатеричном формате, либо в 64-ричном формате (см. столбец 308 строки 310), как показано.

Однако, как показано на фиг.3, если шестнадцатеричное значение "8C" обеспечено в байте 1 UCAF, или 64-ричное значение "j" (см. столбец 302 и строку 312), и значение единицы ("1") имеет место в байте 11 (см. строку 312 и столбец 304), то пароль был успешно предоставлен владельцем карты (достоверность которого была подтверждена ACS эмитента). Это означает, что успешная аутентификация владельца карты произошла (см. столбец 306 строки 312), и, таким образом, AAV генерируется для указания успешной аутентификации владельца карты либо в шестнадцатеричном формате, либо в 64-ричном формате, как показано (см. столбец 308 строки 312). Такие данные AAV могут задействоваться, например, FI-эмитентом при осуществлении определения, авторизовать ли конкретную покупочную транзакцию владельца карты, но в остальном обеспечивают очень мало информации FI-эмитенту или продавцу в отношении того, как владелец карты был аутентифицирован для конкретной транзакции.

В соответствии с новыми аспектами настоящего раскрытия, комбинация новых значений добавляется в поле 302 управляющего байта AAV (позиция 1 UCAF) и в поле 304 способа аутентификации (позиция 11 UCAF), чтобы обеспечить усовершенствованную и/или улучшенную информацию AAV, которая может задействоваться FI-эмитентами и/или продавцами, чтобы принимать решения улучшенной аутентификации и/или авторизации, которые могут выгодным образом улучшить впечатления от совершения покупок клиента или потребителя и улучшить практики FI-эмитентов и/или продавца по предотвращению мошенничества. Например, значения усовершенствованной AAV могут обеспечивать продавцам и/или FI эмитентам возможность идентифицировать ситуации или события рискоориентированной аутентификации и т. п. в течение онлайновой покупочной транзакции и затем предпринимать надлежащее действие(я). Такие улучшенные информация или данные аутентификации могут задействоваться, например, продавцом, чтобы построить базу данных, такую как база 204 данных MPI с фиг.2, которая включает в себя связки между конкретным типом или типами способа(ов) аутентификации и конкретными FI-эмитентами. Затем в течение будущих или последующих покупочных транзакций продавец может сделать выбор обойти процесс аутентификации владельца карты для владельца карты некоторого или конкретного или идентифицированного FI-эмитента (например, поскольку база данных включает в себя запись, указывающую, что конкретный FI-эмитент задействует способ защищенной аутентификации), чтобы обеспечить хорошее восприятие со стороны потребителя. Продавцы могут также включать туда нежелательную информацию процесса аутентификации владельца карты, которая может быть ассоциирована с одним или несколькими FI-эмитентами в базе данных продавца, и использовать эту информацию или данные, чтобы затем требовать, чтобы аутентификация владельца карты происходила для транзакции ввиду вовлеченного увеличенного риска. Соответственно, продавцы могут задействовать улучшенную и/или дополнительную информацию или данные аутентификации, чтобы управлять впечатлениями потребителя от покупочной транзакции путем выгодного использования преимуществ аутентификации только для владельцев карт, ассоциированных с FI-эмитентами, которые обеспечивают наилучшие впечатления потребителя (и наоборот, избегать аутентификации владельцев карт, ассоциированных с FI-эмитентами, имеющими нежелательные решения аутентификации).

Снова со ссылкой на фиг.3, в некоторых вариантах осуществления ACS эмитента сконфигурирован с возможностью генерировать AAV с использованием SPA с улучшенными значениями в качестве аутентификации так, что в составе AAV поле 302 управляющего байта UCAF может теперь включать в себя шестнадцатеричный указатель "90" (см. строку 314), или 64-ричное значение "k", и поле 304 способа аутентификации (байт 11) включает в себя значение "4" (строка 314, столбец 304), чтобы указывать, что произошла "рискоориентированная аутентификация". В частности, как показано столбцом 306 описания аутентификации для строки 314, это означает, что произошла успешная аутентификация посредством рискоориентированной "скрытой" аутентификации, что означает, что владелец карты не осведомлен, что он был аутентифицирован на основе критериев риска (например, у владельца карты не была запрошена какая-либо дополнительная информация, такая как пароль, ввиду того факта, что он распознан как постоянный клиент, и, возможно, поскольку значение покупочной транзакции или денежная сумма также ниже предварительно определенного порогового количества).

Снова со ссылкой на фиг.3, другой пример улучшенного значения в поле 302 управляющего байта UCAF показан как запись шестнадцатеричного указателя "98" (см. строку 316, столбец 302), или 64-ричное значение "m", и поле 304 способа аутентификации (байт 11) включает в себя значение "5" (строка 316, столбец 304), чтобы указывать, что произошла "усиленная аутентификация". В этом случае, как показано столбцом 306 описания аутентификации для строки 316, это означает, что успешная аутентификация через усиленную аутентификацию произошла, например, поскольку покупочная транзакция была сочтена транзакцией "высокого риска", требующей, чтобы владелец карты обеспечил некоторый дополнительный тип информации аутентификации, которая была успешно обеспечена.

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

Другой тип процесса аутентификации владельца карты известен как "рискоориентированная" аутентификация, в которой финансовое учреждение (FI)-эмитент выбирает, когда воздержаться от обеспечения подсказки конкретному владельцу карты для данных аутентификации. Например, FI-эмитент не может требовать у владельца карты обеспечить какие-либо данные аутентификации ввиду распознавания одного или нескольких из адреса Интернет-протокола (IP) владельца карты, машинного "отпечатка", адреса устройства, информации обозревателя, суммы покупки, информации продавца, данных географического местоположения, хронологических данных транзакции и т. п. В сценарии рискоориентированной аутентификации конкретная точка данных может быть использована отдельно или в комбинации с другой точкой данных в соответствии, например, с приложением назначения риска. В другом примере FI-эмитент может делать выбор "прозрачным образом" или "скрытым образом" аутентифицировать владельца карты для транзакций, которые сочтены имеющими "низкий риск". Это означает, что продавец принимает полностью аутентифицированный токен, и владелец карты получает подсказку ввести что-либо еще для того, чтобы быть аутентифицированным.

При некоторых обстоятельствах FI-эмитент может также сделать выбор "усилить" аутентификацию, когда транзакция сочтена имеющей "высокий риск" или "более высокий риск". Усиленный процесс может включать в себя задействование одного или нескольких из каких-либо из вышеупомянутых способов аутентификации. Например, в отношении конкретной транзакции "высокого риска" владелец карты может получить подсказку обеспечить две или более формы информации аутентификации владельца карты (такие как статический пароль, и/или основанный на знаниях идентификатор, и/или одноразовый пароль, и/или биометрические данные) для того, чтобы быть аутентифицированным. Следует понимать, что каждое FI-эмитент может разрабатывать правила, или протоколы, или критерии, которые определяют, что составляет транзакцию "низкого риска", и/или "высокого риска", и/или "более высокого риска", в соответствии с их собственными внутренними процессами и/или процедурами. Например, конкретное FI-эмитент может счесть все транзакции для владельцев карт конкретного типа продукта кредитной карты, которые включают в себя покупку товаров на меньше чем тридцать долларов ($30.00), имеющими "низкий риск", все транзакции для таких владельцев карт для товаров на больше чем двести долларов ($200.00) имеющими "высокий риск" и транзакции для таких владельцев карт для товаров на больше чем пятьсот долларов ($500.00) имеющими "более высокий риск". Следует понимать, что другие факторы данных помимо сумм транзакции (такие как адрес устройства, скорость транзакции, адрес доставки и т. п.) могут также задействоваться, чтобы построить фактор риска для учета при определении, использовать ли усиленную аутентификацию.

Снова со ссылкой на фиг.2, как упомянуто выше, система 200 покупочных транзакций иллюстрирует поток данных аутентификации от сервера 112 управления доступом (ACS) эмитента к серверному компьютеру 106 продавца и плагину 108 продавца, и к системам 202 бэк-офиса эмитента. В частности, в одном варианте осуществления ACS 112 эмитента генерирует AAV с использованием SPA с улучшенными значениями (в качестве доказательства аутентификации). Однако следует понимать, что усовершенствованная AAV или улучшенный токен аутентификации владельца карты может генерироваться алгоритмом другого типа (помимо SPA) для использования в соответствии со способами, устройством и системами, описанными здесь. Как объяснено ранее, поле управляющего байта UCAF указывает формат и содержимое структуры AAV, включая то, какой способ аутентификации был задействован для транзакции. В течение обработки покупочной транзакции AAV передается 201 к плагину 108 продавца серверного компьютера 106 продавца в качестве доказательства аутентификации владельца карты, и в некоторых вариантах осуществления сервер продавца сохраняет 203 указание типа аутентификации владельца карты, которая была задействована для этой транзакции, в базе 204 данных MPI.

В некоторых осуществлениях продавец может сохранять тип аутентификации владельца карты, используемый для множества покупочных транзакций множеством владельцев карт. Типы аутентификации владельца карты могут сохраняться посредством диапазона счета платежной карты в базе данных транзакций, и эти данные или информация могут затем быть использованы продавцом для будущих или последующих событий покупочной транзакции владельца карты и могут задействоваться, чтобы обходить аутентификацию потребителя (путем рискоориентированной аутентификации владельца карты), чтобы улучшить впечатления потребителя. Например, продавец может сохранять информацию в базе 204 данных MPI (или другой базе данных, такой как база данных покупочных транзакций) на основе значений AAV для того, чтобы определять, в течение одной или нескольких последующих покупочных транзакций, касающихся того же самого владельца карты (или подобных владельцев карт, или владельцев карт конкретного FI-эмитента), когда обходить процесс аутентификации владельца карты и просто предоставить покупочную транзакцию платежному шлюзу для обработки авторизации транзакции. Таким образом, продавец может строить базу данных транзакций владельцев карт, которая может быть использована, чтобы определять для конкретных владельцев карт, когда посылать запрос авторизации транзакции FI-эмитенту, которое имеет установленным процесс скрытой аутентификации (например, для транзакций менее пятидесяти долларов ($50.00) и/или для владельцев карт, использующих устройства с конкретного адреса Интернет-протокола (IP)). База данных транзакций также может быть использована серверным компьютером продавца, чтобы определять, когда обходить процесс аутентификации владельца карты для конкретного владельца карты или группы владельцев карт, причем это определение может основываться на хронологических данных прошлых транзакций и/или основываться на типе аутентификации владельца карты, задействуемой одним или несколькими FI-эмитентами.

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

Снова со ссылкой на фиг.2, серверный компьютер 106 продавца также передает 205 значение AAV платежному шлюзу 206 (который может включать в себя одну или несколько платежных сетей и/или дополнительных компонентов), который затем передает 207 значение AAV компьютеру 208 финансового учреждения (FI)-эквайера продавца. Компьютер 208 FI-эквайера продавца посылает 209 запрос авторизации, который содержит исходное значение AAV, компьютеру 118 FI-эмитента. Таким образом, компьютер FI-эмитента 118 принимает запрос на авторизацию, который содержит значение AAV, которое было сгенерировано его собственным ACS (ACS 112 эмитента) в течение процесса аутентификации. Компьютер FI-эмитента 118 может затем сохранять 211 значение AAV в базе 212 данных мошенничества и отчетов эмитента. Когда компьютер 118 FI-эмитента впоследствии уведомляется о мошенничестве, которое произошло в отношении конкретной транзакции или транзакций, компьютер 118 FI-эмитента может затем находить соответствие этих случаев мошенничества, о которых были обеспечены отчеты, с решением(ями) аутентификации владельца карты, которое было или которые были использованы. Компьютер 118 FI-эмитента может быть сконфигурирован с возможностью затем обновлять обработчик правил аутентификации с целью защиты от будущих возникновений того же самого типа мошенничества, касающегося того же самого владельца карты или класса владельцев карт. Таким образом, компьютер 118 FI-эмитента может передавать новые или обновленные правила к ACS 112 эмитента, чтобы использовать для последующих или будущих решений авторизации владельца карты.

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

Фиг.4 изображает блок-схему 400, иллюстрирующую способ покупочной транзакции продавца в соответствии с вариантами осуществления раскрытия. Приложение плагина продавца (MPI) серверного компьютера продавца принимает 402 информацию владельца карты, касающуюся покупочной транзакции, со страницы оформления заказа веб-сайта продавца и затем сравнивает 404 информацию владельца карты с данными владельца карты в базе данных MPI. В некоторых осуществлениях база данных MPI содержит различные типы хронологических данных покупочных транзакций владельца карты, включающих в себя, но не ограничивающихся, историю способов аутентификации владельца карты, идентификационные данные владельца карты множества владельцев карт, результаты аутентификации владельца карты и суммы покупочных транзакций. Данные, сохраненные в базе данных MPI, могут быть организованы по диапазону счета финансового учреждения-эмитента или подобному и могут задействоваться серверным компьютером продавца, чтобы предсказывать впечатления владельца карты от аутентификации для конкретного владельца карты в отношении текущей покупочной транзакции. Снова со ссылкой на этап 404, если происходит совпадение данных владельца карты, то MPI определяет 406, обходить ли аутентификацию владельца карты.

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

Снова со ссылкой на фиг.4, если принимается решение обойти аутентификацию владельца карты, то серверный компьютер продавца передает 408 запрос авторизации транзакции, который включает в себя детали покупочной транзакции (т.е. идентификатор продавца, данные владельца карты, данные покупочной транзакции и т. п.), к платежному шлюзу. Далее серверный компьютер продавца принимает 410 ответ авторизации от платежного шлюза, который указывает, что покупочная транзакция либо была авторизована, либо была отклонена FI-эмитентом. Серверный компьютер продавца затем завершает текущую покупочную транзакцию (например, для онлайновой транзакции серверный компьютер продавца может отображать сообщение подтверждения покупочной транзакции на веб-странице продавца оформления заказа и/или может передавать сообщение подтверждения покупочной транзакции к устройству потребителя, принадлежащему потребителю, указывающее авторизацию покупочной транзакции. В других случаях серверный компьютер продавца может отображать сообщение отклонения транзакции на веб-странице продавца и/или может передавать такое сообщение отклонения транзакции к устройству потребителя, когда FI-эмитент отклонило транзакцию). В некоторых вариантах осуществления MPI может также сохранять текущие данные покупочной транзакции (включающие в себя то, была ли текущая покупочная транзакция авторизована или отклонена) в базе данных MPI в связке с данными владельца карты. Эта информация может быть использована продавцом, например, для разработки рискоориентированного подхода к сетевой аутентификации владельца карты для использования в осуществлении определений, касающихся того, когда обходить конкретные транзакции, которые в противном случае с большой вероятностью были бы брошены конкретными владельцами карт.

Снова со ссылкой на этап 404, если информация владельца карты, касающаяся покупочной транзакции, со страницы оформления заказа веб-сайта продавца не совпадает с данными владельца карты, сохраненными в базе данных MPI (таким образом, указывая счет нового клиента или нового владельца карты, не имеющего истории покупочных транзакций с продавцом), или если на этапе 406 MPI принимает решение не обходить аутентификацию владельца карты для покупочной транзакции, касающейся владельца карты, который есть в базе данных MPI, то MPI передает 412 данные владельца карты и данные покупочной транзакции к серверу управления доступом (ACS) для обработки аутентификации. В отношении этапа 406, MPI может принять решение приступить к обработке аутентификации владельца карты для известного счета владельца карты по ряду причин. Например, данные текущей покупочной транзакции могут не удовлетворять одному или нескольким деловым правилам и/или критериям продавца. Таким образом, MPI может определять, что аутентификация владельца карты для известного владельца карты должна продолжаться, поскольку текущие данные транзакции необычны или иным образом не согласуются с прошлыми данными покупок владельца карты (т. е. текущая покупочная транзакция включает в себя один или несколько дорогостоящих предметов и/или осуществляется с неопознанного IP-адреса), и/или ввиду прошлых случаев мошенничества, о которых обеспечен отчет, ассоциированных со счетом владельца карты, и/или поскольку продавец знает, что впечатления от аутентификации будут приемлемыми.

Снова со ссылкой на фиг.4, после передачи данных владельца карты и данных покупочной транзакции к серверу управления доступом (ACS) для обработки аутентификации на этапе 412, MPI принимает 414 от ACS либо сообщение аутентификации владельца карты, либо сообщение, что аутентификация потерпела неудачу. Когда аутентификация владельца карты терпит неудачу, покупочная транзакция прерывается 420, что в некоторых случаях включает в себя то, что MPI генерирует и отображает сообщение "транзакция отклонена" на веб-странице оформления заказа владельцу карты (или иным образом передает сообщение отклонения покупочной транзакции владельцу карты). Снова со ссылкой на этап 414, когда процесс аутентификации владельца карты успешен, MPI принимает 416 детали аутентификации владельца карты от ACS, которые включают в себя усовершенствованную переменную аутентификации владельца счета (AAV), которая указывает тип процесса аутентификации владельца карты, который был задействован. Следует понимать, что в некоторых случаях сторонний поставщик платежных услуг (PSP) размещает ACS для одного или нескольких финансовых учреждений (FI)-эмитентов, и ACS, таким образом, оперирует, чтобы аутентифицировать владельцев карт от имени одного или нескольких FI-эмитентов. В некоторых осуществлениях ACS может осуществлять связь с владельцем карты, чтобы получить одну или несколько требуемых форм идентификационных данных (таких как биометрические данные, персональный идентификационный номер (PIN) и/или данные секретного кода), причем эти требования могут основываться на одном или нескольких факторах в соответствии, например, с деловыми правилами конкретного FI-эмитента. Например, может требоваться усиленный процесс аутентификации, который требует от владельца карты обеспечить две или более формы идентификационных данных владельца карты в соответствии с деловыми правилами и/или критериями аутентификации, когда, например, текущая покупочная транзакция включает в себя конкретные предварительно определенные данные (такие как полная сумма транзакции сверх предварительно определенной пороговой суммы, такой как 250.00 долларов). В таком случае владелец карты может получить подсказку задействовать один или несколько биометрических датчиков, и/или сенсорный экран, и/или другой компонент ввода, ассоциированный с его электронным устройством, чтобы ввести требуемые данные аутентификации (т. е. образец голоса, сканирование радужной оболочки, отпечаток пальца или подобное) и/или любые другие данные аутентификации для способа(-ов), который эмитент задействует, такого как использование одноразовых паролей посредством отправки сообщения SMS, мобильных токенов и т. п., которые затем передаются к ACS для обработки. MPI затем сохраняет 418 данные аутентификации владельца карты, которые могут включать в себя такие данные, как идентификационные данные владельца карты, идентификационные данные FI-эмитента, данные покупочной транзакции, ассоциированные с текущей покупочной транзакцией, включающие в себя дату транзакции и указатель аутентификации (усовершенствованную AAV), в базе данных MPI. Серверный компьютер продавца затем передает 408 сообщение запроса авторизации покупочной транзакции, которое включает в себя усовершенствованную AAV, к серверному компьютеру платежного шлюза для обработки авторизации покупочной транзакции. Далее, как объяснено выше, серверный компьютер продавца принимает 410 ответ авторизации от платежного шлюза, который указывает, что покупочная транзакция либо была авторизована, либо была отклонена FI-эмитентом. Серверный компьютер продавца затем завершает транзакцию (например, серверный компьютер продавца может передавать потребителю сообщение подтверждения транзакции, указывающее авторизацию покупочной транзакции, или может передавать сообщение отклонения транзакции, когда FI-эмитент отклонило транзакцию), и процесс заканчивается.

Фиг.5 изображает блок-схему 500, иллюстрирующую способ авторизации покупочной транзакции в соответствии с вариантом осуществления раскрытия. Компьютер финансового учреждения (FI)-эмитента принимает 502 от шлюза платежной системы сообщение запроса авторизации покупочной транзакции, которое включает в себя усовершенствованную переменную аутентификации владельца счета (AAV) или токен аутентификации владельца карты, содержащий информацию в соответствии, например, с таблицей, показанной на фиг.3. В некоторых осуществлениях компьютер FI-эмитента определяет 504, что токен аутентификации владельца карты действителен как сгенерированный посредством ACS (который является усовершенствованной AAV), и определяет 506, что счет платежной карты владельца карты поддерживает текущую покупочную транзакцию (т. е. имеет достаточный кредитовый остаток, чтобы покрыть цену покупочной транзакции). FI-эмитент далее генерирует 508 сообщение ответа авторизации покупочной транзакции и передает 510 сообщение ответа авторизации покупочной транзакции платежному шлюзу для маршрутизации к серверному компьютеру продавца, чтобы завершить покупочную транзакцию. Дополнительно, FI-эмитент сохраняет 512 детали покупочной транзакции (включающие в себя усовершенствованную AAV или токен аутентификации владельца карты, который указывает тип задействуемой аутентификации владельца карты) в базе данных покупочных транзакций. FI-эмитента может задействовать такую информацию в более позднее время или впоследствии, чтобы определять, создается ли впечатление, что счет владельца карты используется мошеннически. Такие данные могут также задействоваться FI-эмитентом, чтобы обновлять и/или изменять тип способа аутентификации владельца карты, используемый в связке с этим счетом владельца карты и/или для подобных счетов владельцев карт в отношении будущих покупочных транзакций. Поскольку аутентификация владельца карты происходит отдельно от системы авторизации FI-эмитента, эмитент может задействовать данные усовершенствованной AAV, чтобы определять, была ли транзакция чистым результатом рискоориентированной аутентификации (т. е. скрытая аутентификация) или получил ли владелец карты фактически подсказку и прошел ли подтверждение достоверности. Такая информация может помочь FI-эмитенту одобрить больше транзакций.

Снова со ссылкой на фиг.5, на этапе 504 тип аутентификации владельца карты, указанный усовершенствованной AAV, может помочь FI-эмитенту принять решение о том, одобрить или отклонить запрос авторизации, который "пограничен", поскольку FI-эмитент знает, как владелец карты был аутентифицирован, например, посредством чистого рискоориентированного или усиленного процесса. В некоторых случаях FI-эмитент передает 514 сообщение отказа покупочной транзакции к платежному шлюзу для маршрутизации к серверному компьютеру продавца. Это может происходить, например, когда FI-эмитент было уведомлено владельцем карты о потерянной или украденной кредитной карте или дебетовой карте (и, таким образом, используемый тип аутентификации владельца карты не имеет значения), и/или если FI-эмитент определило, что с высокой вероятностью на этом счете владельца карты происходит мошенничество. В таких случаях FI-эмитент может сохранять данные, касающиеся счета владельца карты, и детали авторизации, включающие в себя AAV. Дополнительно, даже если токен аутентификации владельца карты достоверен, в отношении этапа 506, если счет владельца карты имеет превышенный лимит или по иным причинам не поддерживает сумму покупочной транзакции (т.е. доступный кредитовый остаток владельца карты недостаточен, чтобы покрыть полную сумму покупочной транзакции), то FI-эмитент передает 514 сообщение отказа покупочной транзакции к платежному шлюзу для маршрутизации к серверному компьютеру продавца, и процесс заканчивается. В этом случае FI-эмитент может сохранять данные, касающиеся счета владельца карты, и детали авторизации, включающие в себя AAV.

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

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

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

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

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