Verifone 510 + CTLS 1000SE ошибка Z1 при оплате "телефоном".

[SEU86]

Zverg_077 Подскажите а где вы расшифровываете Tag82? В доступных мне источниках данный бит обозначен как RFU.
Проверил, ключи с индексами 04, 05, 06 загружены

[norad]

Application Interchange Profile
Byte 1
b8 RFU
b7 SDA Supported
b6 DDA supported
b5 Cardholder verification is supported
b4 Terminal risk management is to be performed
b3 Issuer Authentication is supported
b2 On device cardholder verification is supported
b1 CDA supported
Byte 2
b8 EMV mode is supported
b7-2 Each bit RFU
b1 Relay resistance protocol is supported

Находится в книге EMV Contactless Book C-2, Application Interchange Profile. Взято с сайта EMVCO.com

[Zverg_077]

SEU86 Тогда странно, почему во всех случаях *DA проваливается. Проведите пожалуйста операцию по обычной контактной карте MasterCard. Сообщите значение tag 9F34.

Про AIP: Актуальные описания значений для MC приведены в документе "M/Chip Personalization Data Specifications - For Contact and Contactless". Если ваш Банк является участником этой ПС, у вас должен быть доступ к такой документации.

[SEU86]

Значение тега 9F34 - 440302

[Zverg_077]

440302 - криптованный пин с чипа, успешно проверен. Из этого следует, что с RSA у терминала всё ок.
Честно говоря, у меня уже кончаются идеи относительного того, почему проваливается CDA. Попробуйте временно прописать TAC Default - F850ACA000 и проведите операцию по *Pay-сервису. Сообщите результат.

[SEU86]

Прописал TAC Default - F850ACA000. Та же ошибка Z1 невозможно провести операцию в бесконтактном режиме.

[Zverg_077]

Хорошо, попытаюсь найти у коллег Unipos Config Manager, пошагово сверим настройки.

Добавлено спустя 4 часа 48 минут 14 секунд:
Re: Verifone 510 + CTLS 1000SE ошибка Z1 при оплате "телефоном".
Добрался до UCMC, проверьте свои настройки. С этой конфигурацией работает любой *Pay.
Платежные системы - Ключи EMV:

1-keys.png

Профиль терминала:

2-term.png

Карточный продукт:

3-card.png

[SEU86]

Zverg_077 Большое спасибо, за помощь и столь подробный ответ. Но ситуация не поменялась, как была ошибка Z1, так и осталась. Куда копать уже не знаю. Все что можно было проверить проверил, теперь в тупике.

[Zverg_077]

Я бы посоветовал в этом случае обратится к вендору, т.е. в Инпас. Возможно, есть ошибка обработки CDCVM на уровне прикладного приложения.
Ещё вариант: если есть возможность, снять лог APDU с помощью Collis и запостить его в эту тему.

[SEU86]

Collis у нас нет, буду писать в поддержку Инпаса. Если будет решение проблемы отпишусь тут.

[Zverg_077]

Да, отпишитесь. Интересно, в чём заключается проблема.

[norad]

Кстати была у меня недавно похожая проблема, но всё же она с несколько другим продуктом приключилась. Однако есть вариант, что решение может совпасть. Давайте с вами попробуем так:
1. tac decline выставим на нули и tcap сделаем такого вида — ** ** *0
2. Если не сработает, можно временно отключить ключ с индексом 05 и посмотреть, вдруг чего изменилось.

[Zverg_077]

1. tac decline выставим на нули и tcap сделаем такого вида — ** ** *0

Если судить по фото настроек, TAC denial и так нулевой. По поводу Capabilities - с отключенным CDA действительно может уйти онлайн, с битом о невыполненном DA.
Однако решение годится только для экспериментов.Т.к. по правилам MC tag 95 является обязательным для передачи в DE55, а поддержка CDA - обязательна для данного POS Type.
См. Chapter 4 Acquirer Requirements из документа "M/Chip Requirements For Contact and Contactless" 28 September 2017.

p.s. П.2 излишен, т.к. достаточно просто отключить CDA в 9F33.

[WalkmanUfa]

Мне кажется что Action Codes тут ни причем.
Denial пустые, значит безусловного отказа не будет.
Отказ будет если сработал AC Online терминал ответил что не может провести операцию онлайн, и если в AC Default прописан тот же флаг что и сработал в AC Online.

Непонятен 9F10
9F10 (issuer application data)
Key Derivation index 02
Cryptogram version number 15
Card verification results
Byte 1 Bit 8 = 1, Byte 1 Bit 7 = 0 Second Generate AC not requested
Byte 1 Bit 6 = 0, Byte 1 Bit 5 = 0 AAC Returned in First Generate AC
Byte 1 Bit 3 = 1 Offline PIN Verification Performed
Byte 1 Bit 1 = 1 Offline PIN Verification Successful
Byte 3 Bits 8-5 Right nibble of Script Counter = 0
Byte 3 Bits 4-1 Right nibble of PIN Try Counter = 0
Byte 4 Bit 7 = 1 Unable To Go Online Indicated
Byte 4 Bit 2 = 1 Domestic Transaction
DAC/ICC Dynamic Number 2 Bytes 0000
Plaintext/Encrypted Counters 00000000000000FF

[norad]

См. Chapter 4 Acquirer Requirements из документа "M/Chip Requirements For Contact and Contactless" 28 September 2017.

Где вы эту доку нашли? У себя вижу только максимум 16-го года

[WalkmanUfa]

Где вы эту доку нашли? У себя вижу только максимум 16-го года

На MC Connect скорее всего.

[Zverg_077]

Где вы эту доку нашли?

На MC Connect, разумеется.

Мне кажется что Action Codes тут ни причем.

Склоняюсь к тому, что дело именно в них. Обратите внимание, по любому бесконтакту проваливается CDA. А на "телефоне" IAC - Online, Byte1,bit3 = 0 (Do not go online if Combined DDA/AC Generation failed). Соот-но, судя по всему карта отвечает AAC`ом на ARQC.
Другой вопрос, что непонятна причина провала CDA. С сертификатами у терминала всё ок, что подтверждается операцией по контактному MChip. Можно было бы предположить, что карта сформировала неверный SDAD, однако коллега говорит, что на других терминалах такой проблемы нет. Соот-но, предположительно ошибка на уровне конфигурации терминала.

[WalkmanUfa]

Не соглашусь. на сканах чеков
IAC Online в Samsung Pay FFFFFFFFFF
IAC Online в Android Pay 0060000000
а результат тот же - Z1

PS Работает действительно везде кроме наших терминалов. ТС сидит напротив Сидим, ждем что скажет Инпас...

[Zverg_077]

Вероятно, в SamsungPay "сыграл" TAC Default. Но это не отменяет и не объясняет причины провала CDA по любому бесконтакту.
Думаю действительно, окончательно прояснить ситуацию сможет только Инпас.

[WalkmanUfa]

Вероятно, в SamsungPay "сыграл" TAC Default. Но это не отменяет и не объясняет причины провала CDA по любому бесконтакту.

В Андроид пей TAC Default не сыграл получается? Я пока вижу что CDA проваливается всегда но это не мешает провести операцию по живой карте и в приложении Тинькофф.
Я делаю вывод что провал CDA прямой роли не играет на появление Z1.
Получается есть два отдельных вопроса:
1. Почему не работает S-Pay, A-Pay
2. Почему проваливается CDA