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

И второй вопрос: если в ответе эмитента послан неверный скрипт для смены пина, банкомат все равно завершает операцию успешным стейтом, и реверс не происходит, подскажите, в какую сторону копать? Заранее благодарен за полезный совет.

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

По второму вопросу - проверьте конфигурационные параметры, в частности, бит 3 (Solicited script errors are not included) для CAM/EMV Extended Status option 69.

На банкоматах NCR замечательно работает стейт 'b', который позволяет подтверждать ввод нового ПИН и отправлять в одном запросе старый и новый ПИН-блок. Переходите на его использование. Всё остальное от лукавого.

Linux писал(а):стейт 'b'

Плюсую.
По поводу многопроходных - это уж как на хосте решите. У нас был опыт такой реализации, первые два запроса делали без EMV, но и на хосте они никак не обрабатывались, а последнюю - да, с EMV данными, на неё же вешали все авторизационные проверки и вообще всю логику (то есть, если клиент ввёл неверный пин, то об этом станет известно только после того, как он ввёдет новый пин и будет ждать успешной транзакции).

Mirs писал(а):неверный скрипт

Ну если скрипт передаётся в 72 теге, то всё верно, ведь вторая gen AC команда уже выполнена. В этом случае ncr должен послать "успешный" ready B, а потом отдельным unsol сообщением что-то вроде 12...8.c1..