Данные ARQ C PDOL и I CC в сообщении ISO 8583

Question

Я успешно сгенерировал ARQ C, выполнив PDOL, требуемый I CC. Для ARQ C требовались следующие теги PDOL.

9F66 TTQ
9F02 Amount Authorised
5F2A Transaction Currency Code
9A Transaction Date
9F37 Unpredictable Number

AID, возвращаемый из I CC

06 01 11 03 A00000 0F83000000000000000000006975A844

Номер версии криптограммы, как указано выше 17 (11 Hex)

Мой вопрос, когда я отправляю транзакцию в банк-эквайер для авторизации через соединение хоста ISO8583 с хост-соединением, в элементе данных, относящемся к I CC, я заполняю только те теги EMV, которые требуются PDOL и тегами ответа, или я отправляю все теги I CC, включая, например, «Результаты проверки терминала», которые не требовались согласно PDOL?

На основании CVN 17 обязательные поля для проверки криптограммы:

9F02 Amount
9F37 Unpredictable Number
9F36 ATC
9F10 CVR

Answer 1

Согласитесь с комментарием от Михала.

Эквайреру требуется гораздо больше EMV-тегов для передачи их на сторону эмитента карты, определения правильного профиля карты и, наконец, проверки криптограммы. Список данных EMV может отличаться в мелких деталях и месте этих значений EMV, передаваемых в сообщении ISO 8583. Обратитесь к спецификации Acquirer ISO 8583.

Краткое описание тегов EMV и других полей, необходимых для Acquirer Interface, вы можете увидеть в спецификации EMV Книга 4, статья «Запрос на авторизацию».

Сохранить в имейте в виду, что бесконтактные карты, такие как Visa PayWave, могут нуждаться в передаче собственных указанных c тегов в зависимости от спецификации бренда карты.

Answer 2

Говоря простым языком, ваша карта создает криптограмму на основе элементов в CDOL (элементы, их порядок и размер будут указаны в документах схемы платежей для каждого CVN) . Таким образом, на стороне эмитента он должен получить те же элементы для проверки криптограммы (и, необязательно, для генерации криптограммы ответа).

Answer 3

К сожалению, это вопрос, который вы должны задать своему приобретателю. Обычно вы заполняете все имеющиеся у вас данные, особенно потому, что некоторые из них могут использоваться для управления рисками, а не для расчета криптограмм. Список обязательных элементов данных обычно длиннее, чем требуется исключительно для генерации криптограммы. Во-вторых, ваше приложение не должно интерпретировать собственные элементы данных, такие как Данные приложения эмитента, если вам не требуется (помните, что существуют другие спецификации приложений карты, и у вас могут возникнуть проблемы с их дифференцированием на стороне принятия). Примечание: AID не IAD, 9F10 не CVR.