Чиповая операция Pin-change

Софт от SCS, ЕГПО, APTRA, видеонаблюдение и т.д
Mirs
Прохожий
Сообщения: 1
Зарегистрирован: 20 июн 2013, 06:40
Авто: DAZ

Чиповая операция Pin-change

Непрочитанное сообщение Mirs »

Здравствуйте, уважаемые господа!
Хочу реанимировать тему "многопроходные чиповые транзакции".
Банкомат NCR, AANDC 3.4.2., операция Pin-Change по чиповой карте.
Перед отправкой запроса эмитенту делается три прохода между банкоматом и хостом ПЦ:
запрос с кодом операции, состояние ввода нового пина, состояние подверждения нового пина. Каждый проход требует отправки чиповых данных. Приходится вставлять стейты для переинициализации чипа. Ощущение, что это неправильно.
Можно ли настроить банкомат, чтобы для такой операции чип был инициализирован только один раз?

И второй вопрос: если в ответе эмитента послан неверный скрипт для смены пина, банкомат все равно завершает операцию успешным стейтом, и реверс не происходит, подскажите, в какую сторону копать? Заранее благодарен за полезный совет.
booby
Специалист
Сообщения: 391
Зарегистрирован: 21 янв 2013, 07:14
Поблагодарили: 1 раз

Re: Чиповая операция Pin-change

Непрочитанное сообщение booby »

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

По второму вопросу - проверьте конфигурационные параметры, в частности, бит 3 (Solicited script errors are not included) для CAM/EMV Extended Status option 69.
Linux
Новичок
Сообщения: 17
Зарегистрирован: 25 июн 2013, 18:44

Re: Чиповая операция Pin-change

Непрочитанное сообщение Linux »

На банкоматах NCR замечательно работает стейт 'b', который позволяет подтверждать ввод нового ПИН и отправлять в одном запросе старый и новый ПИН-блок. Переходите на его использование. Всё остальное от лукавого.
valcore
Прохожий
Сообщения: 3
Зарегистрирован: 22 янв 2014, 01:43

Re: Чиповая операция Pin-change

Непрочитанное сообщение valcore »

Linux писал(а):стейт 'b'
Плюсую.
По поводу многопроходных - это уж как на хосте решите. У нас был опыт такой реализации, первые два запроса делали без EMV, но и на хосте они никак не обрабатывались, а последнюю - да, с EMV данными, на неё же вешали все авторизационные проверки и вообще всю логику (то есть, если клиент ввёл неверный пин, то об этом станет известно только после того, как он ввёдет новый пин и будет ждать успешной транзакции).
Mirs писал(а):неверный скрипт
Ну если скрипт передаётся в 72 теге, то всё верно, ведь вторая gen AC команда уже выполнена. В этом случае ncr должен послать "успешный" ready B, а потом отдельным unsol сообщением что-то вроде 12...8.c1..
Ответить