English

Эквайринг: EMV-транзакция (EMV Transaction Flow). Часть 3: GET PROCESSING OPTIONS c PDOL и без него

14 августа 2020 5130 Просмотров

Введение

Третья часть цикла о «EMV Transaction flow» посвящена следующему этапу обмена между устройством и картой, коим является команда GPO (Get Processing Options). Помимо этого, опишем различиях в реализации EMV-ядер в рамках разных Платежных систем.

SELECT RESPONCE и File Control Information (FCI) Template

В предыдущей части цикла мы разобрали технологию выбора доступных приложений. Еще раз перечислим все этапы обмена:

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

То есть, мы остановились на APDU-R (ответе карты / SELECT RESPONCE) на команду Application select (Далее - просто «SELECT»).

В очередной раз подчеркнем, что сценарий работы в рамках контактного и бесконтактного чипов различается. Более того, различия возможны также и в работе контактных чипов, специфицированных разными ПС. Об этом и пойдет речь при рассмотрении данного этапа. Суть различий (в том числе) сводится к содержанию объекта (или тэга) 6F (File Control Information (FCI) Template), который карта передает в ответе на команду SELECT. Рассмотрим его более подробно.

Tag 6F FCI Template содержит в себе базовую информацию о карточном приложении в рамках конкретной ПС. Приведем пример объектов в FCI Template возвращаемых в команде SELECT RESPONCE для контактной чиповой карты VISA, снабдив его пояснениями в необходимых местах:

Tag 6F: File Control Information (FCI) Template

Tag 84: Dedicated File (DF) Name: A0000000031010 — уже известный нам AID

Tag A5: File Control Information (FCI) Proprietary Template

Tag 50: Application Label: 56495341 — имя приложения, текстовое значение «VISA»

Tag 87: Application Priority Indicator: 01 — уже известный нам Индикатор приоритета приложения

Tag 5F2D: Language Preference: 7275656E — предпочтительный «язык общения». Текстовое значение «ruen», т.е. приоритетный язык русский (ru), если не поддерживается, то английский (en)

Tag 9F38: Processing Options Data Object List (PDOL): 9F1A02 — объект PDOL, его назначение опишем ниже

Tag BF0C: File Control Information (FCI) Issuer Discretionary Template

Tag 9F5A: Application Program Identifier: 6006430643 — специфичный тэг ПС Visa, в данном случае описывающий региональную принадлежность карты. По байтам это:

  • Byte 1 bits 8-5 = '0110' Visa CEMEA use
  • Byte 1 bits 4-1 = '0000' Visa regional discretion
  • Bytes 2-3 = 0643 RUB
  • Bytes 4-5 = 0643 Russian Federation
Эквайринг бесконтактные платежи

Для сравнения, приведем аналогичный пример FCI Template, возвращаемый в ответе на команду SELECT для контактной карты Mastercard:

Tag 6F: File Control Information (FCI) Template

Tag 84: Dedicated File (DF) Name: A0000000041010 - AID

Tag A5: File Control Information (FCI) Proprietary Template

Tag 50: Application Label: 4D617374657243617264 — имя приложения, текстовое значение «MasterCard»

Tag 87: Application Priority Indicator: 01 — Индикатор приоритета приложения

Tag 5F2D: Language Preference: 7275656E — предпочтительный «язык общения». Текстовое значение «ruen», т.е. приоритетный язык русский (ru), если не поддерживается, то английский (en)

Tag BF0C: File Control Information (FCI) Issuer Discretionary Template

Tag 9F6E: Third Party Data: 06430000303000 — специфичный тэг ПС Mastercard, в данном случае описывающий региональную принадлежность и «форм-фактор». По байтам это:

  • Bytes 1-2 = 0643 Russian Federation
  • Bytes 3-4 = 0000 Unique Identifier
  • Bytes 5-6 = 3030 Device Type: Card — «форм-фактор», в данном случае карта. У карты, привязанной к какому-либо *Pay-сервису (GPay, ApplePay etc.), эти байты будут другие.
  • Bytes 7-7 Proprietary Data:00

Как видим, информация различается не только специфичными для ПС элементами данных. Ключевое отличие состоит в том, что в FCI Mastercard отсутствует такой объект, как PDOL, в то время как в FCI Visa он присутствует. Остановимся на нем несколько подробнее.

PDOL (Processing Options Data Object List) — необходимый набор параметров, которые устройство должно передать карте для дальнейшей обработки в следующей команде. На карте находится в составе тэга 9F38, что видно из примера выше для карты Visa. Для наглядности разберем его. Итак, значение PDOL = 9F1A02. В «переводе» с TLV мы видим, что это тэг 9F1A длиной 02 байта. Тэг 9F1A — это Terminal Country Code (Код страны, в которой расположено устройство). Таким образом, карта ожидает, что терминал передаст ей информацию о своем местоположении. Соответственно, если этого не произойдет, транзакция будет прекращена. Здесь необходимо заметить, что фактически может случится такая ситуация, что в PDOL будут содержаться некие элементы (тэги), неизвестные устройству. Для таких случаев в рамках спецификаций всех ПС предусмотрен единый алгоритм работы программного обеспечения POS или ATM, который предполагает, что на все «непонятное» необходимо отправлять «0». Конкретно в нашем примере это означает, что если устройство в следующей команде вообще не передаст тэг 9F1A, то обмен будет прекращен. Однако если будет передан тэг 9F1A=020000 (0000 — «нулевой» код страны), то обмен будет продолжен, как и в том случае, если устройство отправит на карту тэг вида 9F1A=020643 (0643 — код РФ). При этом, разумеется, в первом случае с «нулевым» кодом, проблемы могут возникнуть на каком-либо другом этапе обмена.

Такой же алгоритм подразумевается и в отношении других объектов PDOL.

Пример команды GET PROCESSING OPTIONS (GPO) c PDOL, снабженный расшифровкой:

Term: 80A800000483020643 (Get Processing Options)

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

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

P1: 00

P2: 00

Lc: 04

Data: 83020643 — поле данных с тэгом 83, содержащее конкатенацию («сложение») величин в том порядке, в каком они были перечислены в элементе PDOL команды SELECT RESPONCE. В нашем случае это элемент tag 9F1A (Terminal Country Code) длиной 02 байта и значением 0643 (Russian Federation).

Эквайринг для торговой точки

GPO без PDOL

Напомним, что в приведенном выше SELECT RESPONSE FCI Template ПС Mastercard не содержит PDOL. Некоторое время тому назад при обработке такой карты могли бы возникнуть проблемы. Дело в том, что определенная часть разработчиков программного обеспечения для POS или ATM (причем, вторые гораздо чаще) реализовывала логику работы, при которой ПО должно было «положить» в поле «Data» команды GPO набор данных, полученных в PDOL на предыдущем шаге. Очевидно, что при отсутствии на карте PDOL это приводило к коллизиям/отказу в обслуживании. В настоящее время такое поведение устройства уже вряд-ли можно встретить, однако факт имел место быть. Поэтому следует сказать, что PDOL может отсутствовать на карте, и в этом случае команда GET PROCESSING OPTIONS должна выполнятся без параметров.

Пример такой команды:

Term: 80A80000028300 (Get Processing Options)

Cla: 80

Ins: A8

P1: 00

P2: 00

Lc: 02

Data: 8300

То есть, видно что Класс команды = 80, Код инструкции = A8, но поле «Data» с тэгом 83 - нулевой длины.

Таким образом, описанные нами этапы EMV Transaction Flow выглядят так:

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

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

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