УПРАВЛЕНИЕ УНИКАЛЬНОСТЬЮ КЛИЕНТОВ В ТОКЕНИЗИРОВАННЫХ СИСТЕМАХ

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

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

Традиционные модели платежей по картам допускали идентификацию источника финансирования электронных транзакций по причине наличия взаимно-однозначного соответствия между PAN (первичным учетным номером), отображаемым на кредитной или дебетовой карте, и счетом, с которого списываются денежные средства для осуществления транзакций с использованием упомянутой карты. В случае сюръективного отношения (например, совместного счета), детали карты остаются под единоличным управлением эмитента. Однако, с появлением вторичных платежных устройств например, брелоков, наклеек и мобильных устройств с возможностями совершения платежа (смартфонов, планшетов, умных часов и т.д.), это взаимно-однозначное соответствие может утрачиваться, поскольку вторичные платежные устройства могут использовать разные PAN для исходной карты. Вторичные платежные устройства, которые используют токенизированные PAN, будут утрачивать это взаимно-однозначное соответствие. Дело в том, что, по соображениям безопасности, при вводе каждого нового вторичного платежного устройства для обеспечения функциональных возможностей платежа (например, посредством NFC, ближней бесконтактной связи, с платежными терминалами), оно снабжается уникальным токеном, известным как DPAN (PAN устройства), в отличие от FPAN (PAN финансирования) на карте, привязанной к счету. DPAN - это PAN, который устройство передает на терминалы торговца для совершения платежей. Торговые системы не знают, переданы ли им DPAN или FPAN; с их точки зрения платежи обрабатываются одинаково. Однако это означает, что торговцы никак не могут знать, FPAN и один или более DPAN, используемые для совершения транзакций на их терминалах, финансируются с одного и того же счета.

Токенизация также может использоваться для защиты транзакций с помощью чипованной и бесконтактной карты, т.е. когда чипованная или бесконтактная карта осуществляет связь с платежным терминалом, она обеспечивает токенизированный PAN в качестве суррогата для PAN, фактически отпечатанного/вытесненного на карте. В предварительной патентной заявке США № 62/132300, поданной 12 марта 2015 г. описаны системы и способы, позволяющие персонифицировать платежные карты (включая контактные и бесконтактные чипованные платежные карты и мобильные устройства), чтобы можно было использовать платежные токены наряду со стандартными PAN.

В патентной заявке США № 14/514290, поданной 14 октября 2014 г., предложено повысить безопасность токенизированных транзакций за счет обеспечения, совместно с токеном, уровня страхования токенов и данных, используемых для генерирования уровня страхования токенов. Как описано здесь, во время выдачи токена осуществляется один или более способов идентификации и проверки, чтобы гарантировать, что токен заменяет PAN, который на законных основаниях использовался запросчиком токена, и уровень страхования токенов назначается соответственно.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

Согласно первому аспекту предусмотрен способ идентификации источника финансирования электронной транзакции, причем согласно упомянутому способу платежный терминал: принимает запрос транзакции, содержащий одни или более учетных данных, от платежного устройства; и определяет, содержат ли упомянутые учетные данные посредник источника финансирования (FSP), и, если нет, генерирует FSP из одних или более из упомянутых учетных данных согласно заранее определенному алгоритму, хранящемуся на упомянутом платежном терминале; причем FSP получается из первичного учетного номера финансирования (FPAN) источника финансирования упомянутого платежного устройства.

Способ может дополнительно содержать: сверку FSP со списком; и отклонение или санкционирование запроса транзакции в зависимости от того, присутствует ли FSP в списке.

Согласно второму аспекту предусмотрен способ блокировки электронной транзакции, причем согласно упомянутому способу платежный терминал: принимает запрос транзакции, содержащий одни или более учетных данных, от платежного устройства; определяет, содержат ли упомянутые учетные данные посредник источника финансирования (FSP), и, если нет, генерирует FSP из одних или более из упомянутых учетных данных согласно заранее определенному алгоритму, хранящемуся на упомянутом платежном терминале; определяет, что упомянутый FSP присутствует в черном списке, хранящемся на платежном терминале; и отклоняет упомянутый запрос транзакции; причем FSP выводится из первичного учетного номера финансирования (FPAN) источника финансирования упомянутого платежного устройства.

Согласно третьему аспекту предусмотрен способ блокировки электронной транзакции, причем согласно упомянутому способу платежный терминал: принимает запрос транзакции, содержащий одни или более учетных данных, от платежного устройства; определяет, содержат ли упомянутые учетные данные посредник источника финансирования (FSP), и, если нет, генерирует FSP из одних или более из упомянутых учетных данных согласно заранее определенному алгоритму, хранящемуся на упомянутом платежном терминале; определяет, что упомянутый FSP отсутствует в белом списке, хранящемся на платежном терминале; и отклоняет упомянутый запрос транзакции; причем FSP выводится из первичного учетного номера финансирования (FPAN) источника финансирования упомянутого платежного устройства.

Согласно четвертому аспекту предусмотрен способ санкционирования электронной транзакции, причем согласно упомянутому способу платежный терминал: принимает запрос транзакции, содержащий одни или более учетных данных, от платежного устройства; определяет, содержат ли упомянутые учетные данные посредник источника финансирования (FSP), и, если нет, генерирует FSP из одних или более из упомянутых учетных данных согласно заранее определенному алгоритму, хранящемуся на упомянутом платежном терминале; определяет, что упомянутый FSP отсутствует в черном списке, хранящемся на платежном терминале; и санкционирует упомянутый запрос транзакции; причем FSP выводится из первичного учетного номера финансирования (FPAN) источника финансирования упомянутого платежного устройства.

Согласно пятому аспекту предусмотрен способ санкционирования электронной транзакции, причем согласно упомянутому способу платежный терминал: принимает запрос транзакции, содержащий одни или более учетных данных, от платежного устройства; определяет, содержат ли упомянутые учетные данные посредник источника финансирования (FSP), и, если нет, генерирует FSP из одних или более из упомянутых учетных данных согласно заранее определенному алгоритму, хранящемуся на упомянутом платежном терминале; определяет, что упомянутый FSP присутствует в белом списке, хранящемся на платежном терминале; и санкционирует упомянутый запрос транзакции; причем FSP выводится из первичного учетного номера финансирования (FPAN) источника финансирования упомянутого платежного устройства.

Согласно шестому аспекту предусмотрен способ, согласно которому платежный терминал: принимает запрос транзакции первичного устройства, содержащий первичный учетный номер финансирования (FPAN) источника финансирования; в качестве реакции на это, генерирует посредник источника финансирования (FSP) из упомянутого FPAN согласно заранее определенному алгоритму, хранящемуся на платежном терминале; в качестве реакции на это, определяет, что упомянутый сгенерированный FSP отсутствует в черном списке, хранящемся на платежном терминале; в качестве реакции на это, санкционирует упомянутый запрос транзакции первичного устройства; выдает запрос, содержащий FPAN, в платежную сеть для урегулирования упомянутой транзакции; после выдачи упомянутого запроса, содержащего FPAN, в упомянутую платежную сеть, принимает сообщение неудачной транзакции первичного устройства из платежной сети; и в качестве реакции на это, добавляет FSP в упомянутый черный список; после чего, платежный терминал: принимает запрос транзакции вторичного платежного устройства, содержащий первичный учетный номер устройства (DPAN) и FSP; определяет, что принятый FSP присутствует в черном списке; и отклоняет упомянутый запрос транзакции вторичного платежного устройства.

Согласно седьмому аспекту предусмотрен способ, согласно которому платежный терминал: принимает запрос транзакции первичного устройства, содержащий первичный учетный номер финансирования (FPAN) источника финансирования; в качестве реакции на это, генерирует посредник источника финансирования (FSP) из упомянутого FPAN согласно заранее определенному алгоритму, хранящемуся на платежном терминале; в качестве реакции на это, определяет, что упомянутый сгенерированный FSP присутствует в белом списке, хранящемся на платежном терминале; в качестве реакции на это, санкционирует упомянутый запрос транзакции первичного устройства; выдает запрос, содержащий FPAN, в платежную сеть для урегулирования упомянутой транзакции; после выдачи упомянутого запроса, содержащего FPAN, в упомянутую платежную сеть, принимает сообщение неудачной транзакции первичного устройства из платежной сети; и в качестве реакции на это, удаляет FSP из упомянутого белого списка; после чего, платежный терминал: принимает запрос транзакции вторичного платежного устройства, содержащий первичный учетный номер устройства (DPAN) и FSP; определяет, что принятый FSP отсутствует в белом списке; и отклоняет упомянутый запрос транзакции вторичного платежного устройства.

Согласно восьмому аспекту предусмотрен способ предоставления устройству возможности совершения платежей, причем упомянутый способ содержит снабжение упомянутого устройства первичным учетным номером устройства (DPAN) и посредником источника финансирования (FSP), полученным из первичного учетного номера финансирования (FPAN) источника финансирования согласно заранее определенному алгоритму.

Согласно девятому аспекту предусмотрен способ, согласно которому вторичное платежное устройство: принимает первичный учетный номер устройства (DPAN) и посредник источника финансирования (FSP), полученный из первичного учетного номера финансирования (FPAN) источника финансирования согласно заранее определенному алгоритму; и передает запрос транзакции вторичного платежного устройства, содержащий упомянутый DPAN и упомянутый FSP, на платежный терминал.

DPAN и FSP могут приниматься в подписанной или зашифрованной записи.

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

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

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

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

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

Согласно способу, после добавления FSP в черный список, платежный терминал может дополнительно: принимать запрос транзакции первичного устройства, содержащий упомянутый FPAN; в качестве реакции на это, генерировать FSP из принятого FPAN согласно упомянутому заранее определенному алгоритму, хранящемуся на платежном терминале; в качестве реакции на это, определять, что упомянутый сгенерированный FSP присутствует в черном списке; и в качестве реакции на это, отклонять упомянутый запрос транзакции первичного устройства.

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

Согласно способу, платежный терминал может дополнительно, после приема упомянутого сообщения одобренной транзакции вторичного платежного устройства: принимать запрос транзакции первичного устройства, содержащий упомянутый FPAN; в качестве реакции на это, генерировать FSP из принятого FPAN согласно упомянутому заранее определенному алгоритму, хранящемуся на платежном терминале; в качестве реакции на это, определять, что упомянутый сгенерированный FSP отсутствует в черном списке; и в качестве реакции на это, санкционировать упомянутый запрос транзакции первичного устройства.

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

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

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

Согласно десятому аспекту предусмотрен способ, согласно которому платежный терминал: принимает запрос транзакции вторичного платежного устройства, содержащий первичный учетный номер устройства (DPAN) и посредник источника финансирования (FSP), выведенный из первичного учетного номера финансирования (FPAN) источника финансирования согласно заранее определенному алгоритму; в качестве реакции на это, определяет, что FSP отсутствует в черном списке, хранящемся на платежном терминале; и, в качестве реакции на это, санкционирует упомянутый запрос транзакции вторичного платежного устройства.

Согласно одиннадцатому аспекту предусмотрен способ, согласно которому платежный терминал: принимает запрос транзакции вторичного платежного устройства, содержащий первичный учетный номер устройства (DPAN) и посредник источника финансирования (FSP), выведенный из первичного учетного номера финансирования (FPAN) источника финансирования согласно заранее определенному алгоритму; в качестве реакции на это, определяет, что FSP присутствует в белом списке, хранящемся на платежном терминале; и, в качестве реакции на это, санкционирует упомянутый запрос транзакции вторичного платежного устройства.

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

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

Согласно способу, после добавления FSP в черный список, платежный терминал может дополнительно: принимать запрос транзакции первичного устройства, содержащий упомянутый FPAN; в качестве реакции на это, генерировать FSP из принятого FPAN согласно упомянутому заранее определенному алгоритму, хранящемуся на платежном терминале; в качестве реакции на это, определять, что упомянутый сгенерированный FSP присутствует в черном списке; и в качестве реакции на это, отклонять упомянутый запрос транзакции первичного устройства.

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

Согласно способу, платежный терминал может дополнительно, после приема упомянутого сообщения одобренной транзакции вторичного платежного устройства: принимать запрос транзакции первичного устройства, содержащий упомянутый FPAN; в качестве реакции на это, генерировать FSP из принятого FPAN согласно упомянутому заранее определенному алгоритму, хранящемуся на платежном терминале; в качестве реакции на это, определять, что упомянутый сгенерированный FSP отсутствует в черном списке; и в качестве реакции на это, санкционировать упомянутый запрос транзакции первичного устройства.

Согласно способу, платежный терминал может дополнительно, после приема упомянутого сообщения одобренной транзакции вторичного платежного устройства: принимать запрос транзакции первичного устройства, содержащий упомянутый FPAN; в качестве реакции на это, генерировать FSP из принятого FPAN согласно упомянутому заранее определенному алгоритму, хранящемуся на платежном терминале; в качестве реакции на это, определять, что упомянутый сгенерированный FSP присутствует в белом списке; и в качестве реакции на это, санкционировать упомянутый запрос транзакции первичного устройства.

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

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

Упомянутые учетные данные согласно любому из аспектов с первого по пятый может содержать один или более из: PAN финансирования (FPAN), PAN устройства (DPAN), даты окончания действия и серийного номера.

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

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

Упомянутый заранее определенный алгоритм согласно любому из аспектов может генерировать FSP таким образом, что: упомянутый FPAN нельзя определить из FSP; и/или с каждым возможным значением упомянутого FPAN однозначно соотнесен отдельный FSP. Заранее определенный алгоритм может содержать криптографическую хэш-функцию.

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

FSP согласно любому из аспектов может быть ссылкой на платежный счет (PAR), определение которой дано в спецификациях EMVCo.

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

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

фиг. 1 - иллюстративная система многосторонних платежных транзакций;

фиг. 2A - поток сообщений;

фиг. 2B - другой поток сообщений;

фиг. 3A - разблокирование вторичного устройства для платежей;

фиг. 3B - использование первичного платежного устройства на платежном терминале;

фиг. 3C - последующее пробное использование вторичного платежного устройства;

фиг. 3D - блок-схема операций процедуры после представления платежного устройства терминалу;

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

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

фиг. 6A - блок-схема операций иллюстративного способа;

фиг. 6B - блок-схема операций другого иллюстративного способа; и

фиг. 7 - пример системы которая облегчает обработку платежных транзакций на платежных терминалах.

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

На фиг. 1 показана иллюстративная система 100 многосторонних платежных транзакций, позволяющая клиенту 110 (например, владельцу карты, пользователю и пр.) совершать платеж по карте или аналогичные транзакции в пользу торговца 120 (например, транзитного агентства). Эмитент 150, обычно финансовая организация, например, банк, устанавливает для клиента 110 клиентский счет 114 и сохраняет и обновляет данные, связанные с этим счетом, например, в базе данных 152. Эмитент 150 также снабжает клиента 110 платежным устройством 112, например, кредитной, дебетовой, предоплаченной или коммерческой картой и/или ее эквивалентом в связи с клиентским счетом 114.

Платежная транзакция инициируется, когда клиент 110 использует платежное устройство 112 для предложения оплаты покупки от торговца 120, обычно на терминале торговой точки (POS) (не показан). Затем требуется ряд обменов между сторонами, изображенными на фиг. 1 для выполнения транзакции. Эти обмены, в целом, можно рассматривать как проводимые за четыре этапа: (1) взаимодействие с устройством чтения карты, (2) санкционирование, (3) клиринг и (4) урегулирование (где этапы (2) и (3) могут происходить одновременно).

На этапе взаимодействия с устройством чтения карты, торговец 120 захватывает (считывает, принимает и т.п.) учетные данные платежного устройства от платежного устройства 112. Например, клиент 110 может поднести свою бесконтактную платежную карту или мобильное платежное устройство с возможностью NFC к устройству чтения с возможностью NFC из состава терминала POS, чтобы терминал POS мог считывать учетные данные платежного устройства, включающие в себя информацию счета клиента, с чипа, защитного элемента или Безопасной среды исполнения (TEE), внедренного(ой) в платежное устройство 112, либо из памяти устройства в случае эмуляции карты на хосте (также известной как облачные платежи).

На этапе санкционирования подтверждаются подлинность клиентского счета, аутентичность платежного устройства 112 и наличие денежных средств на клиентском счете 114. Дополнительно, у некоторых торговцев (включая некоторые транзитные торговцы), терминал проверяет подпись CDA (генерация комбинированного DDA/AC, где DDA означает динамическую аутентификацию данных и AC означает прикладную криптографию). Торговец 120 передает электронными средствами всю или часть информации, захваченной от платежного устройства, на генераторы обработки транзакций банка 130 торговца (или эквайер/обслуживающий банк) для запрашивания санкционирования транзакции. Запрос также может включать в себя сумму транзакции, например, сумму покупки.

Сеть 140 платежной системы, например, сеть обработки платежей MasterCard™, обеспечивает связь между генераторами банка 130 торговца и генераторами эмитента 150, которые, в свою очередь, определяют, санкционировать ли или отклонить платеж. Если эмитент 150 санкционирует платеж, он, соответственно, уменьшает наличие денежных средств на счету 114 клиента и выдает код санкционирования торговцу 120. Код санкционирования передается обратно торговцу 120 через сеть 140 платежной системы и банк 130 торговца.

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

В отношении множественных транзакций с малыми суммами с единичным торговцем, проводимых за относительно короткий период, например, с транзитными платежами (поезда, метро, паром, парковка, сборы и пр.), часто используется несколько другой подход к обработке платежных транзакций. В частности, индивидуальные взносы (например, индивидуальные тарифы) обычно малы, и, таким образом, торговец 120, например, транзитное агентство, может выбирать объединять все транзитные транзакции с участием платежного устройства 112 в течение некоторого периода времени (нескольких часов, дня, выходных, недели, некоторого количества транзакций и т.д.) - именуемого периодом агрегации - до клиринга и урегулирования всех транзакций для итоговой суммы. Индивидуальные взносы объединяются в течение периода агрегации и затем урегулируются в соответствии с правилами сети 140 платежной системы.

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

Пока клиент 110 перемещается, и если этого требуют правила платежной системы, учетные данные платежа, считанные с платежного устройства 112 в точке входа, включаются транзитным агентством 120 в соответствующую транзакцию и передаются банку 130 торговца как часть транзитного запроса агрегации. В свою очередь, банк 130 торговца передает транзитный запрос агрегации в сеть 140 платежной системы, которая передает его эмитенту 150. Эмитент 150 оценивает, может ли начинаться новый период агрегации, и предоставляет свой ответ транзитному агентству 120 через платежную сеть 140 и банк 130 торговца.

Если транзитное агентство 120 принимает ответ санкционирования, указывающий, что запрос агрегации одобрен, транзитное агентство 120 теперь может принимать дополнительные вводы от платежного устройства 112 вокруг транзитной сети и вычислять взносы (тарифы), например, на основании того, где, когда и какой режим транспортировки клиента 110 используется. По истечении периода агрегации (например, клиент 110 накапливает некоторую сумму взносов, проходит некоторый период времени и т.д.), транзитное агентство 120 осуществляет единую транзакцию на сумму, консолидирующую все взносы, накопленные клиентом 110 в течение периода агрегации для очистки и урегулирования в соответствии со стандартными процедурами очистки и урегулирования, установленными сетью 140 платежной системы. Альтернативно, некоторые локальные правила могут позволять транзитному агентству передавать множественные записи очистки относительно одного хорошего санкционирования до подачи пороговой суммы. Например, если торговец является транзитным агентством, в отношении перемещения по карте может выполняться клиринг каждый день, когда используется карта (что уточняет отчеты о состоянии счетов покупателей), пока не будет превышен полный порог агрегации, когда требуется новое санкционирование, чтобы агрегация могла беспрепятственно продолжаться.

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

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

Фиг. 2A демонстрирует поток сообщений, когда клиент 210 использует первичное платежное устройство, например, дебетовую карту 212A, для получения доступа к транзитной системе. На этапе 201 клиент подносит свою карту к платежному терминалу транзитного агентства 220. На этапе 202 (который может осуществляться через несколько минут или часов, если транзитное агентство использует модель отложенного или агрегированного платежа) запрос транзакции подается в банк 230 транзитного агентства. На этапе 203 запрос подается в сеть 240 платежной системы, затем эмитенту 250 карты на этапе 204. Эмитент отклоняет транзакцию, и транзитное агентство узнает от этом через поток 205, 206, 207 сообщений, после чего блокирует дальнейшее перемещение учетных данных платежного устройства, например, путем добавления их в черный список (иначе именуемый отказным списком), хранящийся на каждом терминале, который проверяется при каждом использовании платежного терминала транзитного агентства. Значение, добавляемое в черный список, может представлять, например, код, образованный хешированием PAN с датой окончания срока действия и порядковым номером для генерации значения, уникального для каждого набора учетных данных платежа.

Фиг. 2B демонстрирует почти идентичный поток сообщений, когда клиент 210 использует вторичное платежное устройство, например, смартфон 212B с возможностью платежа посредством NFC, способное совершать платеж с того же счета, что и его карта 212A, для получения доступа к транзитной системе. Единственное различие между потоками сообщений на фиг. 2A и 2B состоит в том, что учетные данные платежа, содержащиеся в сообщениях, связаны с первичным платежным устройством на фиг. 2A (например, содержащим FPAN карты) и вторичным платежным устройством на фиг. 2B (например, содержащим DPAN смартфона). Потоки сообщений, показанные на фиг. 2A и 2B, могут происходить в любом порядке и могут предшествовать, следовать за или перемежаться с одним или более дополнительными аналогичными потоками сообщений, содержащими учетные данные, связанные с дополнительными платежными устройствами того же клиента 210, например, DPAN планшета и/или умных часов и/или наклейки NFC и/или брелока NFC.

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

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

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

FSP можно вычислять из FPAN известным способом (например, посредством хеширования). FSP может предоставляться вторичным платежным устройствам, например смартфонам, помимо или вместо DPAN.

FSP можно сверять со списком, и обеспечение товаров или услуг можно разрешать или отклонять в зависимости от того, присутствует ли FSP в списке.

Например, если клиент транзитной системы получил бесплатную поездку путем поднесения бесконтактной платежной карты к устройству чтения шлюза, которая затем отклоняется, FSP, связанный с этой картой (например, хэш FPAN карты), может добавляться в черный список, доступный всем шлюзам транзитной системы. Если клиент пытается получить дополнительную бесплатную поездку путем поднесения смартфона с возможностями совершения платежа, привязанного к тому же карточному счету, к шлюзу, шлюз блокирует его, поскольку учетные данные, которые смартфон передает на устройство чтения шлюза, включают в себя FSP, внесенный в черный список.

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

Согласно фиг. 3A, когда вторичное платежное устройство 312B можно использовать для платежей, оно принимает полезную нагрузку предоставления из сети 340 платежной системы. Традиционно, эта полезная нагрузка содержит все учетные данные, необходимые для совершения платежей; например, DPAN, дату окончания действия, номер выпуска и т.д. Однако, согласно способу, показанному на фиг. 3A, полезная нагрузка содержит FSP помимо обычных учетных данных.

FSP привязывается к учетным данным первичного платежного устройства, например, генерируется/вычисляется из них согласно заранее определенному алгоритму. Он может представлять собой, например, хэш FPAN, даты окончания срока действия карты и порядкового номера/номера выпуска карты. Альтернативно, он может представлять собой элемент данных ссылки на платежный счет (PAR) разрабатываемый EMVCo, или его аналог. Алгоритм, используемый для вычисления FSP, может быть односторонним; т.е. может быть невозможно/непрактично определять ввод учетных данных из вывода FSP. Он также может генерировать уникальный FSP для каждого FPAN. Полезная нагрузка предоставления может принимать форму подписанной (криптографически защищенной) записи.

Фиг. 3B демонстрирует использование первичного платежного устройства 312A на платежном терминале. Получив учетные данные от любого платежного устройства, терминал 320 торговца проверяет, содержат ли учетные данные FSP. Если нет, как в показанном случае, FSP вычисляется из учетных данных.

Если транзакция затем отклоняется, этот FSP добавляется в черный список. (Черный список - это список учетных данных карты, обычно хранящийся в хешированном формате, использование которых торговец блокирует.) После такого добавления в черный список, клиент 310 может пытаться использовать вторичное платежное устройство 312B для совершения платежа тому же торговцу 320, как показано на фиг. 3C. Однако затем терминал автоматически проверяет FSP и, если находит, сверяет его с черным списком. Обнаружив совпадение, платежный терминал запрещает клиенту 310 получать продукт или услуги, к которому(ой) он пытается получить доступ. Это может осуществляться, например, посредством предупреждения оператору терминала или посредством оставления шлюза к транзитной услуге закрытым.

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

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

Альтернативно, если учетные данные на фиг. 3B обеспечиваются для предоплаты или резервирования товаров или услуг от торговца 320, и эта транзакция/предварительное санкционирование одобрена, то, когда клиент 310 затем приходит к торговцу 320 на фиг. 3C, чтобы забрать эти товары или услуги, он может предъявить свое вторичное платежное устройство 312B для аутентификации себя торговцу 320. Затем терминал автоматически проверяет FSP и, обнаружив его, сверяет его с белым списком (списком FSP, относительно которого товары/услуги зарезервированы или предоплачены). Обнаружив совпадение, платежный терминал позволяет клиенту 310 получить продукт или услугу, к которому(ой) он пытается получить доступ. Это может осуществляться, например, путем указания одобрения оператору терминала, или путем открывания автоматического шлюза к транзитной услуге.

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

Реализация таких процедур FSP не требует никакого изменения современных систем выпуска чипованных карт; каждый раз, когда пластиковая карта представляется устройству чтения, FSP вычисляется как 'первичный' набор учетных данных. Всякий раз, когда устройство предоставляется, FSP всегда персонифицируется на устройство, таким образом, когда он представляется терминалу, FSP обнаруживается и сверяется с черным списком и/или белым списком. Логика санкционирования может оставаться неизменной (т.е. логику FPAN/DPAN изменять не нужно), изменяется только логика устройства чтения.

На фиг. 3D показана блок-схема операций, демонстрирующая логический процесс, задействованный в вышеописанных иллюстративных сценариях. На этапе 301 платежное устройство представляется платежному терминалу. На этапе 302 терминал считывает учетные данные, принятые от платежного устройства. На этапе 303 терминал сверяет FSP с учетными данными. Если ни одного не найдено, то на этапе 303A FSP генерируется из учетных данных. Когда FSP найден или сгенерирован, на этапе 304 он сверяется с черным списком и/или белым списком.

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

На фиг. 4 показана блок-схема операций способа 400 платежного терминала, идентифицирующего источник финансирования электронной транзакции. На этапе 410 терминал принимает запрос транзакции, содержащий одни или более учетных данных, от платежного устройства. На этапе 420 терминал определяет, содержат ли упомянутые учетные данные FSP и, если нет, на этапе 430 генерирует FSP из одних или более из упомянутых учетных данных согласно заранее определенному алгоритму, хранящемуся на терминале, причем FSP получается из FPAN источника финансирования платежного устройства.

На фиг. 5A показана блок-схема операций способа 500A платежного терминала, обрабатывающего электронную транзакцию. На этапе 510A, терминал принимает запрос транзакции, содержащий одни или более учетных данных, от платежного устройства. На этапе 520A терминал определяет, содержат ли упомянутые учетные данные FSP и, если нет, на этапе 530A генерирует FSP из одних или более из упомянутых учетных данных согласно заранее определенному алгоритму, хранящемуся на терминале, причем FSP выводится из FPAN источника финансирования платежного устройства. На этапе 540A, терминал определяет, присутствует ли FSP в черном списке. Если нет, на этапе 551A терминал санкционирует запрос транзакции. Если да, на этапе 552A терминал отклоняет запрос транзакции.

На фиг. 5B показана блок-схема операций способа 500B платежного терминала, обрабатывающего электронную транзакцию. На этапе 510B, терминал принимает запрос транзакции, содержащий одни или более учетных данных, от платежного устройства. На этапе 520B терминал определяет, содержат ли упомянутые учетные данные FSP и, если нет, на этапе 530B генерирует FSP из одних или более из упомянутых учетных данных согласно заранее определенному алгоритму, хранящемуся на терминале, причем FSP выводится из FPAN источника финансирования платежного устройства. На этапе 540B, терминал определяет, присутствует ли FSP в белом списке. Если нет, на этапе 551B терминал санкционирует запрос транзакции. Если да, на этапе 552B терминал отклоняет запрос транзакции.

На фиг. 6A показана блок-схема операций способа 600A. На этапе 601A, вторичное платежное устройство принимает DPAN и FSP, выведенные из FPAN источника финансирования согласно заранее определенному алгоритму. На этапе 602A, вторичное платежное устройство передает первый запрос транзакции, содержащий упомянутый DPAN и упомянутый FSP, на платежный терминал. На этапе 603A, платежный терминал принимает первый запрос транзакции. В качестве реакции на это, на этапе 605A терминал проверяет, присутствует ли FSP в черном списке. Если да, на этапе 606A терминал отклоняет первый запрос транзакции. Если нет, на этапе 607A терминал санкционирует первый запрос транзакции. Затем, на этапе 608A, терминал выдает запрос, содержащий DPAN, в платежную сеть для урегулирования транзакции. Затем, на этапе 609A, платежный терминал принимает сообщение неудачной транзакции, содержащее DPAN (или какие-либо другие данные, идентифицирующие неудачную транзакцию или источник финансирования), из платежной сети. В качестве реакции на это, на этапе 610A терминал добавляет FSP в черный список. Затем, терминал принимает второй запрос транзакции, содержащий FPAN, на этапе 611A. В качестве реакции на это, на этапе 612A терминал генерирует FSP из принятого FPAN согласно упомянутому заранее определенному алгоритму, хранящемуся на терминале. На этапе 613A терминал определяет, что FSP присутствует в черном списке, и отклоняет второй запрос транзакции.

На фиг. 6B показана блок-схема операций способа 600B. На этапе 603B, платежный терминал принимает первый запрос транзакции, содержащий FPAN источника финансирования. В качестве реакции на это, на этапе 604B терминал генерирует FSP из упомянутого FPAN согласно заранее определенному алгоритму, хранящемуся на терминале. На этапе 605B терминал проверяет, присутствует ли FSP в черном списке. Если да, на этапе 606B терминал отклоняет запрос транзакции. Если нет, на этапе 607B терминал санкционирует запрос транзакции. Затем, на этапе 608B, терминал выдает запрос, содержащий FPAN, в платежную сеть для урегулирования транзакции. Затем, на этапе 609B, терминал принимает сообщение неудачной транзакции, содержащее FPAN (или какие-либо другие данные, идентифицирующие неудачную транзакцию или источник финансирования), из платежной сети. В качестве реакции на это, на этапе 610B, терминал добавляет FSP в черный список. Затем, на этапе 611B, терминал принимает дополнительный запрос транзакции, содержащий DPAN и FSP. На этапе 613B, терминал определяет, что FSP присутствует в черном списке, и отклоняет запрос транзакции.

Фиг. 7 демонстрирует пример системы 700, которая обеспечивает обработку платежных транзакций на платежных терминалах. Система 700 включает в себя систему 710 обработки, содержащую процессор(ы) 712, память 714 и устройство(а) 716 хранения. Кроме того, система 710 обработки подключена к устройству(ам) 720 ввода, например, клавиатуре, мыши, сенсорному экрану, микрофону и т.д. и устройству(ам) 725 вывода, например, дисплею, громкоговорителю, световому индикатору и т.д. На устройстве(ах) 716 хранения хранятся операционная система 717, приложение(я) 718 и данные 719.

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

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

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

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

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

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

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

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

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

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

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

Описанные здесь способы, устройства и системы позволяют решить техническую задачу экономичного установления связи между FPAN и одним или более DPAN.