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

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

Настоящая заявка испрашивает преимущество и приоритет по дате подачи Европейской патентной заявки № 15181148.6, поданной 14 августа 2015 г., полное содержание которой включено в настоящий документ посредством ссылки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Способ может дополнительно содержать этапы, на которых платежный терминал: принимает упомянутый запрос транзакции вторичного платежного устройства; в ответ на это определяет, что принятое 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, к платежной сети для совершения упомянутой транзакции; вслед за посыланием упомянутого запроса, содержащего FPAN, к упомянутой платежной сети принимает сообщение о неудаче транзакции первичного устройства от платежной сети; и в ответ на это добавляет FSP в список отказа, сохраненный на платежном терминале; затем платежный терминал: принимает упомянутый запрос транзакции вторичного платежного устройства; в ответ на это определяет, что принятое FSP присутствует в упомянутом списке отказа; и в ответ на это отклоняет упомянутый запрос транзакции вторичного платежного устройства.

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

Согласно седьмому аспекту обеспечен способ, содержащий этапы, на которых платежный терминал: принимает запрос транзакции вторичного платежного устройства, содержащий основной номер счета устройства (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, к платежной сети для совершения упомянутой транзакции; и вслед за посыланием упомянутого запроса, содержащего FPAN, к упомянутой платежной сети принимает сообщение об одобрении транзакции первичного устройства от платежной сети.

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

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

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

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

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

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

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

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

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

фиг.2A изображает поток сообщений;

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

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

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

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

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

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

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

фиг.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), которое идентично для каждого платежного устройства, привязанного к счету, и которое проверяется каждый раз, когда платежное устройство используется.

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

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

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

Вслед за таким добавлением в список отказа клиент 310 может пытаться использовать вторичное платежное устройство 312B, чтобы осуществить платеж тому же самому продавцу 320. Однако терминал затем автоматически проверяет FSP, и когда находит его, сверяет его со списком отказа. При нахождении соответствия платежный терминал останавливает клиента 310 от получения продукта или услуги, к которым он пытался осуществить доступ. Это может, например, осуществляться посредством предупреждения для оператора терминала или того, что вход в транспортный сервис остается закрытым.

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

Если после добавления 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 источника финансирования платежного устройства.

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

Фиг.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), специализированные или совместно используемые процессоры и/или другие аппаратные модули или устройства.