Перекрестные ссылки на родственные заявки
[0001] Эта заявка испрашивает приоритет предварительной заявки на патент (США) № 61/858087, поданной 24 июля 2013 года, предварительной заявки на патент (США) № 61/863863, поданной 8 августа 2013 года, и предварительной заявки на патент (США) № 61/935036, поданной 3 февраля 2014 года, которые полностью содержатся в данном документе по ссылке.
[0002] Данная заявка связана с непредварительной заявкой на патент (США) номер __________, озаглавленной "SYSTEMS AND METHODS FOR INTEROPERABLE NETWORK TOKEN PROCESSING" (дело поверенного №671US03 (79900-910620)), и непредварительной заявкой на патент (США) номер __________, озаглавленной "SYSTEMS AND METHODS FOR COMMUNICATING TOKEN ATTRIBUTES ASSOCIATED WITH A TOKEN VAULT" (дело поверенного №671US04 (79900-910621)), все из которых поданы в один день с настоящей заявкой.
Уровень техники
[0003] В традиционной электронной платежной транзакции, информация PAN (первичного номера счета) потребителя раскрывается для различных объектов, вовлеченных в жизненный цикл транзакции. PAN передается из терминала продавца в систему эквайера, сеть обработки платежей, платежные шлюзы и т.д.
[0004] Поскольку PAN может раскрываться в различные моменты в жизненном цикле транзакции, имеются предложения по использованию платежных "токенов" для того, чтобы осуществлять платежные транзакции. Токен служит в качестве дополнительного уровня безопасности для PAN и фактически становятся прокси-сервером/заместителем PAN и может использоваться вместо PAN при отправке транзакций. Использование платежных токенов вместо PAN позволяет снижать риск мошеннической активности, поскольку реальный PAN никогда не раскрывается.
[0004] Хотя традиционные усилия по использованию платежных токенов являются полезными, должны разрешаться ряд проблем. Например, относительно просто выполнять традиционные процессы аутентификации во время нормальной транзакции с реальным PAN, поскольку потребительские данные и предшествующие статистические данные для реального PAN могут быть легко получены. Следовательно, механизмы определения мошенничества в платежной системе могут определять во время транзакции то, является или нет транзакция мошеннической и/или опасной в ином отношении, так что надлежащие определения могут выполняться посредством объектов, вовлеченных в транзакцию, в отношении того, следует или нет продолжать выполнение транзакции.
[0005] Тем не менее, поскольку токен является запутанным PAN, невозможно выполнять идентичные процессы аутентификации, которые в противном случае могут выполняться с нормальным PAN. Иными словами, продавец, процессор обслуживания платежей или эмитент должен принимать токен, но не может легко связывать этот токен с конкретным потребителем или платежным счетом. Следовательно, нормальные процессы аутентификации и верификации, которые должны нормально возникать в нормальной платежной транзакции, не могут легко выполняться. Хотя может быть возможным для некоторых объектов в платежной системе выполнять любую проверку мошенничества или аутентификацию после того, как реальный PAN получается из токена (например, из хранилища токенов), этот процесс может быть слишком медленным, либо он может мешать цели использования токена в первую очередь, поскольку объекты, такие как продавец, могут принимать и могут обладать реальным PAN.
[0006] Варианты осуществления изобретения разрешают эти и другие проблемы по отдельности и совместно.
Сущность изобретения
[0007] В некоторых вариантах осуществления изобретения, предусмотрена система на основе сетевых токенов. Система на основе сетевых токенов предоставляет платформу, которая может быть использована посредством различных объектов, таких как поставщики сторонних кошельков, продавцы, эквайеры, процессоры обслуживания платежей и т.д., которые используют токены для того, чтобы упрощать платежные транзакции. В системе на основе сетевых токенов, хранилище реестра токенов может предоставлять интерфейсы для различных объектов (например, мобильных устройств, эмитентов, продавцов, поставщиков мобильных кошельков, эквайеров и т.д.), чтобы запрашивать платежные токены, запрашивать информацию относительно платежных токенов или иным образом обрабатывать платежные токены. Система на основе сетевых токенов дополнительно предоставляет такие услуги, как предоставление уровня достоверности токена. Уровень достоверности токена может быть представлен в форме кода уровня достоверности токена, который может пониматься посредством различных объектов в системе на основе сетевых токенов.
[0008] Один вариант осуществления изобретения направлен на способ, содержащий прием, посредством серверного компьютера, запроса на токен из запросчика токенов. После того, как запрос на токен принимается, способ содержит выполнение, посредством серверного компьютера, по меньшей мере, одного процесса аутентификации, ассоциированного с запросом на токен. В ответ на выполнение, по меньшей мере, одного процесса аутентификации способ содержит формирование, посредством серверного компьютера, кода достоверности токена и передачу, посредством серверного компьютера, токена в запросчик токенов.
[0009] Другой вариант осуществления изобретения направлен на способ, содержащий прием, посредством серверного компьютера, сообщения с запросом на авторизацию, содержащего платежный токен, при этом платежный токен ассоциирован с реальным идентификатором счета. Способ дополнительно содержит определение, посредством серверного компьютера, реального идентификатора счета, ассоциированного с платежным токеном. Способ также содержит формирование, посредством серверного компьютера, модифицированного сообщения с запросом на авторизацию, содержащего реальный идентификатор счета, при этом модифицированное сообщение с запросом на авторизацию содержит код уровня достоверности токена, указывающий уровень достоверности, ассоциированный с платежным токеном. Дополнительно, способ содержит передачу, посредством серверного компьютера, модифицированного сообщения с запросом на авторизацию эмитенту для подтверждения.
[0010] Другие варианты осуществления изобретения направлены на серверные компьютеры и системы, которые выполнены с возможностью осуществлять вышеописанные способы.
[0011] В некоторых вариантах осуществления, подтверждение эмитента основано, по меньшей мере, частично на коде уровня достоверности токена.
[0012] В некоторых вариантах осуществления, уровень доверия, ассоциированный с платежным токеном, содержит уровень доверия в отношении того, что платежный токен запрошен держателем счета базового платежного счета, ассоциированного с реальным идентификатором счета.
[0013] В некоторых вариантах осуществления, код уровня достоверности токена указывает способ аутентификации, ассоциированный с платежным токеном.
[0014] В некоторых вариантах осуществления, способ аутентификации содержит, по меньшей мере, одно из следующего: без аутентификации, аутентификация в сети или аутентификация эмитентом.
[0015] В некоторых вариантах осуществления, код уровня достоверности токена основан, по меньшей мере, частично на предыстории транзакций, ассоциированной с реальным идентификатором счета.
[0016] В некоторых вариантах осуществления, сообщение с запросом на авторизацию принимается посредством серверного компьютера из компьютера продавца.
[0017] В некоторых вариантах осуществления, способ дополнительно включает в себя прием сообщения с ответом по авторизации от эмитента, формирование модифицированного сообщения с ответом по авторизации, содержащего платежный токен и код уровня достоверности токена, и передачу модифицированного сообщения с ответом по авторизации в компьютер продавца.
[0018] В некоторых вариантах осуществления, перед приемом сообщения с запросом на авторизацию, платежный токен формируется и предоставляется для серверного компьютера посредством эмитента счета.
[0019] В некоторых вариантах осуществления, код уровня достоверности токена формируется в то время, когда платежный токен формируется, до того, как он формируется, или после того, как он формируется.
[0020] Далее подробно описаны эти и другие варианты осуществления изобретения.
Краткое описание чертежей
[0021] Фиг. 1 показывает блок-схему типичной системы обработки транзакций для электронных платежных транзакций с использованием счетов эмитентов, в соответствии с некоторыми вариантами осуществления изобретения.
[0022] Фиг. 2 показывает блок-схему системы обработки транзакций с использованием системы на основе сетевых токенов, в соответствии с некоторыми вариантами осуществления изобретения.
[0023] Фиг. 3 показывает блок-схему серверного компьютера для обработки токенов, в соответствии с некоторыми вариантами осуществления изобретения.
[0024] Фиг. 4A-4B показывают примерные способы аутентификации, которые могут использоваться для того, чтобы определять уровни достоверности токенов, в соответствии с некоторыми вариантами осуществления изобретения.
[0025] Фиг. 5 показывает блок-схему последовательности операций способа для примерного потока транзакций для NFC в торговой точке, в соответствии с некоторыми вариантами осуществления изобретения.
[0026] Фиг. 6 показывает блок-схему последовательности операций способа для примерной последовательности операций для транзакции на базе электронной коммерции/по принципу "карта в файле", в соответствии с некоторыми вариантами осуществления изобретения.
[0027] Фиг. 7 является блок-схемой последовательности операций примерного способа для передачи кода уровня достоверности токена эмитенту или другому объекту, в соответствии с некоторыми вариантами осуществления изобретения.
[0028] Фиг. 8 показывает блок-схему компьютерного устройства.
Подробное описание изобретения
[0029] Варианты осуществления направлены на системы, способы и устройства для сообщения рисков с использованием уровня достоверности токена. Как пояснено выше, маркирование может заключать в себе замену или смену исходных платежных учетных данных (например, первичного номера счета (PAN)) на заменяющие данные (например, нефинансовый идентификатор или заменяющий PAN). Токен может использоваться для того, чтобы инициировать или управлять транзакционной активностью. Токены также могут повышать безопасность транзакций.
[0030] Тем не менее, даже если токены предоставляют определенный уровень повышенной безопасности транзакций, по-прежнему желательно, если оценка уровня доверия или рисков ассоциирована с токеном, поскольку это позволяет снижать риск мошеннической транзакции. Оценка уровня доверия или рисков может упоминаться в качестве уровня достоверности токена. По существу, уровень достоверности токена предоставляет определенный уровень "достоверности" того, что пользователь с использованием токена фактически является подлинным держателем карты.
[0031] В некоторых вариантах осуществления, уровень достоверности токена основан на том, как держатель карты, учетные данные карты и/или токен аутентифицированы посредством сети обработки платежей, эмитента, продавца или любого другого объекта в платежной системе, который вовлечен в платежную транзакцию. В некоторых вариантах осуществления, уровень достоверности токена может указывать то, что аутентификация не возникает относительно держателя карты, учетных данных карты и/или токена.
[0032] В некоторых вариантах осуществления, уровень достоверности токена может использоваться для дополнительной оценки рисков посредством сети обработки платежей и/или эмитента до подтверждения платежной транзакции.
[0033] В некоторых вариантах осуществления, определение уровня достоверности токена может выполняться во время запроса на токен. В других вариантах осуществления, определение уровня достоверности токена может осуществляться после формирования токена в ответ на запрос на токен.
[0034] В некоторых вариантах осуществления, уровень достоверности токена может быть представлен посредством кода уровня достоверности токена в сообщении с запросом на авторизацию и/или в сообщении с ответом по авторизации.
[0035] В некоторых вариантах осуществления, обработка норм ответственности и споров для платежных транзакций на основе токенов может быть связана с уровнем достоверности токена. Например, объект может нести ответственность за транзакцию, если уровень достоверности токена является низким, и объект подтверждает транзакцию, которая в итоге оказывается мошеннической транзакцией.
[0036] В некоторых вариантах осуществления изобретения, уровни достоверности токенов могут использоваться в различных транзакциях, которые используют различные режимы предъявления (например, QR™-код, бесконтактный, для удаленной электронной коммерции, для неконтактной электронной коммерции и т.д.) для отправки токена в качестве части транзакции.
[0037] В вариантах осуществления изобретения, объект (например, сторонние кошельки, эмитенты, поставщики платежных услуг, посредники в проведении платежей и т.д.) может регистрироваться в системе на основе сетевых токенов, чтобы запрашивать идентификатор запросчика токенов. Система на основе сетевых токенов может сохранять взаимосвязь "токен-PAN" и взаимосвязь запросчиков токенов в хранилище токенов. Зарегистрированный объект может предоставлять свой соответствующий идентификатор запросчика токенов с запросом на токен в систему на основе сетевых токенов, чтобы использовать ее услуги. Например, запросчик токенов может запрашивать выдачу токена через обмен сообщениями по API (интерфейсу прикладного программирования) или пакетный запрос. Система на основе сетевых токенов может идентифицировать и проверять достоверность запрашивающего объекта на основе идентификатора запросчика токенов перед ответом на запрос на токен. Дополнительно, система на основе сетевых токенов может определять уровень достоверности токена как ассоциированный с токеном до ответа на запрос на токен.
[0038] В вариантах осуществления изобретения, сообщения с запросом на токен могут позволять запросчику токенов запрашивать токен, чтобы за счет этого маркировать PAN. После того, как токен принимается посредством запросчика токенов, токен может предоставляться продавцу, чтобы осуществлять платежную транзакцию. После этого токен далее может предоставляться эквайеру, в сеть обработки платежей и/или эмитенту в сообщении с запросом на авторизацию и/или в сообщениях по клирингу. В некоторых случаях, токен может быть заменен посредством реального PAN до того, как сообщение по авторизации или клирингу принимается посредством эмитента.
[0039] Некоторые варианты осуществления изобретения могут предоставлять уровень достоверности для токена в транзакции. Уровень достоверности токена может указывать уровень доверия привязки "токен-PAN"/потребитель. В некоторых вариантах осуществления, уровень достоверности токена может определяться на основе типа выполняемого процесса идентификации и верификации и объекта, который выполняет процесс проверки идентификационных данных и верификации. Например, система на основе сетевых токенов может определять уровень достоверности токена на основе аутентификации потребителя, учетных данных платежных счетов и токена посредством выполнения одного или более способов аутентификации. Процесс аутентификации может выполняться посредством платежной сети и может быть аутентифицирован сетью либо может выполняться посредством эмитента, так что он аутентифицирован эмитентом. Уровень достоверности токена может определяться при выдаче токена и может обновляться, если выполняются дополнительные процессы проверки идентификационных данных и верификации.
[0040] С использованием вариантов осуществления, изобретения потребители и эмитенты могут извлекать выгоду из новых и более защищенных способов оплаты и улучшенных уровней подтверждения. Поскольку уровни достоверности токенов могут быть ассоциированы с токенами, риск мошеннических транзакций с использованием токенов значительно снижается. Посредством определения уровня достоверности токена и формирования кода достоверности токена, вероятность действительности и/или подлинности токена может определяться до того, как осуществляется транзакция, за счет этого исключая необходимость выполнять проверку мошенничества и/или подлинности во время процесса оплаты. Поскольку аутентификация и верификация токена и пользователя токена осуществляются до транзакции, варианты осуществления изобретения также имеют техническое преимущество более быстрой обработки во время транзакции. Это обусловлено тем, что дополнительные этапы аутентификации и верификации не должны выполняться.
[0041] Перед пояснением вариантов осуществления изобретения, описание некоторых терминов может быть полезным в понимании вариантов осуществления изобретения.
[0042] "Токен" может включать в себя любой идентификатор для платежного счета, который является заменой для идентификатора счета. Например, токен может включать в себя последовательность буквенно-цифровых символов, которые могут использоваться в качестве замены для исходного идентификатора счета. Например, токен "4900 0000 0000 0001" может использоваться вместо первичного идентификатора счета или первичного номера счета (PAN) "4147 0900 0000 1234". В некоторых вариантах осуществления, токен может быть "сохранением формата" и может иметь числовой формат, который соответствует идентификаторам счетов, используемым в существующих сетях обработки платежей (например, формат сообщений по финансовым транзакциям по стандарту ISO 8583). В некоторых вариантах осуществления, токен может использоваться вместо PAN для того, чтобы инициировать, авторизовать, проводить расчеты или разрешать платежную транзакцию или представлять исходные учетные данные в других системах, в которых типично должны предоставляться исходные учетные данные. В некоторых вариантах осуществления, значение токена может формироваться таким образом, что восстановление исходного PAN или другого идентификатора счета из значения токена не может вычислительно извлекаться. Дополнительно, в некоторых вариантах осуществления, формат токена может быть выполнен с возможностью позволять объекту, принимающему токен, идентифицировать его в качестве токена и распознавать объект, который выдает токен.
[0043] В некоторых вариантах осуществления, формат токена может позволять объектам в платежной системе идентифицировать эмитента, ассоциированного с токеном. Например, формат токена может включать в себя идентификатор эмитента токенов, который позволяет объекту идентифицировать эмитента. Например, идентификатор эмитента токенов может быть ассоциирован с BIN эмитента базового PAN, чтобы поддерживать существующий поток платежей. Идентификатор эмитента токенов может быть числом, отличным от BIN эмитента, и может быть статическим. Например, если BIN эмитента для эмитента составляет 412345, идентификатор эмитента токенов может составлять 528325, и это число может быть статическим для всех токенов, выданных из/для этого эмитента. В некоторых вариантах осуществления, диапазон идентификаторов эмитентов токенов (например, диапазон BIN эмитентов) может иметь атрибуты, идентичные атрибутам ассоциированного диапазона карт эмитентов, и может быть включен в таблицу маршрутизации идентификаторов эмитентов (например, таблицу маршрутизации BIN). Таблица маршрутизации идентификаторов эмитентов может предоставляться в релевантные объекты в платежной системе (например, продавцам и эквайерам).
[0044] В некоторых вариантах осуществления, диапазон идентификаторов эмитентов токенов (например, диапазон BIN токенов) может быть уникальным идентификатором (например, с длиной в 6-12 цифр), исходящим из набора заранее выделенных идентификаторов эмитентов токенов (например, BIN токенов из 6 цифр), ассоциированных с выдачей токенов. Например, в некоторых вариантах осуществления, один или более диапазонов BIN токенов могут выделяться каждому диапазону BIN/карт эмитентов, который ассоциирован с эмитентом согласно объемам карт для того диапазона. В некоторых вариантах осуществления, диапазон BIN и выделение токенов могут иметь идентичный формат и определение существующего формата таблицы маршрутизации BIN, используемого посредством релевантных объектов в системе обработки платежей. В некоторых вариантах осуществления, диапазоны BIN токенов могут использоваться для того, чтобы формировать платежный токен, и не могут использоваться для того, чтобы формировать неплатежный токен. В связи с этим, неплатежные токены могут содержать различные идентификаторы эмитентов токенов или не могут содержать идентификаторы эмитентов токенов. В некоторых вариантах осуществления, токен может проходить через базовые правила проверки достоверности номера счета, включающие в себя, например, LUHN-проверку или проверку достоверности на основе контрольной суммы, которые могут устанавливаться посредством различных объектов с платежной системой.
[0045] "Инициализация" может включать в себя процесс предоставления данных для использования. Например, инициализация может включать в себя предоставление, доставку или разрешение действия токена на устройстве. Инициализация может завершаться посредством любого объекта, внутреннего или внешнего для системы проведения транзакций. Например, в некоторых вариантах осуществления, токены могут быть инициализированы посредством эмитента или сети обработки платежей в мобильном устройстве. Инициализированные токены могут иметь соответствующие данные на основе токенов, сохраненные и поддерживаемые в хранилище токенов или реестре токенов. В некоторых вариантах осуществления, хранилище токенов или реестр токенов может формировать токен, который затем может инициализироваться или доставляться в устройство. В некоторых вариантах осуществления, эмитент может указывать диапазон токенов, из которого может осуществляться формирование и инициализация токенов. Дополнительно, в некоторых вариантах осуществления, эмитент может формировать и уведомлять хранилище токенов в отношении токена.
[0046] "Атрибуты токена" могут включать в себя любой признак или информацию относительно токена. Например, атрибуты токена могут включать в себя любую информацию, которая может определять то, как токен может использоваться, доставляться, выдаваться, либо в противном случае то, как данные могут быть обработаны в системе проведения транзакций. Например, атрибуты токена могут определять то, как токен может использоваться вместо реального идентификатора счета (например, PAN) для транзакции. Например, атрибуты токена могут включать в себя тип токена, частоту использования, дату истечения срока действия и/или время истечения срока действия токена, число ассоциированных токенов, дату истечения жизненного цикла транзакции и любую дополнительную информацию, которая может быть релевантной для любого объекта в системе обработки транзакций. Например, атрибуты токена могут включать в себя идентификатор кошелька, ассоциированный с токеном, дополнительный псевдоним счета или другой идентификатор счета пользователя (например, адрес электронной почты, имя пользователя и т.д.), идентификатор устройства, номер счета-фактуры и т.д. В некоторых вариантах осуществления, запросчик токенов может предоставлять атрибуты токена во время формирования токенов. В некоторых вариантах осуществления, система на основе сетевых токенов, сеть обработки платежей, ассоциированная с системой на основе сетевых токенов, эмитент или любой другой объект, ассоциированный с токеном, может определять и/или предоставлять атрибуты токена, ассоциированные с конкретным токеном.
[0047] Тип токена может включать в себя любую информацию или индикатор того, как токен может использоваться. Например, тип токена может быть "платежным" или "неплатежным", чтобы идентифицировать токен как платежный токен или неплатежный токен. Платежный токен может включать в себя токен с высоким значением, который может использоваться вместо реального идентификатора счета (например, PAN), чтобы формировать исходные и/или последующие транзакции для счета и/или карты потребителя.
[0048] Другой тип токена может быть "статическим" или "динамическим" типом токена для статических и динамических токенов, соответственно. Например, статический токен может включать в себя токен, который может быть выдан посредством сети обработки платежей или эмитента, который может быть выдан вместо идентификатора счета (например, PAN) и может использоваться в течение определенной длительности базового идентификатора счета (например, PAN). В связи с этим, статические токены могут использоваться для того, чтобы отправлять любое число транзакций и не могут изменяться для каждой транзакции. Статические токены могут быть защищенно сохранены в потребительском устройстве (например, сохранены в защищенном запоминающем устройстве или защищенном элементе мобильного устройства) либо в облаке посредством запросчика токенов и могут доставляться защищенно в мобильное устройство. Тем не менее, статические токены могут включать в себя конфиденциальную информацию, которая может быть защищена, поскольку они могут использоваться для того, чтобы выполнять несколько транзакций за длительные периоды времени.
[0049] Альтернативно, динамические токены могут включать в себя токены, которые ограничены или сужены в использовании (например, ограничены посредством времени, порогового значения суммы (агрегированная сумма или сумма одной транзакции) либо посредством числа использований). В связи с этим, динамические токены могут формироваться и доставляться в расчете на транзакцию или по мере необходимости конечному пользователю, чтобы инициировать платежную транзакцию через зарегистрированное и аутентифицированное устройство и/или канал. Например, динамический токен разового использования может использоваться в веб-узлах для электронной коммерции, и если динамический токен перехвачен посредством третьей стороны, динамический токен может быть бесполезным, поскольку он использован и в силу этого является негодным для будущих транзакций.
[0050] Неплатежные токены могут включать в себя токены, которые не являются заменами для реальных идентификаторов счетов (например, PAN). Например, неплатежные токены могут использоваться посредством систем продавца/эквайера для аналитики, оферт, поддержки клиентов, маркетинга и т.д. Тем не менее, неплатежные токены не могут использоваться для того, чтобы формировать исходные и последующие транзакции с использованием реальных идентификаторов счетов (например, PAN) или других идентификаторов счетов. Соответственно, неплатежные токены могут включать в себя токены с низким значением, которые могут использоваться для неплатежных транзакций или транзакционных услуг посредством объекта в системе обработки транзакций.
[0051] "Частота использования" токена может указывать то, сколько раз токен может использоваться в транзакции. Например, частота использования может указывать то, сколько раз токен может успешно использоваться в платежной транзакции. Например, токен может включать в себя частоту использования как "однократного использования" или "многократного использования". Токен однократного использования может использоваться для того, чтобы формировать одну транзакцию. После первого использования токена однократного использования, все последующее использование для инициирования транзакции может считаться недопустимым, и последующая транзакция может быть отклонена. Токен многократного использования может использоваться для того, чтобы инициировать несколько транзакций.
[0052] "Реальный идентификатор счета" может включать в себя исходный идентификатор счета, ассоциированный с платежным счетом. Например, реальный идентификатор счета может представлять собой первичный номер счета (PAN), выданный посредством эмитента для счета карты (например, кредитная карта, дебетовая карта и т.д.). Например, в некоторых вариантах осуществления, реальный идентификатор счета может включать в себя числовое значение из шестнадцати цифр, к примеру, "4147 0900 0000 1234". Первые шесть цифр реального идентификатора счета (например, "414709"), может представлять реальный идентификатор эмитента (BIN), который может идентифицировать эмитента, ассоциированного с реальным идентификатором счета.
[0053] "Идентификатор эмитента платежного токена" может включать в себя любую последовательность символов, чисел или других идентификаторов, которые могут использоваться для того, чтобы идентифицировать эмитента, ассоциированного с платежным токеном. Например, идентификатор эмитента платежного токена может включать в себя BIN токена, который идентифицирует конкретного эмитента, ассоциированного со счетом, идентифицированным с использованием токена. В некоторых вариантах осуществления, идентификатор эмитента платежного токена может увязываться с реальным идентификатором эмитента (например, BIN) для эмитента. Например, идентификатор эмитента платежного токена может включать в себя числовое значение из шести цифр, которое может быть ассоциировано с эмитентом. Например, любой токен, включающий в себя идентификатор эмитента платежного токена, может быть ассоциирован с конкретным эмитентом. В связи с этим, эмитент может идентифицироваться с использованием соответствующего диапазона идентификаторов эмитентов, ассоциированного с идентификатором эмитента токенов. Например, идентификатор эмитента платежного токена "490000", соответствующий платежному токену "4900 0000 0000 0001", может увязываться с идентификатором эмитента "414709", соответствующим идентификатору платежного счета "4147 0900 0000 1234". В некоторых вариантах осуществления, идентификатор эмитента платежного токена является статическим для эмитента. Например, идентификатор эмитента платежного токена (например, "490000") может соответствовать первому эмитенту, и другой идентификатор эмитента платежного токена (например, "520000") может соответствовать второму эмитенту, и первый и второй идентификаторы эмитентов платежных токенов не могут изменяться или модифицироваться без информирования всех объектов в системе обработки сетевых токенов. В некоторых вариантах осуществления, диапазон идентификатора эмитента платежного токена может соответствовать идентификатору эмитента. Например, платежные токены, включающие в себя идентификаторы эмитентов платежных токенов из "490000"-"490002", могут соответствовать первому эмитенту (например, увязываться с идентификатором эмитента "414709"), и платежные токены, включающие в себя идентификаторы эмитентов платежных токенов из "520000"-"520002", могут соответствовать второму эмитенту (например, увязываться с реальным идентификатором эмитента "417548").
[0054] "Режим предъявления токена" может указывать способ, через который токен отправляется для транзакции. Некоторые неограничивающие примеры режима предъявления токена могут включать в себя машиночитаемые коды (например, QR™-код, штрих-код и т.д.), мобильные бесконтактные режимы (например, связь в поле в ближней зоне (NFC)), удаленные режимы на базе электронной коммерции, неконтактные режимы на базе электронной коммерции и любые другие подходящие режимы, в которых можно отправлять токен. Токены могут предоставляться через любое число различных способов. Например, в одной реализации, токен может встраиваться в машиночитаемый код, который может формироваться посредством поставщика кошельков, приложения для мобильных устройств или другого приложения на мобильном устройстве и отображаться на дисплее мобильного устройства. Машиночитаемый код может сканироваться в POS, через который токен передается продавцу. Мобильный бесконтактный режим может включать в себя прохождение токена через NFC в бесконтактном сообщении. Удаленный режим на базе электронной коммерции может включать в себя отправку токена потребителем или поставщиком кошельков через онлайновую транзакцию или в качестве транзакции на базе электронной коммерции с использованием приложения продавца или другого приложения для мобильных устройств. Неконтактный режим на базе электронной коммерции может включать в себя отправку токена потребителем из приложения-кошелька на мобильном устройстве в местоположении продавца.
[0055] "Маркирование" представляет собой процесс, посредством которого данные заменены заменяющими данными. Например, идентификатор платежного счета (например, первичный номер счета (PAN)) может быть маркирован посредством замены первичного идентификатора счета заменяющим номером, который может быть ассоциирован с идентификатором платежного счета. Дополнительно, маркирование может применяться к любой другой информации, которая может быть заменена заменяющим значением (т.е. токеном).
[0056] "Замена токенов" или "демаркирование" представляет собой процесс восстановления данных, которые заменены во время маркирования. Например, замена токенов может включать в себя замену платежного токена ассоциированным первичным номером счета (PAN), который ассоциирован с платежным токеном во время маркирования PAN. Дополнительно, демаркирование или замена токенов может применяться к любой другой информации. В некоторых вариантах осуществления, замена токенов может достигаться с помощью транзакционного сообщения, такого как ISO-сообщение, интерфейса прикладного программирования (API) или другого типа веб-интерфейса (например, веб-запроса).
[0057] "Аутентификация" представляет собой процесс, посредством которого учетные данные конечной точки (включающей в себя, но не только, приложения, людей, устройства, процессы и системы) могут быть верифицированы, чтобы обеспечивать то, что конечная точка представляет собой то, что объявлено.
[0058] "Исходная" транзакция может включать в себя любую транзакцию, включающую в себя авторизацию, предоставленную посредством эмитента, или авторизацию, предоставленную от имени эмитента.
[0059] "Заменяющая" транзакция может представлять собой любую транзакцию, которая ассоциирована с исходной транзакцией и которая осуществляется после исходной транзакции, включающей в себя повторные платежи, возмещения, отмену платежей или нестандартные платежные операции (возвратные платежи, повторные предъявления и т.д.).
[0060] "Запросчик" может представлять собой приложение, устройство, процесс или систему, которая выполнена с возможностью осуществлять действия, ассоциированные с токенами. Например, запросчик может запрашивать регистрацию в системе на основе сетевых токенов, формирование токенов запроса, активацию токенов, деактивацию токенов, замену токенов, другие связанные с управлением жизненным циклом токенов процессы и/или любые другие связанные с токенами процессы. Запросчик может взаимодействовать с системой на основе сетевых токенов через любые подходящие сети и/или протоколы связи (например, с использованием HTTPS, SOAP и/или XML). Некоторые неограничивающие примеры запросчика могут включать в себя поставщиков сторонних кошельков, эмитентов, эквайеры, продавцов и/или сети обработки платежей. Запросчик может упоминаться в качестве запросчика токенов при запросе формирования нового токена или запросе нового использования существующего токена из системы на основе сетевых токенов. В некоторых вариантах осуществления, запросчик токенов может запрашивать токены для нескольких областей действия и/или каналов. Запросчики токенов могут включать в себя, например, покупателей, продавцов, работающих по принципу "карта в файле", эквайеров, процессоры эквайера и платежные шлюзы, действующие от имени продавцов, посредников в проведении платежей (например, изготовители комплектного оборудования, операторы сетей мобильной связи и т.д.), поставщиков цифровых кошельков и/или эмитентов карт.
[0061] "Идентификатор запросчика токенов" может включать в себя любые символы, номера или другие идентификаторы, ассоциированные с объектом, ассоциированным с системой на основе сетевых токенов. Например, идентификатор запросчика токенов может быть ассоциирован с объектом, который зарегистрирован в системе на основе сетевых токенов. В некоторых вариантах осуществления, уникальный идентификатор запросчика токенов может назначаться для каждой области действия для запроса на токен, ассоциированного с идентичным запросчиком токенов. Например, идентификатор запросчика токенов может идентифицировать спаривание запросчика токенов (например, мобильного устройства, поставщика мобильных кошельков и т.д.) с областью действия токена (например, на базе электронной коммерции, бесконтактный и т.д.). Идентификатор запросчика токенов может включать в себя любой формат или тип информации. Например, в одном варианте осуществления, идентификатор запросчика токенов может включать в себя числовое значение, к примеру, число из десяти цифр или одиннадцати цифр (например, 4678012345).
В некоторых вариантах осуществления, идентификатор запросчика токенов может включать в себя код для поставщика услуг на основе токенов (например, первые 3 цифры), к примеру, системы на основе сетевых токенов, и оставшиеся цифры (например, последние 8 цифр) могут назначаться посредством поставщика услуг на основе токенов для каждого запрашивающего объекта (например, поставщика мобильных кошельков) и для каждой области действия токена (например, бесконтактный, на базе электронной коммерции и т.д.).
[0062] "Конечный пользователь" может включать в себя любое приложение, устройство, потребителя, процесс или систему, которая выполнена с возможностью взаимодействовать с запросчиком для услуг маркирования/демаркирования/управления токенами. Например, конечный пользователь может включать в себя потребителя, продавца, мобильное устройство или любой другой подходящий объект, который может быть ассоциирован с запросчиком в системе на основе сетевых токенов.
[0063] "Потребитель" может включать в себя человека или пользователя, который может быть ассоциирован с одним или более личных счетов и/или потребительских устройств. Потребитель также может упоминаться в качестве держателя карты, держателя счета или пользователя.
[0064] Держатель "по принципу "карта в файле"(COF)" может включать в себя любые объекты, которые сохраняют сведения по счету (например, сведения по картам, идентификаторы платежных счетов, PAN и т.д.) для использования в транзакциях. Например, COF-объект может сохранять платежную информацию в файле для различных типов регулярных платежей, таких как ежемесячные коммунальные платежи, периодические транзакции совершения покупок или любая другая периодическая или будущая транзакция. Поскольку платежные учетные данные и/или ассоциированные токены сохраняются в объекте для будущей транзакции, транзакции, инициируемые посредством COF-объекта, включают в себя транзакции по принципу "без физического наличия карты" (CNP). Другой тип транзакции по принципу "без физического наличия карты" (CNP) включает в себя транзакции на базе электронной коммерции, которые инициируются между удаленными сторонами (например, потребительским устройством и веб-серверным компьютером продавца).
[0065] "Сообщение с запросом на авторизацию" может представлять собой электронное сообщение, которое отправляется в сеть обработки платежей и/или эмитенту платежного счета, чтобы запрашивать авторизацию для транзакции. Сообщение с запросом на авторизацию согласно некоторым вариантам осуществления может соответствовать ISO 8583, который представляет собой стандарт для систем, которые обмениваются информацией электронных транзакций, ассоциированной с платежом, произведенным потребителем с использованием платежного устройства или платежного счета. В некоторых вариантах осуществления изобретения, сообщение с запросом на авторизацию может включать в себя платежный токен, дату истечения срока действия, режим предъявления токена, идентификатор запросчика токенов, криптограмму приложения и данные уровня достоверности. Платежный токен может включать в себя идентификатор эмитента платежного токена, который может быть заменой для реального идентификатора эмитента для эмитента. Например, реальный идентификатор эмитента может быть частью диапазона BIN, ассоциированного с эмитентом. Сообщение с запросом на авторизацию также может содержать дополнительные элементы данных, соответствующие "идентификационной информации", включающие в себя, только в качестве примера: служебный код, CVV (значение проверки подлинности карты), dCVV (динамическое значение проверки подлинности карты), дату истечения срока действия и т.д. Сообщение с запросом на авторизацию также может содержать "информацию транзакции", к примеру, любую информацию, ассоциированную с текущей операцией, такую как сумма транзакции, идентификатор продавца, местоположение продавца и т.д., а также любую другую информацию, которая может быть использована при определении того, следует или нет идентифицировать и/или авторизовать транзакцию.
[0066] "Сообщение с ответом по авторизации" может представлять собой электронное ответное сообщение на сообщение с запросом на авторизацию, сформированное посредством финансового учреждения-эмитента или сети обработки платежей. Сообщение с ответом по авторизации может включать в себя код авторизации, который может представлять собой код, который банк-эмитент кредитных карт возвращает в ответ на сообщение с запросом на авторизацию в электронном сообщении (или непосредственно или через сеть обработки платежей) в устройство доступа продавца (например, POS-терминал), который указывает подтверждение транзакции. Код может служить в качестве подтверждения авторизации. Как отмечено выше, в некоторых вариантах осуществления, сеть обработки платежей может формировать или перенаправлять сообщение с ответом по авторизации продавцу.
[0067] "Серверный компьютер" типично может представлять собой мощный компьютер или кластер компьютеров. Например, серверный компьютер может представлять собой большой мэйнфрейм, кластер миникомпьютеров или группу серверов, выступающих в качестве единицы. Серверный компьютер может быть ассоциирован с таким объектом, как сеть обработки платежей, поставщик кошельков, продавец, аутентификационное облако, эквайер или эмитент.
Примерные системы обработки сетевых токенов
[0068] Фиг. 1 показывает блок-схему типичной системы 100 обработки транзакций, выполненной с возможностью использовать реальные идентификаторы эмитентов (например, банковские идентификационные номера (BIN)), чтобы маршрутизировать сообщения с запросом на авторизацию во время обработки транзакций. Например, платежные учетные данные, выданные для потребителей, могут включать в себя реальные идентификаторы эмитентов (например, BIN), которые могут использоваться для того, чтобы идентифицировать эмитента (и сеть обработки платежей), ассоциированного со счетом, используемым для того, чтобы инициировать транзакцию.
[0069] Система 100 может включать в себя потребителя 110, потребительское устройство 120, устройство 130 доступа, компьютер 140 продавца, компьютер 150 эквайера, компьютер 160 сети обработки платежей и компьютер 170 эмитента. В некоторых реализациях, различные объекты на фиг. 1 могут обмениваться данными между собой с использованием одной или более сетей связи, таких как Интернет, сотовая сеть, TCP/IP-сеть или любая другая подходящая сеть связи. Следует отметить, что один или более объектов в системе 100 могут быть ассоциированы с компьютерным устройством, которое может реализовываться с использованием некоторых компонентов, как описано со ссылкой на фиг. 11.
[0070] Потребитель 110 может быть человеком или субъектом. Потребитель 110 может использовать потребительское устройство 120, чтобы инициировать транзакцию с продавцом посредством взаимодействия с устройством 130 доступа (например, торговым (POS) терминалом).
[0071] Потребительское устройство 120 может быть ассоциировано с платежным счетом потребителя 110. В некоторых реализациях, потребительское устройство 120 может представлять собой мобильное устройство, к примеру, мобильный телефон, планшетный компьютер, PDA, ноутбук, брелок для ключей или любое подходящее мобильное устройство. Например, потребительское устройство 120 может включать в себя кошелек или платежное приложение, которое может быть ассоциировано с одним или более платежных счетов потребителя 110. В некоторых реализациях, потребительское устройство 120 может быть выполнено с возможностью отображать машиночитаемый код (например, QR™-код, штрих-код и т.д.). Потребительское устройство 120 также может включать в себя камеру или сканирующее устройство, допускающее сканирование машиночитаемого кода. В некоторых реализациях, потребительское устройство 120 может допускать обмен данными с устройством 130 доступа с использованием технологии ближней связи, такой как NFC. Например, потребитель 110 может взаимодействовать с устройством 130 доступа посредством быстрого прикосновения или проведения потребительским устройством 120 около устройства 130 доступа. В некоторых реализациях, потребительское устройство 120 может представлять собой платежную карту, к примеру, кредитную карту, дебетовую карту, предоплатную карту, клубную карту покупателя, подарочную карту и т.д.
[0072] Устройство 130 доступа может представлять собой точку доступа в систему обработки транзакций, которая может содержать компьютер 150 эквайера, компьютер 160 сети обработки платежей и компьютер 170 эмитента. В некоторых реализациях, устройство 130 доступа может быть ассоциировано или управляться посредством компьютера 140 продавца. Например, устройство 130 доступа может представлять собой торговый терминал, который может включать в себя бесконтактное считывающее устройство, электронный кассовый аппарат, устройство отображения и т.д. В некоторых реализациях, устройство 130 доступа может быть выполнено с возможностью отображать информацию транзакции в формате, который может считываться посредством потребительского устройства 120 (например, мобильного телефона), включающую в себя QR™-код, штрих-код или любой другой механизм передачи информации. В некоторых реализациях, устройство 130 доступа может представлять собой персональный компьютер, который может использоваться потребителем 110, чтобы инициировать транзакцию с компьютером 140 продавца (например, онлайновую транзакцию).
[0073] Компьютер 140 продавца может быть ассоциирован с продавцом. В некоторых вариантах осуществления, компьютер 140 продавца может быть ассоциирован с продавцом, работающим по принципу "карта в файле" (COF). Например, продавец, работающий по принципу "карта в файле", может сохранять информацию счетов потребителя в файле (например, в базе данных продавца) для будущих платежей, к примеру, различных типов регулярных платежей (например, ежемесячных коммунальных платежей). В некоторых реализациях, потребитель может регистрироваться в одном или более продавцов для услуг по принципу "карта в файле". Компьютер 140 продавца может быть выполнен с возможностью формировать запрос на авторизацию для транзакции, инициируемой потребителем 110 с использованием устройства 130 доступа.
[0074] Компьютер 150 эквайера может представлять традиционный процессор эквайера/эквайера. Эквайер типично представляет собой систему для объекта (например, банка), который имеет деловые отношения с конкретным продавцом, поставщиком кошельков или другим объектом. Компьютер 150 эквайера может функционально соединяться с компьютером 140 продавца и сетью 160 обработки платежей и может выдавать и управлять финансовым счетом для продавца. Компьютер 150 эквайера может быть выполнен с возможностью маршрутизировать запрос на авторизацию для транзакции в компьютер 170 эмитента через компьютер 160 сети обработки платежей и маршрутизировать ответ по авторизации, принимаемый через компьютер 160 сети обработки платежей, в компьютер 140 продавца.
[0075] Компьютер 160 сети обработки платежей может быть выполнен с возможностью предоставлять услуги авторизации и услуги клиринга и расчетов для платежных транзакций. Компьютер 160 сети обработки платежей может включать в себя подсистемы обработки данных, проводные или беспроводные сети, включающие в себя Интернет. Пример компьютера 160 сети обработки платежей включает в себя VisaNet™ под управлением Visa®. Сети обработки платежей, такие как VisaNet™, могут обрабатывать транзакции по кредитным картам, транзакции по дебетовым картам и другие типы коммерческих транзакций. VisaNet™, в частности, включает в себя систему объединенных платежей Visa (VIP), которая обрабатывает запросы на авторизацию, и систему Base II, которая выполняет услуги клиринга и расчетов. Компьютер 160 сети обработки платежей может включать в себя серверный компьютер. В некоторых реализациях, компьютер 160 сети обработки платежей может перенаправлять запрос на авторизацию, принимаемый из компьютера 150 эквайера, в компьютер 170 эмитента через канал связи. Компьютер 160 сети обработки платежей дополнительно может перенаправлять сообщение с ответом по авторизации, принимаемое из компьютера 170 эмитента, в компьютер 150 эквайера.
[0076] Компьютер 170 эмитента может представлять эмитента счета и/или процессор эмитента. Типично, компьютер 170 эмитента может быть ассоциирован с коммерческой организацией (например, банком), которая, возможно, выпускает расчетную и/или платежную карту (например, кредитовый счет, дебетовый счет и т.д.) для платежных транзакций. В некоторых реализациях, коммерческая организация (банк), ассоциированная с компьютером 170 эмитента, также может выступать в качестве эквайера (например, компьютера 150 эквайера).
[0077] Фиг. 2 иллюстрирует систему 200 обработки транзакций с использованием системы на основе сетевых токенов, согласно одному варианту осуществления изобретения.
[0078] Система 200 может включать в себя систему 202 на основе сетевых токенов в дополнение к одному или более компонентов традиционной платежной системы 100, как показано на фиг. 1. Например, система 200 может включать в себя потребителя 110, компьютер 140 продавца, компьютер 150 эквайера, компьютер 160 сети обработки платежей и компьютер 170 эмитента. Система 200 также может включать в себя интерфейсы 208-218 на основе токенов с системой 202 на основе сетевых токенов, включающие в себя интерфейс 208 запросчика токенов, интерфейс 210 на основе токенов продавца, интерфейс 212 на основе токенов эквайера, интерфейс 214 на основе токенов сети обработки платежей, сетевой интерфейс 216 и интерфейс 218 на основе токенов эмитента. В некоторых вариантах осуществления изобретения, связь между различными объектами системы 200 может шифроваться. В некоторых вариантах осуществления изобретения, различные объекты в системе 200 могут обмениваться данными между собой с использованием одной или более сетей связи, таких как TCP/IP, сотовая сеть и т.д. В одном варианте осуществления, среда веб-услуг для системы 202 на основе сетевых токенов может предоставлять один или более интерфейсов связи с системой на основе сетевых токенов и может предоставлять услуги, ассоциированные со связью, включающие в себя аутентификацию объектов, авторизацию запросов, обеспечение безопасности сообщений и т.д.
[0079] Потребитель 110 может иметь возможность инициировать транзакцию с использованием идентификатора платежного счета, который может представлять собой платежную карту, выпущенной под таким брендом, как Visa®, MasterCard®, American Express®, Discover® и т.д. Помимо этого, потребитель 110 может использовать потребительское устройство 120 для того, чтобы инициировать транзакцию с использованием любого подходящего канала транзакций. Примеры каналов транзакций включают в себя сканирование мобильного устройства (например, с использованием QR™-кода или штрих-кода), быстрое прикосновение мобильного устройства к устройству доступа продавца (например, транзакция по стандарту связи в поле в ближней зоне (NFC) или другая бесконтактная/неконтактная транзакция), щелчок на устройстве ввода (к примеру, мыши) компьютера или мобильного устройства, чтобы инициировать транзакцию на базе электронной коммерции (например, онлайновую транзакцию), либо через любой другой подходящий канал, в котором может инициироваться транзакция, и токен может передаваться в компьютер продавца. Например, в некоторых вариантах осуществления, мобильное устройство может использоваться для того, чтобы инициировать удаленную транзакцию из мобильного устройства с токеном, инициализированным в защищенном элементе или другом защищенном запоминающем устройстве мобильного устройства.
[0080] Запросчик 204 токенов может включать в себя приложение, процесс, устройство или систему, которая может запрашивать токен из системы 202 на основе сетевых токенов. Например, запросчик 204 токенов может представлять собой эмитента, эквайера, продавца, работающего по принципу "карта в файле" (также называемого "зарегистрированным продавцом (MOR)), мобильное устройство (например, приложение-кошелек или платежное приложение, установленное на мобильном устройстве), посредника в проведении платежей, поставщика платежных услуг (PSP), поставщика цифровых кошельков (также называемого "поставщиком мобильных кошельков"), поставщика операционной системы (ОС), поставщика услуг сетей связи либо любой другой объект, который может использовать токен или сохранять токен для третьей стороны. Запросчик 204 токенов может взаимодействовать с системой 202 на основе сетевых токенов с использованием интерфейса 208 запросчика токенов для формирования, использования и управления токенами.
[0081] В одном варианте осуществления, каждый запросчик 204 токенов, возможно, должен подвергаться процессу адаптации в системе или регистрации, чтобы обеспечивать то, что запросчик токенов удовлетворяет стандартам интеграции и обеспечения защиты посредством системы безопасности, чтобы использовать услуги маркирования, предоставленные посредством системы 202 на основе сетевых токенов. Например, система 202 на основе сетевых токенов может предоставлять такие услуги, как регистрация карт, формирование токенов, выдача токенов, аутентификация и активация на основе токенов, замена токенов и управление жизненным циклом токенов в зарегистрированные объекты.
[0082] В качестве части процесса адаптации в системе, запросчик 204 токенов может регистрироваться в системе 202 на основе сетевых токенов и может принимать идентификатор запросчика токенов, предоставленный посредством системы 202 на основе сетевых токенов. Запросчик 204 токенов может указывать конфигурационные настройки или атрибуты токена, ассоциированные с токенами, запрашиваемыми посредством запросчика токенов, включающие в себя, например, тип токена (например, статический или динамический), поддерживаемые режимы предъявления токена (например, сканирование, бесконтактный, на базе электронной коммерции и т.д.) и любую другую релевантную конфигурационную информацию токенов, в ходе процесса адаптации в системе. Дополнительно, запросчик 204 токенов может включать в себя ограничения на определенные каналы (например, "карта в файле", бесконтактный и т.д.) для использования запрашиваемых токенов.
[0083] Серверный компьютер 202B для обработки токенов может формировать уникальный идентификатор запросчика токенов для каждого зарегистрированного запросчика токенов. После этого, зарегистрированный запросчик 204 токенов может предоставлять идентификатор запросчика токенов в качестве части каждого запроса на предоставление услуг на основе сетевых токенов в систему 202 на основе сетевых токенов в качестве формы идентификации.
[0084] Система 202 на основе сетевых токенов может предоставлять регистрацию для каждого объекта, который взаимодействует с системой на основе сетевых токенов.
[0085] Запросчик 204 токенов может быть выполнен с возможностью запрашивать новый токен или действия по управлению жизненным циклом запроса для существующего токена (например, изменять существующий токен, деактивировать токен и т.д.). В некоторых вариантах осуществления, запросчик 204 токенов может предоставлять идентификатор счета (например, PAN) и дату истечения срока действия с запросом на новый токен. Система 202 на основе сетевых токенов может использовать идентификатор запросчика токенов, чтобы идентифицировать и проверять достоверность запросчика 204 токенов, а также проверять достоверность транзакции на основе токенов, когда обработка транзакции инициирована с использованием токена.
[0086] Система 202 на основе сетевых токенов может включать в себя базу 202А данных реестра токенов и серверный компьютер 202B для обработки токенов. База 202А данных реестра токенов также может упоминаться в качестве "хранилища токенов". База 202А данных реестра токенов может сохранять и поддерживать выданные или сформированные токены, а также любую другую релевантную информацию для токенов. Например, реестр токенов может включать в себя идентификатор запросчика токенов и идентификатор счета (например, PAN) для каждого токена. База 202А данных реестра токенов и компьютер 202B для обработки токенов могут быть выполнены с возможностью предоставлять услуги, ассоциированные с реестром токенов, включающие в себя, например, регистрацию платежных счетов, формирование токенов, выдачу токенов, аутентификацию и активацию на основе токенов, замену токенов, маршрутизацию токенов, формирование уровней достоверности токенов, управление жизненным циклом токенов и обработку токенов, для объектов, которые зарегистрированы в системе 202 на основе сетевых токенов. В некоторых вариантах осуществления, различные объекты могут обмениваться данными и получать услуги, предоставляемые посредством системы 202 на основе сетевых токенов, с использованием соответствующих интерфейсов с системой 202 на основе сетевых токенов.
[0087] Токены в базе 202А данных реестра токенов могут включать в себя различные состояния токена, которые могут определять то, может или нет токен использоваться в транзакции, а также действия, необходимые для того, чтобы позволять токену использоваться в транзакции. Например, состояния токена могут включать в себя "активный", "неактивный", "действие приостановлено", "отложенный", "деактивированный" или любой другой индикатор относительно доступности для токена, который должен использоваться в транзакции. Например, в некоторых вариантах осуществления, токен может формироваться посредством хранилища токенов и может быть немедленно активным и доступным для транзакций. Дополнительно, эмитенты могут уведомлять компьютер 160 сети обработки платежей или серверный компьютер обработки сетевых токенов в отношении токенов, которые являются "неактивными" или в данный момент не используются. В некоторых вариантах осуществления, значение токена, ассоциированное с неактивным токеном, может обрабатываться идентично как "не обнаружен" посредством серверного компьютера для обработки токенов. Токен может изменяться на "с приостановленным действием", что включает в себя временное состояние, в котором авторизации или полные финансовые исходные транзакции не могут выполняться с токеном. "Деактивированное" состояние токена может включать в себя токен, действие которого может быть постоянно приостановлено, и авторизации или полные финансовые исходные транзакции не могут выполняться. В некоторых вариантах осуществления, токены могут отражать определенные атрибуты, релевантные для маркируемого идентификатора счета (например, PAN). Например, в некоторых вариантах осуществления, токен может отражать источник финансирования и страну, ассоциированную с базовым идентификатором счета.
[0088] В некоторых вариантах осуществления, компьютер 140 продавца и компьютер 150 эквайера могут содержать токен вместо реального идентификатора счета (например, PAN) для различных вариантов использования транзакции. Например, компьютер 140 продавца и/или компьютер 150 эквайера могут принимать токен в традиционном поле PAN сообщения с запросом на авторизацию и могут перенаправлять сообщение с запросом на авторизацию в компьютер 160 сети обработки платежей для обработки. Компьютер 160 сети обработки платежей может заменять токен реальным идентификатором счета (например, PAN) и отправлять модифицированное сообщение с запросом на авторизацию в компьютер 170 эмитента. В некоторых вариантах осуществления, сообщение с запросом на авторизацию дополнительно может иметь токен, перемещенный в новое поле в сообщении авторизации и/или сообщении по клирингу для приема посредством компьютера 170 эмитента, так что эмитент может принимать как идентификатор счета (например, PAN), так и токен в таких сообщениях.
[0089] Соответственно, в некоторых вариантах осуществления, компьютер 170 эмитента может быть выполнен с возможностью принимать как реальный идентификатор счета (например, PAN), так и токен в сообщениях с запросом на авторизацию и в сообщениях по клирингу транзакций, принимаемых из компьютера 160 сети обработки платежей. Сообщения по возвратным платежам и отмене возвратных платежей также могут содержать как токен, так и реальный идентификатор счета (например, PAN). В некоторых вариантах осуществления, компьютер 170 эмитента может выбирать инструктировать компьютеру 160 сети обработки платежей указывать компьютеру 170 эмитента инициализировать токены. В некоторых вариантах осуществления, компьютер 170 эмитента может предоставлять компьютеру 160 сети обработки платежей свою текущую базу данных токенов через интерфейс обработки файлов большого объема.
[0090] В некоторых вариантах осуществления, интерфейс 208 запросчика токенов может использоваться посредством запросчика 204 токенов, чтобы взаимодействовать с системой 202 на основе сетевых токенов. Например, запросчик 204 токенов может отправлять запросы для нескольких действий, включающих в себя выдачу токенов, управление жизненным циклом токенов (например, активацию, деактивацию, обновление учетных данных счетов и т.д.) и аутентификацию на основе токенов. В некоторых вариантах осуществления, интерфейс 208 запросчика токенов может включать в себя интерфейс прикладного программирования (API), либо могут использоваться любые другие релевантные форматы обмена сообщениями. Например, запросчик 204 токенов может отправлять запрос на выдачу токена, который включает в себя информацию счета (например, PAN и любые другие сведения по счету) и идентификатор запросчика токенов. Дополнительно, в некоторых вариантах осуществления, запросчик 204 токенов может предоставлять файл запросов на токен большого объема, который включает в себя множество идентификаторов счетов (например, PAN) и идентификатор запросчика токенов. Система 202 на основе сетевых токенов может формировать и возвращать множество токенов, причем каждый токен ассоциирован с идентификатором счета (например, PAN) из группового файлового запроса. В некоторых вариантах осуществления, запросчик 204 токенов необязательно может предоставлять один или более атрибутов токена с запросом, такие как, например, частота использования (например, однократного использования или многократного использования), тип токена (например, платежный или неплатежный), дата истечения срока действия токена и/или время, число запрашиваемых токенов, дата истечения жизненного цикла транзакции и т.д. В некоторых вариантах осуществления, запрос на токен дополнительно может включать в себя одно или более из MSISDN (номера мобильного абонента в цифровой сети с интегрированными услугами), условного названия счета (например, псевдонима), UUID (универсально уникального идентификатора), ассоциированного со счетом или потребителем, IMEI (международного идентификатора мобильного оборудования), IMSI (международного идентификатора абонента мобильной связи), идентификатора приложения для мобильных устройств, суммы покупок и т.д. Дополнительно, в некоторых вариантах осуществления, продавцы могут использовать интерфейс 208 запросчика токенов, чтобы запрашивать неплатежные токены (например, чтобы использовать в аналитике, программе лояльности, вознаграждениях или других бизнес-ориентированных процессах).
[0091] Дополнительно, запросчик 204 токенов может запрашивать систему 202 на основе сетевых токенов добавлять взаимосвязь "токен–идентификатор счета (например, PAN)" в базу 202А данных реестра токенов. Запросчик 204 токенов также может запрашивать систему 202 на основе сетевых токенов изменять атрибуты для взаимосвязи "токен–идентификатор счета (например, PAN)" в базе 202А данных реестра токенов. Например, запросчик 204 токенов может запрашивать систему 202 на основе сетевых токенов приостанавливать действие токена вследствие потери устройства потребителем. Запросчик 204 токенов может запрашивать систему 202 на основе сетевых токенов деактивировать токен в базе 202А данных реестра токенов. В некоторых вариантах осуществления, соответствующая запись в базе 202А данных реестра токенов может помечаться как деактивированная (например, больше недействительная для новых покупок), но может оставаться доступной для обработки нестандартных платежных операций в течение ограниченного периода времени и после этого может удаляться. В некоторых вариантах осуществления, система 202 на основе сетевых токенов может очищать токены, которые истекли или которые деактивированы в течение определенного периода времени, на периодической основе. Запросчики токенов также могут создавать пакетные файлы запросов на токен (например, добавление, удаление или деактивация) и отправлять их в систему 202 на основе сетевых токенов на периодической основе.
[0092] В некоторых вариантах осуществления, хранилище токенов может содержать следующие записи
[0093] В некоторых вариантах осуществления изобретения, для запросов на NFC-токен, идентификатор запросчика токенов, реальный идентификатор счета (например, PAN), дата истечения срока действия токена и уровень достоверности токена могут сохраняться в хранилище токенов для каждой записи с токеном.
[0094] Для запросов продавца, работающего на базе электронной коммерции по принципу "карта в файле", интерфейс 208 запросчика токенов может использоваться посредством запросчика 204 токенов, чтобы взаимодействовать с системой 202 на основе сетевых токенов. Например, запрос на токен может включать в себя то, предназначен запрос для нового токена, для изменения существующего токена или для деактивации токена. Запросчик 204 токенов также может предоставлять идентификатор запросчика токенов, PAN, дату истечения срока действия, тип токена с запросом на токен. В одном варианте осуществления, AVS- и CAVV-данные, представленные для процесса проверки идентификационных данных и верификации, могут использоваться только для аутентификации и не сохраняются в хранилище токенов.
[0095] Система 202 на основе сетевых токенов может формировать токен, который имеет формат, идентичный формату PAN, чтобы минимизировать сбой через платежную систему, и имеет значение, которое не конфликтует ни с одним реальным PAN или активным токеном. В некоторых вариантах осуществления, если токен не использован в запросе на авторизацию к намеченной дате/времени истечения срока действия, токен может быть повторно выдан посредством системы 202 на основе сетевых токенов.
[0096] В некоторых вариантах осуществления, система 202 на основе сетевых токенов может предоставлять услуги управления жизненным циклом токенов для зарегистрированных объектов. Управление жизненным циклом может быть полезным, когда токен компрометируется, или платежное устройство потеряно. Например, система 202 на основе сетевых токенов может деактивировать токен и его ассоциирования, когда токен становится неактивным, с приостановленным действием или временно заблокированным. Система 202 на основе сетевых токенов может деактивировать токен посредством временной блокировки или приостановки действия токена для конкретного запросчика токенов. Система 202 на основе сетевых токенов также может отменять токен, чтобы постоянно помечать токен как удаленный, чтобы предотвращать все будущие транзакции. Удаленный токен может использоваться во время возвратов/возвратных платежей, если идентичный токен использован для того, чтобы отправлять соответствующую исходную транзакцию для конкретного запросчика токенов. Система 202 на основе сетевых токенов также может обновлять атрибуты токена, к примеру, временные рамки достоверности токенов (например, продлевать или сокращать временные рамки), или частоты разрешенного использования токена. Временные рамки достоверности токена могут означать конкретное число дней, часов, минут или конкретную дату истечения срока действия.
[0097] В некоторых вариантах осуществления, система 202 на основе сетевых токенов может позволять зарегистрированным объектам давать возможность потребителям обновлять информацию относительно PAN, например, назначать различный PAN статическому токену. Например, объект может предоставлять идентификатор запросчика токенов, старый PAN и новый PAN в систему 202 на основе сетевых токенов с использованием своего интерфейса. Система 202 на основе сетевых токенов может формировать новый статический токен и ассоциировать его с новым PAN. Старое ассоциирование токена затем может деактивироваться.
[0098] В некоторых вариантах осуществления, система 202 на основе сетевых токенов может поддерживать токены, сформированные посредством других объектов, таких как системы эмитентов или поставщиков кошельков. Например, база 202А данных реестра токенов может быть выполнена с возможностью сохранять увязку PAN и токена и любые другие атрибуты для внешних токенов. Объекты могут предоставлять внешние токены с использованием своих соответствующих интерфейсов с системой 202 на основе сетевых токенов.
[0099] В некоторых вариантах осуществления, система 202 на основе сетевых токенов может позволять зарегистрированным объектам запрашивать значения CVV2 (проверки подлинности карты) (или другие типы значений проверки подлинности, криптограммы и т.д.) для токенов с использованием своих соответствующих интерфейсов. Система 202 на основе сетевых токенов может использовать токен, чтобы определять реальный идентификатор счета (например, PAN), и может обмениваться данными с компьютером 160 сети обработки платежей (например, с использованием API), чтобы запрашивать CVV2-значения, ассоциированные с реальными идентификаторами счетов. Эти CVV2-значения могут предоставляться в запрашивающие объекты.
[0100] В некоторых вариантах осуществления изобретения, система 202 на основе сетевых токенов может позволять зарегистрированным объектам предоставлять сведения по транзакциям, отправляемым с использованием токенов с использованием своих соответствующих интерфейсов. Например, зарегистрированный объект может предоставлять идентификатор запросчика токенов, идентификатор транзакции, сумму транзакции, дату и время транзакции, идентификатор продавца, адрес продавца, MSISDN, UUID, IMEI и т.д. Эти данные могут сохраняться в базе 202А данных реестра токенов. Эти сведения могут использоваться для программы лояльности или других типов программ. Например, сведения по транзакции могут использоваться для того, чтобы идентифицировать релевантные оферты, которые могут представлять интерес для потребителей, осуществляющих транзакции.
[0101] В некоторых вариантах осуществления, система 202 на основе сетевых токенов может позволять зарегистрированным объектам запрашивать транзакции, выполненные с использованием токенов, посредством предоставления идентификатора запросчика токена, токена или псевдонима токена и диапазона дат (например, даты начала и окончания). Система 202 на основе сетевых токенов может предоставлять список транзакций, осуществляемых с токеном или псевдонимом в идентифицированном диапазоне дат.
[0102] В некоторых вариантах осуществления, система 202 на основе сетевых токенов может позволять зарегистрированным объектам запрашивать данные авторизации и расчетов для данной комбинации токена/PAN и диапазона дат посредством предоставления идентификатора запросчика токена, PAN, токена и диапазона дат.
[0103] В некоторых вариантах осуществления, система 202 на основе сетевых токенов может позволять зарегистрированным объектам запрашивать все токены и их атрибуты, назначаемые для данного PAN и диапазона дат посредством предоставления идентификатора запросчика токена, PAN и диапазона дат.
[0104] В некоторых вариантах осуществления, система 202 на основе сетевых токенов может позволять зарегистрированным объектам запрашивать сведения для конкретной комбинации токена и PAN посредством предоставления идентификатора запросчика токена, PAN и диапазона дат.
[0105] В некоторых вариантах осуществления, система 202 на основе сетевых токенов может предоставлять интерфейс для продавцов, работающих на базе электронной коммерции, чтобы интегрировать в свои веб-приложения, чтобы инициировать запросы на формирование токенов для транзакций по принципу "карта в файле" в ходе процессов контроля. Например, продавцы, работающие на базе электронной коммерции, могут предоставлять идентификатор запросчика токенов, PAN (по принципу "карта в файле"), CVV2, дату истечения срока действия и необязательно потребительский идентификатор пользователя, используемый для веб-приложения на базе электронной коммерции с использованием интерфейса 210 на основе токенов продавца. Система 202 на основе сетевых токенов может предоставлять в ответ токен и dCVV в компьютер 140 продавца. Достоверность токена и dCVV может проверяться посредством компьютера 160 сети обработки платежей, когда он принимается из компьютера продавца в сообщении с запросом на авторизацию во время платежной транзакции.
[0106] В некоторых вариантах осуществления, система 202 на основе сетевых токенов может предоставлять интерфейс для продавцов, работающих на базе электронной коммерции, чтобы предоставлять вариант для потребителей запрашивать токен во время контроля для использования вместо PAN. Например, продавцы, работающие на базе электронной коммерции, могут предоставлять идентификатор запросчика токенов, PAN (по принципу "карта в файле"), CVV2, дату истечения срока действия и необязательно имя и фамилию и расчетный адрес потребителя с использованием интерфейса 210 на основе токенов продавца. Система 202 на основе сетевых токенов может аутентифицировать потребителя/PAN перед формированием токена. Система 202 на основе сетевых токенов может предоставлять токен и dCVV в компьютер продавца. Достоверность токена и dCVV может проверяться посредством компьютера 160 сети обработки платежей, когда он принимается из компьютера продавца в сообщении с запросом на авторизацию во время платежной транзакции.
[0107] В некоторых вариантах осуществления, система 202 на основе сетевых токенов может предоставлять пользовательский интерфейс для потребителя 110. Пользовательский интерфейс может давать возможность потребителю выполнять такие операции, как пользовательская регистрация, регистрация платежных счетов, формирование запросов на токен, деактивация токенов и т.д. В некоторых вариантах осуществления, система 202 на основе сетевых токенов может аутентифицировать потребителя 110 и/или PAN перед формированием и предоставлением токена потребителю 110.
[0108] В некоторых вариантах осуществления, система 202 на основе сетевых токенов может предоставлять сообщение уведомления, чтобы уведомлять участвующих эмитентов или другие объекты в отношении того, что один из их потребителей запрашивает токен (например, запрашивает инициализацию телефона с токеном) с использованием услуги инициализации системы на основе сетевых токенов. Сообщение уведомления может включать в себя код причины сообщения (например, создание токена, деактивация токена, приостановка действия токена или возобновление действия токена), номер токена, уровень достоверности токена и идентификатор запросчика токенов.
[0109] В некоторых вариантах осуществления, интерфейс 210 на основе токенов продавца может позволять компьютеру 140 продавца обмениваться данными с системой 202 на основе сетевых токенов для услуг маркирования и демаркирования, таких как замена токенов, обработка и маршрутизация токенов и т.д. В некоторых вариантах осуществления, интерфейс 210 на основе токенов продавца может включать в себя API. Например, компьютер 140 продавца может использовать интерфейс 210 на основе токенов продавца, чтобы запрашивать информацию PAN, ассоциированную с данным токеном из системы 202 на основе сетевых токенов посредством предоставления идентификатора запросчика токена, значения токена и даты (например, даты или диапазона дат транзакции). В некоторых вариантах осуществления, демаркирование токена может запрашиваться в ходе процесса авторизации и клиринга для транзакции. В некоторых вариантах осуществления, замена токенов может запрашиваться для большого объема токенов.
[0110] В некоторых вариантах осуществления, интерфейс 212 на основе токенов эквайера (который может иметь форму API) может позволять компьютеру 150 эквайера обмениваться данными с системой 202 на основе сетевых токенов для услуг демаркирования и маркирования. Услуги маркирования и демаркирования могут включать в себя замену токенов, обработку и маршрутизацию токенов и т.д. Например, с использованием интерфейса 212 на основе токенов эквайера, эквайеры могут запрашивать систему 202 на основе сетевых токенов инициализировать токен от своего имени. Продавец, эквайер или поставщик кошельков могут принимать токен в ответ на сообщение с запросом на инициализацию, исходящее от эквайера. Сообщение с запросом на инициализацию может поддерживать инициализацию по принципу "карта в файле" и NFC-инициализацию. Например, сообщение с запросом на инициализацию может включать в себя PAN, сумму транзакции, дату и время транзакции, дату истечения срока действия, тип продавца, код страны эквайера, код режима POS-ввода (например, клавишный ввод вручную, бесконтактное считывание с устройства и т.д.), код идентификатора эквайера, результирующий AVS-код, результирующий CVV2-код, результирующий CAVV-код, CAV-данные и любые другие релевантные данные.
[0111] В других вариантах осуществления, компьютер 150 эквайера может использовать интерфейс 212 на основе токенов эквайера, чтобы запрашивать информацию PAN, ассоциированную с данным токеном, из системы 202 на основе сетевых токенов. Это может быть выполнено посредством предоставления токена вместе с идентификатором запросчика токенов, значением токена и датой (например, датой или диапазоном дат транзакции) в интерфейс 212 на основе токенов эквайера. В некоторых вариантах осуществления, демаркирование токена может запрашиваться в ходе процесса авторизации и клиринга для транзакции через интерфейс 212 на основе токенов эквайера. В некоторых вариантах осуществления, процесс замены токенов для большого объема токенов может осуществляться через интерфейс 212 на основе токенов эквайера.
[0112] В некоторых вариантах осуществления, интерфейс 214 на основе токенов сети обработки платежей может позволять компьютеру 160 сети обработки платежей обмениваться данными с системой 202 на основе сетевых токенов для услуг маркирования и демаркирования, таких как замена токенов, обработка и маршрутизация токенов и т.д. Например, компьютер 160 сети обработки платежей может предоставлять токен в систему 202 на основе сетевых токенов взамен PAN или наоборот.
[0113] В некоторых вариантах осуществления, сетевой интерфейс 216 может позволять шлюзу или другим сетям 206 (например, MasterCard®, American Express®, Discover® и т.д.) обмениваться данными с системой 202 на основе сетевых токенов для услуг маркирования и демаркирования через компьютер 160 сети обработки платежей, например, замены токенов, маршрутизации токенов и т.д. Например, другие сети 206 могут взаимодействовать с системой 202 на основе сетевых токенов или компьютером 170 эмитента для замены токена на PAN для транзакций, инициированных с использованием счетов дебетовых карт.
[0114] В некоторых вариантах осуществления, интерфейс 218 на основе токенов эмитента может позволять компьютеру 170 эмитента обмениваться данными с системой 202 на основе сетевых токенов для услуг маркирования и демаркирования, например, регистрации на основе токенов, аутентификации на основе токенов и т.д. В некоторых вариантах осуществления, участвующие эмитенты могут запрашивать систему 202 на основе сетевых токенов маркировать PAN и управлять существующими токенами. Например, компьютер 170 эмитента может предоставлять запрос через интерфейс 218 на основе токенов эмитента на то, что система 2020 на основе сетевых токенов должна создавать токен, деактивировать токен, приостанавливать действие токена или возобновлять действие токена. Дополнительно, интерфейс на основе токенов эмитента может позволять эмитенту выполнять запрос токена, обновлять дату истечения срока действия идентификатора счета (например, PAN), заменять идентификатор счета (например, PAN), ассоциированный с токеном, либо обновлять графику карты или другую информацию, ассоциированную с токеном (например, условия и т.д.). Дополнительно, серверный компьютер 202B для обработки токенов может предоставлять уведомления и другую информацию через интерфейс 218 на основе токенов эмитента. Например, уведомления могут включать в себя уведомления относительно создания токенов, уведомления относительно инициализации устройства, результаты аутентификации и уведомления в отношении деактивации, приостановки действия и возобновления действия токена.
[0115] В некоторых вариантах осуществления, эмитент может формировать и предоставлять токены в систему на основе сетевых токенов. Например, эмитент может предоставлять токен в компьютер 160 сети обработки платежей, чтобы сохранять в хранилище токенов от имени эмитента. Например, компьютер 170 эмитента может предоставлять информацию, такую как идентификатор счета (например, PAN), токен, уровень достоверности токена, идентификатор запросчика токенов, дата истечения срока действия токена, тип токена и состояние токена, в серверный компьютер 202B для обработки токенов. Серверный компьютер для обработки токенов может проверять достоверность того, что отсутствует конфликт с токеном (т.е. что токен уже существует для этого значения), и может формировать запись токена, ассоциированную с предоставленной информацией токена, в базе 202А данных реестра токенов.
[0116] Дополнительно, в некоторых вариантах осуществления, компьютер 170 эмитента может запрашивать сеть 160 обработки платежей формировать токены с использованием собственного диапазона счетов эмитента, а не диапазона токенов сети обработки платежей. Если диапазон токенов эмитента не конфликтует с другим диапазоном идентификаторов эмитентов токенов или счетов, который уже используется, серверный компьютер 202B для обработки токенов может формировать ассоциирование или связывание между диапазоном счетов на основе токенов эмитента и диапазоном реальных идентификаторов эмитента (например, BIN) для эмитента. В некоторых вариантах осуществления, интерфейс 218 на основе токенов эмитента может позволять эмитентам отправлять регистрационный файл большого объема, содержащий токены, сформированные посредством эмитента. В некоторых вариантах осуществления, если компьютер 170 эмитента не может отвечать на запрос на токен (для отдельных или групповых запросов) в случаях инициализации токенов эмитента, то запрос на токен в запросчик 204 токенов может быть отклонен. Например, запросчик 204 токенов может принимать уведомление, информирующее запросчик токенов в отношении того, что возникает тайм-аут эмитента.
[0117] Фиг. 3 иллюстрирует компоненты серверного компьютера 202B для обработки токенов в одном варианте осуществления изобретения.
[0118] Серверный компьютер 202B для обработки токенов может включать в себя процессор 300, функционально соединенный с сетевым интерфейсом 302, запоминающим устройством 304 и машиночитаемым носителем 306.
[0119] Процессор может содержать CPU, который содержит, по меньшей мере, один высокоскоростной процессор данных, подходящий для того, чтобы выполнять программные компоненты для выполнения пользовательских и/или сформированных системой запросов. CPU может представлять собой микропроцессор, такой как Athlon, Duron и/или Opteron компании AMD; PowerPC компаний IBM и/или Motorola; процессор Cell компаний IBM и Sony; Celeron, Itanium, Pentium, Xeon и/или XScale компании Intel; и/или т.п. процессор(ы). CPU взаимодействует с запоминающим устройством через сигнал, проходящий через проводящие тракты, чтобы выполнять сохраненный программный код сигнала согласно традиционным технологиям обработки данных.
[0120] Сетевой интерфейс 302 может быть выполнен с возможностью позволять системе 202 на основе сетевых токенов обмениваться данными с другими объектами, такими как потребительское устройство 120, компьютер 140 продавца, компьютер 150 эквайера, компьютер 160 сети обработки платежей, компьютер 170 эмитента и т.д. с использованием одной или более сетей связи. Сетевые интерфейсы могут принимать, обмениваться данными и/или соединяться с сетью связи. Сетевые интерфейсы могут использовать такие протоколы соединения, как (но не только): прямое соединение, Ethernet (Base T на основе толстой, тонкой, витой пары 10/100/1000 и/или т.п.), протокол Token Ring, беспроводное соединение, к примеру, IEEE 802.11a-x и/или т.п. Сеть связи может представлять собой любое и/или комбинацию следующего: прямое соединение; Интернет; локальная вычислительная сеть (LAN); общегородская вычислительная сеть (MAN); сеть по стандарту на основе действующих миссий как узлов в сети Интернет (OMNI); защищенное пользовательское соединение; глобальная вычислительная сеть (WAN); беспроводная сеть (например, с использованием таких протоколов, как, но не только, прикладной протокол беспроводной связи (WAP), I-режим и/или т.п.); и/или т.п.
[0121] Запоминающее устройство 304 может использоваться для того, чтобы сохранять данные. Запоминающее устройство 304 может соединяться с процессором 300 внутренне или внешне (например, облачное хранение данных) и может содержать любую комбинацию энергозависимого и/или энергонезависимого запоминающего устройства, например, RAM, DRAM, ROM, флэш-памяти или любого другого подходящего запоминающего устройства.
[0122] Машиночитаемый носитель 306 может иметь форму запоминающего устройства (например, флэш-памяти, ROM и т.д.) и может содержать код, выполняемый посредством процессора 300 для реализации способов, описанных в данном документе. Машиночитаемый носитель 306 может включать в себя модуль 308 регистрации запросчиков, модуль 310 регистрации карт, модуль 312 формирования токенов, модуль 314 верификации и аутентификации, модуль 316 маршрутизации и замены токенов, модуль 318 управления жизненным циклом токенов и модуль 320 формирования отчетов и администрирования. Машиночитаемый носитель 306 также может содержать код, выполняемый посредством процессора 300, чтобы реализовывать способ, содержащий: прием сообщения с запросом на первый токен из первого объекта; анализ сообщения с запросом на первый токен; определение того, что сообщение с запросом на первый токен включает в себя запрос на токен; определение первого токена; передачу первого токена в первый объект; прием сообщения с запросом на второй токен из второго объекта; анализ сообщения с запросом на второй токен; определение того, что сообщение с запросом на второй токен включает в себя запрос на токен, ассоциированный с первым токеном; определение атрибутов токена, ассоциированных с первым токеном; и передачу определенных атрибутов токена во второй объект. Машиночитаемый носитель 306 также может содержать машиночитаемый носитель, содержащий код, выполняемый посредством процессора, для реализации способа, содержащего: формирование запроса на токен из запросчика токенов; выполнение, по меньшей мере, одного процесса аутентификации, ассоциированного с запросом на токен; в ответ на выполнение, по меньшей мере, одного процесса аутентификации, формирование кода достоверности токена; и передачу токена в запросчик токенов.
[0123] Модуль 308 регистрации запросчиков может содержать код, который может инструктировать процессору 300 регистрировать каждый объект запросчика токенов в базе 202А данных реестра токенов и формировать идентификатор запросчика токенов для зарегистрированного объекта. Некоторые неограничивающие примеры объектов запросчика токенов могут включать в себя эмитентов, поставщиков кошельков, посредников в проведении платежей (например, продавца, поставщиков кошельков или OEM, имеющих репозиторий по принципу "карта в файле"), продавцов, продавцов, работающих на базе электронной коммерции, управления по транспорту, сети обработки платежей, эквайеры, мобильные устройства (например, приложение-кошелек, платежное приложение и т.д.) либо их субкомпоненты и приложения, и потребителей. Каждый зарегистрированный объект может использовать идентификатор запросчика токенов в качестве части каждого запроса услуги на основе токенов с системой 202 на основе сетевых токенов, что может помогать идентифицировать и проверять достоверность объекта. В одном варианте осуществления, зарегистрированное приложение может предоставлять информацию запросчика токенов в модуль 308 регистрации запросчиков, такую как название объекта, контактная информация, тип объекта (например, продавец, поставщик кошельков, поставщик платежных услуг или PSP, эмитент, посредник в проведении платежей, эквайер, процессор эквайера и т.д.), режимы предъявления токена (например, сканирование, бесконтактный, на базе электронной коммерции и т.д.), тип токена (например, статический/динамический, платежный/неплатежный), параметры интеграции и обеспечения соединения и услуги с подпиской (например, запрос на токен, аутентификация и верификация, управление жизненным циклом и т.д.), а также любую другую релевантную информацию для процесса адаптации в системе.
[0124] Снова ссылаясь на фиг. 2, в некоторых вариантах осуществления, каждый запросчик 204 токенов может регистрироваться в базе 202А данных реестра токенов с использованием интерфейса 208 запросчика токенов. Например, графический пользовательский интерфейс может использоваться для того, чтобы предоставлять информацию запросчика токенов в систему 202 на основе сетевых токенов. Пользовательский интерфейс может представлять собой традиционный графический пользовательский интерфейс в соответствии и/или на основе операционных систем и/или операционных окружений, таких как Apple Macintosh OS, например, Aqua, GNUSTEP, Microsoft Windows (NT/XP), Unix X Windows (KDE, Gnome и/или т.п.), mythTV и/или т.п. Пользовательский интерфейс может предоставлять возможность отображения, выполнения, взаимодействия, обработки и/или работы программных компонентов и/или системных средств через текстовые и/или графические средства. Пользовательский интерфейс предоставляет средство, через которое пользователи могут влиять, взаимодействовать и/или управлять компьютерной системой.
[0125] Модуль 308 регистрации запросчиков может проверять достоверность информации, и после успешной проверки достоверности может сохранять сведения относительно запросчика токенов в базе 202А данных реестра токенов. Модуль 308 регистрации запросчиков также может формировать идентификатор запросчика токенов после успешной регистрации. В одном варианте осуществления, идентификатор запросчика токенов является числовым значением из десяти цифр. Тем не менее, возможны другие форматы идентификатора запросчика токенов. В некоторых вариантах осуществления, в качестве части процесса регистрации, база 202А данных реестра токенов может сохранять информацию объекта запросчика, такую как бизнес-идентификатор, идентификатор запросчика токенов, тип запросчика токенов (например, посредник в проведении платежей, зарегистрированный продавец, продавец, эквайер, эмитент и т.д.) и тип платформы (например, приложение для мобильных устройств посредника в проведении платежей, посредник в проведении платежей онлайн, приложение продавца, приложение поставщика платежных услуг, приложение-кошелек эмитента и т.д.).
[0126] Модуль 310 регистрации карт может содержать код, который может использоваться посредством процессора 300, чтобы выполнять регистрацию карт посредством различных объектов. В некоторых вариантах осуществления, система 202 на основе сетевых токенов может позволять зарегистрированным объектам регистрировать свои платежные карты или счета в системе 202 на основе сетевых токенов с использованием соответствующих интерфейсов. Например, зарегистрированные объекты могут предоставлять идентификатор запросчика токенов (например, принимаемый во время регистрации из модуля 308 регистрации запросчиков), номер платежного счета, CVV2, дату истечения срока действия, имя потребителя и контактную информацию, тип токена, тип/версию ОС и любую другую релевантную информацию для отдельной регистрации карт или групповой регистрации карт. В одном варианте осуществления, модуль 310 регистрации карт может сохранять подробности всех сведений по счетам потребителей в базе 202А данных реестра токенов для всех успешных запросов на активацию и регистрацию. В одном варианте осуществления, база 202А данных реестра токенов может сохранять идентификатор запросчика токенов, MSISDN, номер платежного счета, CVV2, дату истечения срока действия, условное название или псевдоним PAN, почтовый индекс потребителя, UUID, IMEA, IMSI, идентификатор приложения для мобильных устройств, имя и фамилию потребителя и т.д. В одном варианте осуществления, зарегистрированные объекты могут использовать свои соответствующие интерфейсы, чтобы отменять регистрацию платежных счетов посредством предоставления необходимой информации в систему 202 на основе сетевых токенов.
[0127] Модуль 312 формирования токенов может быть выполнен с возможностью формировать токен в ответ на запрос на токен из запросчика токенов. В одном варианте осуществления, модуль 312 формирования токенов может принимать идентификатор запросчика токенов, номер счета (например, PAN), дату истечения срока действия и CVV2. В некоторых вариантах осуществления, модуль 312 формирования токенов также может принимать необязательную информацию, такую как имя потребителя, потребительский адрес и почтовый индекс, тип запрашиваемого токена (например, платежный статический, платежный динамический, неплатежный и т.д.), состояние проверки подлинности карты (например, состояние AVS/CVV-проверки), MSISDN, UUID, IMEI, тип/версия ОС и любая другая подходящая информация. В одном варианте осуществления, модуль 312 формирования токенов может формировать ответ по токену с номером токена, датой истечения срока действия токена и уровнем достоверности токена. В одном варианте осуществления, модуль 312 формирования токенов может проверять достоверность идентификатора запросчика токенов, определять тип PAN и формировать токен из соответствующих диапазонов BIN токенов. База 202А данных реестра токенов может поддерживать корреляцию между картой и ассоциированным запросчиком и токеном. В одном варианте осуществления, модуль 312 формирования токенов может определять то, существует или нет уже токен в базе 202А данных реестра токенов для запроса на токен, перед формированием нового токена. В некоторых вариантах осуществления, если токен не может быть инициализирован, ответ по токену может включать в себя соответствующий код причины. Модуль 312 формирования токенов также может предоставлять интерфейс с запросчиками токенов, чтобы отправлять файл запросов на токен большого объема.
[0128] В одном варианте осуществления, токены могут формироваться на лету через API-вызовы (например, с использованием интерфейса 208 запросчика токенов). Например, когда запрос принимается, чтобы маркировать PAN, модуль 312 формирования токенов может определять диапазон токенов, чтобы назначать токен. Например, диапазон токенов может назначаться на основе того, инициализирует токен эмитент (например, назначенный эмитентом диапазон токенов) или сеть обработки платежей инициализирует токен от имени эмитента (например, назначенный сетью обработки платежей диапазон токенов). В качестве примера, если назначенный сетью обработки платежей диапазон токенов включает в себя "442400000-442400250", то "4424000000005382" может назначаться в качестве значения токена. Хранилище токенов может сохранять взаимосвязь диапазона токенов с PAN, и запись добавления токенов может регистрироваться в журнале. В некоторых вариантах осуществления, модуль 312 формирования токенов может считать список диапазона токенов ассоциированным с диапазоном PAN перед назначением токена.
[0129] В одном варианте осуществления, модуль 312 формирования токенов может осуществлять доступ к таблице диапазона токенов, которая представляет доступные диапазоны токенов, инициализированные посредством компьютера 160 сети обработки платежей, и диапазоны токенов не ассоциированы с диапазонами PAN. Модуль 312 формирования токенов может осуществлять доступ к другой таблице, которая включает в себя минимальные и максимальные диапазоны счетов для диапазонов PAN и ассоциированных токенов. Диапазоны токенов могут включать в себя диапазоны токенов, инициализированные посредством компьютера 160 сети обработки платежей, и диапазоны токенов, инициализированные: посредством компьютера 170 эмитента.
[0130] В одном варианте осуществления, интерфейс 210 на основе токенов продавца может позволять продавцам, работающим на базе электронной коммерции, инициировать запросы на формирование токенов для "карта в файле" в ходе процессов контроля с использованием этих "карт в файле". Например, модуль 312 формирования токенов может принимать идентификатор запросчика токенов, PAN по принципу "карта в файле", CVV2, дату истечения срока действия и необязательно идентификатор потребителя для веб-приложения на базе электронной коммерции. Модуль 312 формирования токенов может предоставлять токен и dCVV, достоверность которых может проверяться посредством компьютера 160 сети обработки платежей в ходе процесса авторизации. Например, токен и dCVV может предоставляться в компьютер продавца, который затем может формировать сообщение запроса на авторизацию с использованием токена и dCVV. Сеть обработки платежей затем может принимать сообщение с запросом на авторизацию и может проверять достоверность токена и dCVV или возможно заменять токен и dCVV реальным номером счета и CVV2-значением, соответствующим номеру счета.
[0131] В одном варианте осуществления, интерфейс 210 на основе токенов продавца может позволять продавцам, работающим на базе электронной коммерции, предоставлять вариант потребителю 110 запрашивать токен в ходе контроля вместо PAN. В таких вариантах осуществления, модуль 312 формирования токенов может аутентифицировать потребителя и/или PAN перед формированием токена. Например, модуль 312 формирования токенов может принимать идентификатор запросчика токенов, PAN по принципу "карта в файле", CVV2, дату истечения срока действия и необязательно имя потребителя и расчетный адрес и может предоставлять потребителю токен и dCVV, достоверность которых может проверяться посредством серверного компьютера 202B для обработки токенов во время передачи. Например, токен и dCVV могут предоставляться в потребительский компьютер, которые могут предоставляться в компьютер продавца, который затем может формировать сообщение запроса на авторизацию с использованием токена и dCVV. Сеть обработки платежей затем может принимать сообщение с запросом на авторизацию и может проверять достоверность токена и dCVV или возможно заменять токен и dCVV реальным номером счета и CVV2-значением, соответствующим номеру счета.
[0132] Модуль 314 верификации и аутентификации может быть выполнен с возможностью осуществлять процесс верификации и аутентификации потребителей. Например, модуль 314 верификации и аутентификации может выполнять аутентификацию и верификацию потребителей через сконфигурированную схему аутентификации. В одном варианте осуществления, схема аутентификации может включать в себя верификацию номера платежного счета, CVV2 и даты истечения срока действия на основе информации потребителей, сохраненной в базе данных, ассоциированной с сетью обработки платежей. В одном варианте осуществления, схема аутентификации может включать в себя прямую верификацию потребителя посредством компьютера 170 эмитента с потребительскими учетными данными для системы онлайнового банковского обслуживания.
[0133] В одном варианте осуществления, схема аутентификации может включать в себя верификацию потребительских учетных данных через ACS (сервер управления доступом) эмитента. Например, ACS-услуга эмитента может быть частью протокола аутентификации, такого как защищенный трехмерный протокол посредством Visa®. ACS-сервер может быть ассоциирован с компьютером 170 эмитента, который может включать в себя зарегистрированный счет потребителя и информацию по доступу. ACS может предоставлять эмитентам возможность аутентифицировать потребителей во время онлайновой покупки, за счет этого уменьшая вероятность мошеннического пользования платежных счетов. Например, ACS может проверять достоверность того, что потребитель зарегистрирован, выполняет верификацию потребителей во время транзакции и предоставляет ответы с цифровой подписью продавцам. Сервер каталогов с адресами множества ACS-компьютеров, ассоциированных со многими эмитентами, может присутствовать в защищенной трехмерной системе, и сервер каталогов может маршрутизировать сообщения в/из ACS.
[0134] В одном варианте осуществления, схема аутентификации может включать в себя верификацию платежного счета с использованием услуги аутентификации потребителей сети обработки платежей (например, услуги аутентификации потребителей Visa™ (VCAS)). Например, VCAS-услуга может аутентифицировать потребителя от имени эмитента до процесса авторизации.
[0135] В некоторых вариантах осуществления, схема аутентификации может быть основана на использовании одноразового пароля (OTP) или сообщения с запросом на авторизацию для суммы в нуль долларов. Например, OTP может предоставляться потребителю 110 посредством компьютера 160 сети обработки платежей или компьютера 170 эмитента. Потребитель 110 может использовать потребительское устройство 120, чтобы предоставлять OTP в систему 202 на основе сетевых токенов для аутентификации. В других вариантах осуществления изобретения, сообщение с запросом на авторизацию для суммы в нуль долларов может отправляться посредством компьютера 140 продавца в компьютер 170 эмитента через компьютер 150 эквайера и компьютер 160 сети обработки платежей, чтобы верифицировать идентификатор потребителя и/или достоверность платежного счета. В одном варианте осуществления, транзакция на сумму в нуль долларов (т.е. сообщение с запросом на авторизацию с суммой в нуль долларов) может использоваться для того, чтобы верифицировать номер платежного счета, любой персональный идентификатор (например, PIN-код), адрес и/или значения проверки подлинности (например, CVV, CVV2 или другие варианты и т.д.).
[0136] В некоторых вариантах осуществления, запросы на то, чтобы инициализировать токены, могут комбинировать запросы аутентификации потребителей с запросом на токен. Например, аутентификация может выполняться до маркирования с использованием любого из ранее поясненных способов аутентификации. В способах аутентификации, в которых компьютер 170 эмитента выполняет аутентификацию, маркирование может выполняться после приема ответа по аутентификации из компьютера 170 эмитента.
[0137] В некоторых вариантах осуществления, регистрация счетов или карт, формирование токенов и верификация и аутентификация могут выполняться в качестве части одного процесса запроса на токен. В некоторых вариантах осуществления, для групповых запросов, регистрация карт и формирование токенов могут выполняться посредством обработки файла большого объема из запросчика 204 токенов. В таких вариантах осуществления, верификация и аутентификация потребителей может выполняться на отдельном этапе. В некоторых вариантах осуществления, запросчик 204 токенов может запрашивать выполнение процесса аутентификации и процесса верификации независимо многократно для конкретной карты или счета, чтобы отражать любые изменения уровней достоверности для токена со временем.
[0138] Модуль 316 маршрутизации и замены токенов может содержать код, выполняемый посредством процессора, чтобы инструктировать процессору позволять зарегистрированным приложениям запрашивать информацию номера платежного счета для данного токена. Например, сеть 160 обработки платежей, компьютер 150 эквайера и т.д. может выдавать запрос на замену токенов во время платежной транзакции. В одном варианте осуществления, зарегистрированный объект может предоставлять, по меньшей мере, одно, два или более из идентификатора запросчика токенов, номера токена, даты истечения срока действия токена, режима предъявления токена, идентификатора транзакции, временной метки транзакции, временной метки запроса и любой другой релевантной информации, чтобы запрашивать информацию номера платежного счета. Модуль 316 маршрутизации и замены токенов может проверять достоверность того, что запрашивающий объект имеет полномочия на то, чтобы выполнять запрос для замены токенов. В одном варианте осуществления, модуль 316 маршрутизации и замены токенов может проверять достоверность увязки PAN/токена и режима предъявления на основе временной метки запроса и временной метки истечения срока действия токена. Модуль 316 маршрутизации и замены токенов может извлекать информацию номера платежного счета из базы 202А данных реестра токенов и предоставлять его вместе с уровнем достоверности в объект запросчика. В одном варианте осуществления, если увязка PAN/токена не является допустимой для запрашиваемой временной метки и режима предъявления, может предоставляться сообщение об ошибке.
[0139] Модуль 318 управления жизненным циклом токенов может содержать код, выполняемый посредством процессора 300, чтобы выполнять операции управления жизненным циклом. Операции управления жизненным циклом могут включать в себя отмену токена, активацию или деактивацию токена, обновление атрибутов токена, замену токена на новый с датой истечения срока действия нового PAN и т.д. В одном варианте осуществления, объект запросчика токенов может предоставлять идентификатор запросчика токенов, номер токена, идентификатор операции управления жизненным циклом и один или более атрибутов токена в систему 202 на основе сетевых токенов, чтобы выполнять запрашиваемую операцию управления жизненным циклом для данного токена. Модуль 318 управления жизненным циклом токенов может верифицировать идентификатор запросчика токенов и ассоциирование токена на основе базы 202А данных реестра токенов. Модуль 318 управления жизненным циклом токенов может выполнять запрашиваемую операцию управления жизненным циклом для данного номера токена и обновлять все соответствующее ассоциирование в базе 202А данных реестра токенов.
[0140] Запросчик 204 токенов запрашивает операцию управления жизненным циклом с использованием интерфейса. Операция управления жизненным циклом может быть ассоциирована с потерянным или украденным потребительским устройством, скомпрометированным номером платежного счета или токеном, изменением номера платежного счета, отменой подписки по принципу "карта в файле" и т.д. В другом примере операции управления жизненным циклом, операция активации токенов может запрашиваться, чтобы активировать неактивный, с приостановленным действием или временно заблокированный токен и его ассоциирования. Операция деактивации токенов может запрашиваться, чтобы временно заблокировать или приостанавливать действие токена. Операция отмены токенов может запрашиваться, чтобы постоянно помечать токен и его ассоциирования как удаленные, чтобы предотвращать все будущие транзакции. В некоторых вариантах осуществления, удаленный токен может использоваться во время возвратов/возвратных платежей, если идентичный токен использован для того, чтобы отправлять соответствующие исходные транзакции. Операция обновления токенов может запрашиваться, чтобы обновлять атрибуты токена, такие как дата истечения срока действия (например, продлевать или сокращать временные рамки достоверности), временная метка, частота использования (на основе предоставленных сведений по токену) и т.д. Временные рамки достоверности могут представлять собой число дней/часов/минут или конкретную дату истечения срока действия.
[0141] В некоторых вариантах осуществления, система 202 на основе сетевых токенов может позволять потребителям запрашивать обновление ассоциирования между PAN и статическим токеном. Например, потребитель 110 может запрашивать обновление своего PAN. Это обновление может осуществляться через интерфейс 208 запросчика токенов, или компьютер 170 эмитента может запрашивать обновление PAN через интерфейс 218 на основе токенов эмитента. Зарегистрированный объект может предоставлять идентификатор запросчика токенов, старый PAN и необязательно новый PAN в модуль 318 управления жизненным циклом токенов, который может ассоциировать новый PAN со статическим токеном или может формировать новый статический токен для нового PAN.
[0142] Модуль 316 формирования отчетов и администрирования может позволять запросчикам токенов запрашивать сведения по транзакции, выполненной с использованием токенов, посредством предоставления идентификатора запросчика токена, псевдонима токена или PAN и диапазона дат транзакции (например, даты начала и окончания). В одном варианте осуществления, система 202 на основе сетевых токенов может извлекать все транзакции на основе токенов из сети 160 обработки платежей и поддерживать в устройстве хранения дат, чтобы предоставлять сведения по транзакции в запрашивающий зарегистрированный объект, чтобы обрабатывать возвраты, возвратные платежи и споры и поддерживать аналитику. Модуль 316 формирования отчетов и администрирования может предоставлять сведения по транзакции, выполненной с использованием данных токенов (или токенов, ассоциированных с данным псевдонимом PAN) между данным диапазоном дат.
[0143] В некоторых вариантах осуществления, модуль 316 формирования отчетов и администрирования может позволять зарегистрированным объектам запрашивать данные авторизации и расчетов из данной комбинации токена/PAN и диапазона дат. В некоторых вариантах осуществления, модуль 316 формирования отчетов и администрирования может позволять зарегистрированным объектам запрашивать все токены и их атрибуты, назначаемые для данного PAN и из данного диапазона дат.
[0144] Модуль 322 определения достоверности токенов может быть выполнен с возможностью определять уровень достоверности токена, ассоциированный с токеном, сформированным посредством модуля 312 формирования токенов. Уровень достоверности токена может определяться на основе результата верификации и аутентификации, выполняемой посредством модуля 314 верификации и аутентификации. Уровень достоверности токена может указывать информацию достоверности, ассоциированную с токеном, к примеру, индикатор достоверности (например, запросчик, сеть, эмитент, ACS, другой), объект, который выполняет проверку достоверности (например, запросчик, сетевой эмитент и т.п.), дату, когда выполнена проверка достоверности, идентификационные данные кошелька/потребительского устройства, бальную оценку уровня достоверности (на основе используемого способа аутентификации) и любую другую релевантную информацию. Модуль 322 определения достоверности токенов может определять уровень достоверности токена во время запроса на токен или может определять уровень достоверности токена позднее. Уровень достоверности токена может использоваться для дополнительной оценки рисков посредством сети процессора обслуживания платежей или эмитента.
[0145] В некоторых вариантах осуществления, уровень достоверности токена может включать в себя информацию достоверности, к примеру, индикатор достоверности, объект, который выполняет процесс аутентификации или проверки достоверности (например, запросчик, сетевой эмитент и т.п.), дату, когда выполнена обработка проверки достоверности, индикатор идентификации кошелька/потребительского устройства, бальную оценку уровня достоверности (на основе используемого способа аутентификации) и любую другую информацию, релевантную для достоверности. Индикаторы и бальные оценки достоверности являются примерами кодов достоверности.
[0146] Некоторые примеры информации достоверности токена включают в себя, но не только, индикатор того, что токен не аутентифицирован, индикатор того, что токен аутентифицирован сетью, индикатор того, что токен аутентифицирован эмитентом, или любой другой индикатор относительно того, как токен, держатель карты и/или учетные данные карты аутентифицированы. Серверный компьютер 202B для обработки токенов может записывать уровень достоверности токена, когда хранилище токенов записывает аутентификацию через модуль 314 верификации и аутентификации.
[0147] В некоторых вариантах осуществления, сеть 160 обработки платежей может отслеживать уровень достоверности токена на основе аутентификации и запроса на привязку на основе токенов. Это может использоваться для того, чтобы информировать эмитента, что токен верифицирован с использованием дополнительных технологий аутентификации. Ниже описывается более подробная информация относительно уровня достоверности токена.
Предоставление данных достоверности токена
[0148] Модуль 322 определения достоверности токенов в серверном компьютере 202B для обработки токенов может содержать код для реализации способа для формирования уровня достоверности токена или кода, ассоциированного с уровнем достоверности токена. Способ может включать в себя прием запроса на токен из запросчика токенов. Способ также может включать в себя выполнение, по меньшей мере, одного процесса аутентификации, ассоциированного с запросом на токен, и в ответ на выполнение, по меньшей мере, одного процесса аутентификации, формирование, посредством серверного компьютера, кода достоверности токена.
[0149] Может выполняться любой подходящий процесс аутентификации или комбинация процессов аутентификации. Аутентификация может быть связана с аутентификацией платежного устройства и/или аутентификацией потребителя, который использует токен. Примеры процессов аутентификации, которые могут выполняться автономно или в комбинации, могут включать в себя проверку значения проверки подлинности, такую как CVV- или CVV2-проверка, проверку на основе AVS (услуги подтверждения адресов), проверку PAN и/или даты истечения срока действия (выполняемая с запросом и ответом по авторизации для суммы в нуль долларов или без долларов эмитенту или выполняемая посредством сети обработки платежей от имени эмитента), проверки для аутентификации по паролю пользователя (например, с использованием 3DS- или защищенной трехмерной инфраструктуры) и верификация по одноразовому паролю (OTP). Другие типы процессов аутентификации, которые могут выполняться, включают в себя процессы проверки подлинности устройств. Например, при запросе платежного токена, мобильный телефон может предоставлять такие характеристики устройства, как идентификатор защищенного элемента, номер SIM-карты, телефонный номер, номер IMEI (международного идентификатора мобильного оборудования), MSISDN-номер и т.д. Потребительская информация, к примеру, день рождения, домашний адрес, посещаемые школы и т.д., также может использоваться для того, чтобы аутентифицировать человека с использованием токена и правомерности токена. Другие примеры верифицирующей информации могут сохраняться в модуле 310 регистрации карт на фиг. 3 и описываются выше.
[0150] Токен затем может передаваться в запросчик токенов. Код достоверности токена может сохраняться в базе 202А данных реестра токенов вместе с токеном для последующего извлечения и использования. Например, код достоверности токена может передаваться, прямо или косвенно, в запросчик токенов, эквайер, сеть обработки платежей или эмитенту во время процесса оплаты.
[0151] Фиг. 4A-4B иллюстрируют примерные способы для способов аутентификации на основе запросов на токен, чтобы определять уровень достоверности токена в одном варианте осуществления изобретения.
[0152] Уровень достоверности токена может выполняться посредством системы 202 на основе сетевых токенов, чтобы аутентифицировать потребителя, учетные данные карт или токен во время запроса на токен или после этого. Снова ссылаясь на фиг. 3, уровень достоверности токена может определяться посредством модуля 322 определения достоверности токенов. Уровень достоверности токена может использоваться для дополнительной оценки рисков посредством компьютера 160 сети обработки платежей или компьютера 170 эмитента. Например, код уровня достоверности может передаваться в сообщении с запросом на авторизацию, чтобы сообщать уровень достоверности для этого токена в транзакции.
[0153] На этапе 402, запросчик 204 токенов может отправлять запрос 402 на токен в базу 202А данных реестра токенов. Запрос 402 на токен может включать в себя PAN, дату истечения срока действия, CVV2, полный адрес потребителя 110, почтовый индекс и идентификатор запросчика токенов. Например, запрос 402 на токен может представлять собой запрос на токен из потребительского устройства 120 (например, приложения-кошелька), чтобы инициировать транзакцию.
[0154] На этапе 404, система 202 на основе сетевых токенов может предоставлять ответ по токену, включающий в себя уровень достоверности токена, номер токена и дату истечения срока действия токена, на основе одного или более способов аутентификации, таких как, но не только, CVV2-проверка, AVS-проверка, процесс аутентификации с использованием авторизации для суммы в нуль долларов, процесс аутентификации, выполняемый посредством сети обработки платежей (OBO) от имени эмитента, процесс аутентификации с использованием процесса 3DS (защищенного трехмерного) расширенного ACS (сервера управления доступом) эмитента или 3DS (защищенного трехмерного) расширенного OTP (одноразового пароля) эмитента, как описано ниже. Можно принимать во внимание, что система 202 на основе сетевых токенов может предоставлять ответ по токену, включающий в себя уровень достоверности токена после аутентификации держателя карты, с использованием одного или более способов аутентификации. Каждый из способов аутентификации подробнее описывается ниже в потоках 1-6 транзакций.
[0155] Поток 1 транзакций иллюстрирует способ аутентификации на основе CVV2-проверки. На этапе 1A, когда запросчик 204 токенов отправляет запрос 402 на токен, запросчик 204 токенов также может отправлять PAN, ассоциированный с платежным счетом, дату истечения срока действия и CVV2-значениее в хранилище 202A токенов, которое, в свою очередь, может отправлять их в компьютер 160 сети обработки платежей для CVV2-проверки. Эта информация может предоставляться пользователем в запросчик 204 токенов до запроса 402 на токен. Например, CVV2-значение может представлять собой защитный код, ассоциированный с платежной картой (например, код из трех цифр, напечатанный на карте).
[0156] На этапе 1B, компьютер 160 сети обработки платежей может выполнять CVV2-проверку и отправлять ответное сообщение в реестр 202A токенов, чтобы подтверждать или отклонять авторизацию пользователя. Например, компьютер 160 сети обработки платежей может сравнивать CVV2-значение, предоставленное посредством потребителя 120, с CVV2-значением для записи (например, сохраненным в базе данных компьютера 160 сети обработки платежей). Если CVV2-значение совпадает со значением, которое сохраняется в базе данных, компьютер 160 сети обработки платежей может авторизовать пользователя. Когда серверный компьютер 202B для обработки токенов формирует токен, серверный компьютер 202B для обработки токенов может реализовывать то, что пользователь аутентифицирован с использованием CVV2-проверки посредством компьютера 160 сети обработки платежей, и может определять уровень достоверности токена, соответственно.
[0157] Поток 2 транзакций иллюстрирует способ аутентификации на основе AVS-проверки. На этапе 2A, когда запросчик 204 токенов отправляет запрос 402 на токен, запросчик 204 также может отправлять PAN, дату истечения срока действия, полный адрес и почтовый индекс, ассоциированные с держателем карты, в хранилище 202A токенов, которое, в свою очередь, может отправлять их в компьютер 160 сети обработки платежей. Эта информация может предоставляться держателем карты (например, пользователем) в запросчик 204 токенов до запроса 402 на токен. AVS-проверка предоставляет возможность сравнения элементов расчетного адреса и почтового индекса, предоставленных посредством потребителя 110, с записями эмитента.
[0158] На этапе 2B, компьютер 160 сети обработки платежей может перенаправлять PAN, дату истечения срока действия, полный адрес и почтовый индекс в компьютер 170 эмитента для AVS-проверки.
[0159] На этапе 2C, компьютер 170 эмитента может выполнять AVS-проверку и может отправлять ответное сообщение в компьютер 160 сети обработки платежей, чтобы подтверждать или отклонять авторизацию пользователя, например, посредством сравнения расчетного адреса и почтового индекса, предоставленных посредством потребителя 110, с данными по записи. Например, если предоставленные расчетный адрес и почтовый индекс совпадают с данными по записи, компьютер 170 эмитента может авторизовать пользователя (например, держателя карты или потребителя).
[0160] На этапе 2D, компьютер 160 сети обработки платежей может перенаправлять ответное сообщение в реестр 202A токенов. Когда серверный компьютер 202B для обработки токенов формирует токен, серверный компьютер 202B для обработки токенов может реализовывать то, что пользователь аутентифицирован с использованием AVS-проверки посредством компьютера 160 сети обработки платежей, и может определять уровень достоверности токена, соответственно.
[0161] Поток 3 транзакций иллюстрирует способ аутентификации на основе авторизации для суммы в нуль долларов. На этапе 3A, когда запросчик 204 токенов отправляет запрос 402 на токен, запросчик 204 токенов также может отправлять PAN и дату истечения срока действия в компьютер 160 сети обработки платежей в сообщении с запросом на авторизацию для суммы в нуль долларов или без долларов в сеть 160 обработки платежей. Эта информация может предоставляться пользователем в запросчик 204 токенов до запроса 402 на токен.
[0162] На этапе 3B, компьютер 160 сети обработки платежей может перенаправлять PAN, дату истечения срока действия и индикатор использования принципа "карта в файле" в компьютер 170 эмитента в сообщении с запросом на авторизацию для суммы в нуль долларов или без долларов.
[0163] На этапе 3C, компьютер 170 эмитента может оценивать PAN и дату истечения срока действия, чтобы определять то, являются они подлинными или мошенническими, и может отправлять ответное сообщение в компьютер 160 сети обработки платежей для того, чтобы аутентифицировать пользователя. Например, компьютер 170 эмитента может выполнять верификацию номера платежного счета, персонального идентификатора, подтверждение адресов и значения проверки подлинности карты (CVV, CVV2 или другие разновидности и т.д.) в качестве части запроса на авторизацию для суммы в нуль долларов.
[0164] На этапе 3D, компьютер 160 сети обработки платежей может перенаправлять ответное сообщение в реестр 202A токенов. Когда серверный компьютер 202B для обработки токенов формирует токен, серверный компьютер 202B для обработки токенов может реализовывать то, что пользователь аутентифицирован с использованием авторизации для суммы в нуль долларов посредством компьютера 160 сети обработки платежей, и может определять уровень достоверности токена, соответственно.
[0165] Поток 4 транзакций иллюстрирует способ OBO-аутентификации сети обработки платежей. На этапе 4A, когда запросчик 204 токенов отправляет запрос 402 на токен, запросчик 204 токенов также может отправлять PAN и дату истечения срока действия в серверный компьютер 202B для обработки токенов, чтобы выполнять OBO-авторизацию сети обработки платежей. Эта информация может предоставляться пользователем в запросчик 204 токенов до запроса 402 на токен.
[0166] На этапе 4B, серверный компьютер 202B для обработки токенов может проверять достоверность PAN и даты истечения срока действия от имени (OBO) эмитента и отправлять ответное сообщение в реестр 202A токенов, чтобы подтверждать или отклонять авторизацию пользователя, соответственно. Например, если PAN и дата истечения срока действия могут быть верифицированы от имени эмитента, серверный компьютер 202B для обработки токенов может авторизовать пользователя. Когда серверный компьютер 202B для обработки токенов формирует токен, серверный компьютер 202B для обработки токенов может реализовывать то, что пользователь аутентифицирован с использованием OBO-проверки сети обработки платежей посредством серверного компьютера 202B для обработки токенов, и может определять уровень достоверности токена, соответственно.
[0167] Поток 5 транзакций иллюстрирует способ защищенной трехмерной расширенной ACS-аутентификации эмитента. На этапе 5A, когда запросчик 204 токенов отправляет запрос 402 на токен, запросчик 204 токенов также может отправлять PAN и дату истечения срока действия, ассоциированные с платежным счетом, непосредственно в компьютер 170 эмитента для 3DS расширенной ACS-проверки эмитента. Эта информация может предоставляться пользователем в запросчик 204 токенов до запроса 402 на токен.
[0168] На этапе 5B, компьютер 170 эмитента может выполнять ACS-проверку и отправлять ответное сообщение в базу 202А данных реестра токенов, чтобы подтверждать или отклонять авторизацию пользователя. Например, компьютер 170 эмитента может запрашивать соответствующий ACS, чтобы аутентифицировать данные с помощью данных, предоставленных посредством потребителя 110 во время регистрации. ACS может отправлять сообщение в потребительское устройство 120 через прямой канал и может запрашивать то, что потребитель должен предоставлять PIN-код или другой код-пароль для того, чтобы аутентифицировать себя. Если пользователь может быть аутентифицирован с использованием ACS, компьютер 170 эмитента может предоставлять эту информацию в серверный компьютер 202B для обработки токенов. Когда серверный компьютер 202B для обработки токенов формирует токен, серверный компьютер 202B для обработки токенов может реализовывать то, что пользователь аутентифицирован с использованием защищенной трехмерной расширенной ACS-проверки эмитента посредством компьютера 160 сети обработки платежей, и может определять уровень достоверности токена, соответственно.
[0169] Поток 6 транзакций иллюстрирует способ защищенной трехмерной расширенной OTP-аутентификации эмитента. На этапе 6A, когда запросчик 204 токенов отправляет запрос 402 на токен, запросчик 204 токенов также может отправлять PAN, дату истечения срока действия и одноразовый пароль (OTP) в компьютер 170 эмитента для 3DS (защищенной трехмерной) расширенной проверки на основе OTP (одноразового пароля) эмитента. Эта информация, за исключением OTP, может предоставляться пользователем в запросчик 204 токенов до запроса 402 на токен.
[0170] На этапе 6B, компьютер 170 эмитента может предоставлять сформированный OTP (одноразовый пароль) в потребительское устройство 120.
[0171] На этапе 6C, потребительское устройство 120 может предоставлять OTP (одноразовый пароль) в запросчик 204 токенов. Например, запросчик 204 токенов может представлять собой мобильное устройство или приложение-кошелек. Держатель карты может вводить OTP в мобильное устройство или приложение-кошелек, работающее на потребительском устройстве 120.
[0172] На этапе 6D, запросчик 204 токенов может предоставлять OTP (одноразовый пароль) в базу 202А данных реестра токенов для проверки достоверности OTP.
[0173] На этапе 6E, база 202А данных реестра токенов может верифицировать OTP и отправлять сообщение, чтобы уведомлять компьютер 170 эмитента в отношении того, чтобы подтверждать или отклонять аутентификацию пользователя. Например, если принимаемый OTP совпадает со сформированным OTP, компьютер 170 эмитента может аутентифицировать пользователя. Когда серверный компьютер 202B для обработки токенов формирует токен, серверный компьютер 202B для обработки токенов может реализовывать то, что пользователь аутентифицирован с использованием защищенной трехмерной расширенной OTP-проверки эмитента посредством компьютера 160 сети обработки платежей, и может определять уровень достоверности токена, соответственно.
[0174] Можно принимать во внимание, что потоки 1-6 транзакций, описанные выше, могут возникать между этапами 402 и этапами 404 или даже до этапа 402. Уровни достоверности токенов, описанные выше, могут быть представлены в форме кода поля уровней достоверности токенов, который может быть частью сообщения с запросом на авторизацию или сообщения с ответом по авторизации.
[0175] "Код достоверности токена" может быть любым подходящим значением, которое представляет уровень достоверности того, что конкретный токен является подлинным и/или может быть доверенным. В некоторых вариантах осуществления, код достоверности токена может включать в себя бальную оценку, которая формируется на основе таких факторов, как число или тип выполняемых процессов аутентификации, платежный канал, аутентифицируемый объект и т.д. Например, по шкале 1-10, где 10 является самым доверенным, код достоверности токена "8" может назначаться для токена, который выдан после того, как несколько проверок для аутентификации выполнено для пользователя токена и платежного устройства, ассоциированного с реальным PAN, который связан с токеном. Альтернативно, код достоверности токена "2" может назначаться токену, который выдан без обработки по аутентификации, выполняемой до выдачи токенов. В других вариантах осуществления, код достоверности токена может представлять исходную информацию относительно того, что выполнены процессы аутентификации, платежного канала, аутентифицируемый объект и т.д., без попытки количественного определения уровня доверия, ассоциированного с такими факторами. Например, код достоверности токена может быть просто числом "2", чтобы указывать то, что токен выдан после того, как выполнена CVV2-проверка, и "7", когда выполнена проверка для аутентификации по одноразовому паролю. Числа "2" и "7" должны быть просто метками для выполняемых процессов аутентификации и не обязательно должны указывать конкретный уровень доверия. Ниже предоставляются другие примеры факторов, которые могут использоваться при определении уровня достоверности токена или кода.
[0176] В некоторых конкретных вариантах осуществления, код уровня достоверности токена может указывать то, как держатель карты, учетные данные карты и токен аутентифицированы посредством платежной сети. Например, код уровня достоверности токена может указывать то, какой из вышеуказанных способов аутентификации использован для того, чтобы аутентифицировать держателя карты, когда токен запрошен и в конечном счете сформирован. Эти способы аутентификации включают в себя, но не только, CVV2-проверку, AVS-проверку, авторизацию для суммы в нуль долларов, OBO сети обработки платежей, 3DS расширенный на основе ACS эмитента и 3DS расширенный на основе OTP эмитента. В течение нормальной платежной транзакции, код уровня достоверности токена может использоваться посредством эмитента 170 для дополнительной оценки рисков, а также для того, чтобы получать определенный уровень доверия в отношении того, что пользователь с использованием токена фактически является подлинным держателем карты.
[0177] В некоторых конкретных вариантах осуществления, код уровня достоверности токена может быть числом из двух цифр, которое указывает уровень достоверности токена. Например, код уровня достоверности токена может колебаться от 00-99, причем 00 является наименьшим уровнем достоверности токена, а 99 является наибольшим уровнем достоверности токена. Можно принимать во внимание, что любая другая схема индикатора может использоваться для кода уровня достоверности токена.
[0178] Использование кода уровня достоверности токена, чтобы сообщать риски в платежной сети, может иметь множество преимуществ. Во-первых, использование кода уровня достоверности токена может повышать безопасность в платежной сети, в частности, для платежных транзакций, включающих в себя использование токена. Поскольку эмитент 170 (и потенциально другие объекты в платежной сети) может иметь возможность обращаться к коду уровня достоверности токена для того, чтобы получать определенный уровень доверия в отношении того, что токен законно сформирован, и того, что он используется посредством подлинного держателя карты, вероятность подтверждения мошеннической транзакции может быть значительно уменьшена. Во-вторых, использование кода уровня достоверности токена повышает эффективность платежной системы во время транзакции, поскольку обработка по аутентификации для токена не требуется. Если посредством эмитента принимается сообщение с запросом на авторизацию 170, которое включает в себя код уровня достоверности токена, который указывает относительно высокий уровень достоверности токена, эмитент 170 может просто авторизовать транзакцию без необходимости выполнения дополнительной аутентификации пользователя и/или токена. Дополнительно, как отмечено выше, поскольку токен представляет собой запутанный PAN, очень затруднительно выполнять типы обработки по аутентификации, которые нормально должны использоваться, когда реальные PAN используются для того, чтобы осуществлять транзакции. Можно принимать во внимание, что использование кода уровня достоверности токена для того, чтобы сообщать риски, позволяет обеспечивать множество других преимуществ, описанных в этом описании.
[0179] Дополнительные преимущества использования кода уровня достоверности токена для того, чтобы сообщать риски в платежной сети, дополнительно могут иллюстрироваться в примерах, описанных ниже.
[0180] Фиг. 5 иллюстрирует примерный поток транзакций для связи в поле в ближней зоне (NFC) в торговой точке (POS) согласно некоторым вариантам осуществления изобретения.
[0181] Процесс 1102 авторизации для транзакции, осуществляемой в POS с использованием NFC-чипа (NFC-кристалла), может включать в себя этапы 502A-502G.
[0182] Процесс 502 авторизации может начинаться, когда пользователь хочет осуществлять транзакцию с продавцом. На этапе 502А, NFC-терминал в компьютере 140 продавца может захватывать данные из потребительского устройства 120 пользователя, когда потребительским устройством 120 быстро прикасаются или проводят в NFC-терминале. Например, снова ссылаясь на фиг. 1, NFC-терминал может быть частью устройства 130 доступа, которое может функционально соединяться с компьютером 140 продавца. В одном варианте осуществления изобретения, в оффлайновом процессе, эмитент, возможно, зарегистрирован в качестве запросчика токенов в хранилище токенов и, возможно, инициализирует токен в приложении-кошельке потребительского устройства 120 (например, сотового телефона с поддержкой NFC). Потребитель 110 может использовать потребительское устройство 120, чтобы производить платеж. Компьютер 140 продавца может захватывать токен, дату истечения срока действия токена, криптограмму на основе чипа и режим POS-ввода из потребительского устройства 120. В одном варианте осуществления, идентификатор запросчика токенов может маскироваться в данных криптограммы на основе чипа. Захваченный токен, возможно, сформирован до текущей транзакции с использованием любого из способов, описанных в вышеприведенном описании.
[0183] На этапе 502B, компьютер 502B продавца может формировать сообщение с запросом на авторизацию с захватываемыми данными и предоставлять его в компьютер 150 эквайера. Сообщение с запросом на авторизацию может включать в себя дополнительные поля, такие как данные транзакции, идентификатор продавца и любые другие релевантные данные. Эти данные могут включать в себя токен, дату истечения срока действия токена, криптограмму на основе чипа и режим POS-ввода.
[0184] Более конкретно, в некоторых вариантах осуществления, сообщение с запросом на авторизацию может включать в себя следующие поля данных: поле данных суммы; поле данных первичных номеров счетов (которое хранит токен); поле даты истечения срока действия; поле данных режимов предъявления токена; поле данных идентификаторов запросчиков токенов; поля данных продавцов, к примеру, поле данных идентификаторов акцептантов карт, поле данных дескрипторов продавцов (название продавца), поле данных MCC (или кодов категорий продавцов), поле данных городов продавцов, поле данных регионов продавцов и поле данных почтовых индексов продавцов; поле данных значений проверки подлинности (например, поле dCVV-данных); поле дискреционных данных эмитентов и поле данных кодов уровней достоверности токенов. Соответствующее сообщение с ответом по авторизации может включать в себя некоторые или все эти поля данных.
[0185] На этапе 502C, сообщение с запросом на авторизацию может быть передано в компьютер 160 сети обработки платежей посредством компьютера 150 эквайера. Сообщение с запросом на авторизацию может включать в себя токен, дату истечения срока действия токена, криптограмму на основе чипа и режим POS-ввода.
[0186] На этапе 502D, компьютер 160 сети обработки платежей может дешифровать части данных на основе чипа, содержащую идентификатор запросчика токенов, и отправлять данные на основе чипа, токен, дату истечения срока действия токена, идентификатор запросчика токенов, уровень достоверности токена, PAN и дату истечения срока действия PAN в компьютер 170 эмитента. Например, компьютер 160 сети обработки платежей может заменять токен на PAN из хранилища токенов и модифицировать сообщение с запросом на авторизацию таким образом, что оно включает в себя PAN вместо токена, перед предоставлением в компьютер 170 эмитента. Модифицированное сообщение с запросом на авторизацию также может включать в себя идентификатор запросчика токенов и уровень достоверности токена. Перед отправкой модифицированного сообщения с запросом на авторизацию в компьютер 170 эмитента, компьютер 160 сети обработки платежей может проверять достоверность того, что токен надлежащим образом используется в корректной области действия. В некоторых вариантах осуществления, проверка достоверности может обходиться, если уровень достоверности токена выше порогового уровня достоверности.
[0187] На 502E, компьютер 170 эмитента может принимать решение по подтверждению после приема модифицированного сообщения с запросом на авторизацию и отправлять сообщение с ответом по авторизации в сеть 160 обработки платежей. Решение по подтверждению может быть основано, по меньшей мере, на коде уровня достоверности токена в сообщении с запросом на авторизацию. Уровень достоверности токена может указывать компьютеру 570 эмитента то, как держатель карты, учетные данные карты и токен аутентифицированы посредством запросчика токенов. Уровень достоверности токена может быть основан на ряде факторов.
[0188] Один фактор может включать в себя индикатор достоверности, который указывает то, какой объект в платежной системе аутентифицирует пользователя или счет для формирования токенов. Например, пользователь, возможно, аутентифицирован для формирования токенов посредством запросчика токенов, компьютера 560 сети обработки платежей, эмитента 570, ACS или другого объекта. Можно принимать во внимание, что аутентификация посредством определенных объектов может влиять на уровень достоверности токена в большей или меньшей степени, чем аутентификация посредством других объектов. Например, если аутентификация выполнена посредством компьютера 570 эмитента, то код уровня достоверности токена может указывать более высокий уровень достоверности токена, чем если авторизация выполнена посредством самого запросчика токенов.
[0189] Другой фактор может включать в себя дату, когда сформирован токен. Токены, сформированные ближе к дате текущей транзакции, могут иметь более высокие уровни достоверности токенов, чем токены, сформированные дальше от даты текущей транзакции. Можно принимать во внимание, что хранилище токенов и/или процессор токенов могут вести учет в реальном времени уровня достоверности токена, ассоциированного с токеном. Уровень достоверности токена может обновляться в любое время по ряду причин, связанных с рядом переменных, одна из которых может включать в себя то, когда сформирован токен.
[0190] Другой фактор может включать в себя идентификационные данные кошелька/устройства. Идентификационные данные кошелька/устройства могут указывать то, для какого цифрового кошелька и/или для какого устройства сформирован токен. Токены, сформированные для цифровых кошельков и/или устройств, которые, как известно, являются более защищенными, могут иметь более высокие уровни достоверности токенов.
[0191] Другой фактор может включать в себя число успешных (например, немошеннических) транзакций, которые завершены с использованием конкретного токена. Большее число успешных транзакций, завершенных с использованием токена, может приводить к более высокому уровню достоверности токена для токена. В некоторых вариантах осуществления, хранилище токенов и/или процессор токенов могут повышать уровень достоверности токена для токена для каждой успешной транзакции или наоборот.
[0192] Уровень достоверности токена, как указано посредством кода уровня достоверности токена, может определяться на основе комбинации любых из факторов, описанных выше. Комбинация факторов может приводить к определению общего уровня достоверности токена. Уровень достоверности токена может обновляться в любое время.
[0193] Решение по подтверждению может приниматься посредством эмитента на основе уровня достоверности токена. Если уровень достоверности токена является относительно низким, и ниже порогового значения, который эмитент задает для подтверждения транзакции, транзакция может быть отклонена. Если уровень достоверности токена является относительно высоким и выше порогового значения, которое эмитент задает для подтверждения транзакции, транзакция может подтверждаться. В некоторых вариантах осуществления, эмитент может базировать свое решение по подтверждению/отклонению на уровне достоверности токена, комбинированном с различными другими факторами. Например, даже если уровень достоверности токена является низким, если токен принят посредством компьютера 570 эмитента через защищенную область действия, компьютер 570 эмитента по-прежнему может подтверждать транзакцию. В некоторых вариантах осуществления, если уровень достоверности токена является низким, компьютер 570 эмитента может выполнять дополнительные процедуры аутентификации, чтобы пытаться аутентифицировать пользователя и токен для транзакции вместо простого отклонения транзакции.
[0194] В некоторых вариантах осуществления, информация достоверности токена, принимаемая в сообщении с запросом на авторизацию, также может использоваться посредством компьютера 160 сети обработки платежей, чтобы формировать детализированную бальную оценку мошенничества. Бальные оценки мошенничества с транзакциями могут формироваться на основе таких характеристик транзакции, как продавец, который осуществляет транзакцию, время суток, дата, скорость транзакции, Интернет-адрес компьютера, используемого для того, чтобы осуществлять транзакцию, и т.д. Эта информация используется для того, чтобы создавать бальные оценки мошенничества с транзакциями, и информация достоверности токена может использоваться для того, чтобы создавать боле детализированные и более точные бальные оценки мошенничества, которые могут передаваться в компьютер 170 эмитента, чтобы помогать эмитенту определять то, следует или нет авторизовать транзакцию.
[0195] В некоторых вариантах осуществления, новые добавленные поля (например, уровень достоверности токена), возможно, должны "удерживаться и возвращаться" в транзакции.
[0196] На 502F, сеть 160 обработки платежей, при приеме ответа, может подставлять PAN вместо токена, необязательно заполнять последние четыре цифры PAN в сообщении с ответом по авторизации и возвращать уровень достоверности токена в модифицированном сообщении с ответом по авторизации в компьютер 150 эквайера. Модифицированное сообщение с ответом по авторизации также может включать в себя PAN-идентификатор продукта.
[0197] На 502G, компьютер 150 эквайера может перенаправлять сообщение с ответом по авторизации в компьютер 540 продавца.
[0198] Процесс 504 обработки клиринга и нестандартных платежных операций может включать в себя этапы 504A-504D, как описано ниже. Например, процесс обработки клиринга и нестандартных платежных операций может выполняться посредством модуля клиринга, чтобы сверять порядок транзакций.
[0199] На этапе 504А, компьютер 150 эквайера может отправлять сообщение по клиринговой тратте с токеном в поле PAN, вместе с данными на основе чипа, в сеть 160 обработки платежей. Сообщение по клиринговой тратте также может включать в себя уровень достоверности токена.
[0200] На этапе 504B, процесс клиринга в сети 160 обработки платежей может распознавать токен и заменять токен реальным PAN (например, из хранилища токенов) в клиринговой тратте в компьютер 170 эмитента. Процесс клиринга может размещать токен в новом поле в сообщении по клиринговой тратте в компьютер 170 эмитента, также заполняя уровень достоверности токена.
[0201] На этапе 504C, если должен возникать возвратный платеж, компьютер 170 эмитента может удерживать и возвращать токен, а также PAN в сеть 160 обработки платежей. В некоторых вариантах осуществления, ответственность за возвратный платеж может ложиться на различные объекты в платежной сети на основе уровня достоверности токена. Например, если объект продолжает выполнение транзакции, несмотря на низкий уровень достоверности токена, ответственность за возвратный платеж может ложиться на этот объект.
[0202] На этапе 504D, процесс клиринга может перемещать токен в поле PAN и отбрасывать реальный PAN из сообщения по клиринговой тратте в компьютер 150 эквайера.
[0203] Фиг. 6 иллюстрирует показывает примерную блок-схему последовательности операций способа для транзакции на базе электронной коммерции/по принципу "карта в файле" согласно одному варианту осуществления изобретения.
[0204] На этапе 602А, потребитель 110 может совершать покупку с использованием потребительского устройства 120. В качестве оффлайнового процесса, до транзакции, продавец (например, онлайновый продавец) может регистрироваться для идентификатора запросчика токенов. Также в качестве оффлайнового процесса, продавец может выполнять в пакетном режиме запрос всех своих PAN для получения соответствующего токена. В этой реализации, токен может быть связан с конкретным продавцом.
[0205] На этапе 602B, компьютер 140 продавца может инициировать сообщение с запросом на авторизацию в компьютер 150 эквайера. Когда авторизация инициируется, продавец/эквайер может предоставлять токен вместо PAN и даты истечения срока действия токена.
[0206] На этапе 602C, компьютер 150 эквайера может перенаправлять сообщение с запросом на авторизацию в компьютер 160 сети обработки платежей.
[0207] На этапе 602D, компьютер 160 сети обработки платежей может распознавать то, что токен исходит от продавца с поддержкой токенов, и заменять токен реальным PAN (например, из хранилища токенов) и отправлять токен в новом поле, идентификатор запросчика токенов и уровень достоверности токена и PAN в компьютер 170 эмитента в модифицированном сообщении с запросом на авторизацию. Идентификатор запросчика токенов и уровень достоверности токена могут быть необязательными для эмитентов.
[0208] На 602E, компьютер 170 эмитента может принимать решение по подтверждению и отправлять сообщение с ответом по авторизации в сеть 160 обработки платежей. Новые добавленные поля (например, уровень достоверности токена), возможно, должны "удерживаться и возвращаться" в транзакции.
[0209] На 602F, сеть 160 обработки платежей, при приеме ответа, может подставлять PAN вместо токена, необязательно заполнять последние четыре цифры PAN в сообщении с ответом по авторизации и возвращать уровень достоверности токена в модифицированном сообщении с ответом по авторизации в компьютер 150 эквайера. Модифицированное сообщение с ответом по авторизации также может включать в себя PAN-идентификатор продукта.
[0210] На 602G, компьютер 150 эквайера может перенаправлять сообщение с ответом по авторизации в компьютер 602G продавца.
[0211] Процесс 604 обработки клиринга и нестандартных платежных операций может включать в себя этапы 604A-604D, как описано ниже. Например, как пояснено со ссылкой на фиг. 5, процесс обработки клиринга и нестандартных платежных операций может выполняться посредством модуля 518 клиринга, чтобы сверять порядок транзакций.
[0212] На этапе 604А, компьютер 150 эквайера может отправлять сообщение по клиринговой тратте с токеном в поле PAN, вместе с данными на основе чипа, в сеть 160 обработки платежей. Сообщение по клиринговой тратте также может включать в себя уровень достоверности токена.
[0213] На этапе 604B, процесс клиринга в сети 160 обработки платежей может распознавать токен и заменять токен реальным PAN (например, из хранилища токенов) в сообщении по клиринговой тратте в компьютер 170 эмитента. Процесс клиринга может размещать токен в новом поле в сообщении по клиринговой тратте в компьютер 170 эмитента, также заполняя уровень достоверности токена.
[0214] На этапе 604C, если должен возникать возвратный платеж, компьютер 170 эмитента может удерживать и возвращать токен, а также PAN в сеть 160 обработки платежей.
[0215] На этапе 604D, процесс клиринга может перемещать токен в поле PAN и отбрасывать реальный PAN из сообщения по клиринговой тратте в компьютер 150 эквайера.
[0216] Можно принимать во внимание, что фиг. 6 является аналогичным фиг. 5 за исключением того, что фиг. 6 иллюстрирует транзакцию по принципу "карта в файле" вместо транзакции на основе NFC. Процессы и способы, описанные относительно уровней достоверности токенов, применяются полностью к фиг. 6. Можно принимать во внимание, что некоторые данные, передаваемые в сообщениях с запросом на авторизацию, отличаются от того, что показано на фиг. 5, поскольку транзакция по принципу "карта в файле" может быть ассоциирована с данными, отличными от данных для транзакции на основе NFC.
[0217] Фиг. 7 является блок-схемой последовательности операций примерного способа 700 для передачи кода уровня достоверности токена эмитенту или другому объекту, в соответствии с некоторыми вариантами осуществления изобретения. На этапе 702, принимается сообщение с запросом на авторизацию, включающее в себя платежный токен. Платежный токен может быть ассоциирован с реальным идентификатором счета. В некоторых вариантах осуществления, сообщение с запросом на авторизацию принимается посредством серверного компьютера из компьютера продавца. В некоторых вариантах осуществления, перед приемом сообщения с запросом на авторизацию, платежный токен может формироваться и предоставляться для серверного компьютера посредством эмитента.
[0218] На этапе 704, после приема сообщения с запросом на авторизацию, определяется реальный идентификатор счета, ассоциированный с платежным токеном.
[0219] На этапе 706, после определения реального идентификатора счета, ассоциированного с платежным токеном, формируется модифицированное сообщение с запросом на авторизацию, включающее в себя реальный идентификатор счета. Модифицированное сообщение с запросом на авторизацию может включать в себя реальный идентификатор счета и код уровня достоверности токена, указывающий уровень риска, ассоциированного с платежным токеном. Уровень риска может указывать то, запрошен или нет платежный токен посредством подлинного держателя счета для базового платежного счета, ассоциированного с реальным идентификатором счета. Код уровня достоверности токена также может указывать способ аутентификации, ассоциированный с формированием платежного токена. Способ аутентификации может включать в себя, но не только: без аутентификации, аутентификация в сети или аутентификация эмитентом. Дополнительно, код уровня достоверности токена может быть основан, по меньшей мере, частично на предыстории транзакций, ассоциированной с реальным идентификатором счета. В некоторых вариантах осуществления, код уровня достоверности токена формируется в то время, когда платежный токен формируется.
[0220] На этапе 708, после формирования модифицированного сообщения с запросом на авторизацию, модифицированное сообщение с запросом на авторизацию передается эмитенту для подтверждения. Подтверждение эмитента может быть основано, по меньшей мере, частично на коде уровня достоверности токена.
[0221] Система на основе сетевых токенов, как пояснено в различных вариантах осуществления, предоставляет платформу, которая может быть использована посредством внешних объектов (например, сторонних кошельков, продавцов, работающих на базе электронной коммерции, посредников в проведении платежей/поставщиков платежных услуг и т.д.) или внутренних сетевых систем обработки платежей, которые имеют потребность использовать токен, чтобы упрощать платежные транзакции. В вариантах осуществления изобретения, токен может поддерживать функциональную совместимость и может приниматься, обрабатываться и маршрутизироваться посредством объектов в платежной системе. Варианты осуществления изобретения могут помогать эмитентам карт и продавцам повышать безопасность карты или обеспечивать новые возможности проведения платежей через маркирование.
[0222] Различные участники и элементы, описанные в данном документе со ссылкой на фиг. 1 и 2, могут управлять одним или более компьютерных устройств таким образом, чтобы упрощать функции, описанные в данном документе. Любые из элементов на фиг. 1 и 2, включающих в себя любые серверы или базы данных, могут использовать любое подходящее число подсистем, чтобы упрощать функции, описанные в данном документе.
[0223] Примеры таких подсистем или компонентов показаны на фиг. 8. Подсистемы, показанные на фиг. 8, соединяются через системную шину 810. Показаны дополнительные подсистемы, такие как принтер 830, клавиатура 818, жесткий диск 820 (или другое запоминающее устройство, содержащее машиночитаемые носители), монитор 812, который соединяется с адаптером 814 дисплея, и т.п. Периферийные устройства и устройства ввода-вывода, которые соединяются с контроллером 824 ввода-вывода (который может представлять собой процессор или любой подходящий контроллер), могут соединяться с компьютерной системой посредством любого числа средств, известных в данной области техники, таких как последовательный порт 816. Например, последовательный порт 816 или внешний интерфейс 822 может быть использован для того, чтобы соединять компьютерное устройство с глобальной вычислительной сетью, к примеру, с Интернетом, с устройством ввода типа "мышь" или со сканером. Соединение через системную шину дает возможность центральному процессору 828 обмениваться данными с каждой подсистемой и управлять выполнением инструкций из системного запоминающего устройства 826 или жесткого диска 820, а также обменом информацией между подсистемами. Системное запоминающее устройство 826 и/или жесткий диск 820 может осуществлять машиночитаемый носитель.
[0224] Любые из программных компонентов или функций, описанных в данной заявке, могут быть реализованы как программный код, который должен выполняться посредством процессора с использованием любого надлежащего машинного языка, такого как, к примеру, Java, C++или Perl, с применением, к примеру, традиционных или объектно-ориентированных технологий. Программный код может быть сохранен как последовательность инструкций или команд на машиночитаемом носителе, таком как оперативное запоминающее устройство (RAM), постоянное запоминающее устройство (ROM), магнитный носитель, такой как жесткий диск или гибкий диск, или оптический носитель, такой как CD-ROM. Любой такой машиночитаемый носитель может размещаться в пределах одного вычислительного устройства либо может присутствовать или находиться внутри различных вычислительных устройств в пределах системы или сети.
[0225] Вышеприведенное описание является иллюстративным и не является ограничивающим. Множество модификаций изобретения должны становиться очевидными специалистам в данной области техники после прочтения раскрытия сущности. Следовательно, объем изобретения должен быть определен не со ссылкой на вышеприведенное описание, а должен быть определен со ссылкой на прилагаемую формулу изобретения в соответствии с ее полным объемом или эквивалентами.
[0226] Один или более признаков из любого варианта осуществления могут комбинироваться с одним или более признаков любого другого варианта осуществления без отступления от объема изобретения.
[0227] Упоминание элемента в единственном числе имеет намерение означать "один или более", если прямо не указано иное.
[0228] Все патенты, заявки на патент, публикации и описания, упомянутые выше, фактически полностью содержатся в данном документе по ссылке. Ни один из них не рассматривается как предшествующий уровень техники.
название | год | авторы | номер документа |
---|---|---|---|
СИСТЕМЫ И СПОСОБЫ ДЛЯ ФУНКЦИОНАЛЬНО СОВМЕСТИМОЙ ОБРАБОТКИ СЕТЕВЫХ МАРКЕРОВ | 2014 |
|
RU2669081C2 |
СИСТЕМА СЕТЕВЫХ ТОКЕНОВ | 2014 |
|
RU2792051C2 |
СИСТЕМА СЕТЕВЫХ ТОКЕНОВ | 2014 |
|
RU2691843C2 |
ЗАЩИЩЕННАЯ ОБРАБОТКА УДАЛЕННЫХ ПЛАТЕЖНЫХ ТРАНЗАКЦИЙ, ВКЛЮЧАЮЩАЯ В СЕБЯ АУТЕНТИФИКАЦИЮ ПОТРЕБИТЕЛЕЙ | 2014 |
|
RU2663476C2 |
ОБРАБОТКА ЗАЩИЩЕННЫХ УДАЛЕННЫХ ПЛАТЕЖНЫХ ТРАНЗАКЦИЙ | 2014 |
|
RU2674329C2 |
СИСТЕМЫ И СПОСОБЫ ЗАМЕНЫ ИЛИ УДАЛЕНИЯ СЕКРЕТНОЙ ИНФОРМАЦИИ ИЗ ДАННЫХ | 2015 |
|
RU2691590C2 |
КРИПТОГРАФИЧЕСКАЯ АУТЕНТИФИКАЦИЯ И ТОКЕНИЗИРОВАННЫЕ ТРАНЗАКЦИИ | 2017 |
|
RU2741321C2 |
СИСТЕМА СПИСАНИЯ И ПЕРЕЧИСЛЕНИЯ ДЛЯ X-PAY ЦИФРОВЫХ КОШЕЛЬКОВ | 2018 |
|
RU2727150C1 |
ИСПОЛЬЗОВАНИЕ УЛУЧШЕННОГО ТОКЕНА АУТЕНТИФИКАЦИИ ВЛАДЕЛЬЦА КАРТЫ | 2016 |
|
RU2699686C1 |
ШЛЮЗОВОЙ УРОВЕНЬ АБСТРАКЦИИ | 2011 |
|
RU2732585C2 |
Изобретение относится к средствам по обмену данными по риску с использованием данных достоверности токена. Техническим результатом является повышение достоверности проведения платежей. Серверный компьютер, содержащий соединенные процессор и машиночитаемый носитель, который содержит код, выполняемый процессором, для приема запроса на токен из запросчика токенов; выполнения по меньшей мере одного процесса аутентификации, ассоциированного с запросом на токен; в ответ на выполнение по меньшей мере одного процесса аутентификации формирования токена и кода достоверности токена, указывающего уровень доверия, ассоциированный с подлинностью токена; и передачи токена в запросчик токенов. Способы описывают работу процессора. 4 н. и 16 з.п. ф-лы, 9 ил.
1. Способ для сообщения рисков с использованием уровня достоверности токена, содержащий этапы, на которых:
- принимают посредством серверного компьютера запрос на токен из запросчика токенов;
- выполняют посредством серверного компьютера по меньшей мере один процесс аутентификации, ассоциированный с запросом на токен;
- в ответ на выполнение по меньшей мере одного процесса аутентификации формируют посредством серверного компьютера токен и код достоверности токена, указывающий уровень доверия, ассоциированный с подлинностью токена; и
- передают посредством серверного компьютера токен в запросчик токенов.
2. Способ по п. 1, дополнительно содержащий этап, на котором сохраняют код достоверности токена в базе данных реестра токенов.
3. Способ по п. 1, в котором по меньшей мере один процесс аутентификации содержит процесс аутентификации, выбранный из группы, состоящей из CVV2-проверки, AVS-проверки и проверки для верификации по одноразовому паролю (OTP).
4. Способ по п. 1, в котором запрос на токен содержит идентификатор счета, ассоциированный с кредитной или дебетовой картой.
5. Способ по п. 1, дополнительно содержащий этапы, на которых:
- извлекают код достоверности токена из базы данных реестра токенов; и
- предоставляют код достоверности токена в сеть обработки платежей после того, как сеть обработки платежей принимает сообщение с запросом на авторизацию для транзакции, осуществляемой с токеном.
6. Серверный компьютер, содержащий процессор и машиночитаемый носитель, соединенный с процессором, причем машиночитаемый носитель содержит код, выполняемый посредством процессора, для реализации способа, содержащего:
- прием запроса на токен из запросчика токенов;
- выполнение по меньшей мере одного процесса аутентификации, ассоциированного с запросом на токен;
- в ответ на выполнение по меньшей мере одного процесса аутентификации формирование токена и кода достоверности токена, указывающего уровень доверия, ассоциированный с подлинностью токена; и
- передачу токена в запросчик токенов.
7. Серверный компьютер по п. 6, в котором способ дополнительно содержит:
- сохранение кода достоверности токена в базе данных реестра токенов.
8. Серверный компьютер по п. 6, в котором по меньшей мере один процесс аутентификации содержит процесс аутентификации, выбранный из группы, состоящей из CVV2-проверки, AVS-проверки и проверки для верификации по одноразовому паролю (OTP).
9. Серверный компьютер по п. 6, в котором запрос на токен содержит идентификатор счета, ассоциированный с кредитной или дебетовой картой.
10. Серверный компьютер по п. 6, дополнительно содержащий:
- извлечение кода достоверности токена из базы данных реестра токенов; и
- предоставление кода достоверности токена в сеть обработки платежей после того, как сеть обработки платежей принимает сообщение с запросом на авторизацию для транзакции, осуществляемой с токеном.
11. Способ для сообщения рисков с использованием уровня достоверности токена, содержащий этапы, на которых:
- принимают посредством серверного компьютера сообщение с запросом на авторизацию, содержащее платежный токен, при этом платежный токен ассоциирован с реальным идентификатором счета;
- определяют посредством серверного компьютера реальный идентификатор счета, ассоциированный с платежным токеном;
- формируют посредством серверного компьютера модифицированное сообщение с запросом на авторизацию, содержащее реальный идентификатор счета, при этом модифицированный запрос на авторизацию содержит код уровня достоверности токена, указывающий уровень доверия, ассоциированный с платежным токеном; и
- передают посредством серверного компьютера модифицированное сообщение с запросом на авторизацию эмитенту для подтверждения.
12. Способ по п. 11, в котором уровень доверия, ассоциированный с платежным токеном, содержит уровень доверия в отношении того, что платежный токен запрошен держателем счета базового платежного счета, ассоциированного с реальным идентификатором счета.
13. Способ по п. 11, в котором код уровня достоверности токена указывает способ аутентификации, ассоциированный с платежным токеном.
14. Способ по п. 13, в котором способ аутентификации содержит по меньшей мере одно из следующего: без аутентификации, аутентификация в сети или аутентификация эмитентом.
15. Способ по п. 11, в котором код уровня достоверности токена основан по меньшей мере частично на предыстории транзакций, ассоциированной с реальным идентификатором счета.
16. Серверный компьютер, содержащий процессор и машиночитаемый носитель, содержащий код, выполняемый посредством процессора, для реализации способа, содержащего:
- определение посредством серверного компьютера реального идентификатора счета, ассоциированного с платежным токеном;
- формирование посредством серверного компьютера модифицированного сообщения с запросом на авторизацию, содержащего реальный идентификатор счета, при этом модифицированный запрос на авторизацию содержит код уровня достоверности токена, указывающий уровень доверия, ассоциированный с платежным токеном; и
- передачу посредством серверного компьютера модифицированного сообщения с запросом на авторизацию эмитенту для подтверждения.
17. Серверный компьютер по п. 16, в котором подтверждение эмитента основано по меньшей мере частично на коде уровня достоверности токена.
18. Серверный компьютер по п. 16, в котором уровень доверия, ассоциированный с платежным токеном, содержит уровень доверия в отношении того, что платежный токен запрошен держателем счета базового платежного счета, ассоциированного с реальным идентификатором счета.
19. Серверный компьютер по п. 16, в котором код уровня достоверности токена указывает способ аутентификации, ассоциированный с платежным токеном.
20. Серверный компьютер по п. 19, в котором способ аутентификации содержит по меньшей мере одно из следующего: без аутентификации, аутентификация в сети или аутентификация эмитентом.
Способ приготовления лака | 1924 |
|
SU2011A1 |
Способ приготовления лака | 1924 |
|
SU2011A1 |
Колосоуборка | 1923 |
|
SU2009A1 |
СПОСОБ СОВЕРШЕНИЯ ПЛАТЕЖНЫХ ОПЕРАЦИЙ ПОЛЬЗОВАТЕЛЯМИ МОБИЛЬНЫХ УСТРОЙСТВ ЭЛЕКТРОННОЙ СВЯЗИ И КОМПЬЮТЕРНАЯ СИСТЕМА БЕЗНАЛИЧНОГО РАСЧЕТА ДЛЯ ЕГО ОСУЩЕСТВЛЕНИЯ | 2003 |
|
RU2263347C2 |
Авторы
Даты
2019-03-06—Публикация
2014-07-24—Подача