Система сетевых токенов

Изобретение относится к сетям обработки платежей. Технический результат – обеспечение вместе с токеном уровня гарантирования токена и данных, использовавшихся для генерации уровня гарантирования токена. Предлагается способ обеспечения уровня гарантирования токена, ассоциированного с платежным токеном, основанного на способе идентификации и верификации, использовавшемся при генерации платежного токена, в котором во время выдачи токена выполняется один или несколько способов идентификации и верификации (ID&V), чтобы гарантировать, что токен заменяет первичный номер счета (PAN), который правомерно используется запросчиком токена, уровень гарантирования токена может быть присвоен данному токену в зависимости от типа ID&V, который выполняется, и объекта, выполняющего ID&V, различные ID&V могут приводить к различными уровням гарантирования токена, эмитент может пожелать знать уровень гарантирования и данные, использовавшиеся при генерации уровня гарантирования, ассоциированного с токеном, перед авторизацией платежной транзакции, которая использует токен. 3 н. и 14 з.п. ф-лы, 10 ил., 13 табл.

 

Перекрестные ссылки на родственные заявки

[0001] Это приложение испрашивает приоритет на основании Свода федеральных законов США, раздел 35 119(e) предварительной заявки на патент США № 61/890162, поданной 11 октября 2013 и озаглавленной «Система сетевых токенов» и предварительной заявки на патент США № 61/906377, поданной 19 ноября 2013 и озаглавленной «Стандарты сетевых токенов», раскрытия которых включены посредством ссылки в настоящий документ во всей их полноте для всех целей.

Уровень техники

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

[0003] В традиционной электронной платежной транзакции информация о первичном номере счета (PAN) клиента доступна различным объектам, задействованным во время жизненного цикла транзакции. PAN передается от терминала торгово-сервисного предприятия системе эквайера, сети обработки платежей, платежным шлюзам и т.д.

[0004] Поскольку PAN может быть доступен в различных точках в жизненном цикле транзакции, были разработаны платежные «токены» для проведения платежных транзакций. Платежные токены служат дополнительным уровнем безопасности к PAN и фактически становятся прокси/суррогатом PAN. Таким образом, платежный токен может использоваться вместо PAN при инициализации платежа или при отправке транзакций. Использование платежных токенов вместо PAN может снизить риск мошенничества, так как реальный PAN недоступен.

[0004] Хотя традиционные усилия по использованию платежных токенов были полезны, необходимо решить ряд дополнительных проблем. Например, так как реальный PAN не очевиден из соответствующего токена, трудно идентифицировать источник токена или эмитента токена. С одной стороны, токен предназначен для сокрытия информации. С другой стороны, было бы полезно идентифицировать по платежному токену источник или эмитента токена, уровень доверия, что пользователь, пытающийся использовать токен, на самом деле является настоящим владельцем карточки, и данные, использовавшиеся для определения уровня доверия. В настоящее время не существует методик для идентификации этой информации.

[0005] Кроме того, токены были традиционно ограничены конкретной сетью или системой обработки платежей и не поддерживали операционную совместимость между платежными сетями. Соответственно, принятие и интеграция токенов с различными платежными системами были ограничены.

[0006] Варианты воплощения настоящего изобретения решают эти и другие проблемы, по-отдельности и все вместе.

Сущность изобретения

[0007] Варианты воплощения настоящего изобретения направлены на обеспечение вместе с токеном уровня гарантирования токена и данных, использовавшихся для генерации уровня гарантирования токена. Во время выдачи токена могут быть предприняты шаги, чтобы гарантировать, что токен заменяет PAN, который правомерно используется запросчиком токена. Этот процесс известен как идентификация и верификация (ID&V), и он может выполняться каждый раз, когда токен запрашивается. Уровень гарантирования токена может быть присвоен данному токену в зависимости от типа ID&V, который выполняется, и объекта, выполняющего ID&V. Различные ID&V могут приводить к различными уровням гарантирования токена. Эмитент может пожелать знать уровень гарантирования и данные, использовавшиеся при генерации уровня гарантирования, ассоциированного с токеном, перед авторизацией платежной транзакции, которая использует токен. Уровень гарантирования, который присвоен данному токену, может измениться с течением времени и может быть перекалиброван на основании факторов, которые влияют на его уровни доверия, таких как любая связь с мошенническими транзакциями связанных с мошенничеством возвратных платежей и т.д.

[0008] В соответствии с иллюстративным вариантом воплощения обеспечен способ. Способ включает в себя этап, на котором принимают, с помощью компьютера, сообщение запроса авторизации от запросчика. Сообщение запроса авторизации содержит платежный токен, представляющий первичный номер счета. Первичный номер счета может быть присвоен эмитентом. Сообщение запроса авторизации предназначено для проведения платежной транзакции с использованием первичного номера счета. Способ также включает в себя этап, на котором принимают, с помощью компьютера, уровень гарантирования токена, ассоциированный с токеном, вместе с данными, использовавшимися для генерации уровня гарантирования токена. Уровень гарантирования токена может представлять собой уровень доверия в ассоциации между платежным токеном и первичным номером счета, представленным платежным токеном. Уровень гарантирования токена может быть основан на способе идентификации и верификации, использовавшимся при генерации платежного токена. В некоторых вариантах воплощения уровень гарантирования токена основан на объекте, выполняющем способ верификации и идентификация. Кроме того, способ включает в себя этап, на котором изменяют, с помощью компьютера, сообщение запроса авторизации, чтобы включить в него уровень гарантирования токена и данные, использовавшиеся для генерации уровня гарантирования токена. Способ дополнительно включает в себя этап, на котором передают, с помощью компьютера, измененное сообщение запроса авторизации эмитенту для одобрения.

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

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

[0011] Другой вариант воплощения описывает устройства, системы и машиночитаемый носитель, выполненные с возможностью выполнения способа, описанного выше.

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

[0013] Эти и другие варианты воплощения описываются более подробно ниже.

Краткое описание чертежей

[0014] Фиг. 1 показывает систему и блок-схему последовательности операций, обеспечивающие обзор различных взаимодействий объектов в экосистеме токенизации в соответствии с иллюстративным вариантом воплощения настоящего изобретения.

[0015] Фиг. 2 показывает систему и блок-схему последовательности операций, обеспечивающие обзор различных взаимодействий объектов в экосистеме токенизации, где платежная сеть служит поставщиком службы токенов, в соответствии с иллюстративным вариантом воплощения настоящего изобретения.

[0016] Фиг. 3 показывает систему и блок-схему последовательности операций для последовательности операций по авторизации для мобильного устройства при транзакции на терминале торгово-сервисного предприятия в соответствии с иллюстративным вариантом воплощения настоящего изобретения.

[0017] Фиг. 4 показывает систему и блок-схему последовательности операций для последовательности операций по авторизации для транзакции электронной торговли с помощью мобильного/цифрового кошелька в соответствии с иллюстративным вариантом воплощения настоящего изобретения.

[0018] Фиг. 5 показывает систему и блок-схему последовательности операций для последовательности операций по авторизации для транзакции электронной торговли с помощью записи о карте в соответствии с иллюстративным вариантом воплощения настоящего изобретения.

[0019] Фиг. 6 показывает систему и блок-схему последовательности операций для последовательности операций по авторизации для сканирования при транзакции на терминале торгово-сервисного предприятия в соответствии с иллюстративным вариантом воплощения настоящего изобретения.

[0020] Фиг. 7 показывает систему и блок-схему последовательности операций для процесса захвата и клиринга для транзакции с токеном в соответствии с иллюстративным вариантом воплощения настоящего изобретения.

[0021] Фиг. 8 показывает систему и блок-схему последовательности операций для процесса запроса возвратного платежа для транзакции с токеном в соответствии с иллюстративным вариантом воплощения настоящего изобретения.

[0022] Фиг. 9 показывает схему, обеспечивающую обзор различных ролей, задействованных при осуществлении службы токенов, в соответствии с иллюстративным вариантом воплощения настоящего изобретения.

[0023] Фиг. 10 показывает иллюстративную компьютерную систему в соответствии с вариантами воплощения настоящего изобретения.

Подробное описание

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

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

[0026] Чтобы платежные токены обеспечили улучшенную защиту от злонамеренного использования, токен может быть ограничен использованием в конкретном домене, например, конкретном торгово-сервисном предприятии или канале. Эти базовые средства управления использованием являются преимуществом токенов, и представленные варианты воплощения описывают способы для их реализации.

[0027] Дополнительно, во время выдачи токена могут быть предприняты шаги, чтобы гарантировать, что токен заменяет PAN, который правомерно использовался запросчиком токена. Этот процесс известен как идентификация и верификация (ID&V), и он может выполняться каждый раз, когда токен запрашивается. Уровень гарантирования токена может быть назначен данному токену в зависимости от типа ID&V, которая выполняется. Различные ID&V могут приводить к различными уровням гарантирования токена. Например, отсутствующая или минимальная ID&V, выполненная ненадежным объектом, может привести к низкому уровню гарантирования токена, в то время как подробная ID&V, выполненная надежным объектом, скорее всего приведет к высокому уровню гарантирования токена. Соответственно, уровень гарантирования, ассоциированный с токеном, зависит от способа ID&V, выполняемого при генерации токена, и объекта, который выполнял способ ID&V. Эмитент может пожелать знать уровень гарантирования и данные, использовавшиеся при генерации уровня гарантирования, ассоциированного с токеном, перед авторизацией платежной транзакции, которая использует токен.

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

[0029] Варианты воплощения настоящего изобретения могут описывать экосистему токенизации (среду токенизации), задавать роли объектов, необходимые для поддержки токенизации, идентифицировать воздействия вариантов воплощения изобретения, указывать поля данных, ассоциированные с запросами токенов, выдачей и предоставлением токенов, обработкой транзакций, и идентифицировать необходимые прикладные программные интерфейсы (API). Варианты воплощения настоящего изобретения предназначены для сохранения операционной совместимости в индустрии платежей. Кроме того, варианты воплощения предназначены для обеспечения уровня гарантирования токена, ассоциированного с токеном, вместе с данными, использовавшимися при генерации уровня гарантирования токена в сообщении запроса авторизации, переданном, например, эмитенту.

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

[0031] Прежде чем обсуждать конкретные варианты воплощения и примеры, ниже приведены некоторые описания терминов, используемых в настоящем документе.

[0032] «Токен» может включать в себя идентификатор для платежного счета, который является заменой для идентификатора счета, такого как первичный номер счета (PAN). Например, токен может включать в себя серию цифр и/или буквенно-цифровых знаков, которые могут использоваться вместо исходного идентификатора счета. Например, может использоваться токен «4900 0000 0000 0001» вместо PAN «4147 0900 0000 1234». В некоторых вариантах воплощения токен может быть «с сохранением формата» и может иметь числовой формат, который соответствует идентификаторам счета, используемым в существующих сетях обработки платежей (например, формат сообщения финансовой транзакции ISO 8583). В некоторых вариантах воплощения токен может использоваться вместо PAN для инициирования, авторизации, проведения или разрешения платежной транзакции или представления исходных учетных данных в других системах, где исходные учетные данные, как правило, были обеспечены. В некоторых вариантах воплощения может генерироваться значение токена так, что восстановление исходного PAN или другого идентификатора счета из значения токена не может быть осуществлено с помощью вычислений. Кроме того, в некоторых вариантах воплощения формат токена может быть выполнен с возможностью позволять объекту, принимающему токен, идентифицировать его как токен и распознавать объект, который выдал токен.

[0033] «Банковский идентификационный номер (BIN)» может быть присвоен платежной сетью эмитенту платежного счета. BIN могут соответствовать спецификациям идентификации счетов и эмитентов в индустрии (например, ISO 7812), так что платежная сеть, назначающая BIN, может быть идентифицирована на основании BIN и соответствующих диапазонов счетов.

[0034] В некоторых вариантах воплощения формат токена может позволять объектам в платежной системе идентифицировать эмитента, ассоциированного с токеном. Например, формат токена может включать в себя идентификатор эмитента токена, который позволяет объекту идентифицировать эмитента. Например, идентификатор эмитента токена может быть ассоциирован с BIN эмитента базового PAN для поддержки существующей последовательности операций платежа. Идентификатор эмитента токена может быть числом, отличающимся от BIN эмитента, и он может быть фиксированным. Например, если BIN эмитента для эмитента равен 412345, идентификатор эмитента токена может быть BIN токена, равный 428325, и это число может быть фиксированным для всех токенов, выданных этим эмитентом или для этого эмитента. В некоторых вариантах воплощения диапазон идентификатора эмитента токена (например, диапазон BIN токена эмитента) может иметь те же самые атрибуты, что и соответствующий диапазон карт эмитента, и он может быть включен в маршрутную таблицу идентификатора эмитента (например, маршрутную таблицу BIN). Маршрутная таблица идентификатора эмитента может быть предоставлена соответствующим объектам в платежной системе (например, торгово-сервисным предприятиям и эквайерам).

[0035] «BIN токена» может называться конкретный BIN, который был назначен только с целью выдачи токенов и который может быть соответственно помечен в таблицах BIN. BIN токенов не могут иметь двойного назначения и не могут использоваться для выдачи и первичных номеров счетов (PAN), и токенов.

[0036] «Диапазоном идентификатора эмитента токена (диапазоном BIN эмитента)» может называться уникальный идентификатор (например, длиной 6-12 цифр), возникающий из множества предварительно выделенных идентификаторов эмитента токенов (например, BIN токенов в 6 цифр). Например, в некоторых вариантах воплощения один или несколько диапазонов BIN токена могут быть выделены каждому диапазону BIN эмитента, который ассоциирован с эмитентом. В некоторых вариантах воплощения диапазоны BIN токена могут использоваться для генерации платежного токена и не могут использоваться для генерации неплатежного токена. В некоторых вариантах воплощения токен может передавать основные правила валидации номера учетной записи, в том числе, например, проверку LUHN или валидацию контрольной суммы, которые могут быть установлены различными объектами в пределах платежной системы. В некоторых вариантах воплощения платежный идентификатор эмитента токена может быть поставлен в соответствие реальному идентификатору эмитента (например, BIN) для эмитента. Например, платежный идентификатор эмитента токена может включать в себя числовое значение в шесть цифр, которое может быть ассоциировано с эмитентом. Например, любой токен, включающий в себя платежный идентификатор эмитента токена, может быть ассоциирован с конкретным эмитентом. Таким образом, эмитент может быть идентифицирован с использованием соответствующего диапазона идентификатора эмитента, ассоциированного с идентификатором эмитента токена. Например, платежный идентификатор «540000» эмитента токена, соответствующий платежному токену «5400 0000 0000 0001», может быть поставлен в соответствие идентификатору «553141» эмитента, соответствующему идентификатору «553141 0900 0000 1234» платежного счета. В некоторых вариантах воплощения платежный идентификатор эмитента токена является фиксированным для эмитента. Например, платежный идентификатор эмитента токена (например, «540000») может соответствовать первому эмитенту, а другой платежный идентификатор эмитента токена (например, «550000») может соответствовать второму эмитенту, и первый и второй платежные идентификаторы эмитента токена не могут быть изменены или модифицированы без информирования всех объектов в пределах системы обработки сетевых токенов. В некоторых вариантах воплощения платежный диапазон идентификатора эмитента токена может соответствовать идентификатору эмитента. Например, платежные токены, включающие в себя платежные идентификаторы эмитента токена «490000» - «490002», могут соответствовать первому эмитенту (например, поставленному в соответствие идентификатору «414709» эмитента), а платежные токены, включающие в себя платежные идентификаторы эмитента токена «520000» - 520002», могут соответствовать второму эмитенту (например, поставленному в соответствие реальному идентификатору эмитента «517548»). Диапазоны BIN токенов и присваивание токенов из этих диапазонов BIN может быть сделано доступным для сторон, одобряющих транзакции, для принятия решений по маршрутизации.

[0037] «Системой службы токенов» называется система, которая обеспечивает запрос, генерацию и выдачу токенов, а так же поддержание установленного соответствия токенов первичным номерам счетов (PAN) в репозитарии (например, хранилище токенов). Система службы токенов может установить уровень гарантирования токена для данного токена, чтобы указать уровень доверия у привязки токена к PAN. Система службы токенов может поддерживать обработку токенов платежных транзакций, представленных с использованием токенов, путем детокенизации токена для получения фактического PAN. В различных вариантах воплощения система службы токенов может включать в себя запросчика токена и поставщика службы токенов, взаимодействующего с запросчиком токена.

[0038] «Поставщиком службы токенов» может называться объект, включающий в себя один или несколько серверных компьютеров в системе службы токенов, которая генерирует, обрабатывает и поддерживает токены. Поставщик службы токенов может включать в себя или осуществлять связь с хранилищем токенов, где хранятся сгенерированные токены. В частности, хранилище токенов может поддерживать взаимно-однозначное соответствие между токеном и первичным номером счета (PAN), представленным токеном. Поставщик службы токенов может иметь возможность не принимать во внимание лицензированные BIN как BIN токенов, чтобы выдать токены для PAN, которые могут быть представлены поставщику службы токенов. Различные объекты экосистемы токенизации могут брать на себя роли поставщика службы токенов. Например, платежные сети и эмитенты или их агенты могут стать поставщиком службы токенов путем реализации служб токенов в соответствии с вариантами воплощения настоящего изобретения. Поставщик службы токенов может обеспечить отчеты или вывод данных инструментам создания отчетов относительно одобренных, ожидающих или отклоненных запросов токенов, включающих в себя любые назначенные ID запросчика токена. Поставщик службы токенов может обеспечить вывод данных, относящихся к основанным на токенах транзакциями, инструментам создания отчетов и приложениям и предоставить токен и/или PAN, в зависимости от обстоятельств, в отчете.

[0039] «Хранилищем токенов» может называться репозитарий, который поддерживает установленные соответствия токен-PAN. В соответствии с различными вариантами воплощения хранилище токенов может также поддерживать другие атрибуты запросчика токена, которые могут быть определены во время регистрации, и которые могут использоваться поставщиком службы токенов для применения доменных ограничений или других средств управления во время обработки транзакций. Хранилище токенов может быть частью системы службы токенов. В некоторых вариантах воплощения хранилище токенов может быть обеспечено как часть поставщика службы токенов. Альтернативно, хранилище токенов может быть удаленным репозитарием, доступным для поставщика службы токенов. Хранилища токенов, из-за деликатного характера соответствий данных, которые хранятся и которыми управляют в них, могут быть защищены с помощью сильной базовой физической и логической защиты.

[0040] «Способ идентификации и верификации (ID&V)» может использоваться для того, чтобы гарантировать, что платежный токен заменяет PAN, который правомерно используется запросчиком токена. Примеры способов ID&V могут включать в себя, но не ограничиваются только этим, сообщение верификации счета, степень риска, основанную на оценке первичного номера счета (PAN), и использование одноразового пароля эмитентом или его агентом для верификации владельца счета. Иллюстративные способы ID&V могут выполняться с использованием такой информации, как подпись пользователя, пароль, офлайновый или онлайновый персональный идентификационный номер (PIN), офлайновый или онлайновый зашифрованный PIN, комбинация офлайнового PIN и подписи, комбинация офлайнового зашифрованного PIN и подписи, биометрика пользователя (например, распознавание голоса, сопоставление отпечатков пальцев и т.д.), шаблон, глиф, основанные на знаниях запросы-ответы, аппаратные токены (несколько вариантов решения), одноразовые пароли (OTP) с ограниченным использованием, программные токены, двухканальные процессы аутентификации (например, через телефон) и т.д. Используя ID&V может быть установлен уровень доверия относительно привязки токена к PAN.

[0041] «Уровнем гарантирования токена» может называться индикатор или значение, которое позволяет поставщику службы токенов указывать уровень доверия у привязки токена к PAN. Уровень гарантирования токена может быть определен поставщиком службы токенов на основании типа выполняемой идентификации и верификации (ID&V) и объекта, который выполнял ID&V. Уровень гарантирования токена может быть задан при выдаче токена. Уровень гарантирования токена может быть обновлен, если выполняется дополнительная ID&V.

[0042] «Запрошенным Уровнем гарантирования токена» может называться уровень гарантирования токена, запрошенный от поставщика службы токенов запросчиком токена. Запрошенный уровень гарантирования токена может быть включен в поле сообщения запроса токена, отправляемого запросчиком поставщику службы токенов для генерации/выдачи токена.

[0043] «Назначенным уровнем гарантирования токена» может называться фактическое (то есть сгенерированное) значение, назначенное поставщиком службы токенов токену в результате процесса идентификации и верификации (ID&V), выполняемого объектом в экосистеме токенизации. Назначенный уровень гарантирования токена может быть обеспечен обратно запросчику токена в ответ на сообщение запроса токена. Назначенный уровень гарантирования токена может отличаться от запрошенного уровня гарантирования токена, содержащегося в сообщении запроса токена.

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

[0045] Атрибуты токена могут идентифицировать тип токена, указывающий, как токен может использоваться. Платежный токен может включать в себя токен для больших сумм, который может использоваться вместо реального идентификатора счета (например, PAN) для генерации первичных и/или последующих транзакций для потребительского счета и/или карты. Другой тип токена может быть «статическим» или «динамическим» типом токена для статических и динамических токенов, соответственно.

[0046] «Режим предъявления токена» может указывать способ, с помощью которого токен представляется для транзакции. Некоторые неограничивающие примеры режима предъявления токена могут включать в себя машиночитаемые коды (например, быстродействующий код (QRC), штрих-код и т.д.), мобильные бесконтактные режимы (например, коммуникация ближнего поля (NFC)), удаленные режимы электронной торговли, режимы пространственной близости электронной торговли и любые другие подходящие режимы, в которых можно представить токен. Токены могут быть обеспечены с помощью любого числа различных способов. Например, в одной реализации токен может быть встроен в машиночитаемый код, который может генерироваться поставщиком кошелька, мобильным приложением или другим приложением на мобильном устройстве и отображаться на дисплее мобильного устройства. Машиночитаемый код может быть отсканирован в POS, посредством чего токен передается торгово-сервисному предприятию. Мобильный бесконтактный режим может включать в себя передачу токена через NFC в бесконтактном сообщении. Удаленный режим электронной торговли может включать в себя представление токена потребителем или поставщиком кошелька посредством онлайновой транзакции или как транзакции электронной торговли с использованием приложения торгово-сервисного предприятия или другого мобильного приложения. Режим пространственной близости электронной торговли может включать в себя представление токена потребителем из приложения кошелька на мобильном устройстве в месте расположения торгово-сервисного предприятия.

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

[0048] «Обмен токена» или «детокенизация» является процессом восстановления данных, которые были подставлены во время токенизации. Например, обмен токена может включать в себя замену платежного токена соответствующим первичным номером счета (PAN), который был ассоциирован с платежным токеном во время токенизации PAN. Таким образом, детокенизацией может называться процесс обмена токена на соответствующее значение PAN на основании сохраненного соответствия токен-PAN, например, в хранилище токенов. Возможность получить PAN в обмен на соответствующий токен может ограничиваться специально авторизованными объектами, людьми, приложениями или системами. Кроме того, детокенизация или обмен токена могут быть применены к любой другой информации. В некоторых вариантах воплощения обмен токена может достигаться через транзакционное сообщение, такое как сообщение ISO, прикладной программный интерфейс (API) или другой тип веб-интерфейса (например, веб-запрос).

[0049] «Запросчиком токена» может называться объект, который хочет осуществить токенизацию в соответствии с вариантами воплощения настоящего изобретения. Запросчик токена может инициировать запрос на токенизацию первичного номера счета (PAN) путем подачи сообщения запроса токена поставщику службы токенов. В соответствии с различными вариантами воплощения, обсуждаемыми в настоящем документе, запросчик токена может больше не нуждаться в хранении PAN, ассоциированного с токеном, после того, как запросчик принял токен в ответ на сообщение запроса токена. Запросчик может быть приложением, устройством, процессом или системой, которая выполнена с возможностью выполнять действия, связанные с токенами. Например, запросчик может запросить регистрацию в системе сетевых токенов, запросить генерацию токена, активацию токена, деактивацию токена, обмен токена, другие процессы, связанный с управлением жизненным циклом токена, и/или любые другие связанные с токеном процессы. Запросчик может взаимодействовать с системой сетевых токенов через любые подходящие сети и/или протоколы связи (например, используя HTTPS, SOAP и/или XML интерфейс среди прочих). Некоторые неограничивающие примеры запросчиков токена могут включать в себя, например, торгово-сервисные предприятия «с записью о карте», эквайеров, процессинговые центры эквайеров и платежные шлюзы, действующие от имени торгово-сервисных предприятий, посредников в реализации платежей (например, фирмы-изготовители комплектного оборудования, операторы мобильной связи и т.д.), поставщиков цифровых кошельков, эмитентов, сторонних поставщиков кошельков и/или сети обработки платежей. В некоторых вариантах воплощения запросчик токена может запросить токены для нескольких доменов и/или каналов. Запросчик токена может быть зарегистрирован и идентифицирован единственным образом поставщиком службы токенов в пределах экосистемы токенизации. Во время регистрации запросчика токена поставщик службы токенов может формально обработать заявку запросчика токена на участие в системе службы токенов. Поставщик службы токенов может собрать информацию, имеющую отношение к природе запросчика и соответствующему использованию токенов, чтобы валидировать и формально одобрить запросчика токена и установить соответствующие средства управления ограничениями домена. Успешно зарегистрированным запросчикам токенов может быть присвоен идентификатор запросчика токена, который также может быть помещен и сохранен в хранилище токенов. Запросчикам токена могут быть отменены или присвоены новые идентификаторы запросчиков токенов. Эта информация может быть предметом отчетности и аудита поставщиком службы токенов.

[0050] «Идентификатор (ID) запросчика токена» может включать в себя любые символы, цифры или другие идентификаторы, ассоциированные с объектом, ассоциированным с системой сетевых токенов. В некоторых вариантах воплощения уникальный ID запросчика токена может присваиваться для каждого домена для запроса токена, ассоциированного с одним и тем же запросчиком токена. Например, ID запросчика токена может идентифицировать объединение в пару запросчика токена (например, мобильное устройство, поставщика мобильного кошелька и т.д.) с доменом токена (например, электронной торговлей, бесконтактной и т.д.). ID запросчика токена может включать в себя любой формат или тип информации. Например, в одном варианте воплощения ID запросчика токена может включать в себя буквенно-цифровое значение, такое как набор из десяти или одиннадцати букв и/или цифр (например, 4678012345). В некоторых вариантах воплощения ID запросчика токена может включать в себя код для поставщика службы токенов (например, первые 3 цифры), такой как система сетевых токенов, и оставшиеся цифры могут быть назначены поставщиком службы токенов для каждого запрашивающего объекта (например, поставщика мобильного кошелька) и домена токена (например, бесконтактной, электронной торговли и т.д.).

[0051] «Индикатором запроса токена» может называться индикатор, используемый для указания, что сообщение, содержащее индикатор, относится с запросу токена. Индикатор запроса токена может быть опционально передан эмитенту как часть способа идентификации и верификации (ID&V), чтобы сообщить эмитенту причины, почему выполняется проверка статуса счета.

[0052] «Домен токена» может указывать факторы, которые могут быть установлены во время выдачи токена, чтобы позволить соответствующее использование токена для платежных транзакций. Примеры домена токена могут включать в себя, но не ограничиваются только этим, режим ввода POS и идентификаторы торгово-сервисного предприятия для однозначного определения, где токен может использоваться. Набор параметров (то есть средства управления ограничениями домена токена) может быть установлен как часть выдачи токена поставщиком службы токенов, который может позволять принудительно задавать соответствующее использование токена в платежных транзакциях. Например, средства управления ограничениями домена токена могут ограничивать использование токена конкретными режимами предъявления, такими как бесконтактные режимы предъявления или режимы предъявления электронной торговли. В некоторых вариантах воплощения средства управления ограничениями домена токена могут ограничивать использование токена конкретным торгово-сервисным предприятием, которое может быть однозначно определено. Некоторые иллюстративные средства управления ограничениями домена токена могут требовать верификации наличия криптограммы токена, которая уникальна для данной транзакции.

[0053] «Датой окончания срока действия токена» может называться дата/время окончания срока действия токена, которая генерируется поставщиком службы токенов и сохраняется в хранилище токенов. Дата окончания срока действия токена может передаваться между объектами экосистемы токенизации во время обработки транзакций, чтобы гарантировать операционную совместимость и минимизировать влияние реализации токенизации. Дата окончания срока действия токена может быть числовым значением (например, 4-значное числовое значение), которое является совместимым со стандартами индустрии.

[0054] «Операционной совместимостью токена» может называться процесс, гарантирующий, что обработка и обмен транзакциями между сторонами через существующие возможности взаимодействия сохраняются при использовании токенов с новыми полями данных и значениями полей данных, которые задаются в вариантах воплощения настоящего изобретения.

[0055] «Обработкой токена» может называться обработка транзакций, в которой присутствует токен вместо первичного номера счета (PAN). Токен обрабатывается от точки взаимодействия и далее по всей сети. Обработка токена дополнительно включает в себя использование хранилища токенов для детокенизации токена для завершения транзакции. Обработка токена может охватывать процессы оплаты, которые включают в себя авторизацию, захват, клиринг и обработку исключений.

[0056] «Потребителем» может быть человек или пользователь, который может быть ассоциирован с одним или несколькими личными счетами и/или потребительскими устройствами. Потребитель может также называться владельцем карточки, владельцем счета или пользователем.

[0057] «Первичный номер счета (PAN)» может быть переменной длины (например, 13-19-разрядным) совместимым со стандартом индустрии номером счета, который генерируется в пределах диапазонов счетов, ассоциированных с BIN эмитентом.

[0058] Торгово-сервисным предприятием «с записью о карте (COF)» могут быть любые объекты, которые хранят реквизиты счета (например, данные о карте, идентификаторы платежного счета, PAN и т.д.) для использования в транзакциях. Например, объект COF может хранить платежную информацию в записях для различных типов периодичных платежей, таких как ежемесячные коммунальные платежи, транзакции периодических покупок или любая другая периодическая или будущая транзакция. Поскольку платежные учетные данные и/или ассоциированные токены сохранены в объекте для будущей транзакции, транзакции, инициируемые объектом COF, включают в себя транзакции «карта физически отсутствует» (CNP). Другой тип транзакции «карта физически отсутствует» (CNP) включает в себя транзакции электронной торговли, которые инициируются между удаленными сторонами (например, потребительским устройством и компьютером веб-сервера торгово-сервисного предприятия).

[0059] «Сообщение запроса авторизации» может быть электронным сообщением, которое отправляют сети обработки платежей и/или эмитенту платежного счета для запроса авторизации на платежную транзакцию. Сообщение запроса авторизации в соответствии с некоторыми вариантами воплощения может соответствовать требованиям ISO 8583, которые являются стандартом для систем, которые обмениваются электронной информацией о транзакции, ассоциированной с платежом, произведенным потребителем, использующим платежное устройство или платежный счет. В некоторых вариантах воплощения изобретения сообщение запроса авторизации может включать в себя платежный токен, дату окончания срока действия, режим предъявления токена, идентификатор запросчика токена, криптограмму токена, уровень гарантирования токена и данные, использовавшиеся для генерации уровня гарантирования токена. Платежный токен может включать в себя идентификатор эмитента платежного токена, который может быть заменой для реального идентификатора эмитента для эмитента. Сообщение запроса авторизации может также содержать дополнительные элементы данных, соответствующие «идентификационной информации», включающие в себя, например, код службы, CVV или CVC (параметр или код проверки подлинности карты), dCVV или dCVC (динамический параметр или код проверки подлинности карты), криптограмму токена, дату окончания срока действия и т.д. Сообщение запроса авторизации может также содержать «информацию о транзакции», например, любую информацию, связанную с текущей транзакцией (например, сумма транзакции, идентификатор торгово-сервисного предприятия, местоположение торгово-сервисного предприятия и т.д.), а так же любую другую информацию, которая может использоваться в определении, идентифицировать ли и/или авторизовать ли платежную транзакцию.

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

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

[0062] «Эмитент» может включать в себя эмитента платежного счета. Платежным счетом (который может быть ассоциирован с одним или несколькими платежными устройствами) может называться любой подходящий платежный счет, в том числе счет кредитной карты, расчетный счет, сберегательный счет, счет торгово-сервисного предприятия, присвоенный потребителю, или предварительно оплаченный счет.

[0063] «Агент» может быть объектом, назначенным эмитентом на выполнение конкретных функций от имени эмитента. Примеры функций могут включать в себя обработку карт, верификацию владельца карты с использованием протокола 3-D Secure и службу токенов. Например, сервер управления доступом (ACS) может быть агентом эмитента, который предоставляет службу 3D-Secure для идентификации и верификации (ID&V).

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

I. Экосистема токенизации

[0065] Реализация решений для токенов, как это показано в вариантах воплощения настоящего изобретения и в соответствии с вариантами воплощения самого настоящего изобретения, включает в себя ряд объектов в пределах экосистемы токенизации, изображенной на фиг. 1.

[0066] Фиг. 1 показывает систему и блок-схему последовательности операций, обеспечивающие обзор различных взаимодействий объектов в экосистеме 100 токенизации в соответствии с иллюстративным вариантом воплощения настоящего изобретения. Экосистема 100 токенизации может включать в себя владельца 102 счета, торгово-сервисное предприятие 106, эквайера 108, платежную сеть 110 и эмитента 104. Запросчик 114 токена и поставщик 116 службы токенов могут формировать систему 112 службы токенов, которая также является частью экосистемы 100 токенизации. Поставщик 116 службы токенов может включать в себя хранилище 118 токенов и серверный компьютер 120 (такой как серверный компьютер, изображенный более подробно на фиг. 10). Как будет обсуждаться ниже, различные объекты экосистемы 100 токенизации могут брать на себя роль запросчика 114 токена. Аналогично, различные объекты экосистемы 100 токенизации могут брать на себя роль(и) поставщика 116 службы токенов. Роли для каждого из этих объектов будут описаны более подробно ниже.

[0067] Эмитент 104 может представлять собой процессинговый центр эмитента бизнес-объекта (например, банк), который мог выдать счет (например, кредитный счет, дебетовый счет и т.д.) для платежных транзакций. В некоторых реализациях бизнес-объект (банк), связанный с эмитентом 104, может также функционировать в качестве эквайера 108. Эмитент 104 может выдать счет, представленный первичным номером счета (PAN), владельцу 102 счета по запросу владельца 102 счета. Владелец 102 счета может использовать счет для проведения платежных транзакций. Эмитент 104 может нести ответственность за авторизацию и текущее управление рисками в экосистеме 100 токенизации. Эмитент 104 должен обрабатывать любые поля данных, обеспеченные в сообщениях, которые передаются к и от эмитента, как определено в вариантах воплощения настоящего изобретения, чтобы должным образом обрабатывать запросы платежных транзакций.

[0068] Владелец 102 счета может пожелать провести платежную транзакцию с торгово-сервисным предприятием 106 с использованием счета (представленного с помощью PAN), выданного эмитентом 104. В целях безопасности, как обсуждается в настоящем документе, владелец 102 счета может не пожелать делиться PAN с торгово-сервисным предприятием 106. Соответственно, токен, представляющий PAN, может быть сгенерирован системой 112 службы токенов и передан серверу 106 торгово-сервисного предприятия (например, серверу торгово-сервисного предприятия или компьютеру).

[0069] В некоторых вариантах воплощения токен можно быть передан посредством коммуникации ближнего поля (NFC) (например, вариант использования в торговой точке). В других вариантах воплощения торгово-сервисное предприятие 106 может уже знать PAN владельца 102 счета (например, вариант использования «с записью о карте»). Например, торгово-сервисное предприятие «с записью о карте» может хранить информацию о счете владельца 102 счета в записях (например, в базе данных торгово-сервисного предприятия) для будущих платежей, таких как различные типы периодических платежей (например, ежемесячные коммунальные платежи). В некоторых реализациях владелец 102 счета может зарегистрироваться в одном или нескольких торгово-сервисных предприятиях 106 для услуг «с записью о карте». Если торгово-сервисное предприятие 106 является торгово-сервисным предприятием «с записью о карте», то торгово-сервисное предприятие 106 может быть запросчиком 114 токена. Когда торгово-сервисное предприятие 106 является запросчиком 114 токена, торгово-сервисное предприятие 106 может нуждаться в обеспечении реализации API службы токенов, которые могут упоминаться в вариантах воплощения настоящего изобретения. Ниже будут более подробно обсуждаться различные варианты использования.

[0070] В соответствии с различными вариантами воплощения торгово-сервисные предприятия «с записью о карте», эквайеры, процессинговые центры эквайеров, платежные шлюзы от имени торгово-сервисных предприятий, посредники в реализации платежей (например, производители устройств фирм-изготовителей комплектного оборудования (OEM)), поставщики цифровых кошельков или эмитенты могут брать на себя роль(и) запросчика 114 токена. Запросчик 114 токена может зарегистрироваться у поставщика 116 службы токенов (то есть в серверном компьютере 120 поставщика 116 услуг). После успешной регистрации у поставщика 116 службы токенов запросчику 114 токена может быть назначен ID запросчика токена. Запросчик 114 токена может реализовать указанный API токена после регистрации у поставщика 116 службы токенов. Различные API, которые могут использоваться применительно к вариантам воплощения настоящего изобретения, обсуждаются ниже применительно к фиг. 9. Запросчик 114 токена может иметь возможность инициировать запрос токена у поставщика 116 службы токенов в соответствии с процессами и технологиями, указанными в API. Запрос токена может быть инициирован путем передачи сообщения запроса токена поставщику 116 службы токенов. Сообщение запроса токена может включать в себя информацию о запросчике токена или ID запросчика токена, средства управления ограничениями домена токена, PAN, который должен быть представлен (например, заменен) токеном и, опционально, запрошенный уровень гарантирования токена.

[0071] Когда поставщик 116 службы токенов обработает сообщение запроса токена, отправленное запросчиком 114 токена, поставщик 116 службы токенов может выдать токен. Выданный токен может быть сохранен в хранилище 118 токенов и предоставлен запросчику 114 токена. Во время генерации токена поставщик 116 службы токенов может идентифицировать и сохранить соответствие токен-PAN в хранилище 118 токенов для использования в последующей обработке транзакций. Хранилище 118 токенов может также навсегда ассоциировать каждый генерируемый токен с запросчиком 114 токена, который подавал запрос, путем захвата и сохранения ID запросчика токена.

[0072] В некоторых вариантах воплощения токены, которые генерируются поставщиком 116 службы токенов, могут иметь соответствующую дату окончания срока действия токена. Дата окончания срока действия токена может соответствовать формату даты окончания срока действия PAN и может быть той же самой датой или датой, отличающейся от даты фактического PAN. В различных вариантах воплощения токены, которые генерируются в ответ на запрос токена от запросчика 114 токена, действительны только для транзакций в пределах домена токена, для которого был выдан токен.

[0073] Соответственно, поставщик 116 службы токенов может быть объектом в пределах экосистемы 100 токенизации, которому может быть разрешено генерировать и/или предоставлять токены запросчику 114 токена. В некоторых вариантах воплощения запросчик 114 токена может быть зарегистрирован у поставщика 116 службы токенов. В соответствии с иллюстративными вариантами воплощения настоящего изобретения платежная сеть 110, эмитент 104 или агент эмитента 104 могут выступать в качестве поставщика 116 службы токенов.

[0074] Поставщик 116 службы токенов может отвечать за ряд отдельных функций в качестве авторизованной стороны для выпуска токенов. Одна или несколько функций поставщика 116 службы токенов может выполняться серверным компьютером 120. Поставщик 116 службы токенов может отвечать за текущую работу и техническое обслуживание хранилища 118 токенов, хранящего генерируемые токены и соответствие между токенами и PAN, представленными токенами. Поставщик 116 службы токенов может отвечать за генерацию и выдачу токенов, а так же применение безопасности и средств управления к генерируемым токенам. Поставщик 116 службы токенов может регистрировать запросчика 114 токена и предоставлять сгенерированный токен устройствам запросчика.

[0075] Поставщик 116 службы токенов может отвечать за создание и/или управление его собственным проприетарным прикладным программным интерфейсом (API) для запросчика 114 токена, хранилища 118 токенов, платформы предоставления токенов и реестра токенов. Поставщик 116 службы токенов может гарантировать, что BIN токенов можно управлять отдельно от традиционных BIN, в частности, чтобы избежать любого случайного совпадения PAN и токенов. Поставщик 116 службы токенов может сгенерировать токен с использованием BIN токенов таким образом, чтобы гарантировать сохранность продукта и других атрибутов PAN в течение всех существующих процессов транзакции.

[0076] В соответствии с различными вариантами воплощения, когда поставщик 116 службы токенов выдает токен для PAN, ассоциированного со счетом, владелец 102 счета может не знать, что был выдан токен для представления счета. В некоторых вариантах воплощения владельца 102 счета могут попросить принять участие в процессе идентификации и верификации (ID&V) во время генерации токена. Например, владельца 102 счета могут попросить предоставить идентификационную информацию, чтобы гарантировать, что токен генерируется для счета, правомерно принадлежащего владельцу 102 счета.

[0077] На основании типа выполняемого ID&V поставщик 116 службы токенов может также сгенерировать уровень гарантирования токена, ассоциированный с генерируемым токеном, во время выпуска токена. Уровень гарантирования токена может представлять уровень доверия в ассоциации между платежным токеном и PAN, представленному платежным токеном. Например, высокий уровень гарантирования токена представляет собой надежную ассоциацию токена с PAN от авторизованного владельца счета, который может поддерживать безопасные и надежные платежные транзакции, инициируемые при оплате. Сгенерированный уровень гарантирования токена может отличаться от запрошенного уровня гарантирования токена, который может быть опционально предоставлен поставщику 116 службы токенов запросчиком 114 в сообщении запроса токена. В некоторых вариантах воплощения на основании типа выполняемого ID&V или объекта, выполняющего ID&V, сгенерированный уровень гарантирования токена может быть таким же, как запрошенный уровень гарантирования токена. Уровни гарантирования токена могут изменяться после того, как они были назначены, и могут повторно вычисляться на основании факторов, которые могут влиять на уровни доверия, такие как сообщение о мошенничестве или связанные с мошенничеством возвратные платежи и т.д.

[0078] Уровень гарантирования токена, сгенерированный поставщиком 116 службы токенов, может быть основан на ID&V, который выполнялся, и объекте, выполняющем ID&V. Способы ID&V могут использоваться по-отдельности или в комбинации для обеспечения конкретного уровня гарантирования токена. Поставщик 116 службы токенов может реализовать один или несколько способов ID&V. Дополнительно, поставщик 116 службы токенов может гарантировать, что способ(ы) ID&V, подходящие для запрошенного уровня гарантирования токена, всегда выполняются при выдаче токена.

[0079] Этапы ID&V могут выполняться поставщиком 116 службы токенов, запросчиком 114 токена или третьей стороной. В случаях, когда этапы ID&V выполняются объектом, отличающимся от поставщика 116 службы токенов, могут быть предоставлены поддающиеся проверке доказательства, чтобы доказать, что этапы выполнялись, и что были обеспечены вытекающие результаты. Поддающиеся проверке доказательства могут состоять из любого значения, предоставленного поставщику 116 службы токенов объектом обработки ID&V, которое поставщик 116 службы токенов может валидировать. Примеры поддающихся проверке доказательств могут включать в себя криптограмму или код авторизации. Они могут применяться ко всем способам ID&V, за исключением случаев, в которых ID&V не выполняется. Поставщик 116 службы токенов может задать уровень гарантирования токена равным соответствующему значению(ям) на основании выполняемого ID&V, и информации о хранении и использовании токена, предоставленной запросчиком 114 токена во время регистрации запросчика токена.

[0080] В соответствии с различными вариантами воплощения настоящего изобретения уровни гарантирования токена могут варьироваться от отсутствия гарантирования до высокого уровня гарантирования в зависимости от выполняемой методологии ID&V, объекта, выполняющего ID&V, и поставщика 116 службы токенов, который подтверждает результат оценки. Иллюстративные способы ID&V могут включать в себя, но не ограничиваются только этим, (1) ID&V не выполняется, (2) верификацию счета, (3) показатель риска поставщика службы токенов, (4) показатель риска поставщика службы токенов с данными запросчика токена и (5) аутентификация эмитента владельца счета. Специалисту в области техники будет понятно, что предшествующие способы ID&V обеспечены только с целями иллюстрации, и что дополнительные способы ID&V могут быть определены и выполнены в соответствии с вариантами воплощения настоящего изобретения.

(1) ID&V не выполняется

[0081] Когда токен выдается без выполнения какого-либо способа ID&V во время выдачи токена, уровень гарантирования токена может указывать (например, значение уровня гарантирования токена может быть установлено равным) «Нет гарантирования». В некоторых вариантах воплощения отсутствие ID&V не приводит к самому низкому уровню гарантирования токена, присваиваемому выданному токену. В зависимости от варианта использования токена и правил поставщика службы токенов, токен может тем не менее использоваться для инициирования платежных транзакций, но не может нести какого-либо гарантирования токена или может нести низкое гарантирование токена. Дополнительные ограничения для использования токенов с отсутствующим уровнем гарантирования могут быть реализованы в соответствии с вариантами воплощения настоящего изобретения.

(2) Верификация счета

[0082] Верификация счета может представлять собой способ гарантирования ID&V, который обеспечивает базовую верификационную проверку счета для валидации, что PAN активен и действителен. В различных вариантах воплощения верификация счета может включать в себя: авторизация за 0$, валидацию проверочного номера карты и верификацию почтового индекса и адреса. Способ верификации счета может выполняться, например, запросчиком 114 токена и сообщаться поставщику 116 службы токенов через API службы токенов. Способ верификации счета может также выполняться поставщиком 116 службы токенов во время выдачи токена. Когда токен выдается путем выполнения верификации счета во время выдачи токена, уровень гарантирования токена может указывать (например, значение уровня гарантирования токена может быть установлено равным) «верификация запросчиком токена выполнена» или «гарантируется запросчиком токена».

(3) Гарантирование поставщиком службы токенов

[0083] Гарантирование поставщиком службы токенов является типом способа гарантирования ID&V, который включает в себя выполнение поставщиком 116 службы токенов основанной на рисках оценки вероятности, что запрос токенизировать PAN гарантируется с достаточным уровнем доверия. Поставщик 116 службы токенов может выполнить основанную на рисках оценку с использованием данных о риске и аутентификации, сохраняемых поставщиком 116 службы токенов. Когда токен выдается с гарантированием поставщиком службы токенов, уровень гарантирования токена может указывать (например, значение уровня гарантирования токена может быть установлено равным) «гарантируется поставщиком службы токенов». В некоторых вариантах воплощения гарантирование поставщиком службы токенов может приводить к среднему уровню гарантирования токена, назначаемому выданному токену.

(4) Гарантирование поставщиком службы токенов с данными запросчика

[0084] Гарантирование поставщиком службы токенов с данными запросчика является способом гарантирования ID&V, который включает в себя использование элементов данных, обеспеченных запросчиком 114 токена, которые могут предсказывать мошенничество. Например, запросчик 114 токена может предоставить, среди прочей информации, возраст счета и историю, адрес выставления счета/доставки и контактную информацию, IP-адрес, ID устройства и информацию об устройстве, географическое местоположение и скорость транзакции. Поставщик 116 службы токенов может иметь соответствующие методики оценки и инструменты для реализации этого способа ID&V и может объединять получающиеся данные ID&V с данными о риске и аутентификации поставщика службы токенов, относящимися к PAN, для определения назначенного уровня гарантирования токена. Когда токен выдается с гарантированием поставщиком службы токенов с данными запросчика, уровень гарантирования токена может указывать (например, значение уровня гарантирования токена может быть установлено равным) «гарантируется поставщиком службы токенов с данными запросчика». В некоторых вариантах воплощения гарантирование поставщиком службы токенов может приводить к среднему уровню гарантирования токена, назначаемому выданному токену.

(5) Верификация эмитентом владельца счета

[0085] Верификация эмитентом владельца счета является способом ID&V, который включает в себя взаимодействие с эмитентом 104 или агентом(ами) эмитента для выполнения верификации владельца счета для обеспечения гарантирования, необходимого для завершения привязки токена к PAN. Способы, используемые для верификации, могут быть реализованы для обеспечения приемлемого пользовательского интерфейса на основании типа устройства (например, мобильный телефон, компьютер и т.д.), который владелец счета может использовать во время процесса аутентификации. В некоторых вариантах воплощения могут быть созданы инструкции для устройства, которым необходимо следовать, чтобы гарантировать единообразный пользовательский интерфейс. Аутентификация эмитентом может использовать входные данные и показатели от запросчика 114 токена, чтобы эмитент 104 мог предоставить максимально интеллектуальный интерфейс владельцу 102 счета. Использование этих данных может позволить эмитенту 104 быть уверенным, что подлинный и авторизованный владелец 102 счета фактически запрашивает токен (или токен запрошен для подлинного и авторизованного владельца 102 счета), без необходимости добавлять дополнительные этапы к процессу. Входные данные, запрошенные/полученные от владельца 102 счета, могут включать в себя, среди прочего, географическое местоположение, информацию об устройстве, IP-адрес, информацию о потребителе (например, адрес электронной почты, номер мобильного телефона, номер проводного телефона, подтвержденный адрес поставки, ID&V потребителя и длительность взаимоотношений с клиентом) и информацию о счете (например, продолжительность по времени активности в кошельке и/или по счету, такая как отсутствует, недавняя или давняя). Когда токен выдается с верификацией эмитентом владельца счета, уровень гарантирования токена может указывать (например, значение уровня гарантирования токена может быть установлено равным), «Гарантируется эмитентом». В некоторых вариантах воплощения верификация эмитентом владельца счета может приводить к высокому уровню или самому высокому уровню гарантирования токена, назначаемому выданному токену.

[0086] В соответствии с различными вариантами воплощения верификация эмитентом владельца счета может быть выполнена через сервер управления доступом (ACS) 3-D Secure, мобильную банковскую верификацию владельца счета с помощью кода аутентификации, федеративные системы входа, функциональность API, способную к генерации, доставке и проверке данных от запросчика токена и общих секретов, одноразового пароля (OTP), кода активации или другого общего секрета между эмитентом 104 и владельцем 102 счета. Если эмитент 104 определяет, что имеется необходимость верифицировать владельца 102 счета, запрашивающего токен, посредством явной верификации (например, с использованием OTP или кода активации), общий секрет может быть доставлен владельцу 102 счета через внеполосный канал.

[0087] Эмитент 104 может использовать множество способов для аутентификации владельца счета. В соответствии с некоторыми вариантами воплощения статические пароли и подача на регистрацию в службе аутентификации во время аутентификации владельца счета не могут быть разрешены для способов ID&V. В отличие от этого, как указано выше, могут использоваться одноразовые пароли для аутентификации владельца счета эмитентом 104. Когда используется OTP, эмитент 104 может потребовать, чтобы OTP имел длину по меньшей мере 6 цифр и не более 8 цифр, OTP генерируется с использованием единой методологии, и предпочтительный способ для доставки является безопасный канал от эмитента 104 к потребительскому устройству владельца 102 счета (например, мобильное банковское приложение, установленное на потребительском устройстве).

[0088] Возвращаясь к фиг. 1, когда генерируются токен и соответствующий уровень гарантирования токена, поставщик 116 службы токенов может сохранить сгенерированный токен, PAN, представленный токеном, уровень гарантирования токена, ассоциированный с токеном, и данные (например, тип выполненного ID&V, данные, использованные при выполнении ID&V, объект, выполнявший ID&V и т.д.), использовавшиеся для генерации уровня гарантирования токена в репозитарии, таком как хранилище 118 токенов.

[0089] Хранилище 118 токенов может обеспечивать возможность генерации и выдачи токенов, установления и сохранения соответствия токен-PAN, и обеспечивать базовую безопасность и связанные с ней элементы управления обработкой, такие как ограничения домена во время обработки транзакций. Хранилище 118 токенов может обеспечивать механизм для соответствия токен-PAN, которое должно быть доступным во время обработки транзакций, такой как авторизация, клиринг и обработка исключений. Хранилище 118 токенов может иметь необходимость хранить все ассоциированные токены, соответствующие данному PAN, в течение всего его жизненного цикла.

[0090] Токен, сгенерированный поставщиком 116 службы токенов, может быть предоставлен запросчику 114 токена в ответ на запрос токена запросчика 114 токена. Как указано выше, запросчик 114 токена может быть зарегистрирован у поставщика 116 службы токенов. Поставщик 116 службы токенов может предоставить сгенерированный токен запросчику 114 токена, когда поставщик 116 службы токенов распознает ID запросчика токена, назначенный запросчику 114 токена во время регистрации. Выдача токена может также включать в себя предоставление токена запросчику 114 токена. Предоставление токена может происходить после того, как токен был сгенерирован и этапы гарантирования завершились. Предоставление токена может выполняться через интерфейс между запросчиком 114 токена и поставщиком 116 службы токенов.

[0091] Если запросчик 114 токена является владельцем 102 счета, после приема токена владелец 102 счета может представить токен торгово-сервисному предприятию 106 в сообщении запроса авторизации платежа. Альтернативно, если запросчик 114 токена является торгово-сервисным предприятием 106, токен может быть непосредственно предоставлен торгово-сервисному предприятию 106 поставщиком 116 службы токенов. Торгово-сервисное предприятие 106 может генерировать сообщение запроса авторизации платежа. Сообщение запроса авторизации платежа может быть для проведения платежной транзакции с использованием первичного номера счета, представленного токеном, содержащимся в сообщении запроса авторизации платежа. Торгово-сервисное предприятие 106 может отправить сообщение запроса авторизации платежа, включающее в себя токен, эквайеру 108 для дальнейшей обработки.

[0092] Эквайер 108 может быть системой (компьютером эквайера или сервером) для объекта (например, банка), у которого имеются деловые отношения с торгово-сервисным предприятием 106. Эквайер 108 может выдать и управлять финансовым счетом для торгово-сервисного предприятия 106. В общем, эквайер 108 может отвечать за авторизацию, захват, клиринг и обработку исключений в экосистеме 100 токенизации. Эквайер 108 может быть соединен с возможностью связи с торгово-сервисным предприятием 106 и сетью 110 обработки платежей. Компьютер 108 эквайера может быть выполнен с возможностью маршрутизации сообщения запроса авторизации, включающего в себя токен, к компьютеру 104 эмитента через компьютер 110 сети обработки платежей. Компьютер 108 эквайера может также маршрутизировать сообщение ответа на запрос авторизации, принятое от компьютера 104 эмитента, через компьютер 110 сети обработки платежей к компьютеру 106 торгово-сервисного предприятия.

[0093] Платежная сеть 110 (также называемая сетью обработки платежей) может быть соединена с возможностью связи с эмитентом 104 и эквайером 108. Платежная сеть 110 может быть выполнена с возможностью предоставления услуг авторизации и расчетно-клиринговых услуг для платежных транзакций. Платежная сеть 110 может включать в себя подсистемы обработки данных, проводные или беспроводные сети, включая в том числе Интернет. Платежная сеть 110 может включать в себя серверный компьютер. В некоторых реализациях платежная сеть 110 может передавать сообщение запроса авторизации, принятое от эквайера 108, эмитенту 104 через канал связи. Сообщение запроса авторизации, принятое от эквайера 108, может включать в себя токен.

[0094] Платежная сеть 110 может осуществлять связь с поставщиком 116 службы токенов для получения уровня гарантирования токена, ассоциированного с токеном. Уровень гарантирования токена может представлять собой уровень доверия в ассоциации между платежным токеном и PAN, представленным платежным токеном. Уровень гарантирования токена может генерироваться поставщиком 116 службы токенов, и, когда токен сгенерирован, сохраняться в хранилище 118 токенов наряду с платежным токеном. Платежная сеть 110 может изменять сообщение запроса авторизации, принятое от эквайера 108, для включения в него уровня гарантирования токена и данных (например, типа выполнявшегося ID&V, данных, используемых при выполнении ID&V, объекта, выполнявшего ID&V и т.д.), использовавшихся для генерации уровня гарантирования токена. Платежная сеть 110 может также изменять сообщение запроса авторизации для включения в него PAN, представленного токеном, содержащимся в сообщение запроса авторизации. Платежная сеть 110 может затем передавать измененное сообщение запроса авторизации эмитенту 104. Платежная сеть 110 может принимать сообщение ответа на запрос авторизации от компьютера 170 эмитента и пересылать принятое сообщение ответа на запрос авторизации эквайеру 108. В некоторых вариантах воплощения платежная сеть 110 может изменять сообщение ответа на запрос авторизации, принятое от эмитента 104, перед пересылкой сообщения ответа на запрос авторизации эквайеру 108. Например, платежная сеть 110 может изменять сообщение ответа на запрос авторизации для удаления PAN (например, замены PAN токеном), если PAN был включен в сообщение ответа на запрос авторизации, и может включать последние 4 цифры PAN в сообщение ответа на запрос авторизации.

[0095] В соответствии с различными вариантами воплощения настоящего изобретения платежная сеть 110 может служить поставщиком 116 службы токенов. Иллюстративный вариант воплощения, в котором платежная сеть 110 служит поставщиком 116 службы токенов, обсуждается более подробно ниже применительно к фиг. 2. Платежная сеть 110, выступающая в качестве поставщика 116 службы токенов, может отвечать за создание и/или управление их собственным проприетарным API запросчика токена, хранилищем токенов, платформой предоставления токенов и реестром токенов. Платежная сеть 110, который не является поставщиком 116 службы токенов, может поддерживать реализацию функций обработки, которые позволяют осуществлять обмен сообщениями с поставщиком 116 службы токенов с целями детокенизации для обеспечения операционной совместимости токенов.

[0096] Фиг. 2 показывает систему и блок-схему последовательности операций, обеспечивающие обзор различных взаимодействий объектов в экосистеме 200 токенизации, где платежная сеть 210 служит поставщиком 216 службы токенов, в соответствии с иллюстративным вариантом воплощения настоящего изобретения. Некоторые из объектов, изображенных на фиг. 2, являются такими же или аналогичными объектам, изображенным на фиг. 1. Подробное описание этих объектов обеспечено выше применительно к фиг. 1 и, как таковое, будет опущено ниже.

[0097] Как изображено на фиг. 2, владелец 102 счета может пожелать провести платежную транзакцию с торгово-сервисным предприятием 106. Владелец 102 счета может быть в состоянии инициировать транзакцию с использованием идентификатора платежного счета (например, первичного номера счета (PAN)). Кроме того, владелец 102 счета может быть способен использовать потребительское устройство для инициирования транзакции с использованием любого подходящего канала транзакции, например, посредством сканирования мобильного устройства (например, с использованием QR™ кода или штрих-код), касания мобильным устройством устройства доступа торгово-сервисного предприятия (например, транзакция с помощью коммуникации ближнего поля (NFC) или другая бесконтактная транзакция/транзакция пространственной близости), щелчка на компьютере или другом мобильном устройстве для инициирования транзакции электронной торговли (например, онлайн-транзакция) или через любой другой канал, в котором может быть инициирована транзакция, и токен может быть передан компьютеру торгово-сервисного предприятия. Например, в некоторых вариантах воплощения мобильное устройство может использоваться для инициирования удаленной транзакции с токеном, предоставленным на безопасный элемент, другую защищенную память мобильного устройства или в «облаке», например, с эмуляцией основной карты.

[0098] Если владелец 102 счета обладает платежным устройством, которое включает в себя токен, представляющий номер учетной записи, владелец 102 счета может представить токен торгово-сервисному предприятию 106 посредством сканирования или касания платежным устройством платежного терминала торгово-сервисного предприятия 106. Если владелец 102 счета не обладает токеном, владелец 102 счета (например, платежное устройство владельца 102 счета) может связаться с запросчиком 114 токена, чтобы запросить токен. Альтернативно, торгово-сервисное предприятие 106 может связаться (или стать) с запросчиком 114 токена, чтобы получить токен для транзакции, инициированной или запрошенной владельцем 102 счета.

[0099] Запросчик 114 токена может зарегистрироваться у поставщика 216 службы токенов (то есть платежной сети 210 на фиг. 2) и может принять идентификатор запросчика токена, предоставленный поставщиком 216 службы токенов. Поставщик 216 службы токенов может установить процесс для регистрации объектов, которые запрашивают, чтобы их назначили запросчиком 114 токена. В некоторых вариантах воплощения объекты, которые хотят считаться запросчиком 114 токена для нескольких поставщиков службы токенов, могут зарегистрироваться отдельно у каждого поставщика службы токенов в соответствии с проприетарными процессами, установленными каждым поставщиком службы токенов. Поставщик 216 службы токенов может определить информацию, которая должна быть собрана у запросчика 114 токена перед регистрацией запросчика 114 токена. Поставщик 216 службы токенов может также установить свои собственные проприетарные процессы для сбора, рассмотрения и одобрения принятой информации. Иллюстративная информация, собранная от запросчика 114 токена, может включать в себя, но не ограничивается только этим, информацию «знай своего клиента» (KYC), а также варианты использования токена, которые регистрирующийся запросчик токена может поддерживать, в том числе любые соответствующие ограничения домена и другие элементы управления транзакциями, которые могут быть реализованы в хранилище 218 токенов. Результатом функции регистрации является решение об одобрение или отклонении заявки на регистрацию предполагаемого запросчика 114 токена. Если запросчик 114 токена одобрен поставщиком 216 службы токенов, запросчику 114 токена присваивается уникальный ID запросчика токена.

[0100] Регистрация запросчика токена является функцией, которая может гарантировать добросовестность системы 216 службы токенов путем подачи на регистрацию, одобрения и регистрации объекта как запросчика 114 токена. Поставщик 216 службы токенов (то есть платежная сеть 210 на фиг. 2) может присвоить по меньшей мере один уникальный ID запросчика токена запросчику 114 токена, и может отвечать за управление жизненным циклом запросчика 114 токена и соответствующим ID запросчика токена. Как часть регистрации, платежная сеть 210 может также захватить запрошенный уровень гарантирования токена и элементы управления ограничением домена токена, ассоциированные с запросчиком 114 токена. Платежная сеть 210 может гарантировать, что ограничения домена доступны хранилищу 218 токенов для применения ограничений во время обработки транзакций с токеном.

[0101] ID запросчика токена, присвоенный платежной сетью 210, действующей в качестве поставщика 216 службы токенов, может быть уникальным и не конфликтовать с другими присвоенными ID запросчика токена от той же самой платежной сети 210 или другого поставщика службы токенов. ID запросчика токена может включать в себя 11-значное числовое значение, присвоенное платежной сетью 210 со следующим иллюстративным правилом: позиции 1-3 могут содержать код поставщика службы токенов, уникальный для каждого поставщика службы токенов; а позиции 4-11 могут быть назначены поставщиком службы токенов для каждого запрашивающего объекта и домена токена. Код поставщика службы токенов может присваиваться каждому поставщику службы токенов и храниться поставщиком службы или набору поставщиков службы, которые обеспечивают управление, разработку и техническое обслуживание вариантов воплощения настоящего изобретения. ID запросчика токена является базовым элементом управляющей информации, который может присутствовать в транзакциях, обсуждаемых в настоящем документе.

[0102] Запросчик 114 токена может указать предпочтения конфигурации или атрибуты токена, ассоциированные с запрошенным токеном. Предпочтения конфигурации или атрибуты токена могут включать в себя, например, тип токена (например, статичный или динамический), поддерживаемые режимы предъявления токена (например, сканирование, бесконтактно, электронная торговля и т.д.) и любую другую соответствующую информация о конфигурации токена в сообщении запроса токена. Запросчик 114 токена может отправить сообщение запроса токена поставщику 216 службы токенов. Соответственно, сообщение запроса токена может включать в себя ID запросчика токена, атрибуты токена, элементы управления ограничениями домена токена, PAN, который должен быть представлен (например, заменен) токеном, и, опционально, запрошенный уровень гарантирования токена.

[0103] Платежная сеть 210 как поставщик 216 службы токенов отвечает за определение ожидаемого уровня гарантирования, ассоциированного с каждым одобренным запросчиком 114 токена. Фактический уровень гарантирования токена может быть определен во время генерации токена на основании типа и результата процесса ID&V. Фактический уровень гарантирования токена может отличаться от запрошенного уровня гарантирования токена.

[0104] Чтобы гарантировать, что токены используются запросчиком 114 токена по назначению, могут быть необходимы дополнительные элементы управления для управления и валидации базового использования токенов. Элементы управления могут быть заданы и реализованы платежной сетью 210 как поставщиком 216 службы токенов на основании условий, включающих в себя варианты использования и домены токена, такие как идентификаторы торгово-сервисных предприятий и режимы предъявления токена, которые идентифицируются во время процесса регистрации запросчика токена. Элементы управления доменом токена могут быть предназначены для того, чтобы гарантировать, что утечка данных токенов не приведет к значительными уровнями последующего мошенничества. Разрешенные элементы управления доменом токена для данного запросчика 114 токена частично управляются вариантами использования токена, указанными во время регистрации запросчика токена и одобренными платежной сетью 210 как поставщиком 216 службы токенов. Элементы управления ограничениями домена могут храниться в хранилище 218 токенов.

[0105] Другие элементы управления, которые предназначены для ограничения транзакций, ассоциированных с запросчиком 114 токена, могут включать в себя использование значения режима предъявления токена, которые находятся в поле данных режим ввода POS (POS Entry Mode) сообщения запроса авторизации платежа. Значения режима предъявления токена могут ограничивать использование токенов только теми режимами предъявления токена, которые были согласованы во время регистрации запросчика токена. Например, если запросчик 114 токена зарегистрировался для варианта использования «с записью о карте», платежная сеть 210 может выдавать токены с ограниченным использованием идентификатором (ID) запросчика токена и значениями режима предъявления токена, которые указывают электронную торговлю, так что только будет разрешена обработка платежной сетью 210 только транзакций электронной торговли. В других вариантах воплощения, когда режим предъявления токена является NFC режимом предъявления в торговой точке, использование токена может быть ограничено только значениями режимов ввода POS с помощью бесконтактной микросхемы.

[0106] В вариантах воплощения, в которых торгово-сервисное предприятие 106 является запросчиком 114 токена, связанные с торгово-сервисным предприятием элементы данных, такие как ID акцептанта карты, в комбинации с идентифицирующими эквайера элементами данных и криптограммой токена могут использоваться для ограничения использования токена путем путем проверки или сравнения этих полей в сообщениях обработки транзакций с элементами управления, установленными в хранилище 218 токенов, для информации, выясненной во время регистрации запросчика токена. Иллюстративный вариант воплощения может включать в себя токенизацию PAN, хранящихся в торгово-сервисных предприятиях «с записью о карте».

[0107] После приема сообщения запроса токена от запросчика 114 токена платежная сеть 210 может сгенерировать токен для PAN, обеспеченного в сообщении запроса токена. Платежная сеть 210 может запросить тип выполняемого ID&V, чтобы подтвердить, является ли человек, проводящий транзакцию, законным владельцем счета. На основании тип выполняемого ID&V и информации об объекте, выполняющем ID&V, платежная сеть 210 может также сгенерировать уровень гарантирования токена, ассоциированный с генерируемым токеном. Уровень гарантирования токена может представлять собой уровень доверия в ассоциации между генерируемым платежным токеном и PAN, представленным платежным токеном. Платежная сеть 210 может сохранить ассоциацию между PAN и сгенерированным токеном вместе с уровнем гарантирования токена и данными, использовавшимися для генерации уровня гарантирования токена, в хранилище 218. Платежная сеть 210 может предоставить токен запросчику 114 токена в сообщении ответа на запрос токена.

[0108] Запросчик 114 токена может представить токен торгово-сервисному предприятию 106, которое может сгенерировать сообщение запроса авторизации платежа, включающее в себя токен. Торгово-сервисное предприятие 106 может отправить сообщение запроса авторизации платежа эквайеру 108, который может затем передать сообщение запроса авторизации платежа платежной сети 210. Если ID запросчика токена также передается торгово-сервисному предприятию 106, транзакцию может быть не разрешено успешно обрабатывать, если ID запросчика токена, присутствующее в сообщении запроса авторизации платежа, не совпадает с ID запросчика токена, ассоциированным с токеном в хранилище 218 токенов, или если криптограмма токена не проходит валидацию.

[0109] После приема сообщения запроса авторизации платежа платежная сеть 210 может взаимодействовать с хранилищем 218 токенов и/или другим сетевым сервером(ами) 220 для детокенизации токена, предоставленного в сообщении запроса авторизации платежа. В частности, платежная сеть 210 может получить PAN, представленный токеном, в результате процесса детокенизации. Платежная сеть 210 может затем изменить сообщение запроса авторизации платежа, чтобы включить PAN наряду с (или вместо) токеном, а также уровень гарантирования токена и данные, использовавшиеся для генерации уровня гарантирования токена. Платежная сеть 210 может отправить измененное сообщение запроса авторизации платежа эмитенту 104.

[0110] Эмитент 104 после приема PAN, токена, представляющего PAN, уровня гарантирования токена и данных, использовавшихся при генерации уровня гарантирования токена, в сообщении запроса авторизации платежа может выполнить валидацию на уровне счета и проверку авторизации. Эмитент 104 может отправить сообщение ответа на запрос авторизации платежа платежной сети 210, одобряющее или отклоняющее платежную транзакцию. Сообщение ответа на запрос авторизации платежа может включать в себя PAN, токен, информацию о запросчике токена или ID запросчика токена, элементы управления ограничениями домена токена, уровень гарантирования токена и данные, использовавшиеся для генерации уровня гарантирования токена, среди прочих данных. Платежная сеть 210 может изменить сообщение ответа на запрос авторизации платежа, чтобы заменить PAN токеном. В некоторых вариантах воплощения платежная сеть 210 может включить уровень гарантирования токена в сообщение ответа на запрос авторизации платежа, но может удалить данные, использовавшиеся при генерации уровня гарантирования токена. Содержание сообщения запроса авторизации платежа и сообщения ответа на запрос авторизации платежа обсуждаются более подробно ниже применительно к иллюстративным вариантам использования. Платежная сеть 210 может отправить измененное сообщение ответа на запрос авторизации платежа торгово-сервисному предприятию 106 через эквайера 108. На основании сообщения ответа на запрос авторизации торгово-сервисное предприятие 106 может завершить транзакцию с владельцем 102 счета.

II. Иллюстративные варианты использования

[0111] В этом разделе представлено описание и схемы последовательностей операций для транзакций с токенами для иллюстративных вариантов использования, представленных на фиг. 3-8. Иллюстративные варианты использования, определенные в вариантах воплощения настоящего изобретения, включают в себя мобильные коммуникации ближнего поля (NFC) в торговой точке (фиг. 3), электронную торговлю с помощью мобильного/цифрового кошелька (фиг. 4), электронную торговлю «с записью о карте» (фиг. 5), сканирование в торговой точке (фиг. 6), обработку клиринга и захвата (фиг. 7) и обработку исключений (фиг. 8). Соответственно, фиг. 3-8 идентифицируют некоторые из элементов данных, которые могут присутствовать в транзакциях с авторизацией, захватом, клирингом и обработкой исключений, в зависимости от варианта использования и элемента данных.

[0112] Реализация службы токенов на основании вариантов воплощения настоящего изобретения может включать в себя передачу связанных с токеном данных в полях данных сообщений, как указано на фиг. 3-8. В иллюстративных вариантах воплощения, изображенных на фиг. 3-8, платежная сеть выступает в качестве поставщика службы токенов. Однако настоящее изобретение не ограничивается иллюстративными вариантами воплощения, изображенными на фиг. 3-8. Например, как указано выше, другие объекты экосистемы токенизации могут выступать в качестве поставщика службы токенов. Варианты воплощения гарантируют, что когда платежная сеть выступает в качестве поставщика службы токенов, платежная сеть может распознать транзакции с токенами, чтобы поставить в соответствие токенам PAN во время обработки транзакций.

Вариант 1 использования: Мобильная NFC в торговой точке

[0113] Обращаясь теперь к фиг. 3, вариантом 300 использования мобильной NFC в торговой точке называется использование поддерживающего NFC мобильного устройства 302 для инициирования бесконтактной оплаты на терминале 302 торгово-сервисного предприятия. Мобильное устройство 302 может быть обеспечено токеном, который сохранен в защищенной памяти, такой как безопасный элемент, мобильного устройства 302. В соответствии с различными вариантами воплощения обеспечение токена может выполняться путем взаимодействия запросчика токена с поставщиком службы токенов, как обсуждалось выше.

[0114] Когда транзакция инициируется, мобильное устройство 302 может сгенерировать бесконтактную транзакцию 306, включающую в себя токен, дату окончания срока действия токена, криптограмму токена и другие элементы данных микросхемы. Эти элементы данных могут быть включены в бесконтактную транзакцию 306 в специальных полях данных, как изображено на фиг. 3. В соответствии с различными вариантами воплощения мобильное устройство 302 может передать элементы данных токена терминалу 304 торгово-сервисного предприятия следующим образом: токен может быть передан в поле F2 данных PAN; дата окончания срока действия токена может быть передана в поле F14 данных даты окончания срока действия PAN; криптограмма токена может быть сгенерирована на основании элементов данных токена и может быть передана в поле F55 данных криптограммы микросхемы; режим предъявления токена может быть установлен равным режиму ввода POS для бесконтактных транзакций в поле F22 данных; и все другие элементы бесконтактных данных могут быть созданы и переданы следуя типичной бесконтактной связи. Криптограмма токена, сгенерированная мобильным устройством 302, может служить полем управления ограничениями домена, которое может использоваться поставщиком службы токенов для валидации добросовестности транзакции, использующей токен.

[0115] Мобильное устройство 302 может передать бесконтактную транзакцию 306, включающую в себя указанные выше поля данных, кассовому терминалу 304 торгово-сервисного предприятия через интерфейс NFC. Терминал 304 торгово-сервисного предприятия может отправить сообщение 310 запроса авторизации эквайеру 308. Сообщение 310 запроса авторизации, отправленное терминалом 304 торгово-сервисного предприятия эквайеру 308, может включать в себя те же самые элементы данных, что и бесконтактная транзакция 306, отправленная мобильным устройством 302 терминалу 304 торгово-сервисного предприятия.

[0116] После приема сообщения 310 запроса авторизации эквайер 308 может выполнить проверки и передать поля данных с токеном и бесконтактные данные платежной сети 312, выступающей в качестве поставщика службы токенов. Сообщение 314 запроса авторизации, отправленное эквайером 308 платежной сети 312, может включать в себя те же самые элементы данных, что и сообщение 310 запроса авторизации и бесконтактная транзакция 306.

[0117] Платежная сеть 312, выступающая в качестве поставщика службы токенов, может обработать транзакцию с токеном. Обработка может включать в себя взаимодействие с хранилищем 313 токенов для получения PAN, представленного принятым токеном. Платежная сеть 312 может верифицировать состояние соответствия токен-PAN в хранилище 313 токенов, чтобы гарантировать, что токен находится в активном состоянии. Платежная сеть 312 может валидировать криптограмму токена, принятую в сообщении 314 запроса авторизации. Платежная сеть 312 может также валидировать элементы управления ограничениями домена, сохраненные в хранилище 313 токенов для принятого токена. Платежная сеть 312 может также извлечь из хранилища 313 токенов уровень гарантирования токена и данные, использовавшиеся при генерации уровня гарантирования токена, ассоциированного с принятым токеном. Платежная сеть 312 может затем изменить сообщение 314 запроса авторизации, чтобы генерировать измененное сообщение 318 запроса авторизации. В измененном сообщении авторизации токен может быть заменен на PAN в поле F2 данных; дата окончания срока действия токена может быть заменена датой окончания срока действия PAN в поле F14 данных; режим ввода POS может быть передан в поле F22 данных; в поле F60.6 данных может быть включен индикатор, чтобы передать эмитенту, что валидация токена «от имени» была завершена поставщиком службы токенов; ID продукта может быть передан в поле F62.23 данных; и могут быть включены различные связанные с токеном поля. Например, связанные с токеном поля могут включать в себя токен, переданный в поле F123 - DSI 68 Tag1 данных, дату окончания срока действия токена, уровень гарантирования токена, переданный в поле F123 - DSI 68 Tag2 данных, данные гарантирования токена и ID запросчика токена, переданный в поле F123 - DSI 68 Tag3 данных. После генерации измененного сообщения 318 запроса авторизации платежная сеть 312 может отправить измененное сообщение 318 запроса авторизации эмитенту 316.

[0118] Поля данных, изображенные в настоящем документе, обеспечены только с иллюстративными целями и не должны рассматриваться как ограничение. Та же самая или аналогичная информация может быть передана в других полях данных. Например, ID запросчика токена может быть передан в подполе 6 подэлемента 33 элемента 48 данных, код продукта может быть передан в подполе 4 подэлемента 33 элемента 48 данных, а уровень гарантирования токена в подполе 5 подэлемента 33 элемента 48 данных. Эти и любые другие поля данных, используемые для передачи информации, обсуждаемой в настоящем документе, находятся в пределах объема настоящего изобретения.

[0119] Эмитент 316 может завершить валидацию на уровне счета и проверку авторизации с использованием информации, предоставленной в измененном сообщении 318 запроса авторизации. Эмитент может отправить сообщение 319 ответа на запрос авторизации платежной сети 312. Например, эмитент 316 может передать информацию о токене платежной сети 312 в предварительно заданных полях данных сообщения 319 ответа на запрос авторизации. Эмитент 316 может передать PAN в поле F2 данных, ID продукта в поле F62.23 данных и токен в поле F123 - DSI 68 Tag1 данных.

[0120] После приема сообщения 319 ответа на запрос авторизации от эмитента 316 платежная сеть 312 может изменить сообщение 319 ответа на запрос авторизации путем замены PAN токеном на основании соответствия. Платежная сеть 312 может сгенерировать измененное сообщение 320 ответа на запрос авторизации, включающее в себя элементы данных, такие как один или несколько токенов в поле F2 данных, уровень гарантирования токена в поле F123 - DSI 68 Tag2 данных, последние 4 цифры PAN в поле F44.15 данных и ID продукта PAN в поле 62.23 данных. Платежная сеть 312 может отправить измененное сообщение 320 ответа на запрос авторизации эквайеру 308. Эквайер 308 может затем передать сообщение 322 ответа на запрос авторизации терминалу 304 торгово-сервисного предприятия. Сообщение 322 ответа на запрос авторизации может включать в себя те же самые поля данных, что и измененное сообщение 320 ответа на запрос авторизации.

[0121] Сообщение 319 ответа на запрос авторизации и измененные сообщения 320 и 322 ответа на запрос авторизации могут указывать, одобрил ли эмитент 316 транзакцию, инициированную владельцем счета, использующим мобильное устройство 302. После того, как сообщение 322 ответа на запрос аутентификации предоставлено терминалу 304 торгово-сервисного предприятия, владелец счета может быть уведомлен относительно успеха или неуспеха транзакции.

Вариант 2 использования: Электронная торговля с помощью мобильного/цифрового кошелька

[0122] Обращаясь теперь к фиг. 4, в варианте 400 использования для электронной торговли с помощью мобильного/цифрового кошелька владелец 402 счета инициирует платежную транзакцию сайту электронной торговли с использованием мобильного/цифрового кошелька для передачи информации о платеже и другой информации о заказе владельцу 404 сайта электронной торговли торгово-сервисного предприятия. Мобильный/цифровой кошелек может управляться эмитентом 416, платежной сетью 412 или другими третьи стороны. В соответствии с различными вариантами воплощения оператор цифрового кошелька может быть запросчиком токена.

[0123] На фиг. 4 возможно, что оператор кошелька уже предусмотрел токенизацию, чтобы больше не хранить PAN в платформе кошелька в целях безопасности или по другим причинам. Когда владелец 402 счета инициирует платежная транзакция в торгово-сервисном предприятии 404 электронной торговли, который работает с используемым кошельком, кошелек может передать сообщение 406 запроса платежной транзакции, включающее в себя токен вместо PAN и другую информацию о заказе (например, адрес доставки) торгово-сервисному предприятию 404 через API кошелька.

[0124] Когда транзакция инициируется, приложение торгово-сервисного предприятия/цифровой кошелек в мобильном устройстве владельца 402 счета может взаимодействовать с платежным приложением для передачи элементов данных торгово-сервисному предприятию 404 в сообщении 406 запроса платежной транзакции. Сообщение 406 запроса платежной транзакции может передать токен в поле PAN сообщения, дату окончания срока действия токена в поле данных даты окончания срока действия PAN сообщения, криптограмма токена может быть опционально сгенерирована на основании элементов данных токена и передана в поле криптограммы токена сообщения, а режим предъявления токена в поле режим ввода POS (как транзакция электронной торговли) сообщения. Сообщение 406 запроса платежной транзакции может также включать в себя ID запросчика токена в опциональном поле сообщения, а также другие элементы данных. В некоторых вариантах воплощения сообщение 406 запроса платежной транзакции может включать в себя те же самые поля данных, что и бесконтактная транзакция 306, изображенная на фиг. 3.

[0125] Терминал 404 торгово-сервисного предприятия может сгенерировать и отправить сообщение 410 запроса авторизации эквайеру 408, несущее поля данных токена. Сообщение 410 запроса авторизации, отправленное терминалом 404 торгово-сервисного предприятия эквайеру 408, может включать в себя те же самые элементы данных, что и сообщение 406 запроса платежной транзакции. В частности, сообщение 410 запроса авторизации может включать в себя токен в поле PAN; дату окончания срока действия токена в поле данных даты окончания срока действия PAN; криптограмму токена в поле криптограммы микросхемы; ID запросчика токена в опциональном поле данных; и режим предъявления токена может быть установлен равным режиму ввода POS для транзакции электронной торговли.

[0126] После приема сообщения 410 запроса авторизации эквайер 408 может провести проверки и передать поля данных токена платежной сети 412, выступающей в качестве поставщика службы токенов. Сообщение 414 запроса авторизации, отправленное эквайером 408 платежной сети 412, может включать в себя те же самые элементы данных, что и сообщение 410 запроса авторизации.

[0127] Платежная сеть 412, выступающая в качестве поставщика службы токенов, может обработать транзакцию. Обработка может включать в себя взаимодействие с хранилищем 413 токенов для извлечения PAN, представленного принятым токеном. Платежная сеть 412 может верифицировать состояние соответствия токен-PAN в хранилище 413 токенов, чтобы гарантировать, что токен находится в активном состоянии. Платежная сеть 412 может валидировать криптограммы токена, когда криптограмма принимается в сообщении 414 запроса авторизации. Платежная сеть 412 может также валидировать элементы управления ограничениями домена, сохраненными в хранилище 413 токенов для принятого токена. Платежная сеть 412 может также извлечь из хранилища 413 токенов уровень гарантирования токена и данные, использовавшиеся при генерации уровня гарантирования токена, ассоциированного с принятым токеном. Платежная сеть 412 может тогда изменить сообщение 414 запроса авторизации, чтобы сгенерировать измененное сообщение 418 запроса авторизации. В измененном сообщении авторизации токен может быть заменен на PAN; дата окончания срока действия токена может быть заменена датой окончания срока действия PAN; может быть добавлен индикатор, чтобы передать эмитенту, что валидация токена «от имени» была завершена поставщиком службы токенов; и связанные с токеном поля могут быть переданы в сообщении запроса авторизации. Связанные с токеном поля могут включать в себя токен, дату окончания срока действия токена, уровень гарантирования токена, данные гарантирования токена и ID запросчика токена. После генерации измененного сообщения 418 запроса авторизации платежная сеть 412 может отправить измененное сообщение 418 запроса авторизации эмитенту 416.

[0128] Эмитент 416 может завершить валидацию на уровне счета и проверку авторизации с использованием информации, предоставленной в измененном сообщении 418 запроса авторизации. Эмитент может отправить сообщение 419 ответа на запрос авторизации платежной сети 412. После приема сообщения 419 ответа на запрос авторизации от эмитента 416 платежная сеть 412 может изменить сообщение 419 ответа на запрос авторизации путем замены PAN токеном на основании соответствия. Платежная сеть 412 может сгенерировать измененное сообщение 420 ответа на запрос авторизации, включающее в себя такие элементы данных, как один или несколько токенов, уровень гарантирования токена, последние 4 цифры PAN и ID продукта PAN. Платежная сеть 412 может отправить измененное сообщение 420 ответа на запрос авторизации эквайеру 408. Эквайер может затем передать сообщение 422 ответа на запрос авторизации терминалу 404 торгово-сервисного предприятия. Сообщение 422 ответа на запрос авторизации может включить в себя те же самые поля данных, что и измененное сообщение 420 ответа на запрос авторизации.

[0129] Сообщение 419 ответа на запрос авторизации и измененные сообщения 420 и 422 ответа на запрос авторизации могут указывать, одобрил ли эмитент 416 транзакцию, инициированную владельцем 402 счета. После того, как сообщение 422 ответа на запрос аутентификации предоставлено терминалу 404 торгово-сервисного предприятия, владелец счета может быть уведомлен относительно успеха или неуспеха транзакции.

Вариант 3 использования: Электронная торговля «с записью о карте»

[0130] Обращаясь теперь к фиг. 5, изображен вариант 500 использования для электронной торговли «с записью о карте». На фиг. 5, торгово-сервисное предприятие 504 электронной торговли, у которого есть данные платежного счета (например, PAN и дата окончания срока действия PAN) уже сохраненные в записи в базе данных, может стремиться устранить базовую угрозу безопасности хранения данных путем замены PAN токеном. Соответственно, в вариантах воплощения, относящихся к транзакциям электронной торговли «с записью о карте», торгово-сервисное предприятие 504 может быть запросчиком токена. После возвращения токена торгово-сервисному предприятию 504 «с записью о карте», все последующие транзакции электронной торговли, которые обрабатываются, могут включать в себя токен и дату окончания срока действия токена (передаваемые в полях данных PAN и даты окончания срока действия PAN) в сообщениях транзакций, передаваемых в экосистеме токенизации.

[0131] Чтобы инициировать платежную транзакцию, владелец 502 счета может войти в систему торгово-сервисного предприятия 504 «с записью о карте» и инициировать покупку электронной торговли на веб-сайте торгово-сервисного предприятия. Веб-сайт торгово-сервисного предприятия может передать элементы данных токена платформе торгово-сервисного предприятия (например, серверу 504 торгово-сервисного предприятия) в специальных полях сообщения запроса платежной транзакции. В соответствии с различными вариантами воплощения веб-сайт торгово-сервисного предприятия может передать элементы данных токена серверу 504 торгово-сервисного предприятия следующим образом: токен может быть передан в поле PAN сообщения запроса платежной транзакции, дата окончания срока действия токена может быть передана в поле даты окончания срока действия PAN сообщения, идентификатор торгово-сервисного предприятия может быть передан в поле данных, режим предъявления токена может быть установлен равным режиму ввода POS для транзакций электронной торговли, ID запросчика токена может быть передан в опциональном поле сообщения, криптограмма токена может быть опциональным элементом данных, который может генерироваться на основании полей данных токена и передаваться в опциональном поле данных сообщения. Все другие идентификаторы торгово-сервисного предприятия могут быть созданы и проведены в сообщении запроса платежной транзакции. В соответствии с различными вариантами воплощения ID запросчика токена и соответственные идентификаторы торгово-сервисного предприятия могут служить полями управления ограничениями домена, которые могут использоваться для валидации добросовестности транзакции.

[0132] Cервер 504 торгово-сервисного предприятия может cгенерировать и отправить сообщение 510 запроса авторизации эквайеру 508, содержащее поля данных токена. Соответственно, сообщение 510 запроса авторизации, отправленное терминалом 504 торгово-сервисного предприятия эквайеру 508, может включать в себя те же самые элементы данных, что и сообщение запроса платежной транзакции, отправленное веб-сайтом торгово-сервисного предприятия серверу 504 торгово-сервисного предприятия.

[0133] После приема сообщения 510 запроса авторизации эквайер 508 может выполнить проверки и передать поля данных токена платежной сети 512, выступающей в качестве поставщика службы токенов. Сообщение 514 запроса авторизации, отправленное эквайером 508 платежной сети 512, может включать в себя те же самые элементы данных, что и сообщение 510 запроса авторизации.

[0134] Платежная сеть 512, выступающая в качестве поставщика службы токенов, может обработать транзакцию с токеном. Обработка может включать в себя взаимодействие с хранилищем 513 токенов для извлечения PAN, представленного принятым токеном. Платежная сеть 512 может верифицировать состояние соответствия токен-PAN в хранилище 513 токенов, чтобы гарантировать, что токен находится в активном состоянии. Платежная сеть 512 может валидировать криптограмму токена, принятую в сообщении 514 запроса авторизации. Платежная сеть 512 может также валидировать элементы управления ограничениями домена, сохраненные в хранилище 513 токенов для принятого токена. Платежная сеть 512 может также извлечь уровень гарантирования токена и данные, использовавшиеся при генерации уровня гарантирования токена, ассоциированного с принятым токеном, из хранилища 513 токенов. Платежная сеть 512 может затем изменить сообщение 514 запроса авторизации для генерации измененного сообщения 518 запроса авторизации. В измененном сообщении авторизации токен может быть заменен на PAN; дата окончания срока действия токена может быть заменена датой окончания срока действия PAN; может быть добавлен индикатор, чтобы передать эмитенту, что валидация токена «от имени» была завершена поставщиком службы токенов; и связанные с токеном поля могут быть переданы в сообщении запроса авторизации. Связанные с токеном поля могут включать в себя токен, дату окончания срока действия токена, уровень гарантирования токена, данные гарантирования токена и ID запросчика токена. После генерации измененного сообщения 518 запроса авторизации платежная сеть 512 может отправить измененное сообщение 518 запроса авторизации эмитенту 516.

[0135] Эмитент 516 может завершить валидацию на уровне счета и проверку авторизации c использованием информации, предоставленной в измененном сообщении 518 запроса авторизации. Эмитент может отправить сообщение 519 ответа на запрос авторизации платежной сети 512. После приема сообщения 519 ответа на запрос авторизации от эмитента 516 платежная сеть 512 может изменить сообщение 519 ответа на запрос авторизации путем замены PAN токеном на основании соответствия. Платежная сеть 512 может сгенерировать измененное сообщение 520 ответа на запрос авторизации, включающее в себя элементы данных, такие как один или несколько токенов, уровень гарантирования токена, последние 4 цифры PAN и ID продукта PAN. Платежная сеть 512 может отправить измененное сообщение 520 ответа на запрос авторизации эквайеру 508. Эквайер может затем передать сообщение 522 ответа на запрос авторизации терминалу 504 торгово-сервисного предприятия. Сообщение 522 ответа на запрос авторизации может включать в себя те же самые поля данных, что и измененное сообщение 520 ответа на запрос авторизации.

[0136] Сообщение 519 ответа на запрос авторизации и измененные сообщения 520 и 522 ответа на запрос авторизации могут указывать, одобрил ли эмитент 516 транзакцию, инициированную владельцем счета, использующим мобильное устройство 502. После того, как сообщение 522 ответа на запрос аутентификации предоставлено терминалу 504 торгово-сервисного предприятия, владелец счета может быть уведомлен относительно успеха или неуспеха транзакции.

Вариант 4 использования: Сканирование в торговой точке

[0137] Обращаясь теперь к фиг. 6, изображен мобильный быстродействующий код (QRC) в варианте использования в торговой точке. На фиг. 6 мобильное устройство 602 может инициировать платеж на основе QRC в местоположении торгово-сервисного предприятия с использованием считывателя 604 QRC. В некоторых вариантах воплощения приложение в мобильном устройстве 602 может генерировать динамический QRC каждый раз, когда платеж инициируется безопасным образом. Когда транзакция инициируется, мобильное устройство 602 может сгенерировать сообщение 606 запроса транзакции, включающее в себя токен, дату окончания срока действия токена, элементы криптограммы токена и любые другие данные из QRC, и передать сообщение 606 запроса транзакции терминалу 604 торгово-сервисного предприятия.

[0138] Когда транзакция инициируется, мобильное устройство 602 может взаимодействовать с терминалом 604 торгово-сервисного предприятия, которое может считывать QRC, и передавать элементы данных терминалу 604 торгово-сервисного предприятия в сообщении 606 запроса платежной транзакции. Сообщение 606 запроса платежной транзакции может передать токен в поле PAN сообщения, дату окончания срока действия токена в поле данных даты окончания срока действия PAN сообщения, данные QRC в поле данных сообщения, криптограмма токена может опционально генерироваться на основании элементов данных токена и передаваться в поле данных криптограммы токена сообщения, а режим предъявления токена в поле данных режим ввода POS (как транзакция на основе QRC) сообщения. Сообщение 606 запроса платежной транзакции может также включать в себя ID запросчика токена в опциональном поле сообщения, так же как другие элементы данных. Криптограмма токена может опционально генерироваться мобильным устройством 602 и может служить полем управления ограничениями домена, которое может использоваться поставщиком службы токенов для валидации добросовестности транзакции, использующей токен.

[0139] Терминал 604 торгово-сервисного предприятия может сгенерировать и отправить сообщение 610 запроса авторизации эквайеру 608, содержащее поля данных токена. Сообщение 610 запроса авторизации, отправленное терминалом 604 торгово-сервисного предприятия эквайеру 608, может включать в себя те же самые элементы данных, что и сообщение 606 запроса платежной транзакции. В частности, сообщение 610 запроса авторизации может включать в себя токен в поле PAN; дату окончания срока действия токена в поле даты окончания срока действия PAN; криптограмму токена в поле криптограммы микросхемы; ID запросчика токена в опциональном поле данных; режим предъявления токена может быть установлен равным режиму ввода POS для транзакции на основе QRC и данные QRC.

[0140] После приема сообщения 610 запроса авторизации эквайер 608 может выполнить проверки и передать поля данных токена платежной сети 612, выступающей в качестве поставщика службы токенов. Сообщение 614 запроса авторизации, отправленное эквайером 608 платежной сети 612, может включать в себя те же самые элементы данных, что и сообщение 610 запроса авторизации.

[0141] Платежная сеть 612, выступающая в качестве поставщика службы токенов, может обработать транзакцию с токеном. Обработка может включать в себя взаимодействие с хранилищем 613 токенов для извлечения PAN, представленного принятым токеном. Платежная сеть 612 может верифицировать состояние соответствия токен-PAN в хранилище 613 токенов, чтобы гарантировать, что токен находится в активном состоянии. Платежная сеть 612 может валидировать криптограмму токена, если криптограмма принята в сообщении 614 запроса авторизации. Платежная сеть 612 может также валидировать элементы управления ограничениями домена, сохраненными в хранилище 613 токенов для принятого токена. Платежная сеть 612 может также извлечь уровень гарантирования токена и данные, использовавшиеся при генерации уровня гарантирования токена, ассоциированного с принятым токеном, из хранилища 613 токенов. Платежная сеть 612 может затем изменить сообщение 614 запроса авторизации, чтобы сгенерировать измененное сообщение 618 запроса авторизации. В измененном сообщении 618 авторизации токен может быть заменен на PAN; дата окончания срока действия токена может быть заменена датой окончания срока действия PAN; может быть добавлен индикатор, чтобы передать эмитенту, что валидация токена «от имени» была завершена поставщиком службы токенов; и связанные с токеном поля могут быть переданы в сообщении запроса авторизации. Связанные с токеном поля могут включать в себя токен, дату окончания срока действия токена, уровень гарантирования токена, данные гарантирования токена и ID запросчика токена. После генерации измененного сообщения 618 запроса авторизации платежная сеть 612 может отправить измененное сообщение 618 запроса авторизации эмитенту 616.

[0142] Эмитент 616 может завершить валидацию на уровне счета и проверку авторизации с использованием информации, предоставленной в измененном сообщении 618 запроса авторизации. Эмитент может отправить сообщение 619 ответа на запрос авторизации платежной сети 612. После приема сообщения 619 ответа на запрос авторизации от эмитента 616 платежная сеть 612 может изменить сообщение 619 ответа на запрос авторизации путем замены PAN токеном на основании соответствия. Платежная сеть 612 может сгенерировать измененное 620 сообщение ответа на запрос авторизации, включающее в себя элементы данных, такие как один или несколько токенов, уровень гарантирования токена, последние 4 цифры PAN и ID продукта PAN. Платежная сеть 612 может отправить измененное сообщение 620 ответа на запрос авторизации эквайеру 608. Эквайер может затем передать сообщение 622 ответа на запрос авторизации терминалу 604 торгово-сервисного предприятия. Сообщение 622 ответа на запрос авторизации может включать в себя те же самые поля данных, что и измененное сообщение 620 ответа на запрос авторизации.

[0143] Сообщение 619 ответа на запрос авторизации и измененное сообщение 620 (и 622) ответа на запрос авторизации могут указывать, одобрил ли эмитент 616 транзакцию, инициированную владельцем 602 счета. После того, как сообщение 622 ответа на запрос аутентификации предоставлено терминалу 604 торгово-сервисного предприятия, владелец счета может быть уведомлен относительно успеха или неуспеха транзакции.

Последовательность операций захвата и клиринга

[0144] Обработкой захвата может называться передача денежных средств от владельца счета торгово-сервисному предприятию. Клирингом может называться процесс передачи, согласования и подтверждения денежных средств, следующих из платежных транзакций. Во время последовательности операций клиринга сообщения клиринга может быть передано от эквайера платежной сети и от платежной сети эмитенту. Процесс клиринга, определенный в вариантах воплощения настоящего изобретения, может быть реализован с помощью системы клиринга, управляемой, например, платежной сетью.

[0145] Фиг. 7 изображает иллюстративные процессы захвата и клиринга для транзакции с токеном. В соответствии с различными вариантами воплощения торгово-сервисное предприятие 702 может сгенерировать файл 706 захвата на основании информации, предоставленной потребителем (например, владельцем счета) во время инициирования транзакции. Файл 706 захвата может включать в себя токен в поле F2 данных PAN и дату окончания срока действия токена в поле F14 данных даты окончания срока действия PAN. Торгово-сервисное предприятие 702 может отправить файл 706 захвата эквайеру 704.

[0146] Эквайер 704 может провести проверки элементов данных файла 406 захвата. Эквайер 704 может создать файл 710 клиринга, который должен быть отправлен платежной сети 708, выступающей в качестве поставщика службы токенов. Файл 710 клиринга может включать в себя токен в поле TCR0 PAN, дату окончания срока действия токена в поле данных даты окончания срока действия PAN, режима предъявления токена, установленный равным режиму ввода POS для зависящей от канала транзакции, в поле TCR0 данных и уровень гарантирования токена в новом поле TCR1 данных, которое может быть добавлено для транзакций с токеном. В некоторых вариантах воплощения файл 710 клиринга может также включать в себя криптограмму в поле TCR7 данных записи.

[0147] Когда платежная сеть 708 принимает файл 710 клиринга, платежная сеть 708 может взаимодействовать с хранилищем 713 токенов, чтобы извлечь PAN, соответствующий принятому токену. Платежная сеть 708 может верифицировать состояние соответствия токен-PAN в хранилище 713 токенов, чтобы гарантировать, что токен находится в активном состоянии. Если криптограмма включена в файл 710 клиринга, платежная сеть 708 может валидировать криптограмму. Платежная сеть 708 может также валидировать элементы управления ограничениями домена, сохраненные в хранилище 713 токенов для принятого токена.

[0148] Платежная сеть 708 может затем изменить файл 710 клиринга, чтобы сгенерировать измененный файл 714 клиринга. В измененном файле 714 клиринга токен может быть заменен на PAN в поле TCR0 данных; может быть добавлен индикатор, чтобы передать эмитенту, что валидация токена «от имени» была завершена поставщиком службы токенов; и связанные с токеном поля могут быть переданы в сообщении запроса авторизации. Связанные с токеном поля могут включать в себя токен в поле TCR5 данных и уровень гарантирования токена в поле TCR1 данных. В некоторых вариантах воплощения криптограмма может быть включена в поле TCR7 данных измененного файла 714 клиринга. После генерации измененного файла 714 клиринга, платежная сеть 708 может отправить измененный файл 714 клиринга эмитенту 712.

[0149] Эмитент 712 может завершить валидацию на уровне счета с использованием информации, предоставленной в измененном файле 714 клиринга, и завершить процесс клиринга.

Последовательность операций исключения

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

[0151] Фиг. 8 изображает иллюстративную последовательность операций обработки токена для запроса возвратного платежа и элементы данных возвратного платежа. В соответствии с различными вариантами воплощения эмитент 802 может подать заявку на возвратный платеж после валидации, что исходная транзакция является допустимым запросом возвратного платежа, и что эмитент 802 имеет соответствующие права на возвратный платеж. Файл 806 записи о возвратном платеже может быть сгенерирован эмитентом 802 и отправлен платежной сети 804. Файл 806 записи о возвратном платеже может включать в себя, среди прочих элементов данных, PAN (который использовался в исходной транзакции покупки) в поле TCR0 данных, токен, соответствующий PAN, в поле TCR5 данных, уровень гарантирования токена, полученный из хранилища 813 токенов в поле данных, и ID запросчика токена может быть передан в опциональном поле в файле 806 записи о возвратном платеже.

[0152] Когда платежная сеть 804 принимает файл 806 записи о возвратном платеже, платежная сеть 804 может верифицировать состояние соответствия токен-PAN в хранилище 813 токенов, чтобы гарантировать, что токен находится в активном состоянии. Если токен не включен в файл 803 записи о возвратном платеже, отправленный эмитентом 802, платежная сеть 804 может извлечь токен для транзакции, которая оспаривается, из хранилища 813 токенов. Платежная сеть 804 может затем сгенерировать измененный файл 810 записи о возвратном платеже, который будет отправлен эквайеру 808. Модификации, реализованные платежной сетью 804 для генерации измененного файла 810 записи о возвратном платеже, могут включать в себя замену PAN соответствующим токеном и, опционально, включение одного или нескольких связанных с токеном полей в измененный файл 810 записи о возвратном платеже, таких как ID запросчика токена и уровень гарантирования токена.

[0153] После приема измененного файла 810 записи о возвратном платеже эквайер 808 может выполнить валидацию измененного файла 810 записи о возвратном платеже и, на основании изучения случая, может перейти к другой фазе обработки спора или, альтернативно, может разрешить возвратный платеж.

III. Прикладные программные интерфейсы (API) поставщика службы токенов

[0154] Фиг. 9 изображает использование прикладных программных интерфейсов (API) поставщиком службы токенов для обеспечения выдачи и обработки токенов (например, для обеспечения службы токенов).

[0155] Варианты воплощения настоящего изобретения описывают взаимодействие между поставщиком 904 службы токенов и другими объектами в экосистеме 900 токенизации посредством использования одного или нескольких API и/или интерфейса(ов) обмена сообщениями для обеспечения запросов токенов, выдачи токенов, выполнения ID&V, детокенизации, маршрутизации токенов и управления жизненным циклом токенов. Соответственно, варианты воплощения настоящего изобретения устанавливают общие элементы данных для интерфейсов, которые может поддерживать поставщик 904 службы токенов. В соответствии с некоторыми вариантами воплощения интерфейсы, обсуждаемые в настоящем документе, могут быть реализованы и сделаны доступными поставщиком 904 службы токенов для использования всеми участвующими объектами, которые взаимодействуют с поставщиком 904 службы токенов.

[0156] Поставщик 904 службы токенов может обеспечить возможность устанавливать и использовать интерфейсы или API с объектами, которые аутентифицируются посредством защищенного способа взаимодействия с поставщиком 904 службы токенов. Например, взаимодействия могут происходить посредством аутентифицированных способов, включающих в себя, но не ограничиваясь только этим, веб-сервисы, обменом сообщениями ISO 8583 через существующий интерфейс платежной сети и файл/пакет. Один или несколько объектов в экосистеме 900 токенизации, такие как запросчик 902 токена, объект, выполняющий ID&V 906, другие сети 908, платежная сеть 910 могут использовать интерфейсы службы токенов.

[0157] Интерфейсы могут быть классифицированы как интерфейс(ы) 912 запроса и выдачи токенов, интерфейс(ы) 914 гарантирования токенов (например, ID&V), интерфейс(ы) 916 детокенизации, интерфейс(ы) 918 маршрутизации токенов и интерфейс(ы) управления жизненным циклом токенов. Один или несколько заданных интерфейсов могут позволять осуществлять передачу сообщений для выполнения конкретных связанных с токенами операций.

Интерфейс(ы) запроса и выдачи токенов

[0158] Как обсуждалось выше, поставщик 904 службы токенов может обеспечивать интерфейс 912, который зарегистрированный запросчик 902 токена может использовать для подачи сообщения запроса токена, включающего в себя исходные платежные учетные данные, и приема сообщения ответа на запрос токена, включающего в себя токен от поставщика 904 службы токенов. Сообщение запроса токена и сообщение ответа на запрос токена могут передаваться между запросчиком 902 токена и поставщиком 904 службы токенов через интерфейс 912 запроса и выдачи токенов.

[0159] Интерфейс 912 запроса и выдачи токенов может поддерживать запросы в режиме реального времени на выдачу токена для запрошенного PAN, или запросы большими партиями через безопасный файл интерфейса, в которых токены генерируются и выдаются в больших количествах и возвращаются запросчику 902 токена. Поставщик 904 службы токенов может реализовать соответствующие элементы управления и процессы для генерации токена на основании входного PAN. В некоторых вариантах воплощения этапы гарантирования могут выполняться на основании запроса.

[0160] Элементы входных данных в сообщении запроса токена могут содержать один или несколько ID запросчиков токена, PAN, дату окончания срока действия PAN и запрошенный уровень гарантирования. Опциональные элементы данных могут включать в себя данные владельца счета, такие как адрес выставления счета/доставки и почтовый индекс для выполнения способа ID&V гарантирования токена. Элементы входных данных для сообщения запроса токена, передаваемые через иллюстративный интерфейс 912 запроса и выдачи токенов, изображены в Таблице 1.

Имя поля	Длина	Формат	Описание
ID запросчика токена	11	Числовой	Уникальный ID, присвоенный запросчику
Длина PAN	1	Двоичный	Длина поля PAN
PAN	Переменная (от 13 до 19 цифр)	Числовой	PAN, для которого запрашивается токен
Дата истечения срока действия PAN	4	Числовой	Дата истечения срока действия PAN, для которого запрашивается токен
Запрошенный уровень гарантирования	2	Числовой	Присутствует, если запрошен уровень гарантирования.
Уровень гарантирования токена	2	Числовой	Присутствует, если запросчик токена выполнял ID&V.
Длина данных владельца карты	2	Двоичный	Длина данных владельца карты, может содержать нуль (0), если отсутствует
Данные владельца карты	Переменная	Буквенно-цифровой	Данные, необходимые для поддержки запрошенного уровня гарантирования. Примерами являются адресом выставления счета, адрес доставки, почтовый индекс и CVV2.
Таблица 1 Элементы входных данных, передаваемые через интерфейс запроса и выдачи токенов

[0161] В ответ на сообщение запроса токена интерфейс 912 запроса и выдачи токенов может передать сообщение ответа, которое содержит один или несколько элементов данных, в том числе, но не ограничиваясь только этим, статус запроса (например, успешен ли запрос или неуспешен) и, если запрос неуспешен, код причины, указывающий тип сбоя. Для успешных запросов элементы дополнительных данных, такие как токен и дата окончания срока действия токена, могут быть возвращены в сообщении ответа на запрос токена. Если во время выдачи токена был выполнен способ гарантирования токена, интерфейс 912 запроса и выдачи токенов может опционально предоставлять назначенный уровень гарантирования токена запросчику 902 токена. Элементы выходных данных для сообщения ответа на запрос токена, передаваемые через иллюстративный интерфейс 912 запроса и выдачи токенов, изображаются в Таблице 2.

Имя поля	Длина	Формат	Описание
Статус запроса	1	Числовой	Указывает успех или неуспех запроса
Код причины	Переменная	Двоичный	Присутствует, если статус запроса является неуспешным
Токен	Переменная (от 13 до 19 цифр)	Числовой	Присутствует, если статус запроса является успешным, токен генерируется поставщиком службы токенов.
Дата окончания срока действия токена	4	Числовой	Присутствует, если статус запроса является успешным, дата окончания срока действия токена генерируется поставщиком службы токенов.
Уровень гарантирования токена	2	Числовой	Присутствует, если статус запроса является успешным и был запрошен ID&V.
Таблица 2 Элементы выходных данных, передаваемые через интерфейс запроса и выдачи токенов

Интерфейс(ы) гарантирования (ID&V) токенов

[0162] Интерфейс 914 гарантирования (ID&V) токенов может передавать запрос на выполнение ID&V при выдаче токена для верификации информации о владельце счета и PAN. Интерфейс 914 гарантирования токенов может быть обеспечен между поставщиком 904 службы токенов и объектом, выполняющим ID&V 906. В некоторых вариантах воплощения поставщик службы токенов может выполнять ID&V. Если поставщик 904 службы токенов обеспечивает поддержку для ID&V, поставщик 904 службы токенов может реализовать один или несколько интерфейсов для поддержки способов ID&V. Дополнительно, поставщик 904 службы токенов может гарантировать, что при выдаче токена выполняется способ(ы) ID&V, подходящий для запрошенного уровня гарантирования токена. Элементы входных данных для сообщения запроса ID&V, передаваемые через иллюстративный интерфейс гарантирования (ID&V) токена, изображен в Таблице 3.

Имя поля	Длина	Формат	Описание поля
Тип транзакции	2	Числовой	• NN - Покупка • NN - Выдача токена • NN - Повторная валидация токена
PAN владельца карты	Переменная (от 13 до 19 цифр)	Числовой	Первичный номер счета; финансовый PAN, который может быть связан с токеном
Дата истечения срока действия карты	4	Числовой	Дата истечения срока действия финансового PAN
ID запросчика токена	11	Числовой	Уникальное значение, присвоенное зарегистрированному объекту, который запрашивает токен
Запрошенный уровень гарантирования	2	Числовой	Указывает уровень валидации, который запросчик токена хотел бы, чтобы был выполнен, такой как отсутствие гарантирования, выполняется верификация запросчиком токена, гарантируется запросчиком токена, гарантируется поставщиком службы токенов, гарантируется поставщиком службы токенов с данными запросчика или гарантируется эмитентом
Местонахождение токена	2	Числовой	Указывает место хранения токена, такое как 01 - удаленное/облако или 02 - безопасный элемент
Протокол	2	Числовой	Описывает, какой протокол использует запросчик токена для осуществления связи с владельцем карты, API мобильного приложения и/или браузер
Результаты верификации счета	2	Числовой	Указывает результаты верификации счета, если она выполнятся, Успех или Неуспех
Показатель риска запросчика токена	4	Числовой	Показатель риска мошенничества, который обеспечивается запросчиком токена
Индикатор несовпадения адресов	2	Числовой	Заполняется, если адрес выставления счета и доставки отличаются
Адрес выставления счета владельца карты	Переменная	Буквенно-цифровой	Включает в себя данные, такие как адресная строка 1, адресная строка 2, город, штат(область)/провинция(край), почтовый индекс и код страны
Информация об устройстве	Переменная	Буквенно-цифровой	Атрибут информации об устройстве состоит из набора атрибутов, относящихся к учетным данным. Они включают в себя, но не ограничиваются только этим, IP-адрес, операционную систему, географическое местоположение, ID устройства и категорию устройства, такую как портативный компьютер или телефон
Номер домашнего телефона	16	Числовой	Номер домашнего телефона, предоставленный владельцем карты
Номер мобильного телефона	16	Числовой	Номер мобильного телефона, предоставленный владельцем карты
Номер рабочего телефона	16	Числовой	Номер рабочего телефона, предоставленный владельцем карты
Информация о счете	Переменная	Буквенно-цифровой	Элемент информации о счете состоит из набора атрибутов, относящихся к платежному счету, таких как адрес электронной почты, возраст счета, число номеров PAN в записи и средняя скорость транзакции.
Таблица 3 Элементы входных данных, передаваемые через интерфейс гарантирования (ID&V) токена

[0163] В ответ на запрос ID&V интерфейс 914 гарантирования (ID&V) токена может передать сообщение ответа на запрос поставщику 904 службы токенов, которое содержит один или несколько элементов данных, в том числе, но не ограничиваясь только этим, статус запроса (например, успех или неуспех) и, если ID&V была неуспешной, код причины, объясняющий тип сбоя. Для успешных запросов интерфейс 914 гарантирования (ID&V) токена может возвращать элементы дополнительных данных в сообщении ответа на запрос ID&V. Иллюстративные элементы выходных данных для сообщения ответа на запрос ID&V, передаваемого через интерфейс 914 гарантирования (ID&V) токена, изображен в Таблице 4.

Имя поля	Длина	Формат	Описание поля
PAN владельца карты	Переменная (от 13 до 19 цифр)	Числовой	Первичный номер счета; финансовый PAN, который может быть связан с токеном
Присвоенный уровень гарантирования	2	Буквенно-цифровой	Указывает уровень валидации, который запросчик токена хотел бы, чтобы был выполнен, и может изменяться сетью
Значение верификации	Переменная	Буквенно-цифровой	Значение верификации получается эмитентом или объектом, который выполняет аутентификацию
Алгоритм верификации	Переменная	Буквенно-цифровой	Указывает алгоритм, использовавшийся для генерации значения верификации
Таблица 4 Элементы выходных данных, передаваемые через интерфейс гарантирования (ID&V) токена

Интерфейс(ы) детокенизации

[0164] Интерфейс(ы) 916 детокенизации может обеспечивать необходимый механизм для обмена выданного токена путем возврата данных исходного PAN и даты окончания срока действия PAN аутентифицированному объекту. Поставщик 904 службы токенов может взаимодействовать с другими сетями 908 (через интерфейс 916 детокенизации) для обработки детокенизации. Поставщик 904 службы токенов может реализовать соответствующие средства обеспечения безопасности, чтобы предоставить доступ к интерфейсу 916 детокенизации. Поставщик 904 службы токенов может гарантировать, что запрос принимается из распознанного и аутентифицированного источника. В некоторых вариантах воплощения поставщик 904 службы токенов может быть платежной сетью, и детокенизация может выполняться платежной сетью. Иллюстративные элементы входных данных для сообщения запроса детокенизации, передаваемого через интерфейс 916 детокенизации, изображены в Таблице 5.

Имя поля	Длина	Формат	Описание
ID запросчика токена	11	Числовой	Уникальный ID, присвоенный запросчику
Длина токена	1	Буквенно-цифровой	Длина токена
Токен	Переменная (от 13 до 19 цифр)	Буквенно-цифровой	Выданный токен
Дата окончания срока действия токена	4	Числовой	Выданная дата окончания срока действия токена
Таблица 5 Элементы входных данных, передаваемые через интерфейс детокенизации

[0165] Интерфейс 916 детокенизации может передавать сообщение ответа на запрос детокенизации, которое содержит элементы выходных данных, такие как статус запроса (например, успех или неуспех) и, если запрос является неуспешным, код причины, объясняющий тип сбоя. Для успешных запросов элементы дополнительных данных, такие как PAN и дата окончания срока действия PAN, могут быть возвращены в сообщении ответа на запрос детокенизации. Иллюстративные элементы выходных данных для сообщения ответа на запрос детокенизации, передаваемых через интерфейс 916 детокенизации, изображены в Таблице 6.

Имя поля	Длина	Формат	Описание
Статус запроса	1	Двоичный	Указывает успех или неуспех запроса
Код причины	Переменная	Двоичный	Присутствует, если статус запроса является неуспешным
Длина PAN	1	Двоичный	Присутствует, если статус запроса является успешным, с длиной поля PAN
PAN	Переменная (от 13 до 19 цифр)	Числовой	Присутствует, если статус запроса является успешным, с PAN
Дата истечения срока действия PAN	4	Числовой	Присутствует, если статус запроса является успешным, с датой истечения срока действия PAN
Таблица 6 Элементы выходных данных, передаваемые через интерфейс детокенизации

Интерфейс(ы) маршрутизации токенов

[0166] Интерфейс(ы) 918 маршрутизации токенов обеспечивает необходимый механизм для маршрутизации транзакции с токеном в платежную сеть 910, которая отвечает за обработку транзакции. В некоторых вариантах воплощения, например, когда платежная сеть выступает в качестве поставщика службы токенов, маршрутизация может также включать в себя маршрутизацию детокенизации для маршрутизации токена для детокенизации. Иллюстративные элементы входных данных для сообщения обработки токена, передаваемые через интерфейс 918 маршрутизации токенов, изображены в Таблице 7.

Имя поля	Длина	Формат	Описание
ID запросчика токена	11	Числовой	Уникальный ID, присвоенный запросчику
Длина токена	1	Двоичный	Длина токена
Токен	Переменная (от 13 до 19 цифр)	Числовой	Выданный токен
Дата окончания срока действия токена	4	Числовой	Выданная дата окончания срока действия токена
Длина элементов данных транзакции	Переменная	Двоичный	Длина поля «другие элементы данных транзакции» (Other Transaction Data Elements), может содержать нуль (0), если отсутствует
Элементы данных транзакции	Переменная	Зависит от реализации	Другие элементы данных транзакции, необходимые поставщику службы токенов для исполнения запроса, содержание является собственностью поставщика службы токенов
Таблица 7 Элементы входных данных, передаваемые через интерфейс маршрутизации токенов

[0167] Интерфейс 918 маршрутизации токенов может передать сообщение ответа за запрос обработки токена, которое содержит элементы выходных данных, такие как статус запроса (например, успех или неуспех) и, если запрос является неуспешным, код причины, объясняющий тип сбоя. Для успешных запросов элементы дополнительных данных, такие как PAN и дата окончания срока действия PAN, могут быть возвращены в сообщении ответа на запрос обработки токена. Иллюстративные элементы выходных данных для сообщения ответа на запрос обработки токена, передаваемые через интерфейс 918 маршрутизации токенов, изображены в Таблице 8.

Имя поля	Длина	Формат	Описание
Статус запроса	1	Двоичный	Указывает успех или неуспех запроса
Код причины	Переменная	Двоичный	Присутствует, если статус запроса является неуспешным
Длина PAN	1	Двоичный	Присутствует, если статус запроса является успешным, с длиной поля PAN
PAN	Переменная (от 13 до 19 цифр)	Числовой	Присутствует, если статус запроса является успешным, с PAN
Дата истечения срока действия PAN	4	Числовой	Присутствует, если статус запроса является успешным, с датой истечения срока действия PAN
Длина элементов данных транзакции	Переменная	Двоичный	Длина поля «другие элементы данных транзакции» (Other Transaction Data Elements), может быть нулем (0), если отсутствует
Элементы данных транзакции	Переменная	Зависит от реализации	Элементы данных транзакции, необходимые сети для продолжения транзакции, содержание является собственностью поставщика службы токенов
Таблица 8 Элементы выходных данных, передаваемые через интерфейс маршрутизации токенов

Интерфейс(ы) управления жизненным циклом токенов

[0168] Токены могут иметь текущее управление и обновления из-за изменений PAN и даты окончания срока действия PAN, а также событий, которые могут вызвать деактивацию соответствия запросчиком 902 токена. Поставщик 904 службы токенов может обеспечить обновления жизненного цикла через интерфейсы для управления изменениями, которые влияют на выданный токен. События жизненного цикла могут обрабатываться с использованием таких интерфейсов, как интерфейс отвязки токена, интерфейс приостановки действия токена, интерфейс активации токена, интерфейс обновления гарантирования токена и интерфейс обновления атрибутов PAN. Таблица 9 обеспечивает иллюстративные события жизненного цикла, которые могут быть сделаны доступными в качестве интерфейсов поставщиком 904 службы токенов.

Интерфейс	Событие/Описание	Кем запрашивается	Выполняемое действие
Отвязка токена	• Устройство потеряно или украдено • Исходные учетные данные больше не действительны • Запросчик токена больше не хранит запись о карте • PAN потерян или украден • Предупреждение о мошенничестве для PAN • Предупреждение о неисправности токена	Запросчик токена Эмитент карты Платежная сеть	Токен отвязывается от PAN, и соответствие отключается для дальнейшего использования.
Приостановка действия токена	• Временная деактивация из-за потерянного или украденного устройства	Запросчик токена	Соответствие токен-PAN временно приостанавливается и в дальнейшем использовании может быть отказано.
Активирование токен	• Возобновить соответствие токен-PAN после временной приостановки действия	Запросчик токена	Соответствие токен-PAN активируется после временной приостановки действия, чтобы позволить дальнейшее использование.
Обновление гарантирования токена	• Текущее управление уровнем гарантирования токена	Поставщик службы токенов	Уровень гарантирования токена обновляется для соответствия токен-PAN на основании выполняемого способа ID&V.
Обновление атрибутов PAN	• Обновления исходных учетных данных, таких как дата окончания срока действия PAN	Запросчик токена	Обновления атрибутов PAN, таких как дата истечения срока действия PAN, делаются для продленияя использования соответствия токен-PAN.
Таблица 9 Интерфейсы обновлений жизненного цикла

[0169] Текущие изменения соответствия токен-PAN из-за событий жизненного цикла, таких как обновление PAN, потеря или кража устройства и деактивация токена из-за завершения взаимоотношений клиента с запросчиком токена, могут обслуживаться поставщиком службы токенов при реализации в соответствии с вариантами воплощения настоящего изобретения.

IV. Технические преимущества и другие спецификации

[0170] В соответствии с различными вариантами воплощения настоящего изобретения токен может увеличить стоимость среды обработки платежей, при этом улучшая прозрачность и защищая информацию о владельце счета. Токены могут быть глобальными и многоканальный; операционно совместимыми с основанными на BIN токенами; связанными, поставленными в соответствие или ассоциированными с базовыми учетными данными; отличающимися и идентифицируемыми в системе; способными передаваться через или маршрутизироваться существующими объектами экосистемы токенизации, чтобы минимизировать влияние экосистемы; совместимыми с существующими платежными технологиями (например, веб, NFC, POS стандартами); способными поддерживать технологии альтернативных платежных каналов (например, код QR); статическими или динамическими (например, ограниченное использование, ограничения по времени); способными поддерживать аутентификацию различными объектами и типами (например, эмитентом, кошельком, торгово-сервисным предприятием); и совместимыми со всеми нормативными обязательствами (например, решениями по маршрутизации).

[0171] Варианты воплощения настоящего изобретения включают в себя использование существующих полей данных, включение связанных с токеном данных в текущие поля, а также новых полей данных для обеспечения согласованности реализации и операционной совместимости во всей экосистеме токенизации. Одно или несколько полей данных, представленных как часть некоторых вариантов воплощения настоящего изобретения, могут быть опциональными.

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

[0173] В соответствии с различными вариантами воплощения, описанными в настоящем документе, платежная сеть может использовать поставщика службы токенов для постановки в соответствие выданный токен номеру PAN во входящем сообщении авторизации до отправки сообщения эмитенту. Платежная сеть может поставить в соответствие PAN обратно токену в любых ответных сообщениях, отосланных обратно эквайеру. Поставщик службы токенов может указывать платежной сети, когда токены, которые считаются потерянными/украденными, были отмечены как приостановленные. Поставщик службы токенов может валидировать токен во входящем сообщении авторизации относительно элементов данных, в том числе ID запросчика токена, и предоставить результат платежной сети относительно допустимости токена в пределах элементов управления ограничениями домена токена. Если PAN считается платежной сетью или эмитентом скомпрометированным или подверженным риску, поставщик службы токенов может уведомить соответствующие запросчики токена о скомпрометированности и деактивировать ассоциированные токены, соответствующие PAN. Поставщик службы токенов может продолжить добавлять и реализовывать такие возможности, как варианты использования для управления жизненным циклом токена и PAN, которые продолжают развиваться.

[0174] Обработка токена и интеграция участвующих платежных сетей с хранилищами токенов может обеспечить возможность применять конкретные элементы управления ограничениями домена, как определено для данного запросчика токена и варианта использования. Элементы управления ограничениями домена зависят от доступности конкретных связанных с управлением элементов данных в сообщениях обработки транзакций и добросовестности лежащих в основе данных, поскольку эти элементы данных могут гарантировать управляемое использование токенов.

[0175] Используя токены, потребители могут иметь возможность проводить платежную транзакцию с использованием существующих данных записи о карте, замененных учетными данными токена и улучшенных с помощью средств защиты. В некоторых вариантах воплощения способность выполнять платежи может быть встроена в устройство (например, мобильный телефон или смартфон). В некоторых вариантах воплощения устройство может включать в себя приложение или программное обеспечение, выполненное с возможностью обеспечения запроса пользователю для активации одной или нескольких платежных карт, чтобы позволить их использование для транзакций, проводимых с использованием устройства. Процесс активации сервиса может включать в себя показатель риска и запрос токена, процесс ID&V и предоставление токена.

[0176] В соответствии с различными вариантами воплощения при использовании лично (или в магазине) потребитель может «оплатить касанием» в бесконтактных терминалах POS. Процесс может включать в себя отправку токена эмитенту через платежную сеть. Платежная сеть может выполнить обмен токен/PAN с использованием принятого токена и отправить соответствующий PAN эмитенту. Кроме того, при использовании приложения потребитель может оплачивать транзакции, проводимые с сертифицированным поддерживаемым приложением торгово-сервисного предприятия, с помощью одного щелчка или выбора на их устройстве. Процесс может включать в себя отправку токена эмитенту через платежную сеть. Платежная сеть может выполнить обмен токен/PAN с использованием принятого токена и отправить соответствующий PAN эмитенту.

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

[0178] Варианты воплощения настоящего изобретения не исключают существующие решения для токенов, реализованных эквайером или другой третьей стороной, в которых эти объекты генерируют токены и задают соответствие токен-PAN в их экосистеме токенизации.

[0179] Атрибуты продукта, такие как тип продукта (например, дебет или кредит), могут сохраняться для токенизированных транзакций.

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

[0181] Таблица 10 обеспечивает перечень опций, которые могут быть реализованы эквайером, в соответствии с различными вариантами воплощения настоящей заявки. Таблица показывает, применима ли опция к транзакции NFC или транзакции электронной торговли.

Опция	Изменение	NFC	Электронная торговля
Принять и передать токен и дату истечения срока действия токена в поле 2 и поле 14		√	√
Принять и передать криптограмму на основе токена в поле 55, использование 1 для транзакций NFC		√
Принять и передать криптограмму на основе токена в поле 126.9 для транзакций электронной торговли			√
Отправить данные AVS в поле 123, использование 2 формата TLV в существующем наборе данных ID 66 - данные AVS	√	√	√
Принять элементы данных токена в поле 123, использование 2, набор данных ID 68 - данные верификации (уровень гарантирования токена, регулируемые/нерегулируемые; первые девять цифр PAN)	√	√	√
Принять последние 4 цифры PAN в поле 44.15 в ответе авторизации	√	√	√
Передать токен в позициях 5-20 TCR 0, который был обработан в сообщении авторизации		√	√
Передать уровень гарантирования токена в позиции 6-7 дополнительных данных TCR 1, который был принят в ответе авторизации	√	√	√
Таблица 10 Опции, реализованные эквайером

[0182] Таблица 11 обеспечивает перечень элементов данных, которые могут быть отправлены в сообщениях, передаваемых через эквайера.

Предварительные данные	Описание	Позиции	Новое поле	BASE II
TC x5 и TC x6, TCR 0*	Токен Примечание: Когда взаимосвязь токен-PAN не может быть найдена, BASE II будет возвращать транзакцию с новым кодом 9E причины возврата - Взаимосвязь токен-PAN не может быть найдена	5-20		√
TC x5 и TC x6, TCR 1	Уровень гарантирования токена	6-7	√	√
Таблица 11 Элементы данных, передаваемых эквайеру/эквайером

[0183] Таблица 12 обеспечивает перечень опций, которые могут быть реализованы эмитентом, в соответствии с различными вариантами воплощения настоящего приложения. Таблица показывает, применима ли опция к транзакции NFC или транзакции электронной торговли.

Опция	Изменение	NFC	Электронная торговля
Принять и обработать режим ввода POS для токена в поле 22	√	√
Принять и обработать криптограмму на основе токена в поле 55, использование 1 для транзакций NFC	√	√
Принять и обработать криптограмму на основе токена в поел 126.9 для транзакций электронной торговли	√		√
Принять и обработать данные AVS в поле 123, использование 2 формата TLV в существующем наборе данных с ID 66 - данные AVS	√	√	√
Принять элементы данных токена в поле 123, использование 2, набор данных ID 68 - данные верификации (токен, ID запросчика токена, уровень гарантирования токена)	√	√	√
Принять и обработать индикатор транзакции микросхемы в поле 60.6 с новым значением 4 (генерируемые Visa данные токена)	√	√	√
Принять уровень гарантирования токена в дополнительных данных TCR 1, позиции 6-7	√	√	√
Принять токен в данных платежной службы TCR 5, позиции 150-165	√	√	√
Подать токен в записи поискового запроса TC 52, позиции 88-103	√	√	√
Сохранить и вернуть токен вместе с PAN для обработки исключения возвратного платежа, копировать запросы (TC52 через Base II и 0600 через SMS)	√	√	√
Таблица 12 Опции, реализуемые эмитентом

[0184] Таблица 13 обеспечивает перечень элементов данных, которые могут быть отправлены в сообщениях, передаваемых через эмитента.

Предварительные данные и поисковый запрос	Описание	Позиции	Новое поле	BASE II
TC x5 и TC x6, TCR 0	Номер счета	5-20		√
TC x5 и TC x6, TCR 1	Уровень гарантирования токена	6-7	√	√
TC x5 и TC x6, TCR 5	Токен	150-165	√	√
TC 52, TCR 1	Токен	88-103	√	√
Таблица 13 Элементы данных, передаваемые эмитенту/эмитентом

[0185] Поля данных, изображенные в таблицах 10-13, обеспечены только с иллюстративными целями и не должны рассматриваться как ограничение. Та же самая или аналогичная информация может быть передана в других полях данных. Эти и любые другие поля данных, используемые для передачи информации, обсуждаемой в настоящем документе, находятся в пределах объема настоящего изобретения.

V. Иллюстративные системы

[0186] Различные участники и элементы, показанные на фиг. 1-9, могут эксплуатировать одно или несколько компьютерных устройств (например, серверный компьютер) для обеспечения функций, описанных в настоящем документе. Любой из элементов на фиг. 1-9 может использовать любое подходящее число подсистем для обеспечения функций, описанных в настоящем документе. Примеры таких подсистем или компонентов показаны на фиг. 10. Показаны такие подсистемы, как принтер 1208, клавиатура 1216, жесткий диск 1218 (или другая память, содержащая машиночитаемые носители), монитор 1212, который соединяется с адаптером 1210 дисплея, и другие. Периферийные устройства и устройства ввода-вывода (I/O), которые соединяются с контроллером 1202 ввода-вывода, могут быть соединены с компьютерной системой посредством любого числа средств, известных в области техники, например, последовательного порта 1214. Например, последовательный порт 1214 или внешний интерфейс 1220 могут использоваться для соединения компьютерного устройства с глобальной сетью, такой как Интернет, устройством ввода с помощью мыши или сканером. Соединение через системную шину позволяет центральному процессору 1206 осуществлять связь с каждой подсистемой и управлять исполнением инструкций из системной памяти 1204 или жесткого диска 1218, а также обмениваться информацией между подсистемами.

[0187] Конкретные подробности относительно некоторых из описанных выше аспектов представлены ниже. Конкретные подробности конкретных аспектов могут быть объединены любым подходящим образом, не отступая от сущности и объема вариантов воплощения изобретения.

[0188] Носители данных и машиночитаемые носители для хранения кода или части кода могут включать в себя любые соответствующие носители, известные или используемые в области техники, в том числе носители данных и коммуникационную среду, такие как, но не ограничиваясь только этим, энергозависимые и энергонезависимые, съемными и несъемными носители, реализованные с помощью любого способа или технологии для хранения и/или передачи информации, такой как машиночитаемые инструкции, структуры данных, программные модули или другие данные, включающие в себя RAM, ROM, EEPROМ, флэш-память или другую технологию памяти, CD-ROM, цифровой универсальный диск (DVD) или другой оптический накопитель, магнитные кассеты, магнитную ленту, запоминающее устройство на магнитных дисках или другие магнитные запоминающее устройства, сигналы данных, передачи данных или любую другую среду, которая может использоваться для хранения или передачи желаемой информации и которая может быть доступна с помощью компьютера. На основании раскрытия и идей, представленных в настоящем документе, обычному специалисту в области техники могут быть понятны другие пути и/или способы для реализации различных вариантов воплощения.

[0189] Следуем понимать, что настоящее изобретение, как описано выше, может быть реализовано в форме управляющей логики, используя компьютерное программное обеспечение модульным или интегрированным образом. На основании раскрытия и идей, представленных в настоящем документе, средний специалист в области техники может узнать и понять другие пути и/или способы для реализации настоящего изобретения с использованием аппаратного обеспечения и комбинации аппаратного и программного обеспечения.

[0190] Любой из программных компонентов или функций, описанных в этой заявке, может быть реализован как программный код для исполнения процессором с использованием любого подходящего компьютерного языка, такого как, например, Java, C++ или Perl с использованием, например, традиционных или объектно-ориентированных методик. Программный код может быть сохранен в виде последовательности инструкций или команд на машиночитаемом носителе, таком как оперативное запоминающее устройство (RAM), постоянное запоминающее устройство (ROM), магнитном носителе, таком как жесткий диск или гибкий диск, или оптическом носителе, таком как CD-ROM. Любой такой машиночитаемый носитель может находиться в одном вычислительном устройстве, и может присутствовать в различных вычислительных устройствах в пределах системы или сети.

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

[0192] Одна или несколько функций из любого варианта воплощения могут быть объединены с одним или несколькими признаками любого другого варианта воплощения, не отступая от объема настоящего изобретения.

[0193] Единственное число означает «один или несколько», если специально не указано иное.

1. Способ обеспечения уровня гарантирования токена, ассоциированного с платежным токеном, основанного на способе идентификации и верификации, использовавшемся при генерации платежного токена, при этом способ содержит этапы, на которых:

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

принимают, с помощью компьютера, уровень гарантирования токена, ассоциированный с токеном, вместе с данными, использовавшимися для генерации уровня гарантирования токена;

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

передают, с помощью компьютера, измененное сообщение запроса авторизации эмитенту для одобрения,

при этом уровень гарантирования токена основан на способе идентификации и верификации, использовавшемся при генерации платежного токена, и

уровень гарантирования токена обновляется, когда выполняется дополнительный способ идентификации и верификации для платежного токена.

2. Способ по п. 1, дополнительно содержащий этапы, на которых:

перед этапом, на котором принимают сообщение запроса авторизации:

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

генерируют, с помощью компьютера, платежный токен и уровень гарантирования токена, ассоциированный с платежным токеном; и

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

3. Способ по п. 2, в котором запрошенный уровень гарантирования токена отличается от уровня гарантирования токена, который сгенерирован и сохранен в репозитарии.

4. Способ по п. 1, в котором уровень гарантирования токена представляет собой уровень доверия в ассоциации между платежным токеном и первичным номером счета, представленным платежным токеном.

5. Способ по п. 1, в котором уровень гарантирования токена дополнительно основан на объекте, выполняющем способ верификации и идентификации.

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

7. Способ по п. 1, дополнительно содержащий этапы, на которых:

принимают, с помощью компьютера, сообщение ответа на запрос авторизации от эмитента, сообщение ответа на запрос авторизации сгенерировано в ответ на сообщение запроса авторизации; и

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

8. Способ по п. 1, дополнительно содержащий этапы, на которых:

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

9. Система для обеспечения уровня гарантирования токена, ассоциированного с платежным токеном, основанного на способе идентификации и верификации, использовавшемся при генерации платежного токена, при этом система содержит:

процессор; и

невременный машиночитаемый носитель, соединенный с процессором, причем машиночитаемый носитель содержит код, который при исполнении процессором предписывает процессору:

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

принимать уровень гарантирования токена, ассоциированный с токеном, вместе с данными, использовавшимися для генерации уровня гарантирования токена;

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

передавать измененное сообщение запроса авторизации эмитенту для одобрения,

при этом уровень гарантирования токена основан на способе идентификации и верификации, использовавшемся при генерации платежного токена, и

уровень гарантирования токена обновляется, когда выполняется дополнительный способ идентификации и верификации для платежного токена.

10. Система по п. 9, в которой код при исполнении процессором дополнительно предписывает процессору:

перед приемом сообщения запроса авторизации:

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

генерировать платежный токен и уровень гарантирования токена, ассоциированный с платежным токеном; и

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

11. Система по п. 10, в которой запрошенный уровень гарантирования токена отличается от уровня гарантирования токена, который сгенерирован и сохранен в репозитарии.

12. Система по п. 9, в которой уровень гарантирования токена представляет собой уровень доверия в ассоциации между платежным токеном и первичным номером счета, представленным платежным токеном.

13. Система по п. 9, в которой уровень гарантирования токена дополнительно основан на объекте, выполнявшем способ верификации и идентификации.

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

15. Система по п. 9, в которой код при исполнении процессором дополнительно предписывает процессору:

принимать сообщение ответа на запрос авторизации от эмитента, сообщение ответа на запрос авторизации сгенерировано в ответ на сообщение запроса авторизации; и

передавать сообщение ответа на запрос авторизации, включающее в себя уровень гарантирования токена, запросчику.

16. Система по п. 9, дополнительно содержащая:

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

при этом код при исполнении процессором дополнительно предписывает процессору:

взаимодействовать с репозитарием.

17. Способ обеспечения уровня гарантирования токена, ассоциированного с платежным токеном, основанного на способе идентификации и верификации, использовавшемся при генерации платежного токена, при этом способ содержит этапы, на которых:

генерируют, с помощью компьютера, платежный токен и уровень гарантирования токена, ассоциированный с платежным токеном, платежный токен представляет первичный номер счета, присвоенный эмитентом;

посылают, с помощью компьютера, платежный токен запросчику;

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

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

передают, с помощью компьютера, измененное сообщение запроса авторизации эмитенту для одобрения,

при этом уровень гарантирования токена основан на способе идентификации и верификации, использовавшемся при генерации платежного токена, и

уровень гарантирования токена обновляется, когда выполняется дополнительный способ идентификации и верификации для платежного токена.