Разработка для EMV

[Carding 4 Carders]

ID TECH производит и продает широкий спектр платежных устройств, почти все из которых в настоящее время совместимы с «чип-картами» (или «смарт-картами»). Платежи, производимые с помощью чип-карты, обычно называются «контактным EMV» или иногда просто «EMV». (EMV, конечно, означает Europay, MasterCard и Visa; консорциум производителей карт.)

С точки зрения отрасли, транзакция EMV - это транзакция, которая соответствует требованиям четырехтомных спецификаций карт EMV для интегральных схем для платежных систем (доступно на https://www.emvco.com/). Чтобы осмыслить эту спецификацию, нужно время. В четырех томах это довольно обширная спецификация. ID TECH пытается сделать «совместимость с EMV» простой достижимой целью для разработчиков, предлагая различные бесплатные инструменты, SDK, демонстрации и другие ресурсы, предназначенные для ускорения вывода на рынок интеграторов POS-терминалов и других лиц, которые требуется быстрое соответствие требованиям EMV.

3-сторонний картридер ViVOpay VP8300

EMV: С чего начать?​

Большинство новых клиентов ID TECH технически подкованы. Но даже в этом случае степень осведомленности клиентов о EMV в новом проекте сильно различается. Большинство клиентов очень хорошо знакомы с платежными системами в контексте MSR (считывателей магнитных полос). Некоторые раньше работали с EMV, но не знают бесконтактного EMV. Другие новички в самой EMV.

В качестве ориентира мы обычно рекомендуем интеграторам ознакомиться с бесплатным техническим документом ID TECH под названием «Транзакции EMV с универсальным SDK». Первая половина этого 25-страничного технического документа представляет собой напоминание о потоке событий EMV.

На каждом этапе этого процесса устройство чтения карт взаимодействует с чипом смарт-карты, используя некоторые протоколы очень низкого уровня, определенные в ISO-7816. Практически вся логика устройства чтения карт заключена в так называемое ядро EMV Level 2. Другими словами, это недоступно для разработчика платежного приложения, которому нужно беспокоиться только о выдаче команд ядру (а не самой карте). Даже это немного искажение. Разработчик платежного приложения фактически отправляет команды читателю; и считыватель будет обрабатывать необходимые базовые взаимодействия с ядром, которое (в свою очередь) будет взаимодействовать с картой.

Общение с читателем​

Как вы отправляете команды читателю? Есть два варианта:

1. Установите соединение (обычно с помощью USB или RS-232) со считывателем и отправьте ему команды прошивки напрямую. Или иначе:
2. Используя SDK для высокоуровневого языка, напишите код (на C / C ++, C #, Objective-C, Java или Swift), который использует соответствующую библиотеку ID TECH SDK для выдачи базовых команд микропрограммы.

Второй метод, как правило, проще, поскольку для освоения высокоуровневых API-интерфейсов универсального SDK ID TECH требуется сравнительно мало времени (плюс мы даем вам множество примеров кода для развития). Вниз сторона № 2 является то, что она, как правило, чтобы связать приложение с одного языка разработки и операционной системы. В случае № 1 выбор языка (и ОС) зависит от вас, но вы должны изучить API команд микропрограмм (байтового уровня) для рассматриваемого устройства и самостоятельно решать все проблемы с подключением.

Независимо от того, решите ли вы поговорить с устройством чтения карт напрямую (через последовательное соединение, используя необработанные команды прошивки) или используя встроенные средства связи и высокоуровневые команды универсального SDK, важно понимать, что транзакция EMV (и здесь я говорю о традиционном контактеEMV, не бесконтактный) проходит в три этапа. На языке универсального SDK мы называем эти этапы запуском транзакции, аутентификацией транзакции и завершением транзакции. (У каждого есть соответствующий метод или функция в USDK.) С точки зрения потока программы это означает, что ядро передает управление обратно вызывающей стороне дважды, во время потока транзакции: один раз, после возврата Start Transaction; и второй раз, после аутентификации транзакции (но до завершения транзакции). Эти точки остановки имеют важное значение для потока данных, потому что, с одной стороны, разные TLV (триплеты длины тега-значения) возвращаются после каждой фазы транзакции, и важно получить необходимые TLV в то время, когда они доступны, потому что они могут быть недоступны на более позднем этапе. Типичный пример:

Криптограммы в EMV​

Одним из наиболее важных элементов данных в любой транзакции EMV является криптограмма приложения, которая возвращается в теге 9F26. Контактный сеанс EMV обычно создает две криптограммы (9F26 возвращается дважды): одна идет до завершения транзакции, другая - после. Событие, которое побуждает карту создать криптограмму, называется запросом Gen AC (Generate Application Cryptogram).

Причина, по которой эти криптограммы важны, заключается в том, что они представляют собой неопровержимое доказательство того, что настоящая законная чип-карта физически присутствовала для данной транзакции. (Они также удостоверяют конкретные значения данных, возникшие во время этой транзакции.) Во время Gen AC ядро L2 представляет чип-карту со списком объектов данных (содержащим данные, специфичные для текущей транзакции), и чип-карта отвечает используя свой закрытый ключ (известный только чипу) для подписи этих данных и создания не подлежащего подделке цифрового артефакта (8-байтовой криптограммы), подтверждающего легитимность карты и данных. Легитимность криптограммы может быть проверена онлайн-органом, который в конечном итоге авторизует транзакцию (или отклонит ее, в зависимости от того, что происходит). Вот почему были изобретены чиповые карты и почему существует EMV. Данные на магнитной полосе легко подделать. Криптограммы, производимые микросхемой по запросу, нелегко подделать.

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

В части I этого поста мы немного поговорили о транзакциях EMV и о том, как они структурированы. Мы видели, что:

• В отличие от транзакций MSR (магнитной полосы) транзакция EMV выполняется в несколько этапов.
• Большая часть обмена данными между чип-картой и считывателем происходит на уровне ядра , вне контроля логики приложения.
• Результаты транзакции возвращаются в виде TLV («тегов»).
• Криптограммы (уникальный 8-байтовый часть данных , полученных с помощью карты, используя секретный ключ , известный только на карту) производится до стадии завершения сделки; и вторая криптограмма создается после вызова для завершения транзакции.
• Криптограмма возвращается с карты в теге 9F26 (тег, определенный EMVCo, а не проприетарный тег ID TECH).

Как правило, вы упаковываете первую криптограмму (и любые другие данные TLV, необходимые вашему внутреннему процессору) для отправки процессору по сети в реальном времени для получения кода авторизации (в теге 89) перед выдачей вызов, чтобы начать этап завершения. Вы несете ответственность за выполнение онлайн-запроса авторизации (потому что ни программа для чтения, ни наш SDK не сделают эту часть за вас), используя веб-API вашего шлюза. У большинства шлюзов есть собственные SDK, чтобы упростить эту часть.

Шлюз (или «внутренний процессор») ответит на ваш запрос авторизации тегами 89, 8A, 91 и (необязательно) 71 или 72. Для завершения транзакции вы передадите эти TLV в универсальный SDK emv_completeTransaction () метод. Ваш код будет уведомлен о результатах через обратный вызов. В обратном вызове вы получите дескриптор данных транзакции, который будет включать группу TLV. Среди TLV будет вторая и последняя криптограмма (упомянутая выше), которая - еще раз - будет в теге 9F26.

Типы криптограмм​

Криптограмма, возвращенная в теге 9F26, непрозрачна. Изучая его напрямую, вы не можете сказать, что это за криптограмма. Однако вы можете проверить тег 9F27 (который также возвращается вместе с 9F26), чтобы узнать, какую криптограмму вам предоставили. Верхний полубайт 9F27 будет содержать необходимую вам информацию. Биты можно расшифровать следующим образом (эта информация взята из EMV Book 3):

b8	b7	b6	b5	b4	b3	b2	b1	Смысл
0	0							AAC
0	1							TC
1	0							ARQC
1	1							AAR
		Икс	Икс					Криптограмма, специфичная для платежной системы
				0				Никаких советов не требуется
				1				Требуется консультация
					Икс	Икс	Икс	Причина / совет / реферальный код
					0	0	0	Нет информации
					0	0	1	Услуга не разрешена
					0	1	0	Превышен лимит попытки ввода PIN-кода
					0	1	1	Ошибка аутентификации эмитента
					1	Икс	Икс	Прочие значения РФС

Вообще говоря, 9F27 будет иметь (шестнадцатеричное) значение 80, 40 или 00, которое преобразуется (соответственно) в ARQC, TC или AAC. Это, в свою очередь, означает «подключиться к сети», «одобрено» или «отклонено».

Важно понимать, что эти значения представляют собой только совет карты . Не всегда этот совет является обязательным. Например, карта требуется для возврата AAC во второй криптограмме (при завершении), если исходная криптограмма была ARQC, но платежное приложение не могло выйти в Интернет. В этом случае AAC не означает автоматически, что ваша транзакция отклонена; это решение остается за сетевым органом (в конечном счете, эмитентом). В специальном сценарии EMV, известном как Quick Chip (или Faster EMV), вы всегда будете получать AAC, потому что онлайн-запрос выполняется позже. Это нормально! Вы по-прежнему можете отправить транзакцию на расчет. Совет карты - это просто совет . Окончательное решение принимает онлайн-авторитет.

Обратите внимание, что в США (которые считаются рынком только онлайн) вы почти всегда получите ARQC в первой криптограмме. Исключением может быть случай, если срок действия карты истек или есть какая-то другая причина, по которой транзакция должна быть полностью отклонена, и в этом случае вы можете (теоретически) увидеть AAC после первого запроса «Gen AC».

Получение данных TLV​

В универсальном SDK, который обеспечивает связь с вашим считывателем ID TECH через USB, RS-232, Bluetooth, аудиоразъем или Ethernet (в зависимости от типа считывателя), все связанные с транзакциями коммуникации с и от считывателя являются асинхронными, что означает, что вам необходимо зарегистрировать одну или несколько пользовательских подпрограмм обратного вызова в SDK, чтобы «услышать ответ» от считывателя. Инструкции по выполнению этого действия приведены не только в документации SDK, но и в образце кода, поставляемом с SDK. В использовании обратных вызовов нет ничего загадочного. Мы предлагаем вам потратить некоторое время на изучение примера кода SDK, чтобы увидеть, как выглядит поток.

Важно помнить, что транзакция EMV происходит поэтапно, и вы получаете разные TLV в конце каждой фазы. Распространенное заблуждение состоит в том, что вы просто получите сразу все теги, которые вам когда-либо понадобятся, в конце фазы завершения. Это не правда. Вы обнаружите, что вам необходимо собирать TLV на каждом этапе.

Какие теги вы можете ожидать на каждом этапе? Вот наиболее типичные теги по фазам транзакции:

Начало транзакции:
4F
50
57
5A
5F20
5F24
5F25
5F2D
5F34
84
9F20
DFEE12
DFEE23

Подтвердить транзакцию:
95
9B
9F02
9F03
9F10
9F13
9F26
9F27
9F34
9F36
9F37
9F4D
9F4F

Завершить транзакцию:
95
99
9B
9F02
9F03
9F10
9F13
9F26
9F27
9F34
9F36
9F37
9F4D
9F4F
9F5B

Почти все это стандартные теги EMVCo, определенные в отрасли. Те, которые начинаются с «DF», являются проприетарными тегами ID TECH. Полный список патентованных тегов ID TECH и их значения можно найти в документе 80000503-001 «Справочное руководство по тегам ID TECH TLV», доступном для загрузки в нашей базе знаний.

Не видите нужный тег? Без проблем. Вы можете использовать универсальный SDK для запроса дополнительных тегов во время транзакции. Подробности этого описаны не только в документации SDK, но и в нашем техническом документе по транзакциям EMV с универсальным SDK .

Какие теги зашифрованы?​

Если в ваш ридер был введен ключ и включено шифрование, содержимое тегов, содержащих конфиденциальные данные, будет зашифровано. Это, очевидно, включает любые теги, содержащие данные трека (например, тег 57) или данные PAN (5A). Полный список зашифрованных тегов см. В документе 80000502-001-F, ID TECH Encrypted Data Output. Если вы используете демонстрационный модуль (с введенным демо-ключом), вы можете вручную расшифровать данные с помощью онлайн-инструмента. Однако, вообще говоря, вам никогда не нужно расшифровывать данные самостоятельно в производственном коде, поскольку вы будете передавать данные прямо на свой процессор.

Шифрование - большая тема. Мы не будем больше обсуждать это прямо сейчас, но если вам это интересно, обязательно посмотрите наши предыдущие публикации по этому поводу.

В первой части этой серии мы говорили о том, чем транзакции с чип-картой отличаются от магнитной полосы. Мы увидели, что между считывателем и картой существует значительная двусторонняя связь. Но (хорошие новости!) Мы также увидели, что большая часть этого взаимодействия обрабатывается автоматически - то есть вне контроля разработчика платежного приложения - ядром EMV читателя.

В части II мы немного поговорили о различных тегах (или данных TLV), которые вы можете ожидать обратно во время транзакции EMV, и о том, что некоторые из них означают. Мы также упомянули, что транзакция EMV происходит поэтапно (с такими именами, как Start, Authenticate и Complete). И мы увидели, что разные TLV возвращаются на разных этапах.

ViVOpay VP8300 может работать с чип-картами, магнитной полосой или бесконтактным способом.

Мы также упоминали (на самом деле много раз), что, хотя вы, безусловно, можете выполнить транзакцию EMV, отправив необработанные команды прошивки непосредственно в устройство чтения карт (через USB или RS-232), обычно легче взаимодействовать с устройством чтения, используя Универсальный SDK ID TECH. (Перейдите сюда для загрузки. Будьте готовы указать платформу: Windows, Linux, MacOS, iOS или Android.)

Почему SDK проще? Ну, во-первых, он заботится о настройке последовательной связи (USB, RS-232 или Bluetooth) с считывателем. Это также изолирует вас от необходимости знать о

команды микропрограмм на уровне устройства и связанные протоколы низкого уровня. Кроме того, вы получаете готовые библиотеки кода, которые помогают с интерпретацией кода ошибки и синтаксическим анализом данных.

Еще одна замечательная особенность универсального SDK заключается в том, что он поставляется с образцом кода, показывающим, как использовать различные библиотеки, которые упрощают эту работу. (Читай дальше.)

Как начать работу с SDK? Давайте посмотрим на основные шаги.

Шаг 1. Установите SDK​

Если вы знаете, для какой операционной системы вы будете разрабатывать, перейдите в раздел «Разработка» - «Главная страница» в базе знаний и перейдите к соответствующей загрузке. Существуют отдельные сборки для Windows, Linux, MacOS, iOS и Android.

Распакуйте архив и попробуйте загрузить образец проекта (посмотрите в папке «Исходный код») в выбранной вами среде IDE. Скомпилируйте и запустите образец приложения с подключенным устройством чтения ID TECH. Убедитесь, что приложение может взаимодействовать с устройством чтения.

Шаг 2. Настройте свою читалку​

Не ожидайте, что сможете запустить транзакцию EMV прямо из коробки! Ваша первая транзакция не удастся, если вы не потратили время на настройку своего ридера. Как минимум, это означает загрузку в ридер:

• Настройки терминала
• СПИД
• CAPK (открытые ключи центра сертификации)

ID TECH предоставляет для них примерные значения (только для целей тестирования), но вам все равно нужно запускать команды, которые загружают образцы значений . Они не загружаются, пока вы не запустите команды! (К счастью, как только ваш читатель загрузит эти элементы, вам не нужно повторно загружать их при каждом запуске. Значения постоянны. Конфигурация - одноразовая вещь.) Взгляните на пример кода SDK, чтобы увидеть, как закончено.

Конфигурация EMV - довольно большая тема. Мы не будем пытаться отдать должное в этом посте. Чтобы познакомиться с этим предметом, обязательно прочтите нашу предыдущую публикацию о настройках терминала , а также прочтите раздел «Конфигурация» в нашем техническом документе EMV.

Шаг 3. Запустите транзакцию​

Пример приложения содержит код для этого. Просмотрите приложение, чтобы увидеть, как оно работает. В противном случае вам, по крайней мере, потребуется настроить собственный обратный вызов (функция, которая будет автоматически вызываться SDK в нужное время), а затем самостоятельно вызвать emv_startTransaction () .

Связь с устройством чтения карт происходит асинхронно, что означает, что при вызове такого метода, как emv_startTransaction () , SDK свяжется с устройством чтения, инициируя цепочку событий, но ваша программа не будет блокироваться, пока события происходят. Вместо этого управление немедленно возвращается вашему приложению (вместе с кодом успеха / ошибки). Код SDK будет отслеживать любые обновления читателя. Например, когда считыватель завершает начальную фазу транзакции EMV, он отправляет данные TLV на главный компьютер (обычно через USB). SDK перехватит эти данные, вызовет ваш собственный обратный вызов и передаст данные обратному вызову.

В итоге вам нужно настроить собственный обратный вызов, если вы хотите услышать ответ от читателя!

Как выглядит обратный звонок?​

В версии универсального SDK для Windows ваш пользовательский обратный вызов должен иметь подпись C #, которая выглядит примерно так:

private void MessageCallBack(IDTechSDK.IDT_DEVICE_Types type,
                             DeviceState state,
                             byte[] data,
                             IDTTransactionData cardData,
                             EMV_Callback emvCallback,
                             RETURN_CODE transactionResultCode)

Чтобы гарантировать, что ваш обратный вызов действительно используется , вам необходимо зарегистрировать его в SDK во время выполнения, например:

IDT_VP3300.setCallback(MessageCallBack);

В этом примере предполагается, что вы используете ViVOpay VP3300 в качестве устройства чтения карт, но очевидно, что SDK будет поддерживать любой ID TECH или считыватель ViVOpay, который вы используете. В конце концов, это универсальный SDK.

Как выглядит код транзакции?​

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

RETURN_CODE rt = IDT_VP3300.SharedController.emv_startTransaction(1.00, 0,2, 0, 30, null, false);
    if (rt == RETURN_CODE.RETURN_CODE_DO_SUCCESS)
        {
            tbOutput.AppendText("Start EMV Successfulrn");
        }
    else
       {
            tbOutput.AppendText("Start EMV failed Error Code: " + "0x" + String.Format("{0:X}", (ushort)rt) + ": " + IDTechSDK.errorCode.getErrorString(rt) + "rn");
       }

Вызов emv_startTransaction () приведет к отправке запроса (через USB или последовательный порт) на считыватель. Считыватель выполнит ATR (то есть соприкоснется с чипом на карте) и заставит ядро EMV перейти в действие.

Предполагая, что начальная транзакция прошла успешно (не истекло время или ошибка), и если вы зарегистрировали обратный вызов (как описано ранее), ваш обратный вызов будет выполнен через одну или две секунды. Ваш код обратного вызова должен содержать довольно объемный оператор «switch» с множеством случаев для обработки различных типов результатов. Результат, на который вы надеетесь, конечно же, - это успешная транзакция EMV с данными TLV. Итак, у вас, вероятно, будет код, похожий на следующий, который будет выполняться (в вашем обратном вызове) в конце фазы запуска:

[ switch statement ... ]
case DeviceState.TransactionData:
   //Transaction data is being returned in IDTTransactionData cardData
SetOutputText("Callback: TransactionDatan");
if (cardData.emv_resultCode == EMV_RESULT_CODE.EMV_RESULT_CODE_GO_ONLINE)
{
    // We will auto-complete. Normally, a host response is required here.
    SetOutputText("Online request. Auto Complete EMV Transaction.n");
    byte[] responseCode = new byte[] { 0x30, 0x30 };
    byte[] iad = null;
    RETURN_CODE rt = IDT_VP3300.SharedController.emv_completeTransaction(false, responseCode, iad, null,null);
    return;
}

В этом коде предполагается, что вы установили свои настройки таким образом, чтобы автоматически выполнять фазу аутентификации транзакции, поэтому вы можете перейти непосредственно от начала к завершению. (Это, конечно, не обязательно. Все зависит от ваших требований.) В реальном платежном приложении ваше приложение приостанавливается во время этого «дела», чтобы подключиться к шлюзу или эквайеру. Затем вы передадите тег 8A (и, возможно, другие) в emv_completeTransaction ().

Чтобы увидеть, как анализировать данные транзакции (TLV), которые возвращаются после каждой фазы транзакции, найдите в примере кода «displayCardData (IDTTransactionData cardData)». Вы увидите различные примеры анализа данных.

Подробнее https://idtechproducts.com