Должны ли быть теги 9f27 (

[Dedock]

Добрый вечер, всем.

С недавних пор начали отлавливать у себя на хосте чиповые операции по своим картам без тега 9F27 -Cryptogram Information Data. Как оказалось, это один из ключевых тегов в 55 поле, которое парсит наш хост, и естественно, не "увидев" 9F27, не хочет обрабатывать операцию. Речь идет о картах Виза. Нигде в документации Визы не говорится о том, что 9F27 должен быть обязательным в 1100-м сообщении. Мало того, Виза его то шлет, то не шлет... Поставщик же нашего софта хостовой части утверждает обратное. С их слов тег должен быть... Люди, кто что может посоветовать? Действительно ли он (9F27 ) должен быть или нет? Мы не выпускаем чиповые карты Мастер, поэтому не знаем как у них с этим дело обстоит. Кто-то может поделиться опытом?

Спасибо.

[DcCtrl]

Здравствуйте.

У нас была похожая ситуация - карточка VISA, тег 9F27 - не передавался. Операции проходили успешно.
Совет - пусть разработчики хоста укажут официальный документ и страницу, где написано, что поле 9F27 - M.

[BAT]

Dedock,
EMV 4.2 Book 4 "The CID does not need to be forwarded to the issuer; the presence of this data element is defined in the respective payment system network interface specifications."
В спецификацифх VISA требования включения 9F27 в 55-е поле не встречал.
Правда, и VISA и EMVCo говорят об обмене хоста с ПС. Обмен терминала с хостом происходит в соответствии с хостовыми протоколами. И здесь во многих протоколах этот тэг указывается как обязательный. Вопрос зачем, если его не обязхательно передавать в ПС, это уже к разработчикам этих протоколов, но терминал должен формировать сообщения в соответствии с этими хостовыми протоколами, а не требованиями EMVCo или платежных систем.

[Dedock]

Спасибо всем за ответы. Попробуем доказать свою правоту документацией.

У меня у вам еще вопрос по тегу 91(IAD). Я перечитал массу документации, в том числе и книгу Голдовского, кажется. Поэтому, плз, не отправляйте, меня искать в доках ответ - мне нужно услышать ответы людей, которые уже с этим сталкивались и работают. Так вот, IAD - это то, что шлется в ответе с хоста терминалу. Терминал же, проверив, что на карте в AIP стоит бит Issuer Authentication is supported, шлет карте команду External Authenticate c IAD, а дальше уже карта решает что делать, т.е. давать ААС или ТС. НО! Я сам видел операции, в ответе которых уходило далеко не IAD, а тоже самое 55 поле, что и в запросе и операция при этом быда успешной.... Люди, как такое может быть? Объясните, плз, почему пос... или карта в этом случае не деклайнят операцию?

Надеюсь, что я правильно выразился.

[BAT]

Объясните, плз, почему пос... или карта в этом случае не деклайнят операцию?

Каких-то противоречий требованиям EMV тут не видно.
Если эмитент не возвращает Issuer Authentication Data (91 тег), то логично, что эмитированная им же карта не станет отклонять на этом основании одобренную операцию.
И тем более в ней не должно быть в AIP бита Issuer Authentication is supported. Иначе получится, что правая рука не знает. что делает левая.
Что касается терминала. то для него вообще не предусмотрено механизма требовать отклонения операции в GenAC2, если она была одобрена хостом. Даже если команда External Authenticate завершилась провалом, терминал лишь взводит соответствующий бит в TVR.

[nick_st]

Dedock,
1. 9F27 обязателен в MasterCard (Banknet), но не обязателен VISA, а хост у Вас работатет по некому общему протоколу с терминалом и соответственно пока (на уровне приема сообщения) не
знает что это за карта VISA или MasterCard. Поэтому разработчики просто решили требовать этот тег всегда - имеют права - т.к. терминальный протокол не специфицирется EMV, VISA, MasterCard и т.д.
2. Обычно, если на второй криптограмме карта отбивает операцию (не генерирует TC), то хост посылает реверс операции (либо не выгружает - если Dual Message)... в принципе
это настраивается при сертификации эквайера как обрабатываются операции - Host based Capture (ARQC), Terminal based Capture (TC)

[Dedock]

nick_st,
Разработчики, конечно, имею право делать то, что им захочется, но все-таки они должны следовать спецификациям платежных систем и EMV.

BAT,
Хм... Что же в этом логичного-то? Некий мошеннический подставной хост пошлет ответ карте в котором нет ни слова о IAD и она одобряет при этом операцию. И это по вашему есть логично? Это во-первых. Во-вторых, почему не должно быть бита в AIP бита Issuer Authentication is supported? Наши карты как раз только с этим битом и выпускаются.

[nick_st]

Разработчики, конечно, имею право делать то, что им захочется, но все-таки они должны следовать спецификациям платежных систем и EMV.

Дело в том, что терминал не знает платежную систему карты - поэтому посылается все по максимуму...

[BAT]

Dedock, , логично не то, что эмитент не отправляет Issuer Authentication Data, а то, что если уж он не отправляет, то его же карта не должна на это реагировать отказом. Если эмитент не использует заложенных в стандарт EMV возможностей по безопасности проведения транзакций, то это печально. Но, поскольку за результат чиповых транзакций ответственность несет эмитент, то это его риски. Жаль только его клиентов.
А насчет "не должно быть бита в AIP бита Issuer Authentication is supported", то это относилось к таким эмитентам. Если в ответе от хоста не будет 91-го тэга, то терминал всё равно не выдаст команду External Authenticate, даже при наличии такого бита. И для чего он тогда?