СПОСОБ ПЕРЕДАЧИ РАСШИРЕННОГО НАБОРА ДАННЫХ ОТ БЕСКОНТАКТНОГО ПЛАТЕЖНОГО УСТРОЙСТВА К ТЕРМИНАЛУ

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

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

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

Изначально безналичный способ оплаты подразумевал под собой предъявление в точке продаж пластиковой платежной карты с микропроцессором и/или магнитной полосой для считывания платежной пластиковой карты POS-терминалом для проведения транзакции.

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

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

Из предшествующего уровня техники известно техническое решение, отраженное в патенте Российской Федерации №2427917 «Устройство, система и способ сокращения времени взаимодействия при бесконтактной транзакции», опубликованного 27 августа 2011 года, в котором раскрыт способ, направленный на сокращение времени взаимодействия при бесконтактной транзакции, при котором обеспечивается повышенная безопасность проведения транзакции за счет аутентификации данных в динамическом режиме. Если аутентификация данных в динамическом режиме успешно завершена, то POS-терминал разрешает одобрить бесконтактную транзакцию в автономном режиме.

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

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

2. разборе и выделении необходимых объектов данных из электронного журнала терминала для рассматриваемой транзакции;

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

4. проверке корректности формата сертификатов банка-эмитента и платежного устройства;

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

6. проверке присутствия сертификата банка-эмитента в списке отозванных сертификатов;

7. проверке факта совпадения идентификатора банка-эмитента - BIN в сертификате банка-эмитента с первыми цифрами PAN платежного устройства.

Наиболее близким аналогом к заявляемому способу является решение, описанное в международной заявке WO 2013177416 «Системы, методы и программное обеспечение для обеспечения бесконтактного протокола», опубликованной 28 ноября 2013 года, в котором приведен метод, заключающийся во взаимодействии между платежным устройством и терминалом по бесконтактному протоколу связи; загрузке, хранении и обновлении объектов данных, содержащих коммерческую информацию например, информация о скидках, специальных предложениях, вознаграждениях, предоставляемых торгово-сервисным предприятием, в коммерческом приложении, которое представляет собой программное обеспечение, загруженное и выполняемое в элементе безопасности, встроенном в платежное устройство; использовании платежного приложения, представляющее собой программное обеспечение, загруженное и выполняемое в элементе безопасности, встроенном в платежное устройство в целях проведения платежной транзакции; предоставлении коммерческой информации терминалу коммерческим приложением; обработке коммерческой информации терминалом с целью применения специальных условий выполнения транзакции (например, применение скидки); предоставлении специальных условий выполнения транзакции держателю платежного устройства.

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

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

Раскрытие изобретения.

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

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

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

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

на рис. 1 приведена в общем виде архитектура компонентов, участвующих в реализации способа;

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

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

на рис. 4.1 и рис. 4.2 приведена схема алгоритма установки признаков неуспешного завершения процедуры офлайновой аутентификации платежного приложения.

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

В реализации предложенного способа участвуют (рис. 1) как минимум, но не ограничиваясь, платежное устройство (5), держатель платежного устройства (4), POS-терминал (2), ридер (3), выполняющий функцию считывающего устройства и может быть использован в виде отдельного устройства, так и встроенным в POS-терминал, и банк-эквайрер (1), обслуживающий POS-терминал (2). Платежное устройство (5) и POS-терминал (2) поддерживают, в том числе, бесконтактный режим взаимодействия.

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

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

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

Платежное устройство отвечает на этот запрос посредством списка доступных приложений и для каждого приложения приводит идентификатор приложения AID (Application Identifier). POS-терминал выбирает одно из списка этих приложений посредством команды (например, SELECT AID). POS-терминал выбирает AID платежного приложения с высшим приоритетом в общем списке. Все последующие обмены данными осуществляются между POS-терминалом и выбранным платежным приложением до тех пор, пока POS-терминал не посылает новую команду выбора.

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

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

После выбора платежного приложения (например, SELECT AID) POS-терминал подает команду инициализации транзакции (например, GET PROCESSING OPTIONS или PERFORM TRANSACTION), с помощью которой POS-терминал сообщает платежному устройству данные, необходимые для того, чтобы определиться с профилем выполнения транзакции. В зависимости от выбранного профиля в ответе на команду инициализации транзакции платежное устройство сообщает POS-терминалу о своих возможностях по выполнению транзакции (о поддержке методов аутентификации устройства и верификации держателя карты, а также способе аутентификации банка-эмитента) и требованиях к POS-терминалу по необходимости выполнения им процедуры управления рисками. Кроме того, в этом же ответе платежное устройство указывает платежному терминалу данные (в виде ссылок на названия файлов и номера их записей), которые терминал должен прочитать для того, чтобы успешно выполнить транзакцию.

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

На рис. 2 приведена общая схема взаимодействия платежного устройства с ридером и POS-терминалом, которые для удобства обозначены на рис. 2 как «платежный терминал», для реализации первого варианта осуществления способа с использованием отдельной команды генерации криптограммы, при котором ридер направляет первую команду (100) выбора вспомогательного приложения с целью запроса от платежного устройства списка имеющихся в нем платежных приложений.

Платежное устройство отвечает на этот запрос списком (101) доступных приложений с идентификаторами AID. Ридер выбирает (102) из списка (101) поддерживаемое ридером платежное приложение с наивысшим приоритетом и после выбора платежного приложения (102) ридером платежное приложение формирует и направляет ридеру набор данных (103), содержащий список требуемых платежному приложению данных и набор дополнительных данных, таких как идентификационный номер карты (PAN) и/или идентификатор банка-эмитента и/или идентификатор клиента системы лояльности банка и/или другие данные, необходимые для определения признака участия держателя платежного устройства в системе предоставления специальных условий обработки транзакций. POS-терминал выполняет процедуру (104), заключающуюся в определении факта участия держателя платежного устройства в системе предоставления специальных условий обработки транзакций, применении специальных условий обработки транзакции и вычислении финального значения суммы транзакции. Затем ридер направляет команду инициализации транзакции (105), передавая в том числе, но не ограничиваясь, размер и тип транзакции, а также реквизиты POS-терминала (например, тип терминала, его возможности по обработке транзакции).

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

Затем ридер направляет команду создания криптограммы (108), отправляя транзакционные данные платежному приложению, для подписи финальной суммы (109) транзакции платежным приложением.

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

Во втором варианте осуществления способа, показанного на рис. 3, взаимодействие платежного устройства и ридера с POS-терминалом, которые для удобства обозначены на рис. 3 как «платежный терминал», происходит похожим образом что и в первом варианте реализации способа, однако функции команды инициализации транзакции (105) и создания криптограммы (108) совмещены в одной команде (205).

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

Платежное устройство отвечает на этот запрос списком (201) доступных приложений с идентификаторами AID. Ридер выбирает (202) из списка (201) поддерживаемое ридером платежное приложение с наивысшим приоритетом, и после выбора платежного приложения (202) ридером платежное приложение формирует и направляет ридеру набор данных (203), содержащий список требуемых платежному приложению данных и набор дополнительных данных, таких как идентификационный номер карты (PAN) и/или идентификатор банка-эмитента и/или идентификатор клиента системы лояльности банка и/или другие данные, необходимые для определения признака участия держателя платежного устройства в системе предоставления специальных условий обработки транзакций. POS-терминал выполняет процедуру (204), заключающуюся в определении факта участия держателя платежного устройства в системе предоставления специальных условий обработки транзакций, применении специальных условий обработки транзакции и вычислении финального значения суммы транзакции. Затем ридер направляет команду инициализации транзакции и формирования криптограммы (например, GET PROCESSING OPTIONS или PERFORM TRANSACTION) (205), передавая транзакционные данные в том числе, но не ограничиваясь, размер и/или тип транзакции, а также реквизиты POS-терминала (например, тип терминала, его возможности по обработке транзакции).

При этом, в этом варианте реализации способа при обработке команды инициализации и формирования криптограммы платежное приложение выполняет: выбор профиля обработки транзакции (206) платежным приложением, в котором платежное приложение выбирает наиболее оптимальный сценарий обработки транзакции, используя финальные параметры транзакции, полученные от ридера и настроек платежного приложения; формирование криптограммы (206), используя в том числе, но не ограничиваясь, транзакционные данные и реквизиты терминала; возврат (207), в зависимости от выбранного профиля, требований к POS-терминалу по верификации держателя, способу авторизации платежной транзакции; опционально возврат набора ссылок (207) на записи данных платежного приложения, которые необходимо прочитать ридеру для выполнения текущей транзакции (например, с помощью команд READ RECORD).

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

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

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

В рамках реализации способа взаимодействия платежного устройства и POS-терминала предложен гибкий алгоритм метода верификации держателя платежного устройства. Зачастую при проведении транзакции держатель платежного устройства не может вспомнить значение секретного ПИН-кода или возможна ситуация, в которой держатель, сомневающийся в надежности ТСП или подозревает, что осуществляется слежение за POS-терминалом с целью получения значения ПИН-кода держателя, не намерен вводить ПИН-код на клавиатуре POS-терминала в ТСП. Из-за ошибочного ввода значений возможен отказ в обработке платежного устройства ридером POS-терминала. Предлагаемый метод позволяет при выборе ридером метода верификации держателя платежного устройства «online PIN», в случае отказа держателя платежного устройства от ввода ПИН-кода с помощью заранее определенного параметра, указывающего на разрешения банка-эмитента использовать метод верификации держателя платежного устройства «Signature», заключающийся в предоставлении держателем платежного устройства личной подписи, завершить транзакцию с использованием метода верификации держателя платежного устройства «Signature».

Предлагаемый механизм реализуется по следующему сценарию:

- платежное устройство передает значение параметра, например, такого как: «CVM Fallback to Signature allowed)) в ответ на команду инициализации транзакции, например, PERFORM TRANSACTION или GET PROCESSING OPTIONS, вместе с транзакционными данными платежного устройства;

- ридер выбирает в качестве метода верификации держателя платежного устройства метод «online PIN»;

- держатель платежного устройства отказывается от ввода ПИН-кода на POS-терминале, например, не помнит значение ПИН-кода или не доверяет ТСП или окружающей среде;

- ридер анализирует значение параметра «CVM Fallback to Signature allowed)). В случае, если параметр указывает на то, что банк-эмитент разрешает использовать в качестве метода верификации метод «Signature)), POS-терминал проводит процедуру верификации держателя платежного устройства, используя в качестве метода верификации держателя платежного устройства предоставление держателем платежного устройства личной подписи;

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

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

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

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

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

1. признак отсутствия необходимых для процедуры офлайновой аутентификации объектов данных, таких как: сертификаты банка-эмитента и платежного устройства, индекс публичного ключа удостоверяющего центра, публичная экспонента платежного устройства и т.д. Рассматриваемый признак может быть установлен в процессе чтения вышеперечисленных данных ридером, при передаче на платежное устройство команды чтения данных, например, READ RECORD с указанием ссылок на записи данных, полученных в ответ на команду инициализации платежной транзакции, с целью получения значений элементов данных, необходимых для проведения процедуры офлайновой аутентификации данных, в случае, если хотя бы один из объектов данных не был прочитан с платежного устройства;

2. признак отсутствия соответствующего публичного ключа УЦ платежной системы в ридере. Данный признак устанавливается на этапе выбора открытого ключа УЦ, заключающегося в поиске в реестре ключей ридера определенного значения ключа, соответствующего прочитанному с платежного устройства индексу открытого ключа УЦ и идентификатору платежной системы (RID), с платежным приложением которой осуществляется взаимодействие, в случае, если такой ключ в ридере отсутствует;

3. признак ошибки распаковки (нарушение формата данных) сертификата банка-эмитента. Рассматриваемый признак устанавливается в процессе проверки формата сертификата банка-эмитента, заключающемся в проверке на соответствие определенных значений сертификата банка-эмитента с заранее детерминированными в спецификации константными значениями, в случае выявления несоответствия;

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

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

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

7. признак ошибки распаковки (нарушение формата данных) сертификата банка-эмитента. Рассматриваемый признак устанавливается в процессе проверки формата сертификата банка-эмитента, заключающемся в проверке на соответствие определенных значений сертификата банка-эмитента с заранее детерминированными в спецификации константными значениями, в случае выявления несоответствия;

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

При этом, на рис. 4.1. и 4.2. приведен алгоритм установки признаков неуспешного завершения процедуры офлайновой аутентификации платежного приложения, где осуществляется проверка наличия необходимых объектов данных (301) для процедуры офлайновой аутентификации платежного приложения (ODA).

Если необходимые объекты данных для процедуры ODA отсутствуют (301), то устанавливается признак отсутствия необходимых для ODA объектов данных (302), иначе осуществляется переход к шагу проверки (303), при котором, если в ридер не загружен публичный ключ удостоверяющего центра (303), то требуется установить признак отсутствия соответствующего публичного ключа УЦ платежной системы в ридере (304).

Если при проверке загрузки публичного ключа УЦ (303) признак ошибки не установлен, то требуется перейти к расшифрованию сертификата банка-эмитента (305), при которой осуществляется проверка на соответствие определенных значений сертификата банка-эмитента (306) с заранее детерминированными в спецификации константными значениями. Если выявлено несоответствие, то требуется установить признак ошибки распаковки (307) сертификата банка-эмитента, иначе осуществляется проверка (308) срока действия сертификата банка-эмитента платежного устройства, при которой если установлено, что срок действия сертификата истек, устанавливается признак (309), иначе переход ко второй части алгоритма (310).

Если хотя бы один из признаков был установлен (302) или (304) или (307) или (309), то переход к установке признака неуспешного завершения процедуры ODA (319).

Вторая часть алгоритма начинается с осуществления проверки (310) на совпадение значения идентификатора банка-эмитента BEST и соответствующих первых цифр PAN платежного устройства, при котором, если выявлено несовпадение требуется установить признак (311), иначе перейти к шагу (312) проверки наличия значения серийного номера сертификата банка-эмитента в списке отозванных сертификатов POS-терминала, при которой, в случае наличия значения серийного номера сертификата банка-эмитента в списке отозванных сертификатов, устанавливается признак (313), иначе происходит расшифровка сертификата платежного устройства (314), при которой осуществляется проверка на соответствие определенных значений сертификата платежного приложения (315) с заранее детерминированными в спецификации константными значениями. Если выявлено несоответствие, то требуется установить признак (316) ошибки распаковки сертификата платежного устройства, иначе осуществляется проверка (317) динамической подписи (SDAD) платежного устройства, при которой ридер осуществляет проверку длины SDAD, восстанавливает данные SDAD, проверяет формат SDAD, сравнивает тип криптограммы, извлеченный из подписи с типом криптограммы, полученным от платежного устройства, вычисляет значение хэш-функции от транзакционных данных, сравнивает посчитанное значение хэш-функции с восстановленным из подписи значением. При проведении вышеперечисленных процедур, в случае окончания проверки (317) с признаком выявления несоответствия и возникновения ошибки (318) требуется установить признак (319) неуспешного завершения процедуры ODA. В случае установки как минимум одного признака, требуется также установить признак (319) неуспешного завершения процедуры ODA.

Рассмотренные признаки устанавливаются в вышеперечисленных процессах и записываются в дополнительный объект данных, например CDA Results, а значения и/или описание каждого признака могут быть отображены на чеке, экране или сохранены в электронный журнал POS-терминала. Что приводит к более эффективному анализу причины неуспешного завершения процедуры офлайновой аутентификации данных для своевременного устранения причины и повышения устойчивости платежной системы в целом.

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

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