English

Эквайринг: EMV-транзакция (EMV Transaction Flow). Часть 5: READ RECORDS

7 декабря 2020 8653 Просмотров

Введение

Предлагаем вашему вниманию очередной материал о «EMV Transaction flow», который посвящен команде READ RECORDS. В рамках статьи разберем примеры чтения данных контактной чиповой карты Mastercard.

GPO RESPONSE

Напомним, что описанные нами в предыдущих материалах этапы EMV Transaction Flow выглядят так:

  1. ATR
  2. Select (1PAY.SYS.DDF01), попытка выбора через PSE. Если отказ, то:
  3. Select (AID), выбор через PSA. Если один апплет, то процедура заканчивается, переход к следующему шагу. Если два апплета, то:
  4. Application select в ручном или автоматическом режиме.
  5. Get Processing Options с PDOL или без него.

Следующим шагом является APDU-R (ответ) на команду Get Processing Options.

Пример:

Response: 770E82023900940828010401300102009000

Tag 77: Response Message Template Format 2 — формат представления данных в ответе.

Tag 82: Application Interchange Profile: 3900 —​ профиль приложения карты с описанием ее функциональных возможностей. По байтам:

  • Byte 1 bit 8 = 0 RFU — зарезервирован для будущего использования.
  • Byte 1 bit 7 = 0 Offline static data authentication is NOT supported — не поддерживается SDA-оффлайн.
  • Byte 1 bit 6 = 1 Offline dynamic data authentication is supported — поддерживается DDA-оффлайн.
  • Byte 1 bit 5 = 1 Cardholder verification is supported — поддерживается верификация держателя карты.
  • Byte 1 bit 4 = 1 Terminal risk management is to be performed — должна быть выполнена процедура управления рисками.
  • Byte 1 bit 3 = 0 Issuer authentication is supported using GENERATE AC command — поддерживается аутентификация эмитента с использованием генерации криптограммы транзакции.
  • Byte 1 bit 2 = 0 On device cardholder verification is NOT supported — не поддерживается верификация держателя карты на мобильном устройстве.
  • Byte 1 bit 1 = 1 Combined DDA / GENERATE AC supported — поддерживается DDA (динамическая аутентификация) вместе с генерацией криптограммы.
  • Byte 2 bit 8 = 0 Only Mag Stripe profile supported —​ не поддерживается исключительный режим магнитной полосы.

Остальные биты второго байта зарезервированы для будущего использования.

Терминал анализирует объект AIP и сравнивает его с третьим байтом своего объекта 9F33 (Terminal Capabilities), после чего выбирается взаимно-поддерживаемый способ аутентификации карты.

Следом за объектом AIP терминалу передается ключевой в рамках команды Read Records элемент - Tag 94 ((AFL) Application File Locator). Данный объект содержит ссылки на линейные файлы карточного приложения, которые терминалу следует прочитать.

Приведем пример его структуры:

AFL = 28010401

28 —​ SFI (Short File Identifier), 28 = decimal 5.

01 —​ номер первой записи SFI

04 —​ номер последней записи SFI

01 —​ число записей для ODA (Offline Data Authentication), т.е. для проверки подлинности карты.

READ RECORDS

Далее терминал направляет команду Read Records в соответствии с ранее полученным AFL. Пример:

Term: 00B2012C00 (Read Record (SFI 05, record 01))

Cla: 00 —​ класс команды

Ins: B2 —​ код инструкции

P1: 01

P2: 2C

Lc: 00

Data:

То есть, терминал читает первую запись в пятом SFI. Рассмотрим находящиеся в ней данные, проанализировав APDU-R карты:

Read Record response (OK): 70818C9F420206435F25031603015F24032011305A0855702956266780855F3401029F0702FF008C219F02069F03069F1A0295055F2A029A039C019F37049F35019F45029F4C089F34038D0C910A8A0295059F37049F4C088E14000000000000000042014403410342031E031F039F0D05BC50BC88009F0E0500000800009F0F05BC70BC98005F280206439F4A01829000

По байтам это:

Tag 70: Application Elementary File (AEF) Data Template

Tag 9F42: Application Currency Code: 0643 —​ код валюты приложения, рубли.

Tag 5F25: Application Effective Date: 160301 —​ дата выпуска карты, 2016, март, 1-е число.

Tag 5F24: Application Expiration Date: 201230 —​ срок действия карты, 2020, декабрь, 30-е число.

Tag 5A: Application Primary Account Number (PAN): 5512345678918085 — собственно, номер карты.

Tag 5F 34: Application PAN Sequence Number: 02 —​ последовательный номер карты. Изначально задумывался в целях использования в профилях, имеющих более одного приложения на одной физической карте. В настоящее время часто используется в криптографических процедурах, связанных с проверкой подлинности карты эмитентским хостом.

Tag 9F07: Application Usage Control (AUC): FF00 —​ элемент, в котором перечисляются возможности использования карты, определенные эмитентом. В нашем случае они таковы:

  • Byte 1 bit 8 = 1 - Valid for domestic cash transactions — разрешены местные (т.е., внутри страны или «доместиковые») операции получения наличных.
  • Byte 1 bit 7 = 1 - Valid for international cash transactions — разрешены зарубежные операции получения наличных.
  • Byte 1 bit 6 = 1 - Valid for domestic goods — разрешены местные операции оплаты товаров.
  • Byte 1 bit 5 = 1 - Valid for international goods — разрешены зарубежные операции оплаты товаров.
  • Byte 1 bit 4 = 1 - Valid for domestic services — разрешены местные операции оплаты услуг.
  • Byte 1 bit 3 = 1 - Valid for international services — разрешены зарубежные операции оплаты услуг.
  • Byte 1 bit 2 = 1 - Valid at ATMs —​ разрешены операции в банкоматах.
  • Byte 1 bit 1 = 1 - Valid at terminals other than ATMs — разрешено использовать в других устройствах (например, в терминалах самообслуживания и т.д.).
  • Byte 2 bit 8 = 0 - Domestic cashback not allowed — не разрешен местный кэшбек.
  • Byte 2 bit 7 = 0 - International cashback not allowed — не разрешен кэшбек зарубежом.

Остальные биты второго байта зарезервированы для будущего использования.

Таким образом по AUC наглядно видно, как можно (и нельзя) использовать данную карты. Предположим, если попытаться получить по ней наличные на кассе при покупке (т.е. кэшбек), транзакция будет отклонена без обращения к эмитенту с оффлайновым кодом ответа Z1.

Далее в рассматриваемой записи присутствуют объекты CDOL1 и CDOL2. CDOL (Card Risk Management Data Object List) — это набор данных необходимых карте для формирования первой (CDOL1) и второй (CDOL2) криптограмм транзакции (Следует заметить, что мы рассматриваем именно контактный чип. При обмене по бесконтактному интерфейсу вторая криптограмма не используется, следовательно CDOL2 в обмене не участвует). Последовательно рассмотрим оба объекта CDOL.

Tag 8C: Card Risk Management Data Object List 1: 9F02069F03069F1A0295055F2A029A039C019F37049F35019F45029F4C089F3403

Как уже говорилось, здесь перечисляются данные, необходимые карте для формирования первой криптограммы. По байтам это:

Tag 9F02, длина 06: Transaction Amount —​ сумма операции.

Tag 9F03, длина 06: Cashback Amount —​ сумма кэшбек.

Tag 9F1A, длина 02: Terminal Country Code —​ код страны терминала.

Tag 95, длина 05: Terminal Verification Results (TVR) —​ объект данных, в который записываются результаты различных проверок (ODA, CVM и многих других), выполненных терминалом (В дальнейшем TVR будет описан при рассмотрении соответствующего этапа EMV-обмена).

Tag 5F2A, длина 02: Transaction Currency Code —​ код валюты транзакции.

Tag 9A, длина 03: Transaction Date —​ дата транзакции.

Tag 9C, длина 01: Transaction Type —​ тип транзакции.

Tag 9F37, длина 04: Unpredictable Number (UN) —​ случайное число, генерируемое терминалом в целях обеспечения уникальности криптограммы операции.

Tag 9F35, длина 01: Terminal Type —​ тип терминала.

Tag 9F45, длина 02: Data Authentication Code (DAC) —​ объект, участвующий в процедуре SDA (Static Data Authentication, статическая проверка подлинности карты). В нашем случае будет отправлено нулевое значение, поскольку, как следует из данных в объекте AIP (см. выше), SDA-оффлайн не поддерживается.

Tag 9F4C, длина 08: ICC Dynamic Number (IDN) —​ динамический номер EMV-приложения. Криптографическая временно-зависимая величина, свидетельствующая о том, что терминалом была выполнена процедура оффлайн-DDA (Dynamic Data Authentication, динамическая аутентификация карты).

Tag 9F34, длина 03: Cardholder Verification Method (CVM) Results —​ результат верификации держателя карты.

Иными словами, CDOL1 содержит набор обязательных данных, которые терминал должен отправить карте в команде Generate AC1. В случае, если какие-либо данные будут отсутствовать, операция завершится ошибкой.

CDOL2

Tag 8D: Card Risk Management Data Object List 2: 910A8A0295059F37049F4C08

Для генерации второй криптограммы карте необходим следующий набор данных:

Tag 91, длина до 16 байт: Issuer Authentication Data (IAD) —​ аутентификационные данные эмитента. Криптографическая величина, передаваемая в составе поля 55 ответного сообщения, свидетельствующая о том, что авторизация была выполнена именно эмитентом карты.

Tag 8A, длина 02: Authorization Response Code —​ код ответа эмитента, передаваемый в поле 39 ответного сообщения.

Tag 95, длина 05: Terminal Verification Results (TVR) — уже упоминавшийся выше объект TVR.

Tag 9F37, длина 04: Unpredictable Number (UN) — уже упоминавшийся выше объект UN.

Tag 9F4C, длина 08: ICC Dynamic Number (IDN) — уже упоминавшийся выше объект IDN.

В случае, если какой-то из этих объектов будет отсутствовать в команде Generate AC2, транзакция будет отклонена картой, а терминал должен будет сформировать автоматическую отмену.

CVM-лист

Следующий элемент данных, присутствующий в рассматриваемой записи —​ CVM-лист. Объект содержит перечисление поддерживаемых картой способов верификации держателя, а также условия их применения и сценарии использования. Его также следует рассмотреть подробно в рамках следующего примера.

Tag 8E: Cardholder Verification Method (CVM) List:

  • 000000000000000042014403410342031E031F03
  • Amount X = 00000000
  • Amount Y = 00000000

CVM 1: 4201 (Enciphered PIN verified online) —​ первый метод, шифрованный ПИН-онлайн. Условия его применения:

  • Byte 1 bit 8 = 0 (default value)
  • Byte 1 bit 7 = 1 (Apply succeeding CVM field if this CVM is unsuccessful)
  • Byte 1 bit 6-1= 000010 (Enciphered PIN verified online)
  • Byte 2 = '01' (If unattended cash) —​ т.е., данный метод должен применяться при обслуживании в банкоматах.

CVM 2: 4403 (Enciphered PIN verification performed by ICC) —​ второй метод, шифрованный оффлайн-ПИН. Условия применения:

  • Byte 1 bit 8 = 0 (default value)
  • Byte 1 bit 7 = 1 (Apply succeeding CVM field if this CVM is unsuccessful)
  • Byte 1 bit 6-1= 000100 (Enciphered PIN verification performed by ICC)
  • Byte 2 = '03' (If terminal supports the CVM type) —​ метод применяется в случае его поддержки терминалом. Иначе — переход к следующему методу.

CVM 3: 4103 (Plaintext PIN verification performed by ICC) —​ третий метод, оффлайновый ПИН-код открытым текстом. Условия применения:

  • Byte 1 bit 8 = 0 (default value)
  • Byte 1 bit 7 = 1 (Apply succeeding CVM field if this CVM is unsuccessful)
  • Byte 1 bit 6-1= 000001 (Plaintext PIN verification performed by ICC)
  • Byte 2 = '03' (If terminal supports the CVM type) — метод применяется в случае его поддержки терминалом. Иначе — переход к следующему методу.

CVM 4: 4203 (Enciphered PIN verified online) —​ четвертый метод, шифрованный ПИН-онлайн. Условия применения:

  • Byte 1 bit 8 = 0 (default value)
  • Byte 1 bit 7 = 1 (Apply succeeding CVM field if this CVM is unsuccessful)
  • Byte 1 bit 6-1= 000010 (Enciphered PIN verified online)
  • Byte 2= '03' (If terminal supports the CVM type) —​ метод применяется в случае его поддержки терминалом. Иначе — переход к следующему методу.

CVM 5: 1E03 (Signature (paper)) —​ пятый метод, собственноручная подпись держателя на чеке. Условия применения:

  • Byte 1 bit 8 = 0 (default value)
  • Byte 1 bit 7 = 0 (Fail Cardholder Verification if this CVM is unsuccessful))
  • Byte 1 bit 6-1= 011110 (Signature (paper))
  • Byte 2 = '03' (If terminal supports the CVM type) —​ метод применяется в случае его поддержки терминалом. Иначе процедура верификации держателя карты считается проваленной.

Механизм работает следующим образом. Терминал анализирует CVM-лист карты и сравнивает его его со вторым байтом своего объекта 9F33 (Terminal Capabilities), после чего подбирается взаимно-поддерживаемый способ верификации.

Issuer Action Codes

Очередной присутствующий в записи объект, Issuer Action Codes (IAC).

Объект IAC состоит из трех блоков: IAC-Default, IAC-Denial и IAC-Online. Каждый из этих блоков определяет условия, при наступлении которых транзакция будет одобрена либо отклонена в оффлайне, либо будет отправлена на авторизацию эмитенту. Следует сказать, что в конфигурации терминала присутствует собственный объект TAC (Terminal Action Codes) - коды действия терминала, имеющий в точности такую же структуру, что и IAC. В процессе выполнения транзакции эти объекты сравниваются между собой в следующем порядке:

IAC-Denial — TAC-Denial

IAC-Online — TAC-Online

IAC-Default — TAC-Default

На основании анализа формируется результат. Как уже говорилось выше, вариантов три: одобрить в оффлайне (актуально только для терминалов, поддерживающих оффлайн), отклонить в оффлайне, либо отправить на авторизацию эмитенту. Процедура называется Terminal Risk Management (TRM). Заметим, что в рассматриваемом нами примере она обязательна, поскольку байт 1 бит 4 приведенного выше объекта AIP равен 1, из чего следует, что процедура TRM должна быть выполнена.

Рассмотрим последовательно все три блока IAC.

IAC-Denial, Tag 9F0E: 0000080000

  • Byte 1 bit 8 = 0 Do not decline if Offline data authentication was not performed — не отклонять, если ODA не выполнялась.
  • Byte 1 bit 7 = 0 Do not decline if Offline static data authentication failed — не отклонять, если SDA провалена.
  • Byte 1 bit 6 = 0 Do not decline if ICC data missing — не отклонять, если некоторые данные на чипе отсутствуют.
  • Byte 1 bit 5 = 0 Do not decline if Card appears on terminal exception file — не отклонять, если карта находится в файле исключений терминала (фактически стоп-файлы в терминалах в настоящее время не используются).
  • Byte 1 bit 4 = 0 Do not decline if Offline dynamic data authentication failed — не отклонять, если DDA провалена.
  • Byte 1 bit 3 = 0 Do not decline if Combined DDA/AC Generation failed — не отклонять, если CDA провалена.
  • Byte 1 bit 2 = 0 Do not decline if SDA selected — не отклонять, если выбрана SDA.
  • Byte 1 bit 1 = 0 RFU
  • Byte 2 bit 8 = 0 Do not decline if ICC and terminal have different application versions — не отклонять, если карта и терминал имеют разные версии приложения.
  • Byte 2 bit 7 = 0 Do not decline if Expired application — не отклонять, если срок действия приложения истек.
  • Byte 2 bit 6 = 0 Do not decline if Application not yet effective — не отклонять, если срок действия приложения не наступил.
  • Byte 2 bit 5 = 0 Do not decline if Requested service not allowed for card product — не отклонять, если запрошенная операция не разрешена для карты.
  • Byte 2 bit 4 = 0 Do not decline if New card —​ не отклонять, если новая карта.

Биты 3-1 второго байта - RFU.

  • Byte 3 bit 8 = 0 Do not decline if Cardholder verification was not successful — не отклонять, если проверка держателя карты неуспешна.
  • Byte 3 bit 7 = 0 Do not decline if Unrecognised CVM — не отклонять, если CVM неизвестен.
  • Byte 3 bit 6 = 0 Do not decline if PIN Try Limit exceeded — не отклонять, если счетчик попыток ввода ПИН-кода переполнен.
  • Byte 3 bit 5 = 0 Do not decline if PIN entry required and PIN pad not present or not working — не отклонять, если ПИН запрошен, но ПИН-пад отсутствует либо неработоспособен.
  • Byte 3 bit 4 = 1 Decline if PIN entry required, PIN pad present, but PIN was not entered — отклонить, если ПИН был запрошен, но не был введен.
  • Byte 3 bit 3 = 0 Do not decline if Online PIN entered —​ не отклонять, если введен онлайн-ПИН.

Биты 2-1 третьего байта - RFU.

  • Byte 4 bit 8 = 0 Do not decline if Transaction exceeds floor limit — не отклонять, если превышен допустимый лимит для оффлайн-операции.
  • Byte 4 bit 7 = 0 Do not decline if Lower consecutive offline limit exceeded — не отклонять, если превышен превышен нижний лимит последовательных оффлайн-транзакций (актуально только для терминалов, поддерживающих одобрение в оффлайне).
  • Byte 4 bit 6 = 0 Do not decline if Upper consecutive offline limit exceeded — не отклонять, если превышен верхний лимит последовательных оффлайн-транзакций (актуально только для терминалов, поддерживающих одобрение в оффлайне).
  • Byte 4 bit 5 = 0 Do not decline if Transaction selected randomly for online processing — не отклонять, если транзакция выбрана для онлайн-авторизации (актуально только для терминалов, поддерживающих одобрение в оффлайне).
  • Byte 4 bit 4 = 0 Do not decline if Merchant forced transaction online —​ не отклонять, если транзакция принудительно отправляется в онлайн (актуально только для терминалов, поддерживающих одобрение в оффлайне).

Биты 3-1 четвертого байта - RFU.

  • Byte 5 bit 8 = 0 Do not decline if Default TDOL used — не отклонять, если использовался TDOL по-умолчанию.
  • Byte 5 bit 7 = 0 Do not decline if Issuer authentication was unsuccessful — не отклонять, если проверка эмитента неуспешна.
  • Byte 5 bit 6 = 0 Do not decline if Script processing failed before final GENERATE AC — не отклонять, если процедура обработки критичных эмитентских скриптов провалена.
  • Byte 5 bit 5 = 0 Do not decline if Script processing failed after final GENERATE AC —​ не отклонять, если процедура обработки не критичных эмитентских скриптов провалена.

Биты 4-1 пятого байта - RFU.

Из примера понятно, что в блоке IAC-Denial содержится описание условий, при наступлении любого из которых транзакция будет отклонена в оффлайне, без попытки отправить на авторизацию эмитенту. В нашем случае такое условие всего одно - транзакция будет отклонена, если не был введен ПИН-код.

При этом, если IAC-Denial на карте отсутствует, терминал считает что все его биты = 0, т.е. нет ни одного условия, при наступлении которого транзакция должна быть отклонена в оффлайне.

IAC-Online, Tag 9F0F: BC70BC9800

  • Byte 1 bit 8 = 1 Go online if Offline data authentication was not performed — отправить онлайн, если ODA не выполнялась.
  • Byte 1 bit 7 = 0 Do not go online if Offline static data authentication failed — не отправлять онлайн, если SDA провалена.
  • Byte 1 bit 6 = 1 Go online if ICC data missing — отправить онлайн, если некоторые данные на чипе отсутствуют.
  • Byte 1 bit 5 = 1 Go online if Card appears on terminal exception file — отправить онлайн, если карта находится в файле исключений терминала (фактически стоп-файлы в терминалах в настоящее время не используются).
  • Byte 1 bit 4 = 1 Go online if Offline dynamic data authentication failed — отправить онлайн, если DDA провалена.
  • Byte 1 bit 3 = 1 Go online if Combined DDA/AC Generation failed — отправить онлайн, если CDA провалена.
  • Byte 1 bit 2 = 0 Do not go online if SDA selected — не отправлять онлайн, если выбрана SDA.
  • Byte 1 bit 1 = 0 RFU
  • Byte 2 bit 8 = 0 Do not go online if ICC and terminal have different application versions — не отправлять онлайн, если карта и терминал имеют разные версии приложения.
  • Byte 2 bit 7 = 1 Go online if Expired application — отправить онлайн, если срок действия приложения истек.
  • Byte 2 bit 6 = 1 Go online if Application not yet effective — отправить онлайн, если срок действия приложения не наступил.
  • Byte 2 bit 5 = 1 Go online if Requested service not allowed for card product — отправить онлайн, если запрошенная операция не разрешена для карты.
  • Byte 2 bit 4 = 0 Do not go online if New card —​ не отправлять онлайн, если новая карта.

Биты 3-1 второго байта - RFU.

  • Byte 3 bit 8 = 1 Go online if Cardholder verification was not successful — отправить онлайн, если если проверка держателя карты неуспешна.
  • Byte 3 bit 7 = 0 Do not go online if Unrecognised CVM — не отправлять онлайн, если CVM неизвестен.
  • Byte 3 bit 6 = 1 Go online if PIN Try Limit exceeded — отправить онлайн, если счетчик попыток ввода ПИН-кода переполнен.
  • Byte 3 bit 5 = 1 Go online if PIN entry required and PIN pad not present or not working — отправить онлайн, если ПИН запрошен, но ПИН-пад отсутствует либо неработоспособен.
  • Byte 3 bit 4 = 1 Go online if PIN entry required, PIN pad present, but PIN was not entered — отправить онлайн, если ПИН был запрошен, но не был введен.
  • Byte 3 bit 3 = 1 Go online if Online PIN entered —​ отправить онлайн, если был введен онлайн-ПИН.

Биты 2-1 третьего байта - RFU.

  • Byte 4 bit 8 = 1 Go online if Transaction exceeds floor limit — отправить онлайн, если если превышен допустимый лимит для оффлайн-операции.
  • Byte 4 bit 7 = 0 Do not go online if Lower consecutive offline limit exceeded — не отправлять онлайн, если превыше нижний лимит последовательных оффлайн-транзакций (актуально только для терминалов, поддерживающих одобрение в оффлайне).
  • Byte 4 bit 6 = 0 Do not go online if Upper consecutive offline limit exceeded — не отправлять онлайн, если превышен верхний лимит последовательных оффлайн-транзакций (актуально только для терминалов, поддерживающих одобрение в оффлайне).
  • Byte 4 bit 5 = 1 Go online if Transaction selected randomly for online processing — отправить онлайн, если транзакция выбрана для онлайн-авторизации (актуально только для терминалов, поддерживающих одобрение в оффлайне).
  • Byte 4 bit 4 = 1 Go online if Merchant forced transaction online —​ отправить онлайн, если транзакция принудительно отправляется в онлайн (просим прощения за тавтологию, но таковы условия. Актуально только для терминалов, поддерживающих одобрение в оффлайне).

Биты 3-1 четвертого байта - RFU.

  • Byte 5 bit 8 = 0 Do not go online if Default TDOL used — не отправлять онлайн, если использовался TDOL по-умолчанию.
  • Byte 5 bit 7 = 0 Do not go online if Issuer authentication was unsuccessful — не отправлять онлайн, если проверка эмитента неуспешна.
  • Byte 5 bit 6 = 0 Do not go online if Script processing failed before final GENERATE AC — не отправлять онлайн, если процедура обработки критичных эмитентских скриптов провалена.
  • Byte 5 bit 5 = 0 Do not go online if Script processing failed after final GENERATE AC —​ не отправлять онлайн, если процедура обработки не критичных эмитентских скриптов провалена.

Биты 4-1 пятого байта - RFU.

Из примера понятно, что в блоке IAC-Online содержится описание условий, при наступлении любого из которых транзакция должна быть отправлена на авторизацию эмитенту.

При этом, если IAC-Online на карте отсутствует, терминал считает, что все его биты = 1, т.е. транзакцию необходимо отправить онлайн в любом случае.

IAC-Default, Tag 9F0D: B450848000

  • Byte 1 bit 8 = 1 Reject if unable to process online and if Offline data authentication was not performed — отклонить, если онлайн невозможен, и если ODA не выполнялась.
  • Byte 1 bit 7 = 0 Do not reject if unable to process online and if Offline static data authentication failed — не отклонять, если онлайн невозможен, и если SDA провалена.
  • Byte 1 bit 6 = 1 Reject if unable to process online and if ICC data missing — отклонить, если онлайн невозможен, и если некоторые критичные данные на чипе отсутствуют.
  • Byte 1 bit 5 = 1 Reject if unable to process online and if Card appears on terminal exception file — отклонить, если онлайн невозможен и карта находится в файле исключений терминала (фактически стоп-файлы в терминалах в настоящее время не используются).
  • Byte 1 bit 4 = 0 Do not reject if unable to process online and if Offline dynamic data authentication failed — не отклонять, если онлайн невозможен и если DDA провалена.
  • Byte 1 bit 3 = 1 Reject if unable to process online and if Combined DDA/AC Generation failed — отклонить, если онлайн невозможен, и если CDA провалена.
  • Byte 1 bit 2 = 0 Do not reject if unable to process online and if SDA selected — не отклонять, если онлайн невозможен и если выбран метод SDA.
  • Byte 1 bit 1 = 0 RFU
  • Byte 2 bit 8 = 0 Do not reject if unable to process online and if ICC and terminal have different application versions — не отклонять, если онлайн невозможен и если карта и терминал имеют разные версии приложения.
  • Byte 2 bit 7 = 1 Reject if unable to process online and if Expired application — отклонить, если онлайн невозможен и если карточное приложение просрочено.
  • Byte 2 bit 6 = 0 Do not reject if unable to process online and if Application not yet effective — не отклонять, если онлайн невозможен, и если срок действия приложения не наступил.
  • Byte 2 bit 5 = 1 Reject if unable to process online and if Requested service not allowed for card product — отклонить, если онлайн невозможен, и если запрошенная операция не разрешена для карты.
  • Byte 2 bit 4 = 0 Do not reject if unable to process online and if New card —​ не отклонять, если онлайн невозможен, и если это новая карта.

Биты 3-1 второго байта - RFU.

  • Byte 3 bit 8 = 1 Reject if unable to process online and if Cardholder verification was not successful — отклонить, если онлайн невозможен, и если процедура проверки держателя неуспешна.
  • Byte 3 bit 7 = 0 Do not reject if unable to process online and if Unrecognised CVM — не отклонять, если онлайн невозможен, и если CVM неизвестен.
  • Byte 3 bit 6 = 0 Do not reject if unable to process online and if PIN Try Limit exceeded — не отклонять, если онлайн невозможен, и если счетчик попыток ввода ПИН-кода переполнен.
  • Byte 3 bit 5 = 0 Do not reject if unable to process online and if PIN entry required and PIN pad not present or not working — не отклонять, если онлайн невозможен, и если ПИН запрошен, но ПИН-пад отсутствует либо неработоспособен.
  • Byte 3 bit 4 = 0 Do not reject if unable to process online and if PIN entry required, PIN pad present, but PIN was not entered — не отклонять, если онлайн невозможен, и если ПИН запрошен, но не был введен.
  • Byte 3 bit 3 = 1 Reject if unable to process online and if Online PIN entered —​ отклонить, если онлайн невозможен, и если был введен онлайн-ПИН.

Биты 2-1 третьего байта - RFU.

  • Byte 4 bit 8 = 1 Reject if unable to process online and if Transaction exceeds floor limit — отклонить, если онлайн невозможен, и если превышен допустимый лимит для оффлайн-операции.
  • Byte 4 bit 7 = 0 Do not reject if unable to process online and if Lower consecutive offline limit exceeded — не отклонять, если онлайн невозможен, и если превышен превышен нижний лимит последовательных оффлайн-транзакций (актуально только для терминалов, поддерживающих одобрение в оффлайне).
  • Byte 4 bit 6 = 0 Do not reject if unable to process online and if Upper consecutive offline limit exceeded — не отклонять, если онлайн невозможен, и если превышен превышен верхний лимит последовательных оффлайн-транзакций (актуально только для терминалов, поддерживающих одобрение в оффлайне).
  • Byte 4 bit 5 = 0 Do not reject if unable to process online and if Transaction selected randomly for online processing — не отклонять, если онлайн невозможен, и если транзакция выбрана для онлайн-авторизации (актуально только для терминалов, поддерживающих одобрение в оффлайне).
  • Byte 4 bit 4 = 0 Do not reject if unable to process online and if Merchant forced transaction online —​ не отклонять, если онлайн невозможен, и если транзакция принудительно отправляется в онлайн (актуально только для терминалов, поддерживающих одобрение в оффлайне).

Биты 4-1 четвертого байта - RFU.

  • Byte 5 bit 8 = 0 Do not reject if unable to process online and if Default TDOL used — не отклонять, если онлайн невозможен, и если использовался TDOL по-умолчанию.
  • Byte 5 bit 7 = 0 Do not reject if unable to process online and if Issuer authentication was unsuccessful — не отклонять, если онлайн невозможен, и если проверка эмитента неуспешна.
  • Byte 5 bit 6 = 0 Do not reject if unable to process online and if Script processing failed before final GENERATE AC — не отклонять, если онлайн невозможен, и если процедура обработки критичных эмитентских скриптов провалена.
  • Byte 5 bit 5 = 0 Do not reject if unable to process online and if Script processing failed after final GENERATE AC —​ не отклонять, если онлайн невозможен, и если процедура обработки не критичных эмитентских скриптов провалена.

Биты 4-1 пятого байта - RFU.

Из примера понятно, что в блоке IAC-Default содержится описание сценариев для терминалов, у которых (временно либо постоянно) отсутствует возможность выполнить онлайн-авторизацию. При наступлении любого из приведенных выше условий операция будет отклонена.

При этом, если IAC-Default на карте отсутствует, терминал считает что все его биты = 1, т.е. для терминалов с отсутствием возможности онлайн-обмена все условия = «отклонить».

Необходимо указать, что результаты анализа TACs-IACs записываются терминалом в объект TVR, который также участвует в формировании криптограммы (повторимся, что TVR будет подробно описан в рамках следующих материалов по «EMV Transaction Flow»).

Таким образом, в рамках команды Read Records терминал получил такие важные данные карты, как CDOLs, CVM-лист, IACs и другие. Все они так или иначе будут использованы в рамках дальнейшего обмена. О чем и расскажем в будущих статьях.

До новых материалов!

Наши платежные решения