# Support Home

## MagTek Support&#x20;

This page gives you quick access to the most essential resources for MagTek products and services. Use the links below to check live system status, explore product-specific or general documentation, try out developer demos, or manage your products. For deeper technical content, use the top menu to find the service and products you need or contact our support team directly.

### Status Pages and MagTek Apps

| **Section**                                                                                   | **Information**                                                                                             |
| --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| [<mark style="color:red;">**Magensa Services Status**</mark>](https://magensa.statuspage.io/) | Go to this page to view real‑time service health, incident history, and maintenance updates for Magensa.    |
| [<mark style="color:red;">**QwickCards Status**</mark>](https://qwickcards.statuspage.io/)    | Go to this page to view real‑time service health, incident history, and maintenance updates for QwickCards. |

### DynaFamily Documentation

| **Section**                                                                                                                        | **Information**                                                                                                                                                                                                                                                 |
| ---------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [<mark style="color:red;">**SCRA Dyna Family Programmer's Manual**</mark>](https://developer.magtek.com/api-and-command-reference) | <p>This is the general API & Command Reference for (SCRA) devices for the DynaFamily. Click for a list of references for a specific Dyna product:<br>- DynaFlex II Go<br>- DynaFlex II SCR<br>- DynaFlex II PED<br>- DynaProx<br>- DynaFlex Pro/SCR (Gen I)</p> |

### Magensa Documentation & APIs

| **Section**                                                                                                                                               | **Information**                                                                                                                                                                                                                               |
| --------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [<mark style="color:red;">**Magensa Documentation & Code**</mark>](https://developer.magtek.com/api-and-command-reference/magensa-documentation-and-code) | Magensa is MagTek's cloud-based payment protection gateway that secures sensitive data and processes transactions across in-person, online, and mobile channels using advanced tokenization, dynamic encryption, and authentication services. |

### Site Categories

| **Section**                                                                                                                                                    | **Information**                                                                                                                                                  |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [<mark style="color:red;">**Get Started**</mark>](https://developer.magtek.com/get-started/)                                                                   | Pick your device, connection basics, your first transaction, and web-based demos.                                                                                |
| [<mark style="color:red;">**Guides**</mark>](https://developer.magtek.com/guides/)                                                                             | Task and concept how-tos: EMV acceptance, L3 certification, security & key management, NFC/MIFARE, firmware & file operations, and PAN vs DPAN / network tokens. |
| [<mark style="color:$danger;">**API & Command Reference**</mark> ](https://developer.magtek.com/api-and-command-reference/)                                    | The complete MMS command set for the DynaFamily readers, documented once: message format, data types, commands, notifications, configuration, and appendices.    |
| [<mark style="color:$danger;">**SDKs & Tools**</mark> ](https://developer.magtek.com/sdks-and-tools/)                                                          | The Universal SDK, MagneFlex Browser Web API, tools & utilities, demos, and Reader Management System (RMS).                                                      |
| [<mark style="color:red;">**Products**</mark>](/products)                                                                                                      | a directory of thin device hubs, each linking into the shared guides, references, and individual product support..                                               |
| [<mark style="color:red;">**Services**</mark>](https://developer.magtek.com/services/)                                                                         | Magensa and Qwantum and Reader Management Systems services.                                                                                                      |
| [<mark style="color:red;">**Downloads, Compliance, & Marketing Materials**</mark>](https://developer.magtek.com/downloads-compliance-and-marketing-materials/) | Firmware, device manuals, PCI security policies, and marketing materials.                                                                                        |
| [<mark style="color:red;">**Resources**</mark>](https://developer.magtek.com/resources/)                                                                       | Changelogs, LLM resources, and support.                                                                                                                          |

### For More Help

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** [support@magtek.com](mailto:support@magtek.com?subject=Support%20Request)
* 📞 **Phone:** 1-562-546-6800 (US)
* 🕐 **Hours:** Monday-Friday, 5:30 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Support Portal:** developer.magtek.com

**Documentation Feedback:**

Help us improve this documentation! [feedback@magtek.com](mailto:feedback@magtek.com?subject=Feedback)
{% endhint %}


# Get Started

### In this section

Get started is the on-ramp for building with MagTek products. It takes you from choosing a device to running your first transaction — the connection basics, the minimum steps to see a card read end to end, and where to go next. If you're new to the platform, start here; once you're up and running, the Guides and the API & Command Reference cover the depth.

### In This Section

<table data-header-hidden><thead><tr><th valign="middle"></th><th></th></tr></thead><tbody><tr><td valign="middle"><strong>Reference Section</strong></td><td><strong>Information Available</strong></td></tr><tr><td valign="middle"><a href="/pages/Gpe1BCpuQOiuJiArOTD5"><mark style="color:red;"><strong>Pick Your Device</strong></mark></a></td><td>Compare devices and choose the right one for your integration.</td></tr><tr><td valign="middle"><a href="/pages/XlelJqPrRbBYZrOcDZmX"><mark style="color:red;"><strong>Connection Basics</strong></mark></a></td><td>Information on the different ways products connect to hosts.</td></tr><tr><td valign="middle"><a href="/pages/MmccJNSMwYKHgFIARL6d"><mark style="color:red;"><strong>Your First Transaction</strong></mark></a></td><td>Run a transaction end to end and see a result.</td></tr><tr><td valign="middle"><a href="/pages/eEeUUgBNsgNcJVTRwvIt"><mark style="color:red;"><strong>Web-based Demos</strong></mark></a></td><td>Try a reader in the browser before you write any code.</td></tr></tbody></table>

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** <support@magtek.com>
* 📞 **Phone:** 1-800-788-6835 (US) | +1-562-546-6616 (International)
* 🕐 **Hours:** Monday-Friday, 6:00 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Support Portal:** <https://www.magtek.com/support>
* 📚 **Knowledge Base:** [https://support.magtek.com](https://support.magtek.com/)
* 💬 **Developer Forum:** [https://forum.magtek.com](https://forum.magtek.com/)

**Documentation Feedback:**

Help us improve this documentation! [Submit feedback](broken://pages/5314c528980689961380bea0044c1256aaeb39bc)
{% endhint %}


# Pick Your Dyna Device

Every reader in the DynaFamily speaks the same MMS command set, so your integration is largely portable across them — the differences are form factor, whether the reader takes a PIN, and how it connects. Use the table below  to narrow down, then open a product hub for full specs.

### Compare the readers

<table><thead><tr><th width="110"></th><th width="116"></th><th width="88.36358642578125" align="center"></th><th width="119" align="center"></th><th width="73" align="center"></th><th width="116"></th><th></th></tr></thead><tbody><tr><td><strong>Reader</strong></td><td><strong>Form factor</strong></td><td align="center"><strong>Contact</strong></td><td align="center"><strong>Contactless</strong></td><td align="center"><strong>PIN entry</strong></td><td><strong>Connection</strong></td><td><strong>Best for</strong></td></tr><tr><td><a href="https://developer.magtek.com/products/dynafamily-mms-dyna-devices/dynaflex-ii-ped"><mark style="color:red;"><strong>DynaFlex II PED</strong></mark></a></td><td>Countertop, PIN pad + display</td><td align="center">✓</td><td align="center">✓</td><td align="center">✓</td><td>USB, BLE</td><td>Attended checkout that needs PIN debit</td></tr><tr><td><a href="https://developer.magtek.com/products/dynafamily-mms-dyna-devices/dynaflex-ii-go"><mark style="color:red;"><strong>DynaFlex II Go</strong></mark></a></td><td>Handheld, portable, battery</td><td align="center">✓</td><td align="center">✓</td><td align="center">—</td><td>USB, Bluetooth LE</td><td>Mobile, curbside, line-busting</td></tr><tr><td><a href="https://developer.magtek.com/products/dynafamily-mms-dyna-devices/dynaflex-ii-scr"><mark style="color:red;"><strong>DynaFlex II SCR</strong></mark></a></td><td>Compact countertop</td><td align="center">✓</td><td align="center">✓</td><td align="center">—</td><td>USB</td><td>Attended checkout without PIN</td></tr><tr><td><a href="https://developer.magtek.com/products/dynafamily-mms-dyna-devices/dynaprox"><mark style="color:red;"><strong>DynaProx</strong></mark></a></td><td>Contactless reader</td><td align="center">—</td><td align="center">✓</td><td align="center">—</td><td>USB</td><td>Tap-only, transit, access control</td></tr></tbody></table>

All are PCI PTS POI–approved SCRAs with EMV L1/L2/L3 support and SRED point-to-point encryption.

### How to choose

* **Need to accept PIN debit?** The [<mark style="color:red;">**DynaFlex II PED**</mark>](https://developer.magtek.com/products/dynafamily-mms-dyna-devices/dynaflex-ii-ped) is the only one with a PIN pad — it's also the one with a full touch display for on-screen prompts.
* **Mobile or handheld?** The [<mark style="color:red;">**DynaFlex II Go**</mark>](https://developer.magtek.com/products/dynafamily-mms-dyna-devices/dynaflex-ii-go) is portable and battery-powered, and it's the one with Bluetooth LE.
* **Attended countertop, no PIN?** The [<mark style="color:red;">**DynaFlex II SCR**</mark>](https://developer.magtek.com/products/dynafamily-mms-dyna-devices/dynaflex-ii-scr) is the compact fixed reader.
* **Contactless/tap only?** The [<mark style="color:red;">**DynaProx**</mark>](https://developer.magtek.com/products/dynafamily-mms-dyna-devices/dynaprox) is contactless-focused.

Because they share the command set, you can confirm exactly which commands a given reader supports in the [<mark style="color:red;">**DynaFamily Command Matrix**</mark>](https://developer.magtek.com/api-and-command-reference/dynafamily-command-matrix) and see full specs and downloads on each product hub.

Looking for a [<mark style="color:red;">**magnetic-stripe reader**</mark>](https://developer.magtek.com/products/card-readers), [<mark style="color:red;">**PIN pad**</mark>](https://developer.magtek.com/products/card-readers), [<mark style="color:red;">**check scanner**</mark>](https://developer.magtek.com/products/micr-and-check-scanners), or [<mark style="color:red;">**OEM component**</mark>](https://developer.magtek.com/products/oem-readers-and-components)? See the full [<mark style="color:red;">**Products**</mark>](https://developer.magtek.com/products) directory.

### Need More Help

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** <support@magtek.com>
* 📞 **Phone:** 1-800-788-6835 (US) | +1-562-546-6616 (International)
* 🕐 **Hours:** Monday-Friday, 6:00 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Official Site:** [https://www.magtek.com](https://www.magtek.com/)
* 💬 **Developer Forum:** [https://forum.magtek.com](https://forum.magtek.com/)

**Documentation Feedback:**

Help us improve this documentation! [Submit feedback](broken://spaces/1lWLescKFIPsMeIJI6Cd/pages/5314c528980689961380bea0044c1256aaeb39bc)
{% endhint %}


# Connection Basics

DynaFamily readers connect to a host over USB or Bluetooth LE. The MMS command set is identical over either transport — how you frame and send commands doesn't change — so the connection choice is about the device and your use case, not your integration code. Wired USB is simplest for fixed, attended setups; Bluetooth LE suits portable and mobile deployments (on the readers that support it, such as the DynaFlex II Go).

### In This Section

<table data-header-hidden><thead><tr><th valign="middle"></th><th></th></tr></thead><tbody><tr><td valign="middle"><strong>Reference Section</strong></td><td><strong>Information Available</strong></td></tr><tr><td valign="middle"><a href="https://developer.magtek.com/guides/guides/connection-basics/how-to-use-usb-connections-usb-only"><mark style="color:red;"><strong>USB</strong></mark></a></td><td>Connecting over USB, including the HID interface the reader presents.</td></tr><tr><td valign="middle"><a href="https://developer.magtek.com/guides/guides/connection-basics/how-to-use-wireless-lan-wlan-connections-wlan-only"><mark style="color:red;"><strong>WLAN</strong></mark></a></td><td>Communicate via a TCP/IP network with MMS products connected to a wireless LAN access point</td></tr><tr><td valign="middle"><a href="https://developer.magtek.com/guides/guides/connection-basics/how-to-use-bluetooth-r-le-connections-bluetooth-r-le-only"><mark style="color:red;"><strong>Bluetooth LE</strong></mark> </a></td><td>Pairing and connecting over Bluetooth Low Energy.</td></tr><tr><td valign="middle"><a href="https://developer.magtek.com/guides/guides/connection-basics/how-to-use-rs-232-uart-connections-slip-only"><mark style="color:red;"><strong>RS-232/UART</strong></mark></a></td><td>Connect the host to the device using a serial connection such as RS-232 UART</td></tr><tr><td valign="middle"><a href="https://developer.magtek.com/guides/guides/connection-basics/how-to-use-slip-format-slip-only"><mark style="color:red;"><strong>SLIP Format</strong></mark></a></td><td>For connection types that do not include error detection and correction, such as serial protocols.</td></tr><tr><td valign="middle"><a href="https://developer.magtek.com/guides/guides/connection-basics/how-to-use-apple-iap2-connections-iap2-only"><mark style="color:red;"><strong>Apple iAP2</strong></mark></a></td><td>Information about developing an iOS app that interfaces with the device via the USB connector using iPod Accessory Protocol (iAP2)</td></tr></tbody></table>

Once connected, head to [<mark style="color:red;">**Your First Transaction**</mark>](https://developer.magtek.com/get-started/your-first-transaction), or the [<mark style="color:red;">**API & Command Reference**</mark>](https://developer.magtek.com/api-and-command-reference) for the command set.

### Need More Help

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** <support@magtek.com>
* 📞 **Phone:** 1-800-788-6835 (US) | +1-562-546-6616 (International)
* 🕐 **Hours:** Monday-Friday, 6:00 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Official Site:** [https://www.magtek.com](https://www.magtek.com/)
* 💬 **Developer Forum:** [https://forum.magtek.com](https://forum.magtek.com/)

**Documentation Feedback:**

Help us improve this documentation! [Submit feedback](broken://spaces/1lWLescKFIPsMeIJI6Cd/pages/5314c528980689961380bea0044c1256aaeb39bc)
{% endhint %}


# Your First Transaction

This walkthrough runs one EMV sale end to end so you can confirm your setup works. It's the quick version — each step links into the full detail.

### Before you begin

* Your reader is connected — see [<mark style="color:red;">**Connection Basics**</mark>](https://developer.magtek.com/get-started/connection-basics).
* Keys are injected and you can decrypt output — see [<mark style="color:red;">**Security & Key Management**</mark>](https://developer.magtek.com/guides/guides/security-and-key-management).

### Run it

1. **Start the transaction.** Send [<mark style="color:red;">**Start Transaction – 0x1001**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands/transactions-command-group-0x10nn/start-transaction-command-0x1001) with the amount and transaction type, and prompt the cardholder to insert, tap, or swipe.
2. **React to the reader.** As the transaction proceeds, the reader sends [<mark style="color:red;">**Transaction Information Update – 0x0101**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/notifications/transactions-source-0x01nn/transaction-information-update-notification-0x0101) notifications reporting progress. On a reader without a display (like the DynaFlex II Go), respond to any prompts it sends via Host Action Request.
3. **Finish.** The reader produces an ARQC; forward it to your processor and return the response, or use Quick Chip to complete immediately. The reader sends [<mark style="color:red;">**Transaction Operation Complete – 0x0105**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/notifications/transactions-source-0x01nn/transaction-operation-complete-notification-0x0105) with the result.

### Go deeper

That's the shape of it. For the full flow — the Quick Chip vs. EMV fork, online authorization, contactless, and configuration — see [<mark style="color:red;">**EMV Acceptance**</mark>](https://developer.magtek.com/guides/guides/emv-acceptance).

### Need More Help

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** <support@magtek.com>
* 📞 **Phone:** 1-800-788-6835 (US) | +1-562-546-6616 (International)
* 🕐 **Hours:** Monday-Friday, 6:00 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Official Site:** [https://www.magtek.com](https://www.magtek.com/)
* 💬 **Developer Forum:** [https://forum.magtek.com](https://forum.magtek.com/)

**Documentation Feedback:**

Help us improve this documentation! [Submit feedback](broken://spaces/1lWLescKFIPsMeIJI6Cd/pages/5314c528980689961380bea0044c1256aaeb39bc)
{% endhint %}


# Web-based Demos

Want to see a reader work before you write any code? MagTek's browser-based demos lets you connect a device and run commands straight from your browser using WebHID — no SDK install required.

{% hint style="info" %}
Requires a WebHID-capable browser (such as Chrome or Edge) and a reader connected over USB.
{% endhint %}

### In This Section

<table data-header-hidden><thead><tr><th valign="middle"></th><th></th></tr></thead><tbody><tr><td valign="middle"><strong>Reference Section</strong></td><td><strong>Information Available</strong></td></tr><tr><td valign="middle"><a href="https://developer.magtek.com/sdks-and-tools/demos-and-sample-code/web-based-demo-documentation"><mark style="color:red;"><strong>Web-based Demo Documentation</strong></mark></a></td><td>Instructions for using the browser-based MagTek Demo Applications.</td></tr><tr><td valign="middle"><a href="https://developer.magtek.com/sdks-and-tools/demos-and-sample-code/web-based-demos-card-readers"><mark style="color:$tint;"><strong>Web-based Demos</strong></mark></a></td><td>All interactive browser-based demonstrations for MagTek devices.</td></tr></tbody></table>

For SDKs, sample code, and the [<mark style="color:red;">**full set of tools**</mark> ](https://developer.magtek.com/sdks-and-tools/tools-and-utilities)once you're ready to build, see <mark style="color:red;">**SDKs & Tools.**</mark>

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** <support@magtek.com>
* 📞 **Phone:** 1-800-788-6835 (US) | +1-562-546-6616 (International)
* 🕐 **Hours:** Monday-Friday, 6:00 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Official Site:** [https://www.magtek.com](https://www.magtek.com/)
* 💬 **Developer Forum:** [https://forum.magtek.com](https://forum.magtek.com/)

**Documentation Feedback:**

Help us improve this documentation! [Submit feedback](broken://spaces/1lWLescKFIPsMeIJI6Cd/pages/5314c528980689961380bea0044c1256aaeb39bc)
{% endhint %}


# Guides​

Guides are task-first, how-to side documentation. [<mark style="color:red;">**API &**</mark>\ <mark style="color:red;">**Command Reference**</mark>](https://developer.magtek.com/api-and-command-reference) is where you look up a specific command, notification, or data\
object, Guides is where you learn how to accomplish something end to end —\
accepting an EMV payment, migrating your keys to AES, getting L3 certified, or\
working with contactless cards. Each guide pullstogether concepts and procedures that used to live inside individual product manuals, and links into the reference for the exact\
command details.

### In This Section

<table data-header-hidden><thead><tr><th valign="middle"></th><th></th></tr></thead><tbody><tr><td valign="middle"><strong>Reference Section</strong></td><td><strong>Information Available</strong></td></tr><tr><td valign="middle"><a href="/pages/roSDsbC7qK0IYUG5ODI3"><mark style="color:red;"><strong>Connection Basics</strong></mark></a></td><td>Information on the different ways products connect to hosts.</td></tr><tr><td valign="middle"><a href="/pages/35l0G4Dr2WXsO1HyMEDR"><mark style="color:red;"><strong>EMV Acceptance</strong></mark></a></td><td>Run a contact or contactless EMV transaction end to end.</td></tr><tr><td valign="middle"><a href="/pages/le63sSBgxjVsT9yu1x2L"><mark style="color:red;"><strong>L3 Certification Guidelines</strong></mark></a></td><td>The certification path, and how a common kernel speeds it up.</td></tr><tr><td valign="middle"><a href="/pages/gKVzm7qmwicpSbg3fnSQ"><mark style="color:red;"><strong>Security &#x26; Key Management</strong></mark> </a></td><td>DUKPT, KSNs, MAC, encryption/decryption, TR-31, and PCI requirements.</td></tr><tr><td valign="middle"><a href="/pages/k4riW6Q5aVBWB0PfMKRJ"><mark style="color:red;"><strong>NFC / MIFARE</strong></mark> </a></td><td>Contactless cards and tags, pass-through, and card emulation.</td></tr><tr><td valign="middle"><a href="/pages/uERlE9jCiY6UAsMRzhJQ"><mark style="color:red;"><strong>Firmware &#x26; File Operations</strong></mark></a></td><td>Updating firmware and moving files to and from a device.</td></tr><tr><td valign="middle"><a href="/pages/9YHZ11U1SnN8XzRxqo2W"><mark style="color:red;"><strong>PAN vs DPAN / Network Tokens</strong></mark></a></td><td>Telling the real account number apart from tokens.</td></tr><tr><td valign="middle"><a href="/pages/LzVs1VlHUwEA9kJLUl3N"><mark style="color:red;"><strong>Google Wallet Smart Tap</strong></mark></a></td><td>A worked integration using the reader's contactless interface for Google Wallet value-added services (VAS) transactions, including connecting the device, sending the command set, and adding a Smart Tap pass.</td></tr><tr><td valign="middle"><a href="/pages/EKTRC8fmmJq7i0yO3D9Z"><mark style="color:red;">​<strong>DynaCast, NFC Card Emulation, and Business Use Cases</strong></mark></a></td><td>Background on card-emulation scenarios and where they apply.</td></tr></tbody></table>

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** <support@magtek.com>
* 📞 **Phone:** 1-800-788-6835 (US) | +1-562-546-6616 (International)
* 🕐 **Hours:** Monday-Friday, 6:00 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Support Portal:** <https://www.magtek.com/support>
* 📚 **Knowledge Base:** [https://support.magtek.com](https://support.magtek.com/)
* 💬 **Developer Forum:** [https://forum.magtek.com](https://forum.magtek.com/)

**Documentation Feedback:**

Help us improve this documentation! [Submit feedback](broken://pages/5314c528980689961380bea0044c1256aaeb39bc)
{% endhint %}


# Connection Basics

DynaFamily readers connect to a host over USB or Bluetooth LE. The MMS command set is identical over either transport — how you frame and send commands doesn't change — so the connection choice is about the device and your use case, not your integration code. Wired USB is simplest for fixed, attended setups; Bluetooth LE suits portable and mobile deployments (on the readers that support it, such as the [<mark style="color:red;">**DynaFlex II Go**</mark>](https://developer.magtek.com/products/dynafamily-mms-dyna-devices/dynaflex-ii-go)).

### In This Section

<table data-header-hidden><thead><tr><th valign="middle"></th><th></th></tr></thead><tbody><tr><td valign="middle"><strong>Reference Section</strong></td><td><strong>Information Available</strong></td></tr><tr><td valign="middle"><a href="https://developer.magtek.com/guides/guides/connection-basics/how-to-use-usb-connections-usb-only"><mark style="color:red;"><strong>USB</strong></mark></a></td><td>Connecting over USB, including the HID interface the reader presents.</td></tr><tr><td valign="middle"><a href="https://developer.magtek.com/guides/guides/connection-basics/how-to-use-wireless-lan-wlan-connections-wlan-only"><mark style="color:red;"><strong>WLAN</strong></mark></a></td><td>Communicate via a TCP/IP network with MMS products connected to a wireless LAN access point</td></tr><tr><td valign="middle"><a href="https://developer.magtek.com/guides/guides/connection-basics/how-to-use-bluetooth-r-le-connections-bluetooth-r-le-only"><mark style="color:red;"><strong>Bluetooth LE</strong></mark> </a></td><td>Pairing and connecting over Bluetooth Low Energy.</td></tr><tr><td valign="middle"><a href="https://developer.magtek.com/guides/guides/connection-basics/how-to-use-rs-232-uart-connections-slip-only"><mark style="color:red;"><strong>RS-232/UART</strong></mark></a></td><td>Connect the host to the device using a serial connection such as RS-232 UART</td></tr><tr><td valign="middle"><a href="https://developer.magtek.com/guides/guides/connection-basics/how-to-use-slip-format-slip-only"><mark style="color:red;"><strong>SLIP Format</strong></mark></a></td><td>For connection types that do not include error detection and correction, such as serial protocols.</td></tr><tr><td valign="middle"><a href="https://developer.magtek.com/guides/guides/connection-basics/how-to-use-apple-iap2-connections-iap2-only"><mark style="color:red;"><strong>Apple iAP2</strong></mark></a></td><td>Information about developing an iOS app that interfaces with the device via the USB connector using iPod Accessory Protocol (iAP2)</td></tr></tbody></table>

Once connected, head to [<mark style="color:red;">**Your First Transaction**</mark>](https://developer.magtek.com/get-started/your-first-transaction), or the [<mark style="color:red;">**API & Command Reference**</mark>](https://developer.magtek.com/api-and-command-reference) for the command set.

### Need More Help

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** <support@magtek.com>
* 📞 **Phone:** 1-800-788-6835 (US) | +1-562-546-6616 (International)
* 🕐 **Hours:** Monday-Friday, 6:00 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Official Site:** [https://www.magtek.com](https://www.magtek.com/)
* 💬 **Developer Forum:** [https://forum.magtek.com](https://forum.magtek.com/)

**Documentation Feedback:**

Help us improve this documentation! [Submit feedback](broken://spaces/1lWLescKFIPsMeIJI6Cd/pages/5314c528980689961380bea0044c1256aaeb39bc)
{% endhint %}


# How to Use USB Connections (USB Only)

{% hint style="success" %}
Applies to: All DynaFamily Products
{% endhint %}

These USB devices conform to the USB specification revision 1.1. They also conform to the Human Interface Device (HID) class specification version 1.1. This document assumes the audience is familiar with USB HID class specifications, which are available at [http://www.usb.org/ ](http://www.usb.org/)MagTek strongly recommends becoming familiar with that standard before trying to communicate with the device directly via USB.

These devices are full-speed, high-powered USB devices that draw power from the USB bus they are connected to. They enter and wake up from Suspend mode when directed to do so by the USB host. They do not support remote wakeup.

When connecting via USB, MMS devices connect to the USB host as a vendor-defined Human Interface Device.&#x20;

* MMS devices identify themselves to the host with MagTek’s vendor ID 0x0801.&#x20;
* DynaFlex products report as Product ID (PID) 0x2020
* DynaProx products report as Product ID (PID) 0x2023&#x20;
* DynaFlex II Go report as Product ID (PID) 0x2024.

Details for exchanging messages with the device are provided in the sections that follow.

### About USB Reports, Usages, Usage Pages, and Usage IDs&#x20;

All USB HID devices send and receive data using Reports. Each report may contain several sections, called Usages, each of which has its own unique four-byte (32-bit) identifier. The two most significant bytes of a usage are called the usage page, and the two least significant bytes are called the usage ID. Vendor-defined HID device usages must have a usage page in the range 0xFF00 - 0xFFFF, and it is common practice for related usage IDs share the same usage page. For these reasons, all usages for MMS devices use vendor-defined usage page 0xFF00, Magnetic Stripe Reader.

HID reports used by the host can be divided into two types:

* Output Reports, which the host uses to send messages (such as commands) to the device.
* Input Reports, which the device uses to send messages (such as responses and unsolicited notifications) to the host.

For information about using output reports to send command messages to / receive response messages from the device, see [<mark style="color:red;">**How to Send Command Requests Using the USB Connection**</mark>](https://developer.magtek.com/guides/guides/connection-basics/how-to-use-usb-connections-usb-only#how-to-send-command-requests-using-the-usb). For information about receiving unsolicited data from the device, see [<mark style="color:red;">**How to Receive Data Using the USB Connection (HID Only)**</mark>](https://developer.magtek.com/guides/guides/connection-basics/how-to-use-usb-connections-usb-only#how-to-receive-data-using-the-usb-connection-hid-only).

## How to Connect to a Device Using the USB Connection&#x20;

The steps for a host to connect to the device using the USB connector are the same as connecting to any USB HID device and are platform specific. The general steps regardless of platform are as follows:

* Enumerate the USB devices connected to the host.
* Locate the desired device by PID.
* Open the USB connection.
* Read the report descriptor.
* Begin listening for incoming reports and sending data using outgoing reports.

## How to Send Command Requests Using the USB&#x20;

Connection MMS communication between the host and the device consists of Messages, which are independent of connection type. This section focuses specifically on how to use the device’s USB HID connection to transmit a Command to the host by composing and sending a Request Message, then listening for and interpreting the corresponding Response Message.

When the device is connected to the host via USB, the host sends one or more Output Reports to the device to send the requests for commands, and listens / waits for the device to send one or more Input Reports containing a response. All reports use Usage Page 0xFF00, Usage ID 0x20, and no Report ID (which some platform libraries present to the calling software as Report ID 0x00).

The host may send Output Reports by using either the default Control pipe or the Interrupt OUT pipe using a blocking call to the platform’s USB libraries. The device ACKs all Output Reports immediately. Upon detecting the ACK for the last Output Report in the message stream, the host software can immediately begin listening for one or more follow-up Input Reports containing the device’s response.

Some messages  may exceed the maximum packet length allowed by USB HID. For this reason, MMS implements a packetizing scheme the host must use when it composes Output Reports to send commands, and when it decomposes Input Reports to receive responses. The host should follow this general sequence to send a request and receive a response:

{% stepper %}
{% step %}

### Choose Command

Choose the command to invoke from [<mark style="color:red;">**Commands**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands).
{% endstep %}

{% step %}

### Construct Request

Construct the command request message using the Request table in the [<mark style="color:red;">**command documentation**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands).&#x20;
{% endstep %}

{% step %}

### Determine Length

Determine the complete length of the command request message.
{% endstep %}

{% step %}

### Determine Report Payload Length

Examine the device’s Report Descriptor to determine what payload length the device expects for an Output Report (operating system libraries may refer to this length as the “Report Length” or “Report Count”). MMS devices using USB HID generally use a payload length of 64 bytes.

* If the message length fits the Single Packet payload length of 62 bytes, wrap the message in the [<mark style="color:red;">**Single Packet Format Table**</mark>](https://developer.magtek.com/guides/guides/connection-basics/how-to-use-usb-connections-usb-only#single-packet-format).
* If the message length does not fit the Single Packet payload length, wrap the message in the format of a single [<mark style="color:red;">**Multi-Packet Head**</mark>](https://developer.magtek.com/guides/guides/connection-basics/how-to-use-usb-connections-usb-only#multi-packet-head-format), followed by zero or more [<mark style="color:red;">**Multi-Packet Middles**</mark>](https://developer.magtek.com/guides/guides/connection-basics/how-to-use-usb-connections-usb-only#multi-packet-middle-format) as necessary, followed by one [<mark style="color:red;">**Multi-Packet Tail**</mark>](https://developer.magtek.com/guides/guides/connection-basics/how-to-use-usb-connections-usb-only#multi-packet-tail-format). If necessary, the host can cancel in the middle of a Multi-Packet message using the [<mark style="color:red;">**Multi-Packet Cancel**</mark>](https://developer.magtek.com/guides/guides/connection-basics/how-to-use-usb-connections-usb-only#multi-packet-cancel-format) packet.
  {% endstep %}

{% step %}

### Send Packets and Wait for ACKs

For each packet, send an Output Report to the device, and wait for the device to ACK the output report USB packet. Upon ACK, either send the next packet in the sequence (if any), or begin listening for an Input Report containing the device’s response message (see [<mark style="color:red;">**How to Receive Data Using the USB Connection (HID Only)**</mark>](https://developer.magtek.com/guides/guides/connection-basics/how-to-use-usb-connections-usb-only#how-to-receive-data-using-the-usb-connection-hid-only)). If an ACK does not arrive, time out and assume the command needs to be started again.
{% endstep %}

{% step %}

### Reassemble Response

Strip wrappers off the device’s response in exactly the same way you constructed the command (using either Single Packet format or Multi-Packet format), and recompose the response message. Be sure to assemble the packets in the correct order using Packet Number, and to truncate the padding based on Message Length or Remaining Message Length.
{% endstep %}

{% step %}

### Parse Response

Parse the final response message using the Response table in the documentation for the command.
{% endstep %}
{% endstepper %}

## Single Packet Format

<table><thead><tr><th width="136.27276611328125">Byte Offset</th><th width="200.45452880859375">Field Name</th><th>Field Value</th></tr></thead><tbody><tr><td>0</td><td>Packet Type</td><td>0x00 = Single Packet</td></tr><tr><td>1</td><td>Message Length</td><td>Message length, denoted as N</td></tr><tr><td>2..N+1</td><td>Message</td><td>Message exactly from section 2.7</td></tr><tr><td>N+2..63</td><td>Padding, if needed</td><td>0x00</td></tr></tbody></table>

## Multi-Packet Head Format

<table><thead><tr><th width="139">Byte Offset</th><th width="198.54541015625">Field Name</th><th>Field Value</th></tr></thead><tbody><tr><td>0</td><td>Packet Type</td><td>0x01 = Multi-packet Head</td></tr><tr><td>1..4</td><td>Message Length</td><td>Total message length before decomposing into packets, denoted as N. If 62 or less, use Single Packet Format.</td></tr><tr><td>5..63</td><td>Message Part</td><td>First 59 bytes of message from section 2.7</td></tr></tbody></table>

## Multi-Packet Middle Format

<table><thead><tr><th width="139">Byte Offset</th><th width="203.09088134765625">Field Name</th><th>Field Value</th></tr></thead><tbody><tr><td>0</td><td>Packet Type</td><td>0x02 = Multi-Packet Middle</td></tr><tr><td>1..2</td><td>Packet Number</td><td>0x0001 = First Multi-Packet Middle 0x0002 = Second Multi-Packet Middle Etc. up to 0xFFFF</td></tr><tr><td>3..63</td><td>Message Part</td><td>Next 61 bytes of message from section 2.7</td></tr></tbody></table>

## Multi-Packet Tail Format

<table><thead><tr><th width="119.9090576171875">Byte Offset</th><th width="234.9090576171875">Field Name</th><th>Field Value</th></tr></thead><tbody><tr><td>0</td><td>Packet Type</td><td>0x03 = Multi-Packet Tail</td></tr><tr><td>1</td><td>Remaining Message Length</td><td>Number of bytes of the message that are being transmitted in this final packet, denoted as n.</td></tr><tr><td>2..n+1</td><td>Message Part</td><td>Final n bytes of message exactly as described in section 2.7</td></tr><tr><td>n+2..63</td><td>Padding, if needed</td><td>0x00</td></tr></tbody></table>

## Multi-Packet Cancel Format

<table><thead><tr><th width="129.9090576171875">Byte Offset</th><th width="240.81817626953125">Field Name</th><th>Field Value</th></tr></thead><tbody><tr><td>0</td><td>Packet Type</td><td>0x04 = Multi-Packet Cancel</td></tr><tr><td>1..2</td><td>Reason for Cancel</td><td>0x0000 = General</td></tr><tr><td>3..63</td><td>Padding</td><td>0x00</td></tr></tbody></table>

### How to Receive Data Using the USB Connection (HID Only)&#x20;

MMS devices use the same mechanism to send Response messages to host commands and to send unsolicited Notifications to the host when events occur, such as device state changes or user interactions.

When the device communicates with the host as a vendor-defined HID device, it sends messages to the host via an Input Report, which it sends to the host using the USB Interrupt IN pipe. Per the USB HID standard, the host polls the device on a regular Polling Interval to see if the device has input reports available to send. If the device does not, it responds to the host’s poll with a USB NAK.

The host software should always be listening for Input Reports from the device containing notification messages and command response messages. Assembling and parsing the incoming message is the same in both cases, but notification messages, which are generally unpredictable, need to be routed to different handlers than responses, which are generally anticipated after sending a command. All input reports use Usage Page 0xFF00, Usage ID 0x20. Because MMS devices only implement one input report, the input report they send to the host does not include an Input Report ID (which some operating system libraries present to the calling software as Input Report ID 0x00), in accordance with the USB HID specification.

Some response and notification messages may exceed the maximum packet length allowed by USB HID. If the message can’t fit into one packet, the device sends multiple packets, each containing partial message data using the same message packet structures described in the Multi-Packet tables above.

Upon receiving an input report, the host can determine the size of message packet Input Reports by looking at the HID report descriptor. The host can locate a specific data element in the report by finding the corresponding Usage and interpreting its contents as binary data. Because MMS devices use a single usage to hold the Input Report contents, unlike devices that divide the Input Report contents into length-delimited Usages, the host software can hard-code its method of finding the packet data; it is not necessary for the host software to examine the Report Descriptor for information about separate data elements’ offsets upon receiving a packet.

The host should follow this general sequence to process incoming Input Reports:

{% stepper %}
{% step %}

### Register Listener

Register a listener with the operating system USB library to have the relevant Input Reports routed to the host software for processing.
{% endstep %}

{% step %}

### Retrieve Usage Data

When an Input Report arrives, knowing from [<mark style="color:red;">**this section**</mark>](https://developer.magtek.com/guides/guides/connection-basics/how-to-use-usb-connections-usb-only#about-usb-reports-usages-usage-pages-and-usage-ids) that the device uses Usage Page 0xFF00, and knowing the desired data is found in the usage with Usage ID 0x0020, call the platform’s USB SDK to retrieve the data from Usage 0xFF000020 in the input report.
{% endstep %}

{% step %}

### Detect Packet Format

Interpret the blob of data according to tables to determine whether the incoming message is in single packet format or multi-packet format. If it is using multi-packet format:

* Continue buffering the message and processing incoming packets until the last packet of the message arrives.
* Assemble the full message. Be sure to assemble the packets in the correct order using the Packet Number, and to truncate the padding based on Message Length or Remaining Message Length.
  {% endstep %}

{% step %}

### Determine Message Type

Determine the message type and message ID and parse it according to the corresponding Response table or Notification table.
{% endstep %}

{% step %}

### Route Message

Route the fully composed message to the appropriate handler.
{% endstep %}
{% endstepper %}

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** [support@magtek.com](mailto:support@magtek.com?subject=Support%20Request)
* 📞 **Phone:** 1-562-546-6800 (US)
* 🕐 **Hours:** Monday-Friday, 5:30 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Support Portal:** developer.magtek.com

**Documentation Feedback:**

Help us improve this documentation! [feedback@magtek.com](mailto:feedback@magtek.com?subject=Feedback)
{% endhint %}


# How to Use Wireless LAN (WLAN) Connections (WLAN Only)

{% hint style="success" %}
Applies to: DynaFlex II PED, DynaFlex Pro/SCR (Gen I)
{% endhint %}

### About Wireless LAN (WLAN) Connections&#x20;

This section provides information about developing software for a host to communicate via a TCP/IP network with MMS products connected to a wireless LAN access point. In this arrangement, the host and device exchange messages as peers using the bidirectional WebSocket protocol. For details about the WebSocket Protocol, formally IETF RFC 6455, see <https://tools.ietf.org/html/rfc6455> and [http://websocket.org](http://websocket.org/).

For information about SDKs and sample code that can wrap the protocol and speed up development, see [<mark style="color:red;">**SDKs and Tools**</mark>](https://developer.magtek.com/sdks-and-tools).

### How to Connect to a Device Using the Wireless LAN (WLAN) Connection&#x20;

Before the device and host can communicate using the wireless LAN (WLAN) connection, the device must first be configured to connect to a WLAN access point. For details about configuring the device, see the device’s Installation and Operation Manual or supporting documentation included with the device.

After the device has been successfully configured for WLAN communication, whenever the device powers on or resets, it attempts to connect to the configured access point. If it is configured to use DHCP, it contacts a DHCP server to acquire a dynamic IP address and register its Hostname to the DNS server, otherwise it uses its configured static IP address. It then opens a WebSocket server listener port, and waits for a host to establish a connection using a WebSocket handshake. If any notification events occur before the host completes the handshake and establishes a connection, the device does not send the corresponding notifications, and it does not buffer while it waits for a host to establish a connection.

If you wish to test the device’s network connection before writing any code, you may choose to use the echo tool at [https://www.websocket.org/echo.html](https://www.websocket.org/echo.htmlhttps://websocket.org/tools/websocket-echo-server), which allows a WebSocket capable browser to connect directly to a local IP address and port to perform a simple echo operation.

To connect to the device, the host software must follow these steps:

{% stepper %}
{% step %}

### Know WebSocket Parameters

Know the WebSocket connection / handshake parameters:

* /host/ is the device’s IP address or IP name (if DNS is in use). By default, when using DHCP, the device registers its Hostname as its IP name. Suggest using the Hostname df-device serial number to keep each server unique. See the serial number label on the back of the device.
* /port/ is the port the device’s WebSocket server is listening on. Per the WebSocket standard, if the host does not specify a port, the connection assumes the default (port 80 for non-secure WebSocket, port 443 for secure WebSocket). For these devices, use the default port.
* /resource name/, /protocols/, and /extensions/ are not required because the device only communicates with a single host and uses binary WebSocket frames.
* /origin/ is not required per the WebSocket standard, because the host software is not a web browser.
* /secure/ is recommended.
  {% endstep %}

{% step %}

### Client Connections

As a WebSocket server, the device can be configured to accept up to four client connections at a time.
{% endstep %}

{% step %}

### Establish Handshake

Establish a connection using a standard WebSocket handshake.
{% endstep %}

{% step %}

### Keep Connection Open

Leave the connection open to listen for incoming WebSocket messages as binary WebSocket frames.
{% endstep %}

{% step %}

### Session End

The device will automatically disconnect from the client at the end of a session. See [<mark style="color:red;">**Command 0x1F03 - Extend Session (Session Management Only)**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands/device-control-command-group-0x1fnn/extend-session-session-management-only-command-0x1f03) for more details.
{% endstep %}

{% step %}

### Ping and Connection Monitoring

Spawn a process to send a WebSocket ping across the connection on a reasonable interval (such as 5 seconds) to make sure the connection is still alive. Note that WebSocket protocol keeps ping / pong and binary message traffic separate, so there is not a risk of collision between MMS messages and a ping. Upon detecting the connection is no longer functioning (such as during power interruptions, wireless interference or out-of-range, network outage, etc.), take appropriate action such as:

* Resetting the state of all host-side operations in process
* Reporting the connection state and recommended troubleshooting procedures to the operator
* Attempting to re-establish the connection
  {% endstep %}
  {% endstepper %}

### How to Send Commands Using the Wireless LAN (WLAN) Connection&#x20;

To send a command to the device using the WLAN connection:

{% stepper %}
{% step %}

### Ensure Open WebSocket

Make sure there is an open WebSocket connection. See How to Connect to a Device Using the Wireless LAN (WLAN) Connection for details.
{% endstep %}

{% step %}

### Choose Command

Choose the command to invoke from [<mark style="color:red;">**Commands**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands).
{% endstep %}

{% step %}

### Construct Request

Construct the command request message using the Request table in the command documentation. For a deeper explanation of the contents of request tables, see [<mark style="color:red;">**Commands**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands).
{% endstep %}

{% step %}

### Transmit Message

Transmit the full command request using the binary WebSocket message type (binary frames).
{% endstep %}

{% step %}

### Listen for Response

Listen for the device’s response, which will also come in as a binary WebSocket message type.
{% endstep %}

{% step %}

### Validate Message

Make sure the incoming message is the expected response, not an asynchronous notification.
{% endstep %}

{% step %}

### Parse Response

Parse the final response message using the Response table in the documentation for the command.
{% endstep %}
{% endstepper %}

### How to Receive Data Using the Wireless LAN (WLAN) Connection&#x20;

MMS devices use the same mechanism to send Response messages to host commands and to send unsolicited Notifications to the host when events occur, such as device state changes or user interactions.

The host software should always be listening for notification messages and should listen for command response messages after sending a command. Receiving the incoming message is the same in both cases, but notification messages, which are generally unpredictable, need to be routed to different handlers than responses, which are generally anticipated after sending a command.

The host should follow this general sequence to process notification messages incoming via WebSocket protocol:

{% stepper %}
{% step %}

### Ensure Open WebSocket

Make sure there is an open WebSocket connection. See How to Connect to a Device Using the Wireless LAN (WLAN) Connection for details.
{% endstep %}

{% step %}

### Route/Parse Message

After a WebSocket message arrives, determine the message type and message ID and route / parse it according to the corresponding Response table or Notification table in section 2.7.
{% endstep %}
{% endstepper %}

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** [support@magtek.com](mailto:support@magtek.com?subject=Support%20Request)
* 📞 **Phone:** 1-562-546-6800 (US)
* 🕐 **Hours:** Monday-Friday, 5:30 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Support Portal:** developer.magtek.com

**Documentation Feedback:**

Help us improve this documentation! [feedback@magtek.com](mailto:feedback@magtek.com?subject=Feedback)
{% endhint %}


# How to Use Bluetooth® LE Connections (Bluetooth® LE Only)

{% hint style="success" %}
Applies to: DynaFlex II PED, DynaFlex II Go, DynaFlex Pro/SCR (Geni I)
{% endhint %}

This section provides information about developing software for a Bluetooth® LE-capable host that needs to communicate with the device using Bluetooth® Low Energy (Bluetooth® LE). The device acts as a Bluetooth® LE server/peripheral, and the host acts as a client/central.

### About GATT Characteristics&#x20;

Messages are exchanged with the device using a service named “DynaFlex”. The UUID for this service is:&#x20;

{% code overflow="wrap" %}

```
0c ba 14 b7 ff 24 47 b0 be 09 26 44 05 38 53 0c 
```

{% endcode %}

in big endian order. This service contains the following characteristics.

Messages are sent to the device using a characteristic named “Message From Host”. The UUID for this service is&#x20;

{% code overflow="wrap" %}

```
47 f0 5f fa 59 09 49 69 bc 57 25 0d 47 e8 74 e5 
```

{% endcode %}

in big endian order. This characteristic supports the Write Request Attribute PDU Method. The value of this characteristic has a variable length. The maximum length is 244 bytes. The host must have performed secure connections pairing with the device before the device will allow it to write to this characteristic.

Messages are sent to the host using a characteristic named “Message To Host”. The UUID for this service is&#x20;

{% code overflow="wrap" %}

```
fe d4 91 18 c7 e2 4a 61 9e d5 e6 dd 65 c3 07 1b 
```

{% endcode %}

in big endian order. This characteristic only supports the Handle Value Notification Attribute PDU Method. The value of this characteristic has a variable length. The maximum length is 244 bytes. The host must have secure connections pairing with the device before the device will send notifications on this characteristic. The host must also enable notifications to be sent from this characteristic before the device will start sending messages on it.

Messages are exchanged with these characteristics using the DynaFlex Bluetooth® LE protocol. This protocol is described in the next section.

### DynaFlex Bluetooth® LE protocol&#x20;

This protocol was designed to meet the following goals:

* Exchange messages with the device.
* Maximize throughput.
* Allow the side receiving a message to detect if a message is partially or completely dropped.

Bluetooth® LE attribute protocol transmits data in protocol data units (PDUs). The maximum size of a PDU is determined by the maximum transmission unit (MTU) agreed on between the host and the device. The MTU is typically set to the minimum of the host and device’s ATT\_MTU size. DynaFlex’s ATT\_MTU size is 247 bytes. Most host’s ATT\_MTU sizes are larger than 247 bytes, so the MTU size agreed on between most hosts and DynaFlex’s is 247 bytes. Since application messages can be much larger than 247 bytes, application messages need to be able to be sent using multiple PDUs. Note that the minimum ATT\_MTU allowed for all hosts and devices is 23 bytes. To maximize throughput, all messages should be sent using the maximum MTU size possible. This protocol allows large application messages to be sent using multiple PDUs. The protocol format for sending and receiving messages is the same for both the host and device. The only difference is the characteristic used. Since the attribute opcode and attribute handle use 3 bytes of the MTU size the attribute value length for the message from host and message to host characteristics is limited to 247 - 3 = 244 bytes.

When a PDU is received in the application layer, it is guaranteed to be correct since Bluetooth® LE does error detection and retries in the lower layers. However, PDUs can be completely dropped if the device goes out of range of the host or bad interference occurs. So host applications should be written with appropriate error detection and handling to account for these potential drops.

### Protocol field definitions&#x20;

The following is the definition of each byte of a characteristic’s value for the DynaFlex Bluetooth® LE protocol:

* The first byte of the characteristic value is the message counter for every PDU. The message counter should be zero for the first message sent after every new BLE connection is established and should increase by one after sending every message. If its’ value is 0xff before it increments, it should have a value of zero after incrementing. All PDUs of a single message should have the same value for the message counter. The side receiving the message can use this counter to help detect if some PDUs of a message or if an entire message is dropped. The message counter for the message from host direction should be completely independent from the message counter for the message to host direction.
* The second byte of the characteristic value is the PDU counter for every PDU. The PDU counter should be zero for the first PDU of a message sent and should increase by one after sending every PDU of that message. If its’ value is 0xff before it increments, it should have a value of one instead of zero after incrementing. This is because the value of zero is reserved to always be used for the first PDU of a message. If the device receives a PDU counter of zero while it is still expecting more PDUs for an existing message, it shall discard any message that it is currently receiving and start receiving the new message. The first PDU of a message has a different protocol format than the remaining PDUs. The side receiving the message shall use this counter to help detect if some PDUs of a message are dropped. The PDU counter for the message from host direction should be completely independent from the PDU counter for the message to host direction.
  * If the PDU counter is zero indicating that this is the first PDU of a message, then the following paragraphs define the remaining bytes of the PDU, otherwise the remaining bytes of the PDU starting with the third byte contain the next portion of the application message.
  * If the PDU counter is zero indicating that this is the first PDU of a message, then the third byte of the PDU contains the protocol control byte (PCB). The protocol control byte is reserved and should always be set to zero. This byte may be used in the future to extend the protocol.
  * If the PDU counter is zero indicating that this is the first PDU of a message, then the fourth, fifth, sixth and seventh byte of the PDU contain the message length in big endian order. This is the length of the entire message not just the portion contained in the current PDU. The receiver of the message shall use this value to determine when it has received all the PDUs of a message.
  * If the PDU counter is zero indicating that this is the first PDU of a message, the remaining bytes of the PDU starting with the eighth byte contain the first portion of the application message. If the entire application message fits into one PDU then it contains all the application message.

## Example PDU sequence&#x20;

The following is an example of sending two application messages in a row where the first 9-byte message fits into a single PDU and the second 512-byte message requires 3 PDUs.

| Message Counter | PDU Counter | PCB | Message Length | Message Portion |
| --------------- | ----------- | --- | -------------- | --------------- |
| 00              | 00          | 00  | 00 00 00 09    | 9 bytes         |

| Message Counter | PDU Counter | PCB | Message Length          | Message Portion |
| --------------- | ----------- | --- | ----------------------- | --------------- |
| 01              | 00          | 00  | 00 00 02 00 (512 bytes) | 237 bytes       |

| Message Counter | PDU Counter | Message Portion |
| --------------- | ----------- | --------------- |
| 01              | 01          | 242 bytes       |

| Message Counter | PDU Counter | Message Portion |
| --------------- | ----------- | --------------- |
| 01              | 02          | 33 bytes        |

### Protocol implementation recommendations:

{% stepper %}
{% step %}

### Optimize Throughput

To optimize throughput, split large messages into the minimum number of PDUs by making all PDUs the agreed upon MTU size long (ideally 247 bytes) except for possibly the last PDU.
{% endstep %}

{% step %}

### Error Detection

Implement error detection that as a minimum detects and discards incomplete messages.
{% endstep %}

{% step %}

### Continue Receiving

If the device detects an incomplete message, it should be able to continue to receive new complete messages.
{% endstep %}

{% step %}

### Use Counters

Use the message counter, PDU counter and message length fields to detect incomplete messages.
{% endstep %}

{% step %}

### New Message Mid-Receive

When receiving a multiple PDU message and expecting more PDUs, if the next PDU has a PDU counter of zero discard the previous message and start receiving the new one.
{% endstep %}

{% step %}

### Look for First PDU

When looking for the first PDU of a message, if a PDU arrives that does not have a PDU counter of zero discard it.
{% endstep %}

{% step %}

### Message Counter Gaps

If the message counter advances by more than one between two messages, assume a message has been dropped. The device should ignore this situation. The host can ignore this situation too or implement error handling of its choice
{% endstep %}
{% endstepper %}

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** [support@magtek.com](mailto:support@magtek.com?subject=Support%20Request)
* 📞 **Phone:** 1-562-546-6800 (US)
* 🕐 **Hours:** Monday-Friday, 5:30 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Support Portal:** developer.magtek.com

**Documentation Feedback:**

Help us improve this documentation! [feedback@magtek.com](mailto:feedback@magtek.com?subject=Feedback)
{% endhint %}


# How to Use RS-232/UART Connections (SLIP Only)

To connect the host to the device using a serial connection such as RS-232 UART, configure the host’s serial port to use 115200 Baud, 8 Bit, No-parity, 1 Stop bit, and No flow control.

When using these connections, the host and device use SLIP format to send and receive MMS messages. For details, see section 2.6 How to Use SLIP Format (SLIP Only). The host software should always be ready to receive notification messages and command response messages from the device.

(BCR Only) When using the UART interface and the device is configured to be enable user action event notifications using Property 1.2.7.1.2.1 User Event Notification Controls Enable, the device cannot determine if it is connected to a host or not, therefore the device will continue reading barcode data even when not connected to a host.


# How to Use SLIP Format (SLIP Only)

For connection types that do not include error detection and correction, such as serial protocols, SLIP provides a means for the host and device to re-synchronize in the case of connection errors by watching for specifically reserved frame delimiters marking the start and end of a message. The MMS SLIP wrapper is defined in Table 9.

All messages start with SLIP’s frame delimiter C0, and must consider SLIP escape sequences that deal with occurrences of C0 inside the SLIP data frame:

* If an outbound message contains the byte value C0, software should encode it into SLIP as DB DC.
* If an inbound message contains the byte sequence DB DC, software should decode it to C0.
* If an outbound message contains the byte value DB, software should encode it into SLIP as DB DD.
* If an inbound message contains the byte sequence DB DD, software should decode it to DB.

Message Info indicates the direction of the message (such as Direction Host to Device for Commands, Direction Device to Host for Notifications). If the host has sent the device a command that exceeds the device’s incoming message buffer capacity, the device responds with a brief message indicating Hardware Capability Exceeded, and populates Length of MMS Message with the maximum possible message length the device can process, followed by a zero length MMS Message and the closing SLIP Frame Delimiter.

## Table - MMS SLIP Wrapper

| Offset     | Value                                                                                                            |
| ---------- | ---------------------------------------------------------------------------------------------------------------- |
| Byte 0     | SLIP Frame Delimiter = 0xC0                                                                                      |
| Byte 1     | Message Info 0x00 = Direction Host to Device 0x02 = Direction Device to Host 0x03 = Hardware Capability Exceeded |
| Bytes 2..5 | Length of MMS Message Use big endian order                                                                       |
| Bytes 6..n | MMS Message                                                                                                      |
| Byte n+1   | SLIP Frame Delimiter = 0xC0                                                                                      |

For further reference, see the definition of the SLIP format in Part D, Section 3 of Specification of the Bluetooth® System, Host Controller Interface, Volume 4, which is available at <https://www.bluetooth.org/Technical/Specifications/adopted.htm>. Note the reference to bluetooth.org is intentional, and the specification does indeed apply to other device connection types.


# How to Use Apple iAP2 Connections (iAP2 Only)

{% hint style="success" %}

### Applies to: DynaFlex II PED, DynaFlex II Go, DynaProx

{% endhint %}

### How to Use Apple iAP2 Connections (iAP2 Only)

This section provides information about developing an iOS app that interfaces with the device via the USB connector using iPod Accessory Protocol (iAP2). For sample code and other supporting materials, see [<mark style="color:red;">**SDKs & Tools**</mark>](https://developer.magtek.com/sdks-and-tools)

To develop host software for an iOS host that connects to the device, you must know the following device properties, which are specified by the purchaser when ordering, and loaded by the manufacturer:

* Apple iAP2 AppBundleID, also known as the SDK Protocol, usually in the form of a reverse DNS string unique to the host software developer or the device purchaser.

The host software should initiate a connection to the device using the iOS SDK’s ExternalAccessory Framework (for sample code, see Apple’s EADemo app). Upon establishing the connection, the host can begin exchanging data with the device.

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** [support@magtek.com](mailto:support@magtek.com?subject=Support%20Request)
* 📞 **Phone:** 1-562-546-6800 (US)
* 🕐 **Hours:** Monday-Friday, 5:30 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Support Portal:** developer.magtek.com

**Documentation Feedback:**

Help us improve this documentation! [feedback@magtek.com](mailto:feedback@magtek.com?subject=Feedback)
{% endhint %}


# EMV Acceptance

EMV acceptance is how your host runs a chip (contact) or contactless EMV sale on a DynaFamily reader. The reader runs the EMV kernel and communicates with the card; your host orchestrates the transaction over the MMS command set — starting it, responding to the reader's prompts, forwarding the ARQC to your processor, and returning the result. This guide walks the full flow on the MMS command path and links to the commands, notifications, and data objects that implement each step.

{% hint style="success" %}
Applies to: DynaFamily EMV-capable readers (DynaFlex II PED, Go, SCR, DynaProx). Examples use the DynaFlex II Go.
{% endhint %}

### How EMV acceptance works

The work is split between the reader and your host:

* **The reader** runs the EMV kernel, talks to the card, and encrypts cardholder data at the point of read (SRED).
* **Your host** starts the transaction, answers the reader's requests, forwards the ARQC to your processor, and returns the response.

There are **two integration surfaces** for this same flow. This guide covers the **MMS command set** directly. The Universal SDK wraps the identical flow in method calls and events — if you integrate through the SDK, the steps below still describe what happens underneath. (The <mark style="color:red;">**.NET EMV Transaction Flow**</mark> sample in the iDynamo manual shows the SDK surface.)

One behavior to note up front: readers **with a display** (e.g., the PED's touch screen) show cardholder prompts themselves. Readers **without a full display**, including the **DynaFlex II Go**, delegate those prompts to your host by sending [<mark style="color:red;">**Host Action Request – Notification 0x1803**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/notifications/notifications-from-user-interface-notification-source-0x18nn/user-interface-host-action-request-notification-0x1803); your host shows the message or collects the selection. Watch for that difference throughout.

### Before you start

* **The reader is connected** over USB or Bluetooth LE.
  * See [<mark style="color:red;">**Connection Basics**</mark>.](https://developer.magtek.com/get-started/connection-basics)
* **Keys are injected and you can decrypt output.**
  * See [<mark style="color:red;">**Security & Key Management**</mark>](https://developer.magtek.com/guides/guides/security-and-key-management)<mark style="color:red;">**.**</mark>
* **EMV configuration is loaded** (Terminal, Processing, Entry Point, and CA public keys).
* See **EMV Configuration** below.
* **You've chosen a flow** — Quick Chip or full EMV (see the fork below).

### The transaction flow

A typical contact or contactless sale runs as follows. Your host drives it with **Start Transaction** and reacts to the reader's notifications:

1. **(Optional) Early card presentation.** If the cardholder taps or inserts before you start, the reader sends [<mark style="color:red;">**Device Information Update – 0x1001**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/notifications/from-device-source-0x10nn/device-information-update-notification-0x1001) to tell your host to start a transaction now.
2. **Host starts the transaction.** Send [<mark style="color:red;">**Start Transaction – 0x1001**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands/transactions-command-group-0x10nn/start-transaction-command-0x1001) with the amount and type (transaction TLV, tag 86: `9C`, `9F02`, `5F2A`), the interfaces to enable (Reader Options, tag A3), a timeout (tag 82), and the flow-control bitmask (tag 84).
3. **Reader waits for the card.** It acknowledges and waits for the cardholder to insert, tap, or swipe. You can abort with [<mark style="color:red;">**Cancel Transaction – 0x1008**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands/transactions-command-group-0x10nn/cancel-transaction-command-0x1008).
4. **Card presented.** The reader sends [<mark style="color:red;">**Transaction Information Update – 0x0101**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/notifications/transactions-source-0x01nn/transaction-information-update-notification-0x0101) reporting the payment technology and a Card Event.
5. **Application selection (if needed).** If the card supports more than one application, a display reader prompts directly; the devic**e** sends [<mark style="color:red;">**Host Action Request – 0x1803**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/notifications/notifications-from-user-interface-notification-source-0x18nn/user-interface-host-action-request-notification-0x1803), and your host replies with [<mark style="color:red;">**Report Cardholder Selection – 0x1802**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/report-cardholder-selection-command-0x1802).
6. **ARQC produced.** The reader sends [<mark style="color:red;">**0x0101**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/notifications/transactions-source-0x01nn/transaction-information-update-notification-0x0101) again reporting a Data Update / ARQC Update, with the EMV ARQC object attached.
7. **Completion** depends on the flow you chose:

#### EMV Transaction Flow (online authorization)

Use this when the issuer must authorize online in real time.

* Your host processes the **ARQC**, sends it to the processor, receives the **ARPC**, and returns it to the reader with [<mark style="color:red;">**Resume Transaction – 0x1004**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands/transactions-command-group-0x10nn/resume-transaction-command-0x1004).
* The reader applies the issuer response, finishes with the card, and sends [<mark style="color:red;">**Transaction Operation Complete – 0x0105**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/notifications/transactions-source-0x01nn/transaction-operation-complete-notification-0x0105) reporting the kernel outcome (Approved or Declined).
* The result shows on-device on a display reader; on the **DynaFlex II Go** the reader sends <mark style="color:red;">**Host Action Request – 0x1803**</mark> so your host can display it.
* If your host is slow to return the ARPC, the reader retries and times out per its ARPC-timeout properties.

#### Quick Chip

The recommended flow for most retail — it minimizes how long the card stays in the reader.

* The reader builds its own internal ARPC (tag `8A` = `Z3`) and completes **immediately** with [<mark style="color:red;">**0x0105**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/notifications/transactions-source-0x01nn/transaction-operation-complete-notification-0x0105) ("Quick Chip Deferred"), so the cardholder can remove the card right away.
* Your host then processes the ARQC, sets the final amount, and coordinates with the processor out-of-band. The reader is **not** involved in the final approve/decline, so you display the result yourself (via [<mark style="color:red;">**Display Message – 0x1803**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/notifications/notifications-from-user-interface-notification-source-0x18nn/user-interface-operation-complete-notification-0x1805) on a display reader, or your own UI on the Go).
* Select it with the Transaction Flow bit in **tag 84** of <mark style="color:red;">**Start Transaction**</mark>.

### Working with EMV data objects

The transaction carries EMV data as TLV objects, each documented once in Data types & shared TLV objects. The ones you'll handle most:

<table data-header-hidden><thead><tr><th valign="middle"></th><th></th></tr></thead><tbody><tr><td valign="middle"><strong>Object</strong></td><td><strong>Description</strong></td></tr><tr><td valign="middle"><a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-arqc-type"><mark style="color:red;"><strong>EMV ARQC</strong></mark> </a></td><td>The authorization request you forward to the processor.</td></tr><tr><td valign="middle"><a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-arpc-type"><mark style="color:red;"><strong>EMV ARPC</strong></mark> </a></td><td>The issuer response you return via <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands/transactions-command-group-0x10nn/resume-transaction-command-0x1004"><mark style="color:red;"><strong>Resume Transaction</strong></mark></a><mark style="color:red;"><strong>.</strong></mark></td></tr><tr><td valign="middle"><a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-batch-data-type"><mark style="color:red;"><strong>EMV Batch Data</strong></mark></a></td><td>Clearing/settlement data returned at completion.</td></tr><tr><td valign="middle"><a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects"><mark style="color:red;"><strong>Terminal / Processing / Entry Point Configuration</strong></mark></a></td><td>Files that control kernel behavior (see <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects"><mark style="color:red;"><strong>EMV Configuration</strong></mark></a>).</td></tr><tr><td valign="middle"><a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-configuration-ca-public-keys-file-type"><mark style="color:red;"><strong>CA Public Keys</strong></mark> </a></td><td>Required for Offline Data Authentication (ODA).</td></tr><tr><td valign="middle"><a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-american-express-drl-configuration-file-type-not-supported-on-expresspay-4.x"><mark style="color:red;"><strong>American Express DRL Configuration</strong></mark></a></td><td> AmEx contactless DRL handling.</td></tr></tbody></table>

### Going online and decryption

When you take a transaction online, you forward the **ARQC** to your processor and return the **ARPC** via <mark style="color:red;">**Resume Transaction – 0x1004**</mark>. Two things to know:

* **Parts of the data are encrypted.** Portions of the EMV ARQC and EMV Batch Data objects are SRED-encrypted. To use them, your host must first determine which key was used, then decrypt.&#x20;
  * See <mark style="color:red;">**Encryption & Decryption**</mark>.
* **You can avoid handling clear PAN.** Magensa's Decrypt-and-Forward service lets you send the encrypted transaction straight to a processor without exposing cardholder data in your environment&#x20;
  * See <mark style="color:red;">**Magensa Services**</mark>.

### Contact vs. contactless

Both run the flow above; enable each interface in **Reader Options (tag A3)** on <mark style="color:red;">**Start Transaction**</mark>.

* **Contactless payments** (tap-to-pay, mobile wallets) follow the same ARQC/ARPC flow.
* **NFC tags** (non-payment) are different: the reader reports the card type and UID via **0x0101** and produces **no ARQC or Batch data** — you continue with pass-through commands.&#x20;
  * See <mark style="color:red;">**NFC / MIFARE**</mark>.
* **Wallet value-added services** (Apple VAS, Google Smart Tap) are configured through the wallet/VAS modes in **tag 84** —&#x20;
  * See NFC / MIFARE&#x20;
  * See <mark style="color:red;">**Google Wallet Smart Tap Integration.**</mark>

### EMV configuration

The kernel's behavior is controlled by configuration files you load onto the device:

* <mark style="color:red;">**Terminal Configuration**</mark>, <mark style="color:red;">**Processing Configuration**</mark>, and <mark style="color:red;">**Entry Point Configuration**</mark> control the contact and contactless kernels.
* <mark style="color:red;">**CA Public Keys**</mark> enable Offline Data Authentication.
* Load them using the file-operations commands and the file-type definitions in the data-object pages above.
* **To clear or reset a configuration**, load the file type with `EMPTY` content — worked hex examples are in <mark style="color:red;">**Appendix C: Erasing EMV Configurations**</mark>.

### Certification (EMV L3)

Your device and payment application must be L3-certified with each processor. Dyna-family readers share a **common EMV kernel**, so certifying one family member can carry to the others, and Quick Chip is included in Magensa's L3 certifications.&#x20;

* For the full strategy and the discovery questions to scope your certification, see <mark style="color:red;">**L3 Certification Guideline.**</mark>

### Related

### **Commands**

<table data-header-hidden><thead><tr><th valign="middle"></th><th></th></tr></thead><tbody><tr><td valign="middle"><strong>Command</strong></td><td><strong>Description</strong></td></tr><tr><td valign="middle"><mark style="color:red;"><strong>Start Transaction 0x1001</strong></mark></td><td>The host uses this command to start a payment transaction.</td></tr><tr><td valign="middle"><mark style="color:red;"><strong>Resume Transaction 0x1004</strong></mark></td><td>The host uses this command to provide the device with additional/modified data to resume a transaction that is currently paused.</td></tr><tr><td valign="middle"><mark style="color:red;"><strong>Cancel Transaction 0x1008</strong></mark></td><td>The host can use this command to cancel a transaction in progress that it initiated using Start Transaction.</td></tr><tr><td valign="middle"><mark style="color:red;"><strong>Report Cardholder Selection 0x1802</strong></mark></td><td>The host uses this command to provide a cardholder selection to the device when the device itself does not have a display or inputs to prompt the cardholder for a selection.</td></tr></tbody></table>

### **Notifications**

<table data-header-hidden><thead><tr><th valign="middle"></th><th></th></tr></thead><tbody><tr><td valign="middle"><strong>Notification</strong></td><td><strong>Description</strong></td></tr><tr><td valign="middle"><mark style="color:red;"><strong>Transaction Information Update 0x0101</strong></mark></td><td>During a transaction.</td></tr><tr><td valign="middle"><mark style="color:red;"><strong>Transaction Operation Complete 0x0105</strong></mark></td><td>Upon completion of a transaction</td></tr><tr><td valign="middle"><mark style="color:red;"><strong>Host Action Request 0x1803</strong></mark></td><td>This notification requests that the host take action during operations involving the device’s User Interface modules.</td></tr></tbody></table>

### **Data Types**

<table data-header-hidden><thead><tr><th valign="middle"></th><th></th></tr></thead><tbody><tr><td valign="middle"><strong>Type</strong></td><td><strong>Description</strong></td></tr><tr><td valign="middle"><mark style="color:red;"><strong>EMV ARQC Type</strong></mark></td><td>Information on how the device formats ARQC messages.</td></tr><tr><td valign="middle"><mark style="color:red;"><strong>EMV ARPC Type</strong></mark></td><td>Information on how the device formats ARPC messages,</td></tr><tr><td valign="middle"><mark style="color:red;"><strong>EMV Batch Data Type</strong></mark></td><td>Information on the device formats EMV batch data, such as merchant data and pre-defined EMV batch data tags.</td></tr><tr><td valign="middle"><mark style="color:red;"><strong>Configuration Objects</strong></mark></td><td>All Configuration Object Types can be found in <mark style="color:red;"><strong>Data Types and Shared TLV Data Objects</strong></mark> Section. </td></tr></tbody></table>

### **Guides**

<table data-header-hidden><thead><tr><th valign="middle"></th><th></th></tr></thead><tbody><tr><td valign="middle"><strong>Guide</strong></td><td><strong>Description</strong></td></tr><tr><td valign="middle"><mark style="color:red;"><strong>Security &#x26; Key Management</strong></mark></td><td>This section covers how DynaFamily readers protect cardholder data and manage keys.</td></tr><tr><td valign="middle"><mark style="color:red;"><strong>NFC / MIFARE</strong></mark></td><td>DynaFamily readers with a contactless interface can exchange commands directly with NFC tags and MIFARE cards through <mark style="color:red;"><strong>pass-through commands</strong></mark> and can present themselves as a card to another reader through NFC card emulation. </td></tr><tr><td valign="middle"><mark style="color:red;"><strong>L3 Certification Guidelines</strong></mark></td><td>Pursuing an L3 Certification (Level 3 Certification) with an EMV (Europay, Mastercard, Visa) payment processor involves several steps.</td></tr></tbody></table>

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** <support@magtek.com>
* 📞 **Phone:** 1-800-788-6835 (US) | +1-562-546-6616 (International)
* 🕐 **Hours:** Monday-Friday, 6:00 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Official Site:** [https://www.magtek.com](https://www.magtek.com/)
* 💬 **Developer Forum:** [https://forum.magtek.com](https://forum.magtek.com/)

**Documentation Feedback:**

Help us improve this documentation! [Submit feedback](broken://spaces/1lWLescKFIPsMeIJI6Cd/pages/5314c528980689961380bea0044c1256aaeb39bc)
{% endhint %}


# L3 Certification Guidelines

## Guidelines For Pursuing Certification

Pursuing an L3 Certification (Level 3 Certification) with an EMV (Europay, Mastercard, Visa) payment processor involves several steps. Level 3 Certification typically pertains to testing and certifying integrated circuit cards (ICCs) with advanced functionalities, such as contactless payments. Here are the general steps you might follow, but keep in mind that specific requirements may vary based on the EMV payment processor and the region.

## Initial Considerations

#### UNDERSTAND EMV SPECIFICATIONS:

Familiarize yourself with the EMV specifications, especially those related to Level 3 testing. This may include understanding the EMVCo specifications and guidelines.

#### CONTACT THE PAYMENT PROCESSOR:

Reach out to the specific EMV payment processor with which you want to achieve Level 3 Certification. Obtain information on their certification process, requirements, and any necessary documentation. Be sure to verify Expiry Dates for the payment device's L1 or L2 certifications.

Proceed to Step 3 only after Steps 1 and 2 are 100% complete.

## SECONDARY <a href="#secondary_considerations" id="secondary_considerations"></a>

#### CONSIDERATIONS

**MEET PREREQUISITES:**

* Ensure that you meet any prerequisites set by the EMV payment processor. This might include having successfully completed Level 1 and Level 2 certifications.

**PREPARE TEST ENVIRONMENT:**

* Set up a test environment that replicates real-world scenarios for payment transactions. Include the necessary hardware, software, and test cards to perform comprehensive testing.
* Obtain test card or tools as defined by the processor. Most will require a purchased ICC or UL tool kit.
* Identify if MagTek/Magensa test environments need to be enabled. This could be Magensa Decrypt and Forward or Magensa Decrypt.
* In the absence of Magensa Decrypt an Forward or Magensa Decrypt, identify key creation and distribution activities.&#x20;

**DOCUMENTATION AND APPLICATION FORMS:**

* Complete any required documentation or application forms provided by the EMV payment processor. This may involve providing details about your system architecture, specifications, and other relevant information.

**INTEGRATION AND DEVELOPMENT:**

* Integrate your payment application with the EMV payment processor's test environment. Develop and modify your application to support the necessary Level 3 functionalities.

**TESTING:**

* Conduct thorough testing of your integrated circuit cards in the test environment. This includes testing various scenarios, such as contact and contactless transactions, to ensure compliance with EMV specifications.

**SUBMIT TEST RESULTS:**

* Provide the test results to the EMV payment processor for evaluation. This may involve submitting detailed reports, logs, and any other requested information.

**ADDRESS FEEDBACK:**

* If the payment processor provides feedback or identifies issues during the testing process, address them promptly. Make the necessary adjustments to your system to ensure compliance.

**FINAL CERTIFICATION:**

* Once the system successfully passes all required tests and meets the EMV specifications, the payment processor may issue the Level 3 Certification LOA.

**STAY INFORMED:**

* Stay informed about any updates or changes to EMV specifications. Regularly check for new guidelines and requirements to maintain compliance.

{% hint style="info" %}
**Note**: The specifics of the process may vary, and it is advisable to work closely with the EMV payment processor, as well as refer to the latest documentation provided by EMVCo and the specific payment processor you are dealing with.
{% endhint %}

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** <support@magtek.com>
* 📞 **Phone:** 1-800-788-6835 (US) | +1-562-546-6616 (International)
* 🕐 **Hours:** Monday-Friday, 6:00 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Official Site:** [https://www.magtek.com](https://www.magtek.com/)
* 💬 **Developer Forum:** [https://forum.magtek.com](https://forum.magtek.com/)

**Documentation Feedback:**

Help us improve this documentation! [Submit feedback](broken://spaces/1lWLescKFIPsMeIJI6Cd/pages/5314c528980689961380bea0044c1256aaeb39bc)
{% endhint %}


# Security & Key Management

This section covers how DynaFamily readers protect cardholder data and manage keys: encrypting data at the point of read, the keys and key-serial numbers behind DUKPT, verifying message integrity with MACs, loading keys with TR-31, and the PCI requirements deployers must meet. These pages are the concepts and procedures; the <mark style="color:red;">**security commands**</mark> and <mark style="color:red;">**data objects**</mark> that implement them live in the <mark style="color:red;">**API & Command Reference**</mark>.

{% hint style="success" %}
Applies to: DynaFamily (DynaFlex II PED, Go, SCR, DynaProx). The core concepts — DUKPT, KSN, MAC, TR-31 — apply to MagTek MMS SCRAs generally.
{% endhint %}

### In This Section

<table data-header-hidden><thead><tr><th valign="middle"></th><th></th></tr></thead><tbody><tr><td valign="middle"><strong>Reference Section</strong></td><td><strong>Information Available</strong></td></tr><tr><td valign="middle"><mark style="color:red;"><strong>DUKPT: 3DES/TDEA --> AES Migration</strong></mark></td><td>How DUKPT derives a unique key per transaction, and the path (and reasons) for moving from legacy 3DES/TDEA DUKPT to AES DUKPT on your devices and host.</td></tr><tr><td valign="middle"><mark style="color:red;"><strong>Key Serial Numbers (KSN)</strong></mark></td><td>What a KSN is, how it's structured, and how it identifies the unique key used to encrypt a given transaction under DUKPT.</td></tr><tr><td valign="middle"><mark style="color:red;"><strong>Message Authentication Codes (MAC)</strong></mark></td><td>How a MAC lets the host and device confirm a message hasn't been altered in transit, and when one is required.</td></tr><tr><td valign="middle"><mark style="color:red;"><strong>Encryption &#x26; Decryption</strong></mark></td><td>How the reader encrypts data at the point of read (SRED), how to determine which key was used, and how to decrypt the output on your host.</td></tr><tr><td valign="middle"><mark style="color:red;"><strong>TR-31 Key Blocks</strong></mark></td><td>The ANSI TR-31 key-block format used to transport and load keys securely into the device.</td></tr><tr><td valign="middle"><mark style="color:red;"><strong>PCI requirements (24-hour Reset, device lock)</strong></mark> </td><td>The operational requirements the device enforces for PCI compliance: the 24-hour automatic reset and the device lock feature.</td></tr></tbody></table>

### Where to Find Security Information

The <mark style="color:red;">**Guides**</mark> section (where you are now) contains articles on implementation. actual commands and objects live in the <mark style="color:red;">**API & Command Reference**</mark> section:

**Key Security Commands**

<table data-header-hidden><thead><tr><th valign="middle"></th><th></th></tr></thead><tbody><tr><td valign="middle"><strong>Reference Section</strong></td><td><strong>Information Available</strong></td></tr><tr><td valign="middle"><mark style="color:red;"><strong>Get Challenge</strong></mark></td><td>Requests a random challenge from the device, used to build a secured command.</td></tr><tr><td valign="middle"><mark style="color:red;"><strong>Send Secured Command to Device</strong></mark> </td><td>Transmits another command to the device securely.</td></tr><tr><td valign="middle"><mark style="color:red;"><strong>Load Key using TR-31</strong></mark></td><td>Loads a key into one of the device's secure key slots.</td></tr><tr><td valign="middle"><mark style="color:red;"><strong>Challenge Device lock State/Passcode</strong></mark></td><td>Change the device's lock state or its lock passcode.</td></tr><tr><td valign="middle"><mark style="color:red;"><strong>Get Key Info</strong></mark></td><td>Retrieves information about a key slot and the key stored in it.</td></tr><tr><td valign="middle"><mark style="color:red;"><strong>PCI requirements (24-hour Reset, device lock)</strong></mark> </td><td>The operational requirements the device enforces for PCI compliance: the 24-hour automatic reset and the device lock feature.</td></tr></tbody></table>

### Security Data Objects

Individual Security Data Objects can be found in the <mark style="color:red;">**Data Types & Shared TLV Objects**</mark> section.&#x20;

<table data-header-hidden><thead><tr><th valign="middle"></th><th></th></tr></thead><tbody><tr><td valign="middle"><strong>Reference Section</strong></td><td><strong>Information Available</strong></td></tr><tr><td valign="middle"><mark style="color:red;"><strong>Security Operation</strong></mark></td><td>This non-TLV data structure consists of four or five bytes that describes a security operation, including the algorithms and methods to be used in that operation.</td></tr><tr><td valign="middle"><mark style="color:red;"><strong>Security Parameters</strong></mark></td><td>This structure contains an Encrypted Signature Capture FileType specifying the operation to be performed.</td></tr><tr><td valign="middle"><mark style="color:red;"><strong>Key Information</strong></mark></td><td> Identifies the key being used for operation.</td></tr><tr><td valign="middle"><mark style="color:red;"><strong>TR-31 Key Block</strong></mark></td><td>The data object, its tags, and structure (in the command reference).</td></tr></tbody></table>

### For More Help

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** <support@magtek.com>
* 📞 **Phone:** 1-800-788-6835 (US) | +1-562-546-6616 (International)
* 🕐 **Hours:** Monday-Friday, 6:00 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Official Site:** [https://www.magtek.com](https://www.magtek.com/)
* 💬 **Developer Forum:** [https://forum.magtek.com](https://forum.magtek.com/)

**Documentation Feedback:**

Help us improve this documentation! [Submit feedback](broken://spaces/1lWLescKFIPsMeIJI6Cd/pages/5314c528980689961380bea0044c1256aaeb39bc)
{% endhint %}


# DUKPT: 3DES/TDEA -> AES Migration

## **DEVELOPER GUIDE**

When is the right time to transition to AES DUKPT and what needs to be considered?

### INITIAL CONSIDERATIONS

#### A Brief History <a href="#a_brief_history" id="a_brief_history"></a>

Since the 1970s the electronic payments and secure banking communities have strived to provide their customers with greater convenience, faster speeds, and improved security for electronic transactions. Throughout this timeline, the Open Standards Community, comprised of the International Standards Organization (ISO) and the American National Standards Institute (ANSI-X9), have led the way with the development of numerous security standards that have provided an open platform for proper implementation of accepted encryption and authentication methods. This platform was further augmented in 2007 when the PCI Security Standards council adopted these standards and provided a superset of additional guidance and requirements for PCI DSS.

Collectively, the Open Standards and PCI Security Standards communities have provided a trusted foundation for guiding the global implementation of accepted security methods for Electronic Payments and Secure Banking.

Paramount amongst these security standards has been defining the use of encryption and authentication technologies for the protection of customer PINs and payment data.&#x20;

**TDEA ENCRYPTION WITH DUKPT KEY MANAGEMENT**

Since 1998, the use of Triple DES (3DES), also known as Triple Data Encryption Algorithm (TDEA), in combination with DUKPT Key Management (Derived Unique Key Per Transaction) has been the gold-standard for protection of PINs and payment data. To its credit, the TDEA DUKPT platform continues to serve its community well and has never yet suffered a “real world” security compromise.

That said, numerous universities and security labs have conducted research and published data that suggests the security capabilities of TDEA DUKPT may soon be challenged (and surpassed) by security threats from advanced computing platforms that will brute-force calculations at ever faster speeds (e.g., quantum computers). These threats may soon provide a viable path for attackers to “crack” the TDEA DUKPT level of security. To mitigate these threats, stronger encryption and authentication methods are required.&#x20;

### **AES DUKPT ENCRYPTION**

In anticipation of increased security threats to the TDEA DUKPT platform, the Open Standards community released a new set of improved security standards in 2017 that support AES DUKPT. (Reference: ANSI X9.24-3) The AES DUKPT standards provide a pathway to improved security features that are significantly stronger and more resistant to brute-force attacks. Specifically, these standards use the AES algorithm (Advanced Encryption Standard) in conjunction with an updated DUKPT specification. AES-128 DUKPT and AES-256 DUKPT are the new standards.

AES-128 uses crypto keys that are 128-bits in length and AES-256 uses crypto keys that are 256-bits in length. Both are far more secure than the existing TDEA DUKPT implementation that uses crypto keys that provide only 112-bits of key strength.

In the world of cryptography, each additional bit represents an order-of-magnitude improvement in security. The larger AES key sizes represent a significant improvement in encryption protection from attackers. In addition, the AES algorithm itself provides numerous security improvements for faster calculation speeds and reduces the possibilities of crypto-analysis side-channel attacks.

### **CMAC AUTHENTICATION**

In addition to stronger AES encryption, CMAC (cipher-based message authentication code) authentication enhances the security of sensitive data. In this context, CMAC authentication is the cryptographic process of validating that the encrypted sensitive data has not been manipulated or altered from its original form. The authentication process begins within the trusted hardware reader device, where prior to AES encryption, the sensitive clear-text data has a cryptographic CMAC calculation applied to it using a secret MAC key. This results in a unique 6-digit CMAC checksum that is unique to the sensitive data.

The sensitive data is then AES encrypted within the hardware reader device and the CMAC checksum is included with the encrypted data packet that is transferred to a trusted decryption host. Upon receipt at the trusted decryption host, the sensitive data is both decrypted and CMAC validated to confirm that clear-text sensitive data is still in its original form and without alteration or compromise.

Combined, the use of AES DUKPT encryption in combination with CMAC data authentication provides a powerful “one-two punch” that ensures sensitive data remains protected and intact.

### Initial Decisions

**Planning your Roadmap**

TDEA DUKPT is in its twilight era and needs to be replaced by the more secure AES DUKPT platform. The benefits of doing so are improved security and higher confidence that financial transaction data will remain safe for now and into the future.

To stay ahead of potential threats, PCI has been encouraging the electronic payments community to begin the migration from TDEA DUKPT to AES DUKPT to protect both PIN and payment data. Although no mandates have been made, the threat landscape is expanding, and the urgency to migrate towards more secure encryption is accelerating.

## What developers need to consider when creating their roadmap to AES encryption.

* **WHAT DATA DO I NEED TO PROTECT? WHAT PROTECTION SHOULD I USE?**
  * Ideally, to meet PCI DSS requirements, it is necessary to protect sensitive PAN (Personal Account Number) payment data and/or PIN (Personal Identification Number) data so that the clear-text sensitive data is never stored, transmitted, or available within the merchant’s payment systems. To do this, it is recommended to use AES DUKPT to protect this sensitive data.
* **IS THERE A REQUIREMENT TO AUTHENTICATE DATA?**
  * No. PCI DSS only requires that sensitive data be protected/encrypted. However, this document recommends that CMAC authentication be used when available, as it provides an additional layer of security to ensure that sensitive data has not been altered from its original form. This will direct which decryption host services, card readers, and PIN entry devices are used to meet this extra level of security.

### SECONDARY CONSIDERATIONS <a href="#secondary_considerations" id="secondary_considerations"></a>

After determining the data that needs to be protected and the best protection method, the next step is to determine how to build out the complete ecosystem including the customer environment, hardware, and services.&#x20;

* **WHAT HARDWARE DO I NEED?**
  * To move to AES DUKPT encryption, you will need a card reader / PIN entry device (PED) that is specifically rated and approved to support AES DUKPT operations. Check the data sheet of your device or speak with the product support team from your vendor. Ideally, the device should be a “PCI Approved” device rated as “PCI 6.x” (or higher) and list AES support.
* **DO I NEED NEW KEYS?**
  * Yes, you will minimally need to have a new AES BDK generated as your Data Protection Key. If the reader device also supports PIN entry, an additional AES BDK is required as your PIN Protection Key. Regarding AES Key Size, you will need to select between 128-bits or 256-bits. Typically, the card reader / PED vendor provides key-generation and key-injection services.
* **WHAT ABOUT DECRYPTION SERVICES?**
  * You will need to check with your existing Payment Gateway / Decryption service and validate that they can support AES DUKPT decryption for your specific reader device. Ensure they can support both AES-128 and AES-256 key sizes. Additionally, you should check if they can provide CMAC data validation services.
* **AES-128 VS AES-256 KEY SIZE? WHICH ONE SHOULD I CHOOSE?**
  * All things being equal, it is preferable to migrate to AES-256 DUKPT. Doing so ensures that you are using the maximum level of encryption protection available. However, in some cases you may discover that certain products / services only support AES-128 DUKPT. In that case, it is your preference. Although AES-256 DUKPT is strongest, AES-128 DUKPT still provides encryption that is substantially stronger than TDEA DUKPT and is fully supported by PCI.
* **HOW DO I INJECT THE NEW AES KEY(s)?**
  * Typically, all newly ordered reader devices are injected with their AES key(s) from the factory during the initial order process. For devices already in the field, these devices can typically be updated via remote management services. Check with your reader vendor for details.
* &#x20;**CAN I STILL USE MY TDEA DUKPT DEVICES DURING THE MIGRATION TO AES?**
  * Yes. There should be no problems with operating a “mixed fleet” of both TD

### CONCLUSION <a href="#conclusion" id="conclusion"></a>

Transitioning from TDEA DUKPT to AES DUKPT requires a plan and trusted partners. MagTek and Magensa have a complete solution of integrated hardware, services, and support to make this migration simple, fast, and painless. Partner with us today and let us show you how to migrate to a higher-security AES DUKPT platform that provides maximum data protection for your customers and your business.

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** <support@magtek.com>
* 📞 **Phone:** 1-800-788-6835 (US) | +1-562-546-6616 (International)
* 🕐 **Hours:** Monday-Friday, 6:00 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Official Site:** [https://www.magtek.com](https://www.magtek.com/)
* 💬 **Developer Forum:** [https://forum.magtek.com](https://forum.magtek.com/)

**Documentation Feedback:**

Help us improve this documentation! [Submit feedback](broken://spaces/1lWLescKFIPsMeIJI6Cd/pages/5314c528980689961380bea0044c1256aaeb39bc)
{% endhint %}


# Key Serial Numbers (KSNs)

\
The device can use two different types of keys: Triple Data Encryption Standard (TDES) DUKPT Keys and AES DUKPT Keys. The Key Serial Number (KSN) format is slightly different depending on which type of key is injected into the key slot that is being used by the operation being performed or the data being passed.

When the device and host are using TDES keys, the Key Serial Number (KSN) is an 80-bit value. The rightmost 21 bits are the current value of the encryption counter associated with that key. The leftmost 59 bits are the Initial KSN for that key, which is specified during key injection and is a combination of the Key Set ID that identifies the Base Derivation Key (BDK) injected into the device during manufacture, and the device’s serial number (DSN); how those two values are combined into the 59 bit Initial KSN is defined by a convention the customer defines when architecting the solution, with support from MagTek.For example, one common scheme is to concatenate:

* a 7 hex digit (28 bit) Key Set ID,
* a 7 hex digit (28 bit) Device Serial Number,
* and a 3 bit Initial Key Load Counter the injecting host increments each time the same key is re-loaded into the device.

In these cases, the key can be referenced by an 8-digit MagTek part number (“key ID”) consisting of the 7 hex digit Key Set ID plus a trailing “0.”

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** <support@magtek.com>
* 📞 **Phone:** 1-800-788-6835 (US) | +1-562-546-6616 (International)
* 🕐 **Hours:** Monday-Friday, 6:00 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Official Site:** [https://www.magtek.com](https://www.magtek.com/)
* 💬 **Developer Forum:** [https://forum.magtek.com](https://forum.magtek.com/)

**Documentation Feedback:**

Help us improve this documentation! [Submit feedback](broken://spaces/1lWLescKFIPsMeIJI6Cd/pages/5314c528980689961380bea0044c1256aaeb39bc)
{% endhint %}


# Message Authentication Codes (MAC)

“MAC” is an abbreviation of Message Authentication Code, which is a string of bytes included in a message that can be used to provide reasonable assurance that the message originated from a trusted source and has not been modified.

### MACs for EMV Data

This section describes how to calculate MACs for EMV ARQC and EMV Batch Data.

The key and variant used to calculate the MAC is determined by how the DUKPT Key Mapping is mapped; this can be set up for TDES or AES mode.

The key used to calculate the MAC is normally the same key used to encrypt the encrypted data included as part of the same data structure. For TDES MAC, the key variant is always Message Authentication, Request or Both Ways. For AES MAC, this can be AES-128 or AES-256; the valid usages are: 0x08 = MAC Generate, 0x0A = MAC Generate/Verify.

**For TDES MAC:**

* ANSI X9.24-3-2017
* The MAC operations follow the CBC procedure described in ISO 16609 Section C.4 using padding method 1 defined in ISO 9797 section 6.1.1.

**For AES CMAC:**

* NIST Special Publication 800-38B Section 6.2 MAC Generation

The data structure for both EMV ARQC and EMV Batch Data has the following format related to MACing:

{% code overflow="wrap" %}

```
AAAA /* 2-byte MSB message length excluding padding and CBC-MAC */

F9<len> /* container for MAC structure and generic data */ DFDF54(MAC KSN)<len><val>

​DFDF55(MAC Encryption Type)<len><val> DFDF25(IFD Serial Number)<len><val>

<Nested TLV data objects specific to the message>
​
<Padding to force the 2-byte MSB message length plus F9 plus padding to be a multiple of 8 bytes>
​
<Four byte CBC-MAC of all data starting with the 2-byte MSB message length and ending with the last byte of padding (if any)>
```

{% endcode %}

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** <support@magtek.com>
* 📞 **Phone:** 1-800-788-6835 (US) | +1-562-546-6616 (International)
* 🕐 **Hours:** Monday-Friday, 6:00 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Official Site:** [https://www.magtek.com](https://www.magtek.com/)
* 💬 **Developer Forum:** [https://forum.magtek.com](https://forum.magtek.com/)

**Documentation Feedback:**

Help us improve this documentation! [Submit feedback](broken://spaces/1lWLescKFIPsMeIJI6Cd/pages/5314c528980689961380bea0044c1256aaeb39bc)
{% endhint %}


# Encryption & Decryption

For EMV ARQC and EMV Batch Data, the device encrypts data using TDES in CBC-like chaining without an Initial Vector:

* The device begins by TDES encrypting the first 8 bytes of clear text data. The 8-byte result is placed in an encrypted data buffer.
* Continue using TDES CBC method with the encrypted 8 bytes XORed with the next 8 bytes of clear text; encrypt that result and place it into the encrypted data buffer.
* Repeat until all clear text bytes have been encrypted.
* If the final block of clear text contains fewer than 8 bytes, the device pads the end of the block to make 8 bytes.
* After the final clear text block is XORed with the prior 8 bytes of encrypted data, the device encrypts it and places it in the encrypted data value.
* No Initial Vector is used.

The host must decrypt the data in 8-byte blocks, ignoring any final unused bytes in the last block. When a value consists of more than one block, use the CBC method to decrypt the data by following these steps:

{% stepper %}
{% step %}

### Start with the last block

Start decryption on the last block of 8 bytes (call it block N) using the key.
{% endstep %}

{% step %}

### XOR with previous block

XOR the result of the decryption with the next-last block of 8 bytes (block N-1).
{% endstep %}

{% step %}

### Repeat backwards

Repeat until reaching the first block.
{% endstep %}

{% step %}

### First block handling

Do not XOR the first block with anything.
{% endstep %}

{% step %}

### Concatenate blocks

Concatenate all blocks.
{% endstep %}

{% step %}

### Truncate padding

Determine the expected length of the decrypted data (for EMV ARQC and EMV Batch Data this information is included as part of the unencrypted data structure) and truncate the end of the decrypted data block to the expected data length, which discards the padding at the end.
{% endstep %}
{% endstepper %}

### How to Determine the Key

When the device and the host are using TDES DUKPT key and the device is encrypting data, the host software must generate a key (the “derived key”) to use for decryption.

{% stepper %}
{% step %}

### Determine the Initial Key loaded into the device

The lookup methods the host software uses depend on the overall solution architecture and are outside the scope of this document. Most solutions do this in one of two ways, both of which use the Initial Key Serial Number that arrives with the encrypted data:

* Look up the value of the Base Derivation Key using the Initial KSN portion of the current KSN as an index value, then use TDES DUKPT algorithms to calculate the value of the Initial Key; or
* Look up the value of the Initial Key directly, using the Initial KSN portion of the current KSN as an index value.
  {% endstep %}

{% step %}

### Derive the current key

Apply TDES DUKPT algorithms to the Initial Key value and the encryption counter portion of the KSN that arrives with the encrypted data.
{% endstep %}

{% step %}

### Determine key variant used by the device

Determine which variant of the current key the device used to encrypt. The variants are defined in ANS X9.24-1:2009 Annex A. Which variant the host should use depends on the type of data the host is decrypting. The encrypted portions of EMV ARQC and EMV Batch Data both use the Data Encryption, Request or Both Ways variant.
{% endstep %}

{% step %}

### Calculate the variant and decrypt

Use the variant algorithm with the current key to calculate that variant, then decrypt the data according to the steps in How to Decrypt Data.
{% endstep %}
{% endstepper %}

### How to Decrypt Data

For EMV ARQC and EMV Batch Data, the device encrypts data using TDES in CBC-like chaining without an Initial Vector:

* The device begins by TDES encrypting the first 8 bytes of clear text data. The 8-byte result is placed in an encrypted data buffer.
* Continue using TDES CBC method with the encrypted 8 bytes XORed with the next 8 bytes of clear text; encrypt that result and place it into the encrypted data buffer.
* Repeat until all clear text bytes have been encrypted.
* If the final block of clear text contains fewer than 8 bytes, the device pads the end of the block to make 8 bytes.
* After the final clear text block is XORed with the prior 8 bytes of encrypted data, the device encrypts it and places it in the encrypted data value.
* No Initial Vector is used.

The host must decrypt the data in 8-byte blocks, ignoring any final unused bytes in the last block. When a value consists of more than one block, use the CBC method to decrypt the data by following these steps:

{% stepper %}
{% step %}

### Start with the last block

Start decryption on the last block of 8 bytes (call it block N) using the key.
{% endstep %}

{% step %}

### XOR with previous block

XOR the result of the decryption with the next-last block of 8 bytes (block N-1).
{% endstep %}

{% step %}

### Repeat backwards

Repeat until reaching the first block.
{% endstep %}

{% step %}

### First block handling

Do not XOR the first block with anything.
{% endstep %}

{% step %}

### Concatenate blocks

Concatenate all blocks.
{% endstep %}

{% step %}

### Truncate padding

Determine the expected length of the decrypted data (for EMV ARQC and EMV Batch Data this information is included as part of the unencrypted data structure) and truncate the end of the decrypted data block to the expected data length, which discards the padding at the end.
{% endstep %}
{% endstepper %}

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** <support@magtek.com>
* 📞 **Phone:** 1-800-788-6835 (US) | +1-562-546-6616 (International)
* 🕐 **Hours:** Monday-Friday, 6:00 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Official Site:** [https://www.magtek.com](https://www.magtek.com/)
* 💬 **Developer Forum:** [https://forum.magtek.com](https://forum.magtek.com/)

**Documentation Feedback:**

Help us improve this documentation! [Submit feedback](broken://spaces/1lWLescKFIPsMeIJI6Cd/pages/5314c528980689961380bea0044c1256aaeb39bc)
{% endhint %}


# TR-31 Key Blocks

TR-31 is an ANSI standard format for securely transporting a cryptographic key from one system to another. Instead of sending a key as raw bytes, the sender wraps it in a **key block** that binds the key to information about how it may be used — so a key can't be moved to a device and then used for a purpose it was never intended for. Dyna-family readers use TR-31 to load keys into their secure key slots.

Two pieces work together:

* <mark style="color:red;">**TR-31 Key Block (data object)**</mark> — the format itself: a header describing the key's attributes (type, algorithm, allowed usage, mode) plus the encrypted key and a MAC that protects the whole block from tampering. This is what you build and hand to the device.
* <mark style="color:red;">**Load Key Using TR-31 (command)**</mark> — the command that delivers a TR-31 key block to the reader and loads it into a key slot. The device validates the block, then stores the key for use.

### When you'll use it

Loading or rotating a key on the device — for example, provisioning an initial DUKPT key or updating a key later in the field. The TR-31 format is how the key gets there safely; how DUKPT then uses that key per transaction is covered in the security guides.

### Learn more

<table data-header-hidden><thead><tr><th valign="middle"></th><th></th></tr></thead><tbody><tr><td valign="middle"><strong>Reference Section</strong></td><td><strong>Information Available</strong></td></tr><tr><td valign="middle"><mark style="color:red;"><strong>TR-31 Key Block</strong></mark></td><td>The data object, its tags, and structure (in the command reference).</td></tr><tr><td valign="middle"><mark style="color:red;"><strong>Load Key using TR-31</strong></mark></td><td>Loads a key into one of the device's secure key slots.</td></tr><tr><td valign="middle"><mark style="color:red;"><strong>Security &#x26; Key Management</strong></mark></td><td>DUKPT, key serial numbers (KSN), and how keys are used once loaded.</td></tr></tbody></table>

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** <support@magtek.com>
* 📞 **Phone:** 1-800-788-6835 (US) | +1-562-546-6616 (International)
* 🕐 **Hours:** Monday-Friday, 6:00 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Official Site:** [https://www.magtek.com](https://www.magtek.com/)
* 💬 **Developer Forum:** [https://forum.magtek.com](https://forum.magtek.com/)

**Documentation Feedback:**

Help us improve this documentation! [Submit feedback](broken://spaces/1lWLescKFIPsMeIJI6Cd/pages/5314c528980689961380bea0044c1256aaeb39bc)
{% endhint %}


# PCI Requirements

### PCI Requirements

Due to Payment Card Industry (PCI) certification requirements, the device must automatically reset at least once every 24 hours. This is required for security purposes, so that the device can reinitialize memory and perform a self-test. Host software developers and potentially end users should be aware of this.

By default, the device will automatically reset 23 hours after it boots up and it will attempt to send a warning notification message to the host 3 minutes before the reset occurs.

The default behavior is adjustable. See the following for more information:

* Property 1.2.7.1.1.4 Auto Reset Configuration
* Property 1.2.7.1.1.3 Device Reset Will Occur Soon Notification Control
* Device Reset Will Occur Soon notification in Notification 0x1001 - Device Information Update

One way the host software could handle receiving a device reset-will-occur notification:

1. Cancel any operation that is in process (for example, a transaction) if it is unlikely to end before the reset.
2. Optionally send Command 0x1F01 - Reset Device instead of waiting for the automatic reset to occur.
3. Re-connect with the device and re-start any operation that was in process.

### Device Lock feature

The purpose of locking a device is to disable most of the device’s functionality for use cases that need this extra layer of security. When a device is locked, it will reject all commands except for a few. Use of the device lock feature is optional. It is not required by PCI.

* The device lock state can be either unlocked or locked. The device lock state can be retrieved by getting a property.
* The device lock state can be changed by setting a secure property or it can be changed with a command that requires knowledge of the device lock passcode.
* The device can be configured to always have the device lock state set to locked after a reset or power cycle by setting a property.
* If the device has a display and the device is locked, the welcome screen will display “WELCOME” “Device is Locked”. This screen can be customized.
* The device lock passcode can be changed by setting a secure property or it can be changed with a command that requires knowledge of the current device lock passcode.

Commands and properties to manage the device lock feature:

* Command 0xEF06 – Change Device Lock State
* Command 0xEF07 – Change Device Lock Passcode
* Property 1.2.3.1.1.2 Custom Idle Page Image Device Locked (Display Only)
* Property 1.2.5.2.1.1 Device Lock State
* Property 1.2.5.2.1.2 Device Lock State After Reset
* Property 1.2.5.2.1.3 Device Lock Passcode

Only the following commands are allowed when the device lock state is set to locked:

* Command 0x1F01 - Reset Device
* Command 0x1F03 - Extend Session (Session Management Only)
* Command 0x1F04 – Terminate Bluetooth® LE Connection (Bluetooth® LE Only)
* Command 0xD101 - Get Property
* Command 0xD112 - Set Property (Secured)
* Command 0xDF01 - Echo
* Command 0xE001 - Get Challenge
* Command 0xEF06 – Change Device Lock State
* Command 0xEF09 – Encrypt User Data
* Command 0xEEEE - Send Secured Command to Device

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** <support@magtek.com>
* 📞 **Phone:** 1-800-788-6835 (US) | +1-562-546-6616 (International)
* 🕐 **Hours:** Monday-Friday, 6:00 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Official Site:** [https://www.magtek.com](https://www.magtek.com/)
* 💬 **Developer Forum:** [https://forum.magtek.com](https://forum.magtek.com/)

**Documentation Feedback:**

Help us improve this documentation! [Submit feedback](broken://spaces/1lWLescKFIPsMeIJI6Cd/pages/5314c528980689961380bea0044c1256aaeb39bc)
{% endhint %}


# NFC/MIFARE

DynaFamily readers with a contactless interface can exchange commands directly with NFC tags and MIFARE cards through **pass-through commands** and can present themselves as a card to another reader through NFC card emulation. This guide explains the supported card technologies and how contactless support is organized; the **pass-through commands** themselves live in the [<mark style="color:red;">**API & Command Reference**</mark>](https://developer.magtek.com/api-and-command-reference)<mark style="color:red;">**.**</mark>

{% hint style="success" %}
Applies to: DynaFamily readers with a contactless (NFC) interface — DynaFlex II PED, Go, SCR, and DynaProx.
{% endhint %}

### Supported card technologies

The reader provides a pass-through command for each supported tag family, letting your host send commands to, and receive responses from, the card directly:

* **NTag / MIFARE Ultralight (Type 2)**&#x20;
  * Pass-through for NTag and MIFARE Ultralight tags.
* **MIFARE Classic / MINI / Plus SL1 (Type 2)**&#x20;
  * Pass-through for an activated MIFARE Classic, MINI, or Plus SL1 tag.
* **MIFARE DESFire (Type 4)**&#x20;
  * Pass-through for MIFARE DESFire tags.
* **MIFARE Plus (Type 2)**&#x20;
  * Pass-through for MIFARE Plus tags.

Each card's unique identifier is returned as the NFC UID data object.

### How pass-through works

Once the reader detects and activates a contactless tag, your host sends tag-specific commands through the matching pass-through command above and reads the tag's responses.\
For lower-level access to any card that supports the ISO 14443-4 APDU, use [<mark style="color:red;">**Generic Pass-through**</mark> ](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands/generic-pass-through-commands-command-group-0x30nn)<mark style="color:red;">**Commands**</mark>. Entering and leaving pass-through mode is handled by[ <mark style="color:red;">**Pass-Through Mode Start/Stop**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands/generic-pass-through-commands-command-group-0x30nn/pass-through-mode-start-stop-command-0x3001), and [<mark style="color:red;">**Start/Stop Polling**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands/generic-pass-through-commands-command-group-0x30nn/start-top-polling-command-0x3002) requests the reader to poll for a card.

### Card emulation (DynaCast)

Beyond reading tags, the reader can emulate a card so it can be read by another NFC device — the basis for MagTek's [<mark style="color:red;">**DynaCast NFC card-emulation use cases**</mark>](/guides/guides/dynacast-nfc-card-emulation-and-the-business-use-cases). Card emulation is initiated with the [<mark style="color:red;">**Card Emulation**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/card-emulation-command-0x1840) command, using the Card Emulation data object.

### Related Integrations

| **Section**                                                                                                                                                                                        | **Information**                                                                                                                                                                                                 |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [​<mark style="color:red;">**Google Wallet Smart Tap**</mark>](/guides/guides/google-wallet-smart-tap-integration)                                                                                 | A worked integration using the reader's contactless interface for Google Wallet value-added services (VAS) transactions, including connecting the device, sending the command set, and adding a Smart Tap pass. |
| [<mark style="color:red;">​</mark><mark style="color:red;">**DynaCast, NFC Card Emulation, and Business Use Cases**</mark>](/guides/guides/dynacast-nfc-card-emulation-and-the-business-use-cases) | Background on card-emulation scenarios and where they apply.                                                                                                                                                    |

### See also

| **Section**                                                                                                                                                                                                                                          | **Information**                         |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------- |
| [​<mark style="color:red;">**NFC / MIFARE Pass-through Commands**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands/nfc-mifare-pass-through-commands-contactless-only-command-group-0x11nn) | The full command group in the reference |
| [<mark style="color:red;">**Generic Pass-through**</mark> ](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands/generic-pass-through-commands-command-group-0x30nn)                                   | Polling and raw APDU access             |

### For M[ore Help](#user-content-fn-1)[^1]

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** <support@magtek.com>
* 📞 **Phone:** 1-800-788-6835 (US) | +1-562-546-6616 (International)
* 🕐 **Hours:** Monday-Friday, 6:00 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Official Site:** [https://www.magtek.com](https://www.magtek.com/)
* 💬 **Developer Forum:** [https://forum.magtek.com](https://forum.magtek.com/)

**Documentation Feedback:**

Help us improve this documentation! [Submit feedback](broken://spaces/1lWLescKFIPsMeIJI6Cd/pages/5314c528980689961380bea0044c1256aaeb39bc)
{% endhint %}

[^1]:


# Firmware & File Operations

File operations let your host move files to and from the reader — firmware images, EMV configuration files, certificates, and more. All of them use the File Operations command group and share the Common File Structure format. The most common file operation is updating firmware, covered first below.

{% hint style="success" %}
Applies to: DynaFamily (DynaFlex II PED, Go, SCR, DynaProx). Examples use the DynaFlex II Go.
{% endhint %}

### Updating firmware

Firmware images are signed by MagTek and delivered as a Firmware File Type object. There are two ways to apply one — a code path and a Windows utility.

#### Using the commands

1. **Get the signed image.** Obtain the firmware file for your device (see Getting firmware files below).
2. **Send it to the device** with Load Firmware File – 0xD801, supplying the image type (boot loader, main app, Wi-Fi, or BLE module), a SHA-256 hash of the image, the payload, and a **Load Option** (Default or Auto Commit). The device must have **more than 5% battery** or it won't run the command.
3. **The device validates and authenticates** the signed image.
4. **Commit the image:**
   * If you sent **Auto Commit**, the device commits automatically.
   * Otherwise (Default mode), commit it with Commit Firmware from File – 0xD901.
5. **The device reports the result** and resets: Firmware Update Successful – 0x0905 or Firmware Update Failed – 0x0906. If the image is already current, the device sends Firmware is Up to Date – 0x0907.

#### Using the Firmware Update Utility (Windows)

If you don't need to script it, MagTek's Windows utility performs the same update through a GUI — see How to use the Firmware Update Utility.

### Working with other files

The same command group handles non-firmware files — for example loading EMV configuration or certificate files, or retrieving files from the device:

| **Section**                                                                        | **Information**                                    |
| ---------------------------------------------------------------------------------- | -------------------------------------------------- |
| <mark style="color:red;">**Start Send File to Device (Secured) – 0xD811**</mark>   | Send a file that must be sent securely.            |
| <mark style="color:red;">**Start Send File to Device (Unsecured) – 0xD812**</mark> | Send a file that doesn't require a secure channel. |
| <mark style="color:red;">**Start Get File from Device – 0xD821**</mark>            | Retrieve a file from the device.                   |
| <mark style="color:red;">**Get File Info from Device – 0xD825**</mark>             | Read a file's metadata without downloading it.     |
| <mark style="color:red;">**Delete File from Device – 0xD831**</mark>               | Remove a file.                                     |

For how files are framed, see About Files and the Common File Structure data object. Loading and erasing EMV configuration files specifically is covered in EMV acceptance.

### Checking the firmware version

To read the device's current firmware before or after an update, use the Firmware Identification Information properties.

### Getting firmware files

Firmware images and the Windows utility are downloads, not part of this guide — find the files for your device on its **Firmware & downloads** page, or in Downloads & compliance.

### Related

### Commands

| **Section**                                                                      | **Information**                                                                                                                                                                                                                                                                                     |
| -------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <mark style="color:red;">**Load Firmware File 0xD801**</mark>                    | The host uses this command to send a firmware image file, signed by MagTek, to the device as the first step in updating firmware.                                                                                                                                                                   |
| <mark style="color:red;">**Commit Firmware from File 0xD901**</mark>             | The host uses this command to commit a file previously uploaded using Command 0xD801 into the device’s permanent memory after the device has authenticated the file.                                                                                                                                |
| <mark style="color:red;">**Start Get File from Device – 0xD821**</mark>          | The host uses this command to request a file stored on the device. File types include standard files (images and certificates), MagTek custom files (configuration, firmware), and in some cases even large data blob output (such as signature capture data).                                      |
| <mark style="color:red;">**Start Send File to Device (Secured) 0xD811**</mark>   | The host uses this command to start sending secured files to the device for storage or processing. It is similar to Start Send File to Device (Unsecured),  but is used to send a different subset of file types that impact device security and require some form of authentication from the host. |
| <mark style="color:red;">**Start Send File to Device (Unsecured) 0xD812**</mark> | The host uses this command to start sending unsecured files to the device for storage or processing. It is similar to Start Send File to Device (Secured) but is used to send a different subset of file types that do not impact device security.                                                  |
| <mark style="color:red;">**Start Get File from Device 0xD821**</mark>            | \`The host uses this command to request a file stored on the device. File types include standard files (images and certificates), MagTek custom files (configuration, firmware), and in some cases even large data blob output (such as signature capture data).                                    |
| <mark style="color:red;">**Get File Info 0xD825**</mark>                         | The host uses this command to request the file information of a file stored on the device. File types include standard files (images and certificates), MagTek custom files (configuration, firmware), and in some cases even large data blob output (such as signature capture data).              |
| <mark style="color:red;">**Delete File 0xD831**</mark>                           | The host uses this command to request the deletion of a file stored on the device.                                                                                                                                                                                                                  |

### Notifications

| **Section**                                                           | **Information**                                                                                                                                             |
| --------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <mark style="color:red;">**Firmware Update Successful 0x0905**</mark> | This notification reports the successful completion of firmware update operations the host initiated using Load Firmware File and Commit Firmware from File |
| <mark style="color:red;">**Firmware Update Failed 0x0906**</mark>     | This notification reports the failure of a Firmware Update command the host initiated using Load Firmware File and Commit Firmware from File.               |
| <mark style="color:red;">**Firmware is Up to Date 0x0907**</mark>     | This notification reports Firmware is up to date for host initiated Load Firmware File.                                                                     |

### Guides

| **Section**                                        | **Information**                   |
| -------------------------------------------------- | --------------------------------- |
| <mark style="color:red;">**EMV acceptance**</mark> | Guide to loading EMV config files |

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** <support@magtek.com>
* 📞 **Phone:** 1-800-788-6835 (US) | +1-562-546-6616 (International)
* 🕐 **Hours:** Monday-Friday, 6:00 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Official Site:** [https://www.magtek.com](https://www.magtek.com/)
* 💬 **Developer Forum:** [https://forum.magtek.com](https://forum.magtek.com/)

**Documentation Feedback:**

Help us improve this documentation! [Submit feedback](broken://spaces/1lWLescKFIPsMeIJI6Cd/pages/5314c528980689961380bea0044c1256aaeb39bc)
{% endhint %}


# PAN vs. DPAN/Network Tokens

When you handle card data, it helps to know exactly which "number" you're holding — the real account number, a network's stand-in, or a token you created to avoid storing the real one. They look similar but carry very different sensitivity and PCI obligations.

### PAN — the real account number

The **PAN (Primary Account Number)** is the actual card number on a physical card. It's sensitive data and is fully in PCI scope. On a Dyna-family reader, PAN read from a card is encrypted at the point of read (SRED) and carried inside the transaction data (for example, within the EMV ARQC) — your host works with the encrypted form and decrypts only where authorized. See Encryption & decryption.

### DPAN — the network token used by wallets

A **DPAN (Device PAN)** is a **network token** that stands in for the real PAN. When a card is added to a mobile wallet (Apple Pay, Google Pay), the wallet stores a DPAN rather than the real card number. So when a cardholder taps, the reader receives the DPAN plus a cryptogram — **not** the underlying account number. The DPAN maps back to the real PAN only at the payment network. In practice this means contactless wallet taps inherently carry a network token, which reduces the value of the data if it's ever exposed.

### Tokens — replacing the PAN in your own systems

Separately from anything the network does, you can replace a PAN in **your** environment with a token so you never store the sensitive number. MagTek's Magensa <mark style="color:red;">**TokenExchange**</mark> is a cloud, vaultless tokenization service that does this via REST APIs, with a few token types:

* **Payment tokens** — for standard payment operations (sale, refund).
* **Transaction tokens** — for tokenized payment links or QR codes.
* **PII tokens** — for non-payment sensitive data.

See <mark style="color:red;">**TokenExchange**</mark> and <mark style="color:red;">**TokenExchange Connect**</mark>.

### Telling them apart

* **PAN** — the real, sensitive card number; protect and encrypt it, and it's in full PCI scope.
* **DPAN / network token** — the network's stand-in a wallet presents on tap; you receive this instead of the PAN for wallet transactions.
* <mark style="color:red;">**TokenExchange**</mark>**&#x20;token** — a stand-in **you** generate to keep the PAN out of your systems entirely.

The short version: a PAN is the sensitive number itself; a DPAN is the network's substitute used in device/wallet transactions; and a <mark style="color:red;">**TokenExchange**</mark> token is the substitute you use in place of the PAN in your own applications.

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** <support@magtek.com>
* 📞 **Phone:** 1-800-788-6835 (US) | +1-562-546-6616 (International)
* 🕐 **Hours:** Monday-Friday, 6:00 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Official Site:** [https://www.magtek.com](https://www.magtek.com/)
* 💬 **Developer Forum:** [https://forum.magtek.com](https://forum.magtek.com/)

**Documentation Feedback:**

Help us improve this documentation! [Submit feedback](broken://spaces/1lWLescKFIPsMeIJI6Cd/pages/5314c528980689961380bea0044c1256aaeb39bc)
{% endhint %}


# Google Wallet Smart Tap Integration

**Document Number: D998200680-100**

**REGISTERED TO ISO 9001:2015**

MagTek I 1710 Apollo Court I Seal Beach, CA 90740 I Phone: (562) 546-6400 I Technical Support: (888) 624-8350 [www.magtek.com](http://www.magtek.com/)

Copyright © 2018 - 2024 MagTek, Inc. Printed in the United States of America

INFORMATION IN THIS PUBLICATION IS SUBJECT TO CHANGE WITHOUT NOTICE AND MAY CONTAIN TECHNICAL INACCURACIES OR GRAPHICAL DISCREPANCIES. CHANGES OR IMPROVEMENTS MADE TO THIS PRODUCT WILL BE UPDATED IN THE NEXT PUBLICATION RELEASE. NO PART OF THIS DOCUMENT MAY BE REPRODUCED OR TRANSMITTED IN ANY FORM OR BY ANY MEANS, ELECTRONIC OR MECHANICAL, FOR ANY PURPOSE, WITHOUT THE EXPRESS WRITTEN PERMISSION OF MAGTEK, INC.

MagTek®, MagnePrint®, and MagneSafe® are registered trademarks of MagTek, Inc. Magensa™ is a trademark of MagTek, Inc.

DynaFlex™, DynaFlex Pro™, DynaProx™, DynaFlex II SCRA™, DynaFlex II PED™, and DynaFlex II GO™ are trademarks of MagTek, Inc.

AAMVA™ is a trademark of AAMVA.

American Express® and EXPRESSPAY FROM AMERICAN EXPRESS® are registered trademarks of American Express Marketing & Development Corp.

D-PAYMENT APPLICATION SPECIFICATION® is a registered trademark to Discover Financial Services CORPORATION

MasterCard® is a registered trademark and PayPass™ and Tap & Go™ are trademarks of MasterCard International Incorporated.

Visa® and Visa payWave® are registered trademarks of Visa International Service Association.

&#x20;ANSI®, the ANSI logo, and numerous other identifiers containing "ANSI" are registered trademarks, service marks, and accreditation marks of the American National Standards Institute (ANSI).

ISO® is a registered trademark of the International Organization for Standardization. UL™ and the UL logo are trademarks of UL LLC.

PCI Security Standards Council® is a registered trademark of the PCI Security Standards Council, LLC. EMV® is a registered trademark in the U.S. and other countries and an unregistered trademark elsewhere. The EMV trademark is owned by EMVCo, LLC. The Contactless Indicator mark, consisting of four graduating arcs, is a trademark owned by and used with permission of EMVCo, LLC.

The *Bluetooth*® word mark and logos are registered trademarks owned by Bluetooth SIG, Inc. and any use of such marks by MagTek is under license.

Google Play™ store, Google Wallet™ payment service, and Android™ platform are trademarks of Google Inc.

Apple Pay®, iPhone®, iPod®, Mac®, and OS X® are registered trademarks of Apple Inc., registered in the U.S. and other countries. iPad™ is a trademark of Apple. Inc. App Store<sup>SM</sup> is a service mark of Apple Inc., registered in the U.S. and other countries. IOS is a trademark or registered trademark of Cisco in the U.S. and other countries and is used by Apple Inc. under license.

Microsoft®, Windows®, and .NET® are registered trademarks of Microsoft Corporation. NFC is governed by The NFC Forum.

All other system names and product names are the property of their respective owners.

## Table - Revisions

<table data-header-hidden><thead><tr><th valign="top"></th><th valign="top"></th><th valign="top"></th></tr></thead><tbody><tr><td valign="top">Rev Number</td><td valign="top">Date</td><td valign="top">Notes</td></tr><tr><td valign="top">100</td><td valign="top">September 24, 2024</td><td valign="top">Initial Release</td></tr></tbody></table>

### LIMITED WARRANTY <a href="#bookmark0" id="bookmark0"></a>

MagTek warrants that the products sold pursuant to this Agreement will perform in accordance with

MagTek’s published specifications. This warranty shall be provided only for a period of one year from the date of the shipment of the product from MagTek (the “Warranty Period”). This warranty shall apply only to the “Buyer” (the original purchaser, unless that entity resells the product as authorized by MagTek, in which event this warranty shall apply only to the first repurchaser).

During the Warranty Period, should this product fail to conform to MagTek’s specifications, MagTek will, at its option, repair or replace this product at no additional charge except as set forth below. Repair parts and replacement products will be furnished on an exchange basis and will be either reconditioned or new. All replaced parts and products become the property of MagTek. This limited warranty does not include service to repair damage to the product resulting from accident, disaster, unreasonable use, misuse, abuse, negligence, or modification of the product not authorized by MagTek. MagTek reserves the right to examine the alleged defective goods to determine whether the warranty is applicable.

Without limiting the generality of the foregoing, MagTek specifically disclaims any liability or warranty for goods resold in other than MagTek’s original packages, and for goods modified, altered, or treated without authorization by MagTek.

Service may be obtained by delivering the product during the warranty period to MagTek (1710 Apollo Court, Seal Beach, CA 90740). If this product is delivered by mail or by an equivalent shipping carrier, the customer agrees to insure the product or assume the risk of loss or damage in transit, to prepay shipping charges to the warranty service location, and to use the original shipping container or equivalent. MagTek will return the product, prepaid, via a three (3) day shipping service. A Return Material

Authorization (“RMA”) number must accompany all returns. Buyers may obtain an RMA number by contacting MagTek Support Services at (888) 624-8350.

**EACH BUYER UNDERSTANDS THAT THIS MAGTEK PRODUCT IS OFFERED AS-IS. MAGTEK MAKES NO OTHER WARRANTY, EXPRESS OR IMPLIED, AND MAGTEK DISCLAIMS ANY WARRANTY OF ANY OTHER KIND, INCLUDING ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.**

**IF THIS PRODUCT DOES NOT CONFORM TO MAGTEK’S SPECIFICATIONS, THE SOLE REMEDY SHALL BE REPAIR OR REPLACEMENT AS PROVIDED ABOVE. MAGTEK’S LIABILITY, IF ANY, SHALL IN NO EVENT EXCEED THE TOTAL AMOUNT PAID TO MAGTEK UNDER THIS AGREEMENT. IN NO EVENT WILL MAGTEK BE LIABLE TO THE BUYER FOR ANY DAMAGES, INCLUDING ANY LOST PROFITS, LOST SAVINGS, OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OF, OR INABILITY TO USE, SUCH PRODUCT, EVEN IF MAGTEK HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR FOR ANY CLAIM BY ANY OTHER PARTY.**

**LIMITATION ON LIABILITY**

EXCEPT AS PROVIDED IN THE SECTIONS RELATING TO MAGTEK’S LIMITED WARRANTY, MAGTEK’S LIABILITY UNDER THIS AGREEMENT IS LIMITED TO THE CONTRACT PRICE OF THIS PRODUCT.

MAGTEK MAKES NO OTHER WARRANTIES WITH RESPECT TO THE PRODUCT, EXPRESSED OR IMPLIED, EXCEPT AS MAY BE STATED IN THIS AGREEMENT, AND MAGTEK DISCLAIMS ANY IMPLIED WARRANTY, INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

MAGTEK SHALL NOT BE LIABLE FOR CONTINGENT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES TO PERSONS OR PROPERTY. MAGTEK FURTHER LIMITS ITS LIABILITY OF ANY KIND WITH RESPECT TO THE PRODUCT, INCLUDING NEGLIGENCE ON ITS PART, TO THE CONTRACT PRICE FOR THE GOODS.

MAGTEK’S SOLE LIABILITY AND BUYER’S EXCLUSIVE REMEDIES ARE STATED IN THIS SECTION AND IN THE SECTION RELATING TO MAGTEK’S LIMITED WARRANTY.

### SOFTWARE LICENSE AGREEMENT <a href="#bookmark1" id="bookmark1"></a>

IMPORTANT: YOU SHOULD CAREFULLY READ ALL THE TERMS, CONDITIONS AND RESTRICTIONS OF THIS LICENSE AGREEMENT BEFORE INSTALLING THE SOFTWARE PACKAGE. YOUR INSTALLATION OF THE SOFTWARE PACKAGE PRESUMES YOUR ACCEPTANCE OF THE TERMS, CONDITIONS, AND RESTRICTIONS CONTAINED IN THIS AGREEMENT. IF YOU DO NOT AGREE WITH THESE TERMS, CONDITIONS, AND RESTRICTIONS, PROMPTLY RETURN THE SOFTWARE PACKAGE AND ASSOCIATED DOCUMENTATION TO THE ADDRESS ON THE FRONT PAGE OF THIS DOCUMENT, ATTENTION: CUSTOMER SUPPORT.

**TERMS, CONDITIONS, AND RESTRICTIONS**

MagTek, Incorporated (the "Licensor") owns and has the right to distribute the described software and documentation, collectively referred to as the "Software."

LICENSE: Licensor grants you (the "Licensee") the right to use the Software in conjunction with MagTek products. LICENSEE MAY NOT COPY, MODIFY, OR TRANSFER THE SOFTWARE IN WHOLE OR IN PART EXCEPT AS EXPRESSLY PROVIDED IN THIS AGREEMENT. Licensee

may not decompile, disassemble, or in any other manner attempt to reverse engineer the Software. Licensee shall not tamper with, bypass, or alter any security features of the software or attempt to do so.

TRANSFER: Licensee may not transfer the Software or license to the Software to another party without the prior written authorization of the Licensor. If Licensee transfers the Software without authorization, all rights granted under this Agreement are automatically terminated.

COPYRIGHT: The Software is copyrighted. Licensee may not copy the Software except for archival purposes or to load for execution purposes. All other copies of the Software are in violation of this Agreement.

TERM: This Agreement is in effect as long as Licensee continues the use of the Software. The Licensor also reserves the right to terminate this Agreement if Licensee fails to comply with any of the terms, conditions, or restrictions contained herein. Should Licensor terminate this Agreement due to Licensee's failure to comply, Licensee agrees to return the Software to Licensor. Receipt of returned Software by the Licensor shall mark the termination.

LIMITED WARRANTY: Licensor warrants to the Licensee that the disk(s) or other media on which the Software is recorded are free from defects in material or workmanship under normal use.

THE SOFTWARE IS PROVIDED AS IS. LICENSOR MAKES NO OTHER WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

Because of the diversity of conditions and PC hardware under which the Software may be used, Licensor does not warrant that the Software will meet Licensee specifications or that the operation of the Software will be uninterrupted or free of errors.

IN NO EVENT WILL LICENSOR BE LIABLE FOR ANY DAMAGES, INCLUDING ANY LOST PROFITS, LOST SAVINGS, OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE, OR INABILITY TO USE, THE SOFTWARE. Licensee's sole remedy in

the event of a defect in material or workmanship is expressly limited to replacement of the Software disk(s) if applicable.

GOVERNING LAW: If any provision of this Agreement is found to be unlawful, void, or unenforceable, that provision shall be removed from consideration under this Agreement and will not affect the enforceability of any of the remaining provisions. This Agreement shall be governed by the laws of the State of California and shall inure to the benefit of MagTek, Incorporated, its successors or assigns.

ACKNOWLEDGMENT: LICENSEE ACKNOWLEDGES THAT HE HAS READ THIS AGREEMENT, UNDERSTANDS ALL OF ITS TERMS, CONDITIONS, AND RESTRICTIONS, AND AGREES TO BE BOUND BY THEM. LICENSEE ALSO AGREES THAT THIS AGREEMENT SUPERSEDES ANY AND ALL VERBAL AND WRITTEN COMMUNICATIONS BETWEEN LICENSOR AND LICENSEE OR THEIR ASSIGNS RELATING TO THE SUBJECT MATTER OF THIS AGREEMENT.

QUESTIONS REGARDING THIS AGREEMENT SHOULD BE ADDRESSED IN WRITING TO MAGTEK, INCORPORATED, ATTENTION: CUSTOMER SUPPORT, AT THE ADDRESS LISTED IN THIS DOCUMENT, OR E-MAILED TO [SUPPORT@MAGTEK.COM.](mailto:support@magtek.com)

DEMO SOFTWARE / SAMPLE CODE: Unless otherwise stated, all demo software and sample code are to be used by Licensee for demonstration purposes only and MAY NOT BE incorporated into any production or live environment. The PIN Pad sample implementation is for software PIN Pad test purposes only and is not PCI compliant. To meet PCI compliance in production or live environments, a third-party PCI compliant component (hardware or software-based) must be used.

<br>


# Introduction

## About This Document

This document provides instructions to use the *DynaFlex, DynaProx Utility* software for configuring a device to accept Google Wallet Smart Tap Passes. It is part of a larger library of documents designed to assist implementers. For details, see the product Support pages on [www.magtek.com.](http://www.magtek.com/)

The following documents are essential:

* D998200383 DynaFlex Family Programmer’s Manual ( COMMANDS )

## System Requirements <a href="#id-1.2_system_requirements" id="id-1.2_system_requirements"></a>

* A Windows 10 host with available USB port
* Microsoft .NET 4.6.1 and above installed on the host
* Microsoft Access Database Engine 2016 Redistributable installed on the host
* USB-C cable with USB Type-A or USB-C for host connection
* Software *1000007406 DynaFlex, DynaProx Utility*, provided by MagTek

## How to Download, Install, and Launch the Software <a href="#id-1.3_how_to_download-_install-_and_launch" id="id-1.3_how_to_download-_install-_and_launch"></a>

To download *DynaFlex, DynaProx Utility* software, follow these steps.

* &#x20;Download the software with the name *1000007406.zip (DynaFlex, DynaProx Utility*) from MagTek.
* Extract the .zip file on the host’s hard drive.
* Install the *AccessDatabaseEngine.exe* from the folder *Access Database Engine* in the extracted folder.
* Download and install Microsoft .NET 4.6.1 or above from [https://dotnet.microsoft.com/download/dotnet-framework.](https://dotnet.microsoft.com/download/dotnet-framework)
* Launch *DynaFlexUtility.exe*.
* See the steps in the sections below to connect to a device.

## Device Requirements <a href="#id-1.4_device_requirements" id="id-1.4_device_requirements"></a>

* For Apple VAS and Google Wallet VAS transactions, see instructions for configuration in the SDK document appendix:
  * D998200380 MAGTEK UNIVERSAL SDK PROGRAMMER'S MANUAL (MICROSOFT.NET)


# How to Connect to Devices Using DynaFlex Utility

To connect via an interface listed in the Connection Type box, follow these steps.

## How to Connect Using the USB Connection <a href="#id-2.1_how_to_connect_using_the_usb_connect" id="id-2.1_how_to_connect_using_the_usb_connect"></a>

* For best results, use the cable that is included with the device.
* Connect the USB-C end of the cable to DynaFlex device.

<figure><img src="/files/wV0qQMpMIPtBet3wd4Ai" alt=""><figcaption></figcaption></figure>

<p align="center"><strong>Figure - Connecting DynaFlex to a USB Host</strong></p>

* If you plan to route the cable out the back of the device, route the cable through the cable management clip to change its direction. Even if you are not routing out the back, you may use the cable clip for strain relief, to help stabilize the mechanical connection when cardholders or operators move the device or the cable.
* Route the cable in the desired direction (e.g., out the back, left, right, or down into the countertop).
* Connect the other end of the USB cable to the host’s USB port.
* As soon as the device starts receiving power through USB, it automatically powers on.
* Launch the DynaFlex Utility and select DynaFlex device in the Device Type list, then press the connect button.

<figure><img src="/files/12QppdezBLcZP12XkUaF" alt=""><figcaption></figcaption></figure>

* The Output log shows the status of the connection.

<figure><img src="/files/WcNQ8j5hDlFvVEcmLDjj" alt=""><figcaption></figcaption></figure>

* To disconnect the device, press Disconnect button.

<figure><img src="/files/IjR54u0vhAnfoJL6XVji" alt=""><figcaption></figcaption></figure>

## How to Connect Using the Bluetooth LE Connection

The following instructions are for pairing the DynaFlex II GO to a PC.

* Launch the DynaFlex Utility to connect to the device by USB connection. Obtain Bluetooth LE Device name from selecting the Settings tab, Wireless/BLE menu, and at Bluetooth LE Settings press the Get button for Device Name

<figure><img src="/files/G4heZgbYkTuqnoGSkm4j" alt=""><figcaption></figcaption></figure>

* Place the device into Pairing Mode by pressing and holding the power button on device until 4 beeps and release the button. The 4th LED will blink green.

<figure><img src="/files/b87o8kh2d4xQHeVORJQ4" alt=""><figcaption></figcaption></figure>

* On the PC, open Settings and choose Bluetooth & other devices. Make sure the “Bluetooth” is turned ON . On the right panel, choose Add Bluetooth or other device.

<figure><img src="/files/nfeoibl1CuFKiS3IU7pk" alt=""><figcaption></figcaption></figure>

* At the Add a device window, select Bluetooth.

<figure><img src="/files/agAi5ZbLtfNkKTJlaAQc" alt=""><figcaption></figcaption></figure>

* To pair, click on the device name that was been retrieved from DynaFlex Utility.

<figure><img src="/files/jg3syKHBWG0fSF7YshX3" alt=""><figcaption></figcaption></figure>

* Enter the PIN, (“000000” by default), and press Connect .

<figure><img src="/files/NJHvek8VQSUvB6tEJ2FB" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/dGwAbqJNW2crF3YNOvEe" alt=""><figcaption></figcaption></figure>

* Go back to DynaFlex Utility, disconnect the current USB connection.
* Click on Device list to find the added BLE device similar as below.

<figure><img src="/files/M7NzgiY5RZB4pUPULfjp" alt=""><figcaption></figcaption></figure>


# Update Firmware

* Press the Settings tab, and then select the Update menu.

<figure><img src="/files/0u56FD0kH89OvR5GAnF2" alt=""><figcaption></figcaption></figure>

2. Select the Firmware Type, press the Update Firmware button. Navigate and select the firmware file.

<figure><img src="/files/MqiaTGuJu6kPlIaN06oM" alt=""><figcaption></figcaption></figure>

* &#x20;Check the status displayed in the software.

<figure><img src="/files/ecCCpq3FuroSvWTinAuT" alt=""><figcaption></figcaption></figure>


# Send The Command Set

* Select the Tools tab , and select the Send Command menu.

<figure><img src="/files/e3dONbBcKLxUlnHk83jO" alt=""><figcaption></figcaption></figure>

* Below the Output box, change the Log Type to All Messages . Because the Output box auto scrolls after each command sent, the bottom displays the response referenced in these instructions.

<figure><img src="/files/4ScUfIai8JE4BBLThl8J" alt=""><figcaption></figcaption></figure>

* Enter the following sequence of commands into the Raw Command text box&#x20;

{% hint style="info" %}
Note: Commands may need to be copied and pasted to the time.
{% endhint %}

**Set Protection Key Command**

{% code overflow="wrap" %}

```applescript
AA0081040117EF04842BEF0481010182207DD1722EC35C25737E7776D54D638C807EFC 467EAF70A1F6909C518420CCCEE3830217DF
```

{% endcode %}

**Response**

{% code overflow="wrap" %}

```
Communication: <- AA-00-81-04-82-17-EF-04-82-04-00-00-00-00
```

{% endcode %}

**Set Your Long Term Key Command**

{% code overflow="wrap" %}

```
AA0081040118EF05848196EF0581010182040000000183020079858180B402AA3EC2EC 15DE2DCF8B06C75038DD0CBDA17C03FE6A71DBF2757A6CD050C39B99E2E190FC11C80E B07F0E6E1CA4B19A2FCEF4D35C48E0CF545045FC5F1E5C2973A8A8A05B33EBABD1D9A8 FE6CBC7E55A1083AD3CB00B452504015A96A82E3F0F49ACE94F20622251705071B73A5 6E8DAD2B971CD8865ACCB66A169DF0BEF88602BB2E
```

{% endcode %}

**Response**

{% code overflow="wrap" %}

```
Communication: <- AA-00-81-04-82-18-EF-05-82-04-00-00-00-00-84-08-EF-05-81-04-00-00-00-01
```

{% endcode %}

**Retrieve your key version Command**

{% code overflow="wrap" %}

```
AA008104010AEF058405EF05810100
```

{% endcode %}

**Response**

{% code overflow="wrap" %}

```
Communication: <- AA-00-81-04-82-0A-EF-05-82-04-00-00-00-00-84-08-EF-05-81-04-00-00-00-01
```

{% endcode %}

**Set Collector ID Slot 1 with value Command: “DF7C083230313830363038DF7D0103”**

{% code overflow="wrap" %}

```
AA0081040110D1118429D11181072B06010401F6098501018919E117E115E113E111D0 0FDF7C083230313830363038DF7D0103
```

{% endcode %}

**Response**

{% code overflow="wrap" %}

```
Communication: <- AA-00-81-04-82-10-D1-11-82-04-00-00-00-00-84-82-00-29-D1-11-81-07-2B-06-01-04-01-F6-09-85-01-01-89-19-E1-17-E1-15-E1-13-
E1-11-D0-0F-DF-7C-08-32-30-31-38-30-36-30-38-DF-7D-01-03
```

{% endcode %}

**Set Google Wallet Smart Tap POS Capability Command: (this sample set value to 08140300)**

{% code overflow="wrap" %}

```
AA008104010BD111841ED11181072B06010401F609850101890EE10CE10AE108E106DA 0408140300
```

{% endcode %}

**Response**

{% code overflow="wrap" %}

```
Communication: <- AA-00-81-04-82-0B-D1-11-82-04-00-00-00-00-84-82-00-1E-D1-11-81-07-2B-06-01-04-01-F6-09-85-01-01-89-0E-E1-0C-E1-0A-E1-08-E1-06-DA-04-08-14-03-00
```

{% endcode %}


# Add Google Smart Tap Pass to Google Wallet

The following instructions is for installing a demo test Google Pass into an Android device. This pass is identified as Collector ID 20180608

* Follow the link below. The link can be sent to an Android device by email. [https://pay.google.com/gp/v/save/eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJnb29nbGUiL](https://pay.google.com/gp/v/save/eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJnb29nbGUiLCJvcmlnaW5zIjpbImh0dHA6Ly9sb2NhbGhvc3Q6ODA4MCJdLCJpc3MiOiJnb29nbGUtcGF5LWZvci1wYXNzZXMtZ3RlY2hAcGF5LXBhc3Nlcy1zbWFydC10YXAtc2FtcGxlLmlhbS5nc2VydmljZWFjY291bnQuY29tIiwiaWF0IjoxNTI5OTU2MDcwLCJ0eXAiOiJzYXZldG9hbmRyb2lkcGF5IiwicGF5bG9hZCI6eyJsb3lhbHR5T2JqZWN0cyI6W3siY2xhc3NJZCI6IjMyNjUzMjAxMTE2NDE5NTYxODMuMDYxOV9nb29nbGVEZW1vVGVzdCIsInN0YXRlIjoiYWN0aXZlIiwiaWQiOiIzMjY1MzIwMTExNjQxOTU2MTgzLjA2MTlfZ29vZ2xlRGVtb1Rlc3Qtb2JqMDEifV19fQ.MjUBdBtGyQwcE3xI-q6tVNBiApZppLMp0Op0XvB-c31Ri-JttJCzGXZvURNvKFDGXTNQQDqVBgQziuBMR_ZL0_lp7q8B5nwfSR32I0Kr220n3CezAsikaM5rKVf83UXT9fvqagnRn0QVVuS7fyLLc9nBDxRhRnkqEz2dQPgrNZ1u2AEJBPSoM6sLTeHssOWUMp7dgW6REJg7NUcczXJgLSOpAmD08G14q1qfS5T4Jb4knwPeIMnggNMjHcSBmz0z6W4DGD5Ld16nKOty4TvoDh4EevEJF7U7UQcOwIpozIXRVKs8rlqEXMObGsrk4hPM-I2p6H4DBrVcpyG8HD6Iug) [CJvcmlnaW5zIjpbImh0dHA6Ly9sb2NhbGhvc3Q6ODA4MCJdLCJpc3MiOiJnb29nbGUtcGF5LWZvci1](https://pay.google.com/gp/v/save/eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJnb29nbGUiLCJvcmlnaW5zIjpbImh0dHA6Ly9sb2NhbGhvc3Q6ODA4MCJdLCJpc3MiOiJnb29nbGUtcGF5LWZvci1wYXNzZXMtZ3RlY2hAcGF5LXBhc3Nlcy1zbWFydC10YXAtc2FtcGxlLmlhbS5nc2VydmljZWFjY291bnQuY29tIiwiaWF0IjoxNTI5OTU2MDcwLCJ0eXAiOiJzYXZldG9hbmRyb2lkcGF5IiwicGF5bG9hZCI6eyJsb3lhbHR5T2JqZWN0cyI6W3siY2xhc3NJZCI6IjMyNjUzMjAxMTE2NDE5NTYxODMuMDYxOV9nb29nbGVEZW1vVGVzdCIsInN0YXRlIjoiYWN0aXZlIiwiaWQiOiIzMjY1MzIwMTExNjQxOTU2MTgzLjA2MTlfZ29vZ2xlRGVtb1Rlc3Qtb2JqMDEifV19fQ.MjUBdBtGyQwcE3xI-q6tVNBiApZppLMp0Op0XvB-c31Ri-JttJCzGXZvURNvKFDGXTNQQDqVBgQziuBMR_ZL0_lp7q8B5nwfSR32I0Kr220n3CezAsikaM5rKVf83UXT9fvqagnRn0QVVuS7fyLLc9nBDxRhRnkqEz2dQPgrNZ1u2AEJBPSoM6sLTeHssOWUMp7dgW6REJg7NUcczXJgLSOpAmD08G14q1qfS5T4Jb4knwPeIMnggNMjHcSBmz0z6W4DGD5Ld16nKOty4TvoDh4EevEJF7U7UQcOwIpozIXRVKs8rlqEXMObGsrk4hPM-I2p6H4DBrVcpyG8HD6Iug) [wYXNzZXMtZ3RlY2hAcGF5LXBhc3Nlcy1zbWFydC10YXAtc2FtcGxlLmlhbS5nc2VydmljZWFjY29](https://pay.google.com/gp/v/save/eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJnb29nbGUiLCJvcmlnaW5zIjpbImh0dHA6Ly9sb2NhbGhvc3Q6ODA4MCJdLCJpc3MiOiJnb29nbGUtcGF5LWZvci1wYXNzZXMtZ3RlY2hAcGF5LXBhc3Nlcy1zbWFydC10YXAtc2FtcGxlLmlhbS5nc2VydmljZWFjY291bnQuY29tIiwiaWF0IjoxNTI5OTU2MDcwLCJ0eXAiOiJzYXZldG9hbmRyb2lkcGF5IiwicGF5bG9hZCI6eyJsb3lhbHR5T2JqZWN0cyI6W3siY2xhc3NJZCI6IjMyNjUzMjAxMTE2NDE5NTYxODMuMDYxOV9nb29nbGVEZW1vVGVzdCIsInN0YXRlIjoiYWN0aXZlIiwiaWQiOiIzMjY1MzIwMTExNjQxOTU2MTgzLjA2MTlfZ29vZ2xlRGVtb1Rlc3Qtb2JqMDEifV19fQ.MjUBdBtGyQwcE3xI-q6tVNBiApZppLMp0Op0XvB-c31Ri-JttJCzGXZvURNvKFDGXTNQQDqVBgQziuBMR_ZL0_lp7q8B5nwfSR32I0Kr220n3CezAsikaM5rKVf83UXT9fvqagnRn0QVVuS7fyLLc9nBDxRhRnkqEz2dQPgrNZ1u2AEJBPSoM6sLTeHssOWUMp7dgW6REJg7NUcczXJgLSOpAmD08G14q1qfS5T4Jb4knwPeIMnggNMjHcSBmz0z6W4DGD5Ld16nKOty4TvoDh4EevEJF7U7UQcOwIpozIXRVKs8rlqEXMObGsrk4hPM-I2p6H4DBrVcpyG8HD6Iug) [1bnQuY29tIiwiaWF0IjoxNTI5OTU2MDcwLCJ0eXAiOiJzYXZldG9hbmRyb2lkcGF5IiwicGF5bG9hZC](https://pay.google.com/gp/v/save/eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJnb29nbGUiLCJvcmlnaW5zIjpbImh0dHA6Ly9sb2NhbGhvc3Q6ODA4MCJdLCJpc3MiOiJnb29nbGUtcGF5LWZvci1wYXNzZXMtZ3RlY2hAcGF5LXBhc3Nlcy1zbWFydC10YXAtc2FtcGxlLmlhbS5nc2VydmljZWFjY291bnQuY29tIiwiaWF0IjoxNTI5OTU2MDcwLCJ0eXAiOiJzYXZldG9hbmRyb2lkcGF5IiwicGF5bG9hZCI6eyJsb3lhbHR5T2JqZWN0cyI6W3siY2xhc3NJZCI6IjMyNjUzMjAxMTE2NDE5NTYxODMuMDYxOV9nb29nbGVEZW1vVGVzdCIsInN0YXRlIjoiYWN0aXZlIiwiaWQiOiIzMjY1MzIwMTExNjQxOTU2MTgzLjA2MTlfZ29vZ2xlRGVtb1Rlc3Qtb2JqMDEifV19fQ.MjUBdBtGyQwcE3xI-q6tVNBiApZppLMp0Op0XvB-c31Ri-JttJCzGXZvURNvKFDGXTNQQDqVBgQziuBMR_ZL0_lp7q8B5nwfSR32I0Kr220n3CezAsikaM5rKVf83UXT9fvqagnRn0QVVuS7fyLLc9nBDxRhRnkqEz2dQPgrNZ1u2AEJBPSoM6sLTeHssOWUMp7dgW6REJg7NUcczXJgLSOpAmD08G14q1qfS5T4Jb4knwPeIMnggNMjHcSBmz0z6W4DGD5Ld16nKOty4TvoDh4EevEJF7U7UQcOwIpozIXRVKs8rlqEXMObGsrk4hPM-I2p6H4DBrVcpyG8HD6Iug) [I6eyJsb3lhbHR5T2JqZWN0cyI6W3siY2xhc3NJZCI6IjMyNjUzMjAxMTE2NDE5NTYxODMuMDYxO](https://pay.google.com/gp/v/save/eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJnb29nbGUiLCJvcmlnaW5zIjpbImh0dHA6Ly9sb2NhbGhvc3Q6ODA4MCJdLCJpc3MiOiJnb29nbGUtcGF5LWZvci1wYXNzZXMtZ3RlY2hAcGF5LXBhc3Nlcy1zbWFydC10YXAtc2FtcGxlLmlhbS5nc2VydmljZWFjY291bnQuY29tIiwiaWF0IjoxNTI5OTU2MDcwLCJ0eXAiOiJzYXZldG9hbmRyb2lkcGF5IiwicGF5bG9hZCI6eyJsb3lhbHR5T2JqZWN0cyI6W3siY2xhc3NJZCI6IjMyNjUzMjAxMTE2NDE5NTYxODMuMDYxOV9nb29nbGVEZW1vVGVzdCIsInN0YXRlIjoiYWN0aXZlIiwiaWQiOiIzMjY1MzIwMTExNjQxOTU2MTgzLjA2MTlfZ29vZ2xlRGVtb1Rlc3Qtb2JqMDEifV19fQ.MjUBdBtGyQwcE3xI-q6tVNBiApZppLMp0Op0XvB-c31Ri-JttJCzGXZvURNvKFDGXTNQQDqVBgQziuBMR_ZL0_lp7q8B5nwfSR32I0Kr220n3CezAsikaM5rKVf83UXT9fvqagnRn0QVVuS7fyLLc9nBDxRhRnkqEz2dQPgrNZ1u2AEJBPSoM6sLTeHssOWUMp7dgW6REJg7NUcczXJgLSOpAmD08G14q1qfS5T4Jb4knwPeIMnggNMjHcSBmz0z6W4DGD5Ld16nKOty4TvoDh4EevEJF7U7UQcOwIpozIXRVKs8rlqEXMObGsrk4hPM-I2p6H4DBrVcpyG8HD6Iug) [V9nb29nbGVEZW1vVGVzdCIsInN0YXRlIjoiYWN0aXZlIiwiaWQiOiIzMjY1MzIwMTExNjQxOTU2](https://pay.google.com/gp/v/save/eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJnb29nbGUiLCJvcmlnaW5zIjpbImh0dHA6Ly9sb2NhbGhvc3Q6ODA4MCJdLCJpc3MiOiJnb29nbGUtcGF5LWZvci1wYXNzZXMtZ3RlY2hAcGF5LXBhc3Nlcy1zbWFydC10YXAtc2FtcGxlLmlhbS5nc2VydmljZWFjY291bnQuY29tIiwiaWF0IjoxNTI5OTU2MDcwLCJ0eXAiOiJzYXZldG9hbmRyb2lkcGF5IiwicGF5bG9hZCI6eyJsb3lhbHR5T2JqZWN0cyI6W3siY2xhc3NJZCI6IjMyNjUzMjAxMTE2NDE5NTYxODMuMDYxOV9nb29nbGVEZW1vVGVzdCIsInN0YXRlIjoiYWN0aXZlIiwiaWQiOiIzMjY1MzIwMTExNjQxOTU2MTgzLjA2MTlfZ29vZ2xlRGVtb1Rlc3Qtb2JqMDEifV19fQ.MjUBdBtGyQwcE3xI-q6tVNBiApZppLMp0Op0XvB-c31Ri-JttJCzGXZvURNvKFDGXTNQQDqVBgQziuBMR_ZL0_lp7q8B5nwfSR32I0Kr220n3CezAsikaM5rKVf83UXT9fvqagnRn0QVVuS7fyLLc9nBDxRhRnkqEz2dQPgrNZ1u2AEJBPSoM6sLTeHssOWUMp7dgW6REJg7NUcczXJgLSOpAmD08G14q1qfS5T4Jb4knwPeIMnggNMjHcSBmz0z6W4DGD5Ld16nKOty4TvoDh4EevEJF7U7UQcOwIpozIXRVKs8rlqEXMObGsrk4hPM-I2p6H4DBrVcpyG8HD6Iug) [MTgzLjA2MTlfZ29vZ2xlRGVtb1Rlc3Qtb2JqMDEifV19fQ.MjUBdBtGyQwcE3xI-](https://pay.google.com/gp/v/save/eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJnb29nbGUiLCJvcmlnaW5zIjpbImh0dHA6Ly9sb2NhbGhvc3Q6ODA4MCJdLCJpc3MiOiJnb29nbGUtcGF5LWZvci1wYXNzZXMtZ3RlY2hAcGF5LXBhc3Nlcy1zbWFydC10YXAtc2FtcGxlLmlhbS5nc2VydmljZWFjY291bnQuY29tIiwiaWF0IjoxNTI5OTU2MDcwLCJ0eXAiOiJzYXZldG9hbmRyb2lkcGF5IiwicGF5bG9hZCI6eyJsb3lhbHR5T2JqZWN0cyI6W3siY2xhc3NJZCI6IjMyNjUzMjAxMTE2NDE5NTYxODMuMDYxOV9nb29nbGVEZW1vVGVzdCIsInN0YXRlIjoiYWN0aXZlIiwiaWQiOiIzMjY1MzIwMTExNjQxOTU2MTgzLjA2MTlfZ29vZ2xlRGVtb1Rlc3Qtb2JqMDEifV19fQ.MjUBdBtGyQwcE3xI-q6tVNBiApZppLMp0Op0XvB-c31Ri-JttJCzGXZvURNvKFDGXTNQQDqVBgQziuBMR_ZL0_lp7q8B5nwfSR32I0Kr220n3CezAsikaM5rKVf83UXT9fvqagnRn0QVVuS7fyLLc9nBDxRhRnkqEz2dQPgrNZ1u2AEJBPSoM6sLTeHssOWUMp7dgW6REJg7NUcczXJgLSOpAmD08G14q1qfS5T4Jb4knwPeIMnggNMjHcSBmz0z6W4DGD5Ld16nKOty4TvoDh4EevEJF7U7UQcOwIpozIXRVKs8rlqEXMObGsrk4hPM-I2p6H4DBrVcpyG8HD6Iug)[q6tVNBiApZppLMp0Op0XvB-c31Ri-](https://pay.google.com/gp/v/save/eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJnb29nbGUiLCJvcmlnaW5zIjpbImh0dHA6Ly9sb2NhbGhvc3Q6ODA4MCJdLCJpc3MiOiJnb29nbGUtcGF5LWZvci1wYXNzZXMtZ3RlY2hAcGF5LXBhc3Nlcy1zbWFydC10YXAtc2FtcGxlLmlhbS5nc2VydmljZWFjY291bnQuY29tIiwiaWF0IjoxNTI5OTU2MDcwLCJ0eXAiOiJzYXZldG9hbmRyb2lkcGF5IiwicGF5bG9hZCI6eyJsb3lhbHR5T2JqZWN0cyI6W3siY2xhc3NJZCI6IjMyNjUzMjAxMTE2NDE5NTYxODMuMDYxOV9nb29nbGVEZW1vVGVzdCIsInN0YXRlIjoiYWN0aXZlIiwiaWQiOiIzMjY1MzIwMTExNjQxOTU2MTgzLjA2MTlfZ29vZ2xlRGVtb1Rlc3Qtb2JqMDEifV19fQ.MjUBdBtGyQwcE3xI-q6tVNBiApZppLMp0Op0XvB-c31Ri-JttJCzGXZvURNvKFDGXTNQQDqVBgQziuBMR_ZL0_lp7q8B5nwfSR32I0Kr220n3CezAsikaM5rKVf83UXT9fvqagnRn0QVVuS7fyLLc9nBDxRhRnkqEz2dQPgrNZ1u2AEJBPSoM6sLTeHssOWUMp7dgW6REJg7NUcczXJgLSOpAmD08G14q1qfS5T4Jb4knwPeIMnggNMjHcSBmz0z6W4DGD5Ld16nKOty4TvoDh4EevEJF7U7UQcOwIpozIXRVKs8rlqEXMObGsrk4hPM-I2p6H4DBrVcpyG8HD6Iug)[JttJCzGXZvURNvKFDGXTNQQDqVBgQziuBMR\_ZL0\_lp7q8B5nwfSR32I0Kr220n3CezAsikaM5rKV](https://pay.google.com/gp/v/save/eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJnb29nbGUiLCJvcmlnaW5zIjpbImh0dHA6Ly9sb2NhbGhvc3Q6ODA4MCJdLCJpc3MiOiJnb29nbGUtcGF5LWZvci1wYXNzZXMtZ3RlY2hAcGF5LXBhc3Nlcy1zbWFydC10YXAtc2FtcGxlLmlhbS5nc2VydmljZWFjY291bnQuY29tIiwiaWF0IjoxNTI5OTU2MDcwLCJ0eXAiOiJzYXZldG9hbmRyb2lkcGF5IiwicGF5bG9hZCI6eyJsb3lhbHR5T2JqZWN0cyI6W3siY2xhc3NJZCI6IjMyNjUzMjAxMTE2NDE5NTYxODMuMDYxOV9nb29nbGVEZW1vVGVzdCIsInN0YXRlIjoiYWN0aXZlIiwiaWQiOiIzMjY1MzIwMTExNjQxOTU2MTgzLjA2MTlfZ29vZ2xlRGVtb1Rlc3Qtb2JqMDEifV19fQ.MjUBdBtGyQwcE3xI-q6tVNBiApZppLMp0Op0XvB-c31Ri-JttJCzGXZvURNvKFDGXTNQQDqVBgQziuBMR_ZL0_lp7q8B5nwfSR32I0Kr220n3CezAsikaM5rKVf83UXT9fvqagnRn0QVVuS7fyLLc9nBDxRhRnkqEz2dQPgrNZ1u2AEJBPSoM6sLTeHssOWUMp7dgW6REJg7NUcczXJgLSOpAmD08G14q1qfS5T4Jb4knwPeIMnggNMjHcSBmz0z6W4DGD5Ld16nKOty4TvoDh4EevEJF7U7UQcOwIpozIXRVKs8rlqEXMObGsrk4hPM-I2p6H4DBrVcpyG8HD6Iug) [f83UXT9fvqagnRn0QVVuS7fyLLc9nBDxRhRnkqEz2dQPgrNZ1u2AEJBPSoM6sLTeHssOWUMp7dg](https://pay.google.com/gp/v/save/eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJnb29nbGUiLCJvcmlnaW5zIjpbImh0dHA6Ly9sb2NhbGhvc3Q6ODA4MCJdLCJpc3MiOiJnb29nbGUtcGF5LWZvci1wYXNzZXMtZ3RlY2hAcGF5LXBhc3Nlcy1zbWFydC10YXAtc2FtcGxlLmlhbS5nc2VydmljZWFjY291bnQuY29tIiwiaWF0IjoxNTI5OTU2MDcwLCJ0eXAiOiJzYXZldG9hbmRyb2lkcGF5IiwicGF5bG9hZCI6eyJsb3lhbHR5T2JqZWN0cyI6W3siY2xhc3NJZCI6IjMyNjUzMjAxMTE2NDE5NTYxODMuMDYxOV9nb29nbGVEZW1vVGVzdCIsInN0YXRlIjoiYWN0aXZlIiwiaWQiOiIzMjY1MzIwMTExNjQxOTU2MTgzLjA2MTlfZ29vZ2xlRGVtb1Rlc3Qtb2JqMDEifV19fQ.MjUBdBtGyQwcE3xI-q6tVNBiApZppLMp0Op0XvB-c31Ri-JttJCzGXZvURNvKFDGXTNQQDqVBgQziuBMR_ZL0_lp7q8B5nwfSR32I0Kr220n3CezAsikaM5rKVf83UXT9fvqagnRn0QVVuS7fyLLc9nBDxRhRnkqEz2dQPgrNZ1u2AEJBPSoM6sLTeHssOWUMp7dgW6REJg7NUcczXJgLSOpAmD08G14q1qfS5T4Jb4knwPeIMnggNMjHcSBmz0z6W4DGD5Ld16nKOty4TvoDh4EevEJF7U7UQcOwIpozIXRVKs8rlqEXMObGsrk4hPM-I2p6H4DBrVcpyG8HD6Iug) [W6REJg7NUcczXJgLSOpAmD08G14q1qfS5T4Jb4knwPeIMnggNMjHcSBmz0z6W4DGD5Ld16nKOt](https://pay.google.com/gp/v/save/eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJnb29nbGUiLCJvcmlnaW5zIjpbImh0dHA6Ly9sb2NhbGhvc3Q6ODA4MCJdLCJpc3MiOiJnb29nbGUtcGF5LWZvci1wYXNzZXMtZ3RlY2hAcGF5LXBhc3Nlcy1zbWFydC10YXAtc2FtcGxlLmlhbS5nc2VydmljZWFjY291bnQuY29tIiwiaWF0IjoxNTI5OTU2MDcwLCJ0eXAiOiJzYXZldG9hbmRyb2lkcGF5IiwicGF5bG9hZCI6eyJsb3lhbHR5T2JqZWN0cyI6W3siY2xhc3NJZCI6IjMyNjUzMjAxMTE2NDE5NTYxODMuMDYxOV9nb29nbGVEZW1vVGVzdCIsInN0YXRlIjoiYWN0aXZlIiwiaWQiOiIzMjY1MzIwMTExNjQxOTU2MTgzLjA2MTlfZ29vZ2xlRGVtb1Rlc3Qtb2JqMDEifV19fQ.MjUBdBtGyQwcE3xI-q6tVNBiApZppLMp0Op0XvB-c31Ri-JttJCzGXZvURNvKFDGXTNQQDqVBgQziuBMR_ZL0_lp7q8B5nwfSR32I0Kr220n3CezAsikaM5rKVf83UXT9fvqagnRn0QVVuS7fyLLc9nBDxRhRnkqEz2dQPgrNZ1u2AEJBPSoM6sLTeHssOWUMp7dgW6REJg7NUcczXJgLSOpAmD08G14q1qfS5T4Jb4knwPeIMnggNMjHcSBmz0z6W4DGD5Ld16nKOty4TvoDh4EevEJF7U7UQcOwIpozIXRVKs8rlqEXMObGsrk4hPM-I2p6H4DBrVcpyG8HD6Iug) [y4TvoDh4EevEJF7U7UQcOwIpozIXRVKs8rlqEXMObGsrk4hPM-I2p6H4DBrVcpyG8HD6Iug](https://pay.google.com/gp/v/save/eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJnb29nbGUiLCJvcmlnaW5zIjpbImh0dHA6Ly9sb2NhbGhvc3Q6ODA4MCJdLCJpc3MiOiJnb29nbGUtcGF5LWZvci1wYXNzZXMtZ3RlY2hAcGF5LXBhc3Nlcy1zbWFydC10YXAtc2FtcGxlLmlhbS5nc2VydmljZWFjY291bnQuY29tIiwiaWF0IjoxNTI5OTU2MDcwLCJ0eXAiOiJzYXZldG9hbmRyb2lkcGF5IiwicGF5bG9hZCI6eyJsb3lhbHR5T2JqZWN0cyI6W3siY2xhc3NJZCI6IjMyNjUzMjAxMTE2NDE5NTYxODMuMDYxOV9nb29nbGVEZW1vVGVzdCIsInN0YXRlIjoiYWN0aXZlIiwiaWQiOiIzMjY1MzIwMTExNjQxOTU2MTgzLjA2MTlfZ29vZ2xlRGVtb1Rlc3Qtb2JqMDEifV19fQ.MjUBdBtGyQwcE3xI-q6tVNBiApZppLMp0Op0XvB-c31Ri-JttJCzGXZvURNvKFDGXTNQQDqVBgQziuBMR_ZL0_lp7q8B5nwfSR32I0Kr220n3CezAsikaM5rKVf83UXT9fvqagnRn0QVVuS7fyLLc9nBDxRhRnkqEz2dQPgrNZ1u2AEJBPSoM6sLTeHssOWUMp7dgW6REJg7NUcczXJgLSOpAmD08G14q1qfS5T4Jb4knwPeIMnggNMjHcSBmz0z6W4DGD5Ld16nKOty4TvoDh4EevEJF7U7UQcOwIpozIXRVKs8rlqEXMObGsrk4hPM-I2p6H4DBrVcpyG8HD6Iug)
* If not already signed in, sign in with a Google account from the Android device.
* After accessing the Google Smart Tap Pass, press on Add.

<figure><img src="/files/7cwXWOQ0MfB7XEvsa3oP" alt=""><figcaption></figcaption></figure>


# Google Wallet VAS Transaction

* Select the Transaction tab, select the DEMO menu, seect the desired Transaction Type, and then select the Google Wallet PASS option.

<figure><img src="/files/xOuPwzpW3u3wUT1tY8Xh" alt=""><figcaption></figcaption></figure>

* Select a VAS mode from the VASMode.
  * **Single Mode:** The device reads only VAS data from a tapped smartphone or reads EMV payment data from a tapped card. When the device sends ARQC to conclude the transaction, it only includes either EMV payment data in container FC for cards, or includes VAS data in FE container for smartphones.
  * **Dual Mode:** The device reads both VAS data and EMV payment data from a tapped smartphone or reads EMV payment data from a tapped card. When device sends ARQC to the host to conclude the transaction, it includes EMV payment data in container FC and includes VAS data, if available, in container FE.
  * **VASOnly Mode:** The device reads only VAS data from a tapped smartphone and does not read data from a tapped card. If the tapped smartphone does not support VAS, the device does not detect or read from the smartphone. When the device send ARQC to conclude the transaction, it includes VAS data in container FE and does not include EMV payment data in container FC.

<figure><img src="/files/kUiTHhDjk8NL0WWRl5WS" alt=""><figcaption></figcaption></figure>

* Press the Start EMV Transaction button to start the transaction.

<figure><img src="/files/yYwziFKRODYcG2LhjF2r" alt=""><figcaption></figcaption></figure>

* Present the payment device with Google Wallet near the reader to continue the contactless transaction.
* To view the transaction result after the transaction is completed, press RESULT menu. Parsed details can be seen in the ARQC tab, which shows details of the FE TLV object containing the Google Wallet VAS data. The status is displayed in the Outpit log

<figure><img src="/files/FD9x5AJ3XmElbFAshPl0" alt=""><figcaption></figcaption></figure>


# TLV Parsing/Forming of the Command Set

For more information on Google Wallet Smart Tap see document D998200597 DynaFlex II Go Programmer’s Manual (COMMANDS).

* Property 1.1.1.1.1.10 Google Smart Tap Collector ID Slot 1&#x20;
* Property 1.1.1.1.1.11 Google Smart Tap Collector ID Slot 2&#x20;
* Property 1.1.1.1.1.12 Google Smart Tap Collector ID Slot 3&#x20;
* Property 1.1.1.1.1.13 Google Smart Tap Collector ID Slot 4&#x20;
* Property 1.1.1.1.1.14 Google Smart Tap Collector ID Slot 5&#x20;
* Property 1.1.1.1.1.15 Google Smart Tap Collector ID Slot 6&#x20;
* Property 1.1.1.1.1.1A Google Smart Tap POS Capability

The section uses the following sample values for demonstration purposes. Keys, Collector ID, and Capability will need to be replaced with actual values during integration.

**(Protection Key - Key 0)**

{% code overflow="wrap" %}

```
7DD1722EC35C25737E7776D54D638C807EFC467EAF70A1F6909C518420CCCEE3
```

{% endcode %}

**(Google Sample Key - Key 1)**

{% code overflow="wrap" %}

```
30770201010420826D17E50767B165B0E4D9E332F8D1D1E20224284FB4DAF1E50A03246E70797D A00A06082A8648CE3D030107A14403420004721C978FCEBDCDF98A8518BDC4FEDFD802B4EE4 128E2513B665593375E238786014E7CBE8511915DC5337AF57DCD248F2653C7A6AAAEE6913096 FD71C85BC4D7
```

{% endcode %}

## Protection Key <a href="#id-7.1_protection_key" id="id-7.1_protection_key"></a>

{% code overflow="wrap" %}

```
AA0081040117EF04842BEF0481010182207DD1722EC35C25737E7776D54D638C807EFC467EAF70 A1F6909C518420CCCEE3830217DF
```

{% endcode %}

<pre data-overflow="wrap"><code>AA00
    [81] [4] 0117EF04
    [84] [43] 
EF0481010182207DD1722EC35C25737E7776D54D638C807EFC467EAF70A1F6909C5184 20CCCEE3830217DF
<strong>        EF04
</strong>            [81] [1] 01
            [82] [32] 
7DD1722EC35C25737E7776D54D638C807EFC467EAF70A1F6909C518420CCCEE3 (AES
Key : Key 0)
            [83] [2] 17DF (CRC for content of Key
0) CRC16_MCRF45X(7DD1722EC35C25737E7776D54D638C807EFC467EAF70A1F6909C
518420CCCEE3)
</code></pre>

## Long Term Key

{% code overflow="wrap" %}

```
AA0081040118EF05848196EF0581010182040000000183020079858180B402AA3EC2EC15DE2DCF8 B06C75038DD0CBDA17C03FE6A71DBF2757A6CD050C39B99E2E190FC11C80EB07F0E6E1CA4B 19A2FCEF4D35C48E0CF545045FC5F1E5C2973A8A8A05B33EBABD1D9A8FE6CBC7E55A1083AD
3CB00B452504015A96A82E3F0F49ACE94F20622251705071B73A56E8DAD2B971CD8865ACCB66 A169DF0BEF88602BB2E
```

{% endcode %}

<pre data-overflow="wrap"><code>AA00
    [81] [4] 0118EF05
    [84] [150] 
EF0581010182040000000183020079858180B402AA3EC2EC15DE2DCF8B06C75038DD0C BDA17C03FE6A71DBF2757A6CD050C39B99E2E190FC11C80EB07F0E6E1CA4B19A2FCEF4
D35C48E0CF545045FC5F1E5C2973A8A8A05B33EBABD1D9A8FE6CBC7E55A1083AD3CB00 B452504015A96A82E3F0F49ACE94F20622251705071B73A56E8DAD2B971CD8865ACCB6 6A169DF0BEF88602BB2E
<strong>        EF05
</strong>            [81] [1] 01
            [82] [4] 00000001
            [83] [2] 0079
            [85] [128] 
            B402AA3EC2EC15DE2DCF8B06C75038DD0CBDA17C03FE6A71DBF2757A6CD050C39B99E2
E190FC11C80EB07F0E6E1CA4B19A2FCEF4D35C48E0CF545045FC5F1E5C2973A8A8A05B 33EBABD1D9A8FE6CBC7E55A1083AD3CB00B452504015A96A82E3F0F49ACE94F2062225
1705071B73A56E8DAD2B971CD8865ACCB66A169DF0BEF8 ( Encrypted
Key  AES(Key 1) with Key 0)
            [86] [2] BB2E (CRC for encrypted
key) CRC16_MCRF45X(B402AA3EC2EC15DE2DCF8B06C75038DD0CBDA17C03FE6A71DB F2757A6CD050C39B99E2E190FC11C80EB07F0E6E1CA4B19A2FCEF4D35C48E0CF545045 FC5F1E5C2973A8A8A05B33EBABD1D9A8FE6CBC7E55A1083AD3CB00B452504015A96A82 E3F0F49ACE94F20622251705071B73A56E8DAD2B971CD8865ACCB66A169DF0BEF8)


PRIVATE
Key 30770201010420826D17E50767B165B0E4D9E332F8D1D1E20224284FB4DAF1E50 A03246E70797DA00A06082A8648CE3D030107A14403420004721C978FCEBDCDF98A851 8BDC4FEDFD802B4EE4128E2513B665593375E238786014E7CBE8511915DC5337AF57DC D248F2653C7A6AAAEE6913096FD71C85BC4D7
Encrypted
LTPK B402AA3EC2EC15DE2DCF8B06C75038DD0CBDA17C03FE6A71DBF2757A6CD050C3 9B99E2E190FC11C80EB07F0E6E1CA4B19A2FCEF4D35C48E0CF545045FC5F1E5C2973A8 A8A05B33EBABD1D9A8FE6CBC7E55A1083AD3CB00B452504015A96A82E3F0F49ACE94F2 0622251705071B73A56E8DAD2B971CD8865ACCB66A169DF0BEF8
CRC for Key BB2E

</code></pre>

## Retrieve Your Key Version

{% code overflow="wrap" %}

```
AA008104010AEF058405EF05810100
```

{% endcode %}

{% code overflow="wrap" %}

```
AA00
    [81] [4] 010AEF05
    [84] [5] EF05810100

    EF05
        [81] [1] 00 ( Get Key version)
```

{% endcode %}

**Response**

{% code overflow="wrap" %}

```
AA008104820AEF058204000000008408EF05810400000001
```

{% endcode %}

<pre data-overflow="wrap"><code>AA00
    [81] [4] 820AEF05
    [82] [4] 00000000
    [84] [8] EF05810400000001

        EF05
<strong>            [81] [4] 00000001
</strong></code></pre>

## Set Collector ID Slot 1

With value DF7C083230313830363038DF7D0103

{% code overflow="wrap" %}

```
AA0081040110D1118429D11181072B06010401F6098501018919E117E115E113E111D00FDF7C0832 30313830363038DF7D0103
```

{% endcode %}

<pre data-overflow="wrap"><code>AA00
    [81] [4] 0110D111
    [84] [41] D11181072B06010401F6098501018919E117E115E113E111D00FDF 7C083230313830363038DF7D0103
        D111
            [81] [7] 2B06010401F609
            [85] [1] 01
            [89] [25] E117E115E113E111D00FDF7C083230313830363038DF7D0103

<strong>            DF7C [08] 3230313830363038 Collector ID
</strong>            DF7D [01] 03 (Type)
</code></pre>

## Set Google Smart Tap POS Capability

This sample sets value to 08140300

{% code overflow="wrap" %}

```
AA008104010BD111841ED11181072B06010401F609850101890EE10CE10AE108E106DA040814030 0
```

{% endcode %}

<pre data-overflow="wrap"><code>AA00
<strong>    [81] [4] 010BD111
</strong>    [84] [30] 
D11181072B06010401F609850101890EE10CE10AE108E106DA0408140300
<strong>        D111
</strong>            [81] [7] 2B06010401F609
            [85] [1] 01
            [89] [14] E10CE10AE108E106DA0408140300
</code></pre>


# DynaCast, NFC Card Emulation, and the Business Use Cases

## Turn Every Tap Into a Digital Experience

#### BUSINESS SOLUTION GUIDE:

Understand the benefits DynaCast, NFC Card Emulation, offers and the business use cases.

#### Overview:

DynaCast delivers receipts, access, and links directly to a user’s phone.

#### Use Cases and Benefits:

How to expand the use of NFC Card Emulation technology with MagTek DynaFlex II Go and DynaProx and add revenue building value to your application offering.

#### Executive Summary <a href="#executive_summary" id="executive_summary"></a>

DynaCast is NFC Card Emulation technology integrated into MagTek DynaFlex II Go and DynaProx devices. It delivers significant value at the point-of-sale and the point-of-interaction by seamlessly connecting users to personalized digital experiences via custom URLs. It supports a wide variety of use cases, including instant loyalty program enrollment, digital product information, warranty registration, customer feedback collection, social media engagement, flexible payment solutions, personalized upselling, order tracking, subscription services, charity donations, digital business cards, event invitations, instant software downloads, product recall notifications, queue management, and immersive AR/VR experiences.

For merchants, this technology reduces costs associated with physical receipts and marketing materials, provides frictionless customer engagement without requiring app downloads, and facilitates comprehensive data collection for analytics. It significantly enhances the customer experience through personalized and timely interactions, increases opportunities for upselling, strengthens brand loyalty, aligns with sustainability initiatives, and helps prevent fraud by eliminating easily counterfeited printed coupons.

Consumers benefit through enhanced convenience, personalized offers, immediate access to relevant information, improved security and privacy, and engaging, interactive experiences optimized for mobile devices. The solution also aligns with consumer preferences for sustainability and provides instant support and resolution channels, significantly elevating the overall shopping experience.

#### How DynaCast Offers More than Standard NFC Card Emulation <a href="#how_dynacast_offers_more_than_standard_n" id="how_dynacast_offers_more_than_standard_n"></a>

Unlock instant, engaging digital interactions at the point-of-sale and point-of-interaction with MagTek DynaFlex II Go and DynaProx DynaCast technology. DynaFlex II Go and DynaProx devices transform the checkout experience by emulating a secure, read-only smart card that delivers custom URLs directly to customers' smartphones instantaneously.

DynaCast allows an NFC-enabled device, like a smartphone, to function like a contactless smart card. This enables the smartphone to interact with other NFC readers, like MagTek DynaFlex II Go and DynaProx devices, for various applications like payments, access control, and ticketing. This allows users to digitally access a limitless number of points and gives users the freedom to no longer need physical access objects (like ID badges, tickets, coupons, etc.).

#### Specifications and Core Features:

* Compliant with ISO/IEC14443 Type-A and NFC Forum Type 4 standards
* No app required on consumer’s phones.
* No complex consumer setup
* Works with most modern smartphones including: iPhone 7 and later and Android devices equipped with NFC capabilities

### BENEFITS AND USE CASES <a href="#benefits_and_use_cases" id="benefits_and_use_cases"></a>

#### Merchant and User Benefits <a href="#merchant_and_user_benefits" id="merchant_and_user_benefits"></a>

**MERCHANT/BUSINESS BENEFITS**

For merchants, having DynaCast enhances customer engagement and captures valuable interaction data. This results in several key benefits:

* **Cost Savings: Reduces paper receipts, printed coupons, and marketing materials.**
* Frictionless Engagement: No need for app downloads; only a tap is needed.
* Data Collection G Analytics: Track customer interactions with URL clicks.
* Improved Customer Experience: Personalized, real-time interactions.
* Increased Sales G Upselling: Digital promotions and recommendations delivered.
* Brand Loyalty G Retention: Seamless sign-ups for loyalty programs.
* Sustainability G Eco-Friendly: Reduce waste and align with green business initiatives.
* Fraud Prevention: Eliminates printed coupons that can be easily counterfeited.

**CUSTOMER/USER BENEFITS**

Users simply tap their phone, resulting in key benefits, including:

* **Convenience: No need to carry physical receipts, coupons, or loyalty cards.**
* Personalized Offers: Receive targeted deals and product recommendations.
* Ǫuick Access to Information: Instantly retrieve warranty info, manuals, or product info.
* **Secure G Private: No need to share personal information directly with the merchant.**
* Mobile-Friendly: Work seamlessly on any smartphone without extra steps.
* Engaging G Interactive: Access videos, AR experiences, or gamified promotions.
* Sustainable Choice: Reduce reliance on paper and physical media.
* Immediate Support G Resolution: Get instant access to FAǪs, live chat, or service.

#### Use Cases <a href="#use_cases" id="use_cases"></a>

DynaCast opens a world of opportunities. Experience secure, personalized, and frictionless interactions with DynaCast built into DynaFlex II Go and DynaProx devices, transforming every transaction into an opportunity for deeper customer connection, brand loyalty, and revenue generation. Empowering restaurant, retail, hospitality, healthcare, airline, transportation, and banking industries with technology tailored to their needs.

* &#x20;Loyalty Program Enrollment G Rewards: Instantly direct customers.
* Digital Product Information: Provide access to product details, reviews, and videos.
* Warranty Registration: Allow customers to register their purchased product.
* Surveys G Feedback Collection: Prompt customers to leave a review.
* Social Media Engagement: Direct customers to share on social media.
* Payment Options G BNPL Links: Guide users to payment and financing applications.
* Personalized Upselling: Offer related product recommendations or discounts.
* **Order Tracking: Provide real-time order status updates and delivery tracking.**
* Subscription Services: Offer quick sign-up for recurring purchases or memberships.
* Charity Donations: Enable customers to donate at checkout.
* Digital Business Cards: Share the merchant’s contact details, app, or services.
* Event G Webinar Invitations: Invite customers to exclusive events.
* Instant Software Downloads: Provide a direct download link for apps and software.
* Emergency Recall Notices: Offer a quick way for customers to check recall info.
* Ǫueue Management G Waitlist Signups: Offer check in for curbside pickup, reservations, or healthcare appointments.
* Mobile AR G VR Experiences: Engage users with augmented reality or virtual stores.

<figure><img src="/files/NBj0D943XBIAIM10cPTY" alt=""><figcaption></figcaption></figure>

### Conclusion <a href="#conclusion" id="conclusion"></a>

DynaFlex II Go and DynaProx devices with DynaCast allow ISVs to offer their clients more. MagTek’s Devices deliver a robust, versatile, and secure payment solution ideal for businesses seeking reliable and future-proof transaction devices. With multiple form-factors including mobile, countertop, and kiosk options, these devices easily adapt to diverse operational settings, accommodate to limited spaces, and deliver while flexible mounting options.

<figure><img src="/files/dNCHh4VBDarWV0wJLOC6" alt=""><figcaption></figcaption></figure>

#### Need More help

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** [support@magtek.com](mailto:support@magtek.com?subject=Support%20Request)
* 📞 **Phone:** 1-562-546-6800 (US)
* 🕐 **Hours:** Monday-Friday, 5:30 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Support Portal:** developer.magtek.com

**Documentation Feedback:**

Help us improve this documentation! [feedback@magtek.com](mailto:feedback@magtek.com?subject=Feedback)
{% endhint %}


# API & Command Reference

The API & Command Reference is where you look up the exact programming details of the ) command sets that MagTek products use — every command, notification, data object, configuration property, and status code. Where the [<mark style="color:red;">**Guides**</mark>](https://developer.magtek.com/guides/) walk you through accomplishing a task end to end, this is where you look up a specific detail while you build.

### Information in this group

| **Section**                                                                                                                                               | **Information**                                                                                                                                                                                                                               |
| --------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [<mark style="color:red;">**SCRA DynaFamily Programmer's Manual**</mark> ](/api-and-command-reference/scra-dynafamily-programmers-manual)                 | The complete MMS command set, documented once for the whole Dyna family: message format, data types, commands, notifications, configuration, and status codes.                                                                                |
| [<mark style="color:red;">**DynaFamily Command Matrix**</mark>](/api-and-command-reference/dynafamily-command-matrix)                                     | Which commands each reader supports, so you can confirm availability before building against a specific device.                                                                                                                               |
| [<mark style="color:red;">**Magensa Documentation & Code**</mark>](https://developer.magtek.com/api-and-command-reference/magensa-documentation-and-code) | Magensa is MagTek's cloud-based payment protection gateway that secures sensitive data and processes transactions across in-person, online, and mobile channels using advanced tokenization, dynamic encryption, and authentication services. |

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** <support@magtek.com>
* 📞 **Phone:** 1-800-788-6835 (US) | +1-562-546-6616 (International)
* 🕐 **Hours:** Monday-Friday, 6:00 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Official Site:** [https://www.magtek.com](https://www.magtek.com/)
* 💬 **Developer Forum:** [https://forum.magtek.com](https://forum.magtek.com/)

**Documentation Feedback:**

Help us improve this documentation! [Submit feedback](broken://spaces/1lWLescKFIPsMeIJI6Cd/pages/5314c528980689961380bea0044c1256aaeb39bc)
{% endhint %}


# DynaFamily Command Matrix

Every MMS command is documented once in this reference. This matrix shows which commands each DynaFamily reader supports, so you can confirm availability before building against a device. A command marked — is not available on that device's current firmware; some commands depend on a hardware option (noted below the table).

**Legend:** ✓ supported · — not supported

| Command                                                                                                                                                                                                                                                                                                       | DynaFlex II PED | DynaFlex II Go | DynaProx | DynaFlex II SCR |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------: | :------------: | :------: | :-------------: |
| **Transactions**                                                                                                                                                                                                                                                                                              |                 |                |          |                 |
| [<mark style="color:red;">**Start Transaction**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/transactions-command-group-0x10nn/command-0x1001-start-transaction)                                                                                                            |        ✓        |        ✓       |     ✓    |        ✓        |
| [<mark style="color:red;">**Resume Transaction**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/transactions-command-group-0x10nn/resume-transaction-command-0x1004)                                                                                                          |        ✓        |        ✓       |     ✓    |        ✓        |
| [<mark style="color:red;">**Cancel Transaction**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/transactions-command-group-0x10nn/cancel-transaction-command-0x1008)                                                                                                          |        ✓        |        ✓       |     ✓    |        ✓        |
| **NFC / MIFARE pass-through**                                                                                                                                                                                                                                                                                 |                 |                |          |                 |
| [<mark style="color:red;">**NTag / MIFARE Ultralight**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/nfc-mifare-pass-through-commands-contactless-only-command-group-0x11nn/pass-through-command-for-ntag-mifare-ultralight-type-2-command-0x1100)                           |        ✓        |        ✓       |     ✓    |        ✓        |
| [<mark style="color:red;">**MIFARE Classic / MINI / Plus SL1**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/nfc-mifare-pass-through-commands-contactless-only-command-group-0x11nn/pass-through-command-for-mifare-classic-mini-r-plus-sl1-security-level-1-command-0x1101) |        ✓        |        ✓       |     ✓    |        ✓        |
| [<mark style="color:red;">**MIFARE DESFire**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/nfc-mifare-pass-through-commands-contactless-only-command-group-0x11nn/pass-through-command-for-mifare-desfire-type-4-command-0x1102)                                             |        ✓        |        ✓       |     ✓    |        ✓        |
| [<mark style="color:red;">**MIFARE Plus**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/nfc-mifare-pass-through-commands-contactless-only-command-group-0x11nn/pass-through-command-for-mifare-plus-type-2-command-0x1103)                                                   |        ✓        |        ✓       |     ✓    |        ✓        |
| **User interface**                                                                                                                                                                                                                                                                                            |                 |                |          |                 |
| [<mark style="color:red;">**Request Cardholder Signature**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/request-cardholder-signature-touch-only-command-0x1801)                                                                         |        ✓        |        —       |     —    |        —        |
| [<mark style="color:red;">**Report Cardholder Selection**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/report-cardholder-selection-command-0x1802)                                                                                      |        ✓        |        —       |     ✓    |        ✓        |
| [<mark style="color:red;">**Display Message**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/display-message-display-only-command-0x1803)                                                                                                 |        ✓        |        —       |     —    |        —        |
| [<mark style="color:red;">**Read Barcode (BCR option)**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/read-barcode-bcr-only-command-0x1804)                                                                                              |        ✓        |        ✓       |     ✓    |        ✓        |
| [<mark style="color:red;">**Buzzer**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/buzzer-command-0x1805)                                                                                                                                |        ✓        |        ✓       |     ✓    |        ✓        |
| [<mark style="color:red;">**Personal Info Entry**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/personal-info-entry-command-0x1806)                                                                                                      |        ✓        |        ✓       |     —    |        ✓        |
| [<mark style="color:red;">**Show Image**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/show-image-display-only-command-0x1821)                                                                                                           |        ✓        |        —       |     —    |        —        |
| [<mark style="color:red;">**Show QR Code**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/show-qr-code-display-only-command-0x1822)                                                                                                       |        ✓        |        —       |     —    |        —        |
| [<mark style="color:red;">**Show Bitmap Image**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/show-bitmap-image-display-only-command-0x1823)                                                                                             |        ✓        |        —       |     —    |        —        |
| [<mark style="color:red;">**Display Flexible UI Pages**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/display-flexible-ui-pages-display-only-command-0x1830)                                                                             |        ✓        |        —       |     —    |        —        |
| [<mark style="color:red;">**LED Control**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/led-control-command-0x1807)                                                                                                                      |        ✓        |        ✓       |     ✓    |        ✓        |
| [<mark style="color:red;">**Card Emulation**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/card-emulation)                                                                                                                                     |        ✓        |        ✓       |     ✓    |        ✓        |
| **Generic pass-through**                                                                                                                                                                                                                                                                                      |                 |                |          |                 |
| [<mark style="color:red;">**Pass-Through Mode Start / Stop**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/generic-pass-through-commands-command-group-0x30nn/pass-through-mode-start-stop-command-0x3001)                                                                   |        ✓        |        ✓       |     ✓    |        ✓        |
| [<mark style="color:red;">**Start / Stop Polling**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/generic-pass-through-commands-command-group-0x30nn/start-stop-polling-command-0x3002)                                                                                       |        ✓        |        ✓       |     ✓    |        ✓        |
| [<mark style="color:red;">**ISO 14443-4 APDU Pass-Through**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/generic-pass-through-commands-command-group-0x30nn/iso-14443-4-apdu-pass-through-commands-command-0x3003)                                                          |        ✓        |        ✓       |     ✓    |        ✓        |
| **Device control**                                                                                                                                                                                                                                                                                            |                 |                |          |                 |
| [<mark style="color:red;">**Reset Device**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/device-control-command-group-0x1fnn/reset-device-command-0x1f01)                                                                                                                    |        ✓        |        ✓       |     ✓    |        ✓✓       |
| [<mark style="color:red;">**Set Notification Subscriptions**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/device-control-command-group-0x1fnn/set-notification-subscriptions-command-0x1f02)                                                                                |        ✓        |        ✓       |     ✓    |        —        |
| [<mark style="color:red;">**Extend Session**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/device-control-command-group-0x1fnn/extend-session-session-management-only-command-0x1f03)                                                                                        |        ✓        |        —       |     —    |        —        |
| [<mark style="color:red;">**Terminate Bluetooth LE Connection**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/device-control-command-group-0x1fnn/terminate-bluetooth-le-connection-bluetooth-le-only-command-0x1f04)                                                        |        —        |        ✓       |     —    |        —        |
| [<mark style="color:red;">**Erase All Bluetooth LE Bonds**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/device-control-command-group-0x1fnn/erase-all-bluetooth-le-bonds-bluetooth-le-only-command-0x1f05)                                                                  |        —        |        ✓       |     —    |        —        |
| **Banking functions**                                                                                                                                                                                                                                                                                         |                 |                |          |                 |
| [<mark style="color:red;">**Request PIN with Host Supplied Account Data**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/banking-functions-touch-display-only-command-group-0x20nn/request-pin-with-host-supplied-account-data-banking-functions-only-command-0x2001)         |        ✓        |        —       |     —    |        —        |
| [<mark style="color:red;">**Request PIN with Card Supplied Account Data**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/banking-functions-touch-display-only-command-group-0x20nn/request-pin-with-card-supplied-account-data-banking-functions-only-command-0x2002)         |        ✓        |        —       |     —    |        —        |
| **Settings & information**                                                                                                                                                                                                                                                                                    |                 |                |          |                 |
| [<mark style="color:red;">**Get Property**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/settings-and-information-command-group-0xd1nn/get-property-command-0xd101)                                                                                                          |        ✓        |        ✓       |     ✓    |        ✓        |
| [<mark style="color:red;">**Set Property (Unsecured)**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/settings-and-information-command-group-0xd1nn/set-property-unsecured-command-0xd111)                                                                                    |        ✓        |        ✓       |     ✓    |        ✓        |
| [<mark style="color:red;">**Set Property (Secured)**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/settings-and-information-command-group-0xd1nn/set-property-secured-command-0xd112)                                                                                        |        ✓        |        ✓       |     ✓    |        ✓        |
| **File operations**                                                                                                                                                                                                                                                                                           |                 |                |          |                 |
| [<mark style="color:red;">**Load Firmware File**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/file-operations-command-group-0xd8nn/load-firmware-file-command-0xd801)                                                                                                       |        ✓        |        ✓       |     ✓    |        ✓        |
| [<mark style="color:red;">**Start Send File to Device (Secured)**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/file-operations-command-group-0xd8nn/start-send-file-to-device-secured-command-0xd811)                                                                       |        ✓        |        ✓       |     ✓    |        ✓        |
| [<mark style="color:red;">**Start Send File to Device (Unsecured)**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/file-operations-command-group-0xd8nn/start-send-file-to-device-unsecured-command-0xd812)                                                                   |        ✓        |        ✓       |     ✓    |        ✓        |
| [<mark style="color:red;">**Start Get File from Device**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/file-operations-command-group-0xd8nn/start-get-file-from-device-command-0xd821)                                                                                       |        ✓        |        ✓       |     ✓    |        ✓        |
| [<mark style="color:red;">**Get File Info from Device**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/file-operations-command-group-0xd8nn/get-file-info-from-device-command-0xd825)                                                                                         |        ✓        |        ✓       |     ✓    |        ✓        |
| [<mark style="color:red;">**Delete File from Device**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/file-operations-command-group-0xd8nn/delete-file-from-device-command-0xd831)                                                                                             |        ✓        |        ✓       |     ✓    |        ✓        |
| [<mark style="color:red;">**Commit Firmware from File**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/process-files-command-group-0xd9nn/commit-firmware-from-file-command-0xd901)                                                                                           |        ✓        |        ✓       |     ✓    |        ✓        |
| **Diagnostics & utilities**                                                                                                                                                                                                                                                                                   |                 |                |          |                 |
| [<mark style="color:red;">**Echo**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/diagnostics-and-utilities-command-group-0xdfnn/echo-command-0xdf01)                                                                                                                         |        ✓        |        ✓       |     ✓    |        ✓        |
| **Security**                                                                                                                                                                                                                                                                                                  |                 |                |          |        —        |
| [<mark style="color:red;">**Get Challenge**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/security-command-group-0xennn/get-challenge-command-0xe001)                                                                                                                        |        ✓        |        ✓       |     ✓    |        ✓        |
| [<mark style="color:red;">**Send Secured Command to Device**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/security-command-group-0xennn/send-secured-command-to-device-command-0xeeee)                                                                                      |        ✓        |        ✓       |     ✓    |        ✓        |
| [<mark style="color:red;">**Load Key Using TR-31**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/security-command-group-0xennn/load-key-using-tr-31-command-0xef01)                                                                                                          |        ✓        |        ✓       |     ✓    |        ✓        |
| [<mark style="color:red;">**Generate CSR Keys**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/security-command-group-0xennn/generate-csr-keys-wlan-only-command-0xef02)                                                                                                      |        —        |        —       |     —    |        —        |
| [<mark style="color:red;">**Change Device Lock State**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/security-command-group-0xennn/change-device-lock-state-command-0xef06)                                                                                                  |        —        |        ✓       |     —    |        ✓        |
| [<mark style="color:red;">**Change Device Lock Passcode**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/security-command-group-0xennn/change-device-lock-passcode-command-0xef07)                                                                                            |        ✓        |        ✓       |     ✓    |        ✓        |
| [<mark style="color:red;">**Get Key**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/security-command-group-0xennn/get-key-info-command-0xef11)                                                                                                                               |        ✓        |        ✓       |     ✓    |        ✓        |
| **Manufacturing**                                                                                                                                                                                                                                                                                             |                 |                |          |                 |
| [<mark style="color:red;">**Establish Ephemeral KBPK**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/manufacturing-command-group-0xfnnn/establish-ephemeral-kbpk-command-0xf017)                                                                                             |        ✓        |        ✓       |     ✓    |        ✓        |

### Notes on device-specific commands

* **PIN / banking** (Request PIN) require a PIN-entry device — **PED only**.
* **Bluetooth LE** commands (Terminate Connection, Erase Bonds) require a BLE radio — **DynaFlex II Go only** among these; corded devices omit them.
* **Full-display UI** commands (Display Message, Show Image / QR / Bitmap, Flexible UI Pages, Request Cardholder Signature) require the full touch display — DynaFlex II **PED only**.
* **Read Barcode** requires the barcode-reader (BCR) hardware option.
* **Establish Ephemeral KBPK** is a provisioning/manufacturing command — confirm whether it should be publicly listed or kept to an internal space.

### Need More Help

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** [support@magtek.com](mailto:support@magtek.com?subject=Support%20Request)
* 📞 **Phone:** 1-562-546-6800 (US)
* 🕐 **Hours:** Monday-Friday, 5:30 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Support Portal:** developer.magtek.com

**Documentation Feedback:**

Help us improve this documentation! [feedback@magtek.com](mailto:feedback@magtek.com?subject=Feedback)
{% endhint %}


# SCRA DynaFamily Programmer's Manual

The SCRA DynaFamily Programmer's Manual is the complete reference for the Multi-Interface Card Reader Platform (MMS) command set. It's written once for the whole family — DynaFlex, DynaProx, and DynaFlex II Go share the same commands, responses, and notifications — so this manual is device-agnostic. To confirm which commands a specific reader supports, use the DynaFamily Command Matrix.

New to the platform? Start with [<mark style="color:red;">**About The SCRA DynaFamily Programmer's Manual**</mark> ](/api-and-command-reference/scra-dynafamily-programmers-manual)for scope and conventions, and [<mark style="color:red;">**About Terminology**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/about-terminology) for the vocabulary used throughout.

### In This Manual

| **Section**                                                                                                                                                                        | **Information**                                                                                    |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| [<mark style="color:red;">**About The SCRA DynaFamily Programmer's Manual**</mark> ](/api-and-command-reference/scra-dynafamily-programmers-manual)                                | An introductory section that covers scope and conventions                                          |
| [<mark style="color:red;">**About Terminology**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/about-terminology)                                           | the vocabulary used throughout.                                                                    |
| [<mark style="color:red;">**Message Format & Structure**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/message-format-and-structure)                       | How MMS requests, responses, and notifications are framed and parsed.                              |
| [<mark style="color:red;">**Data Types and Shared TLV Data Objects**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects) | The shared TLV and EMV objects the commands carry.                                                 |
| [<mark style="color:red;">**Commands**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands)                                                             | The full command set, grouped by family.                                                           |
| [<mark style="color:red;">**Notifications**</mark> ](/api-and-command-reference/scra-dynafamily-programmers-manual/notifications)                                                  | the asynchronous messages a device sends during transactions, device events, and firmware updates. |
| [<mark style="color:red;">**Properties**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/properties)                                                         | The configurable properties and parameters.                                                        |
| [<mark style="color:red;">**Appendices**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/appendices)                                                         | Status and response codes, plus supporting reference material.                                     |

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** <support@magtek.com>
* 📞 **Phone:** 1-800-788-6835 (US) | +1-562-546-6616 (International)
* 🕐 **Hours:** Monday-Friday, 6:00 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Official Site:** [https://www.magtek.com](https://www.magtek.com/)
* 💬 **Developer Forum:** [https://forum.magtek.com](https://forum.magtek.com/)

**Documentation Feedback:**

Help us improve this documentation! [Submit feedback](broken://spaces/1lWLescKFIPsMeIJI6Cd/pages/5314c528980689961380bea0044c1256aaeb39bc)
{% endhint %}


# About The SCRA DynaFamily Programmer's Manual

These pages detail how to communicate with Secure Card Reader Authenticator (SCRA) devices which implement MagTek Messaging Schema (MMS) and the DynaFlex family, DynaFlex II Go and DynaProx system architecture.

These pages also describe how to communicate with PIN Entry Devices (PED) which implement MagTek Messaging Schema (MMS) and the DynaFlex/DynaProx family system architecture. (PED ONLY)

These pages use **bold face** to:

* Highlight terms / concepts being formally defined in the current sentence / paragraph
* Highlight important distinguishing keywords in sentences
* Indicate hyperlinks to other sections / tables

These pages use a small number of annotation standards that are important to understand:

* Hexadecimal values are prefixed with **0x** unless the context clearly indicates an un-prefixed number is hexadecimal (for example, TLV tags, lengths, and values are always assumed to be hex).
* Binary values are prefixed with **0b** unless the context clearly indicates the value is binary.
* Decimal values are not prefixed unless required for clarity, in which case the prefix is **0d**.

The standard documented by these pages makes extensive use of Tag-Length-Value encoding. [<mark style="color:red;">**Tag-Length-Value (TLV) Encoding**</mark> ](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects)describes how to encode and decode TLV, and how to read the tables in this document that describe TLV data objects.

## See Also

* [<mark style="color:red;">**Tag-Length-Value (TLV) Encoding**</mark> ](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects)

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** <support@magtek.com>
* 📞 **Phone:** 1-800-788-6835 (US) | +1-562-546-6616 (International)
* 🕐 **Hours:** Monday-Friday, 6:00 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Official Site:** [https://www.magtek.com](https://www.magtek.com/)
* 💬 **Developer Forum:** [https://forum.magtek.com](https://forum.magtek.com/)

**Documentation Feedback:**

Help us improve this documentation! [Submit feedback](broken://spaces/1lWLescKFIPsMeIJI6Cd/pages/5314c528980689961380bea0044c1256aaeb39bc)
{% endhint %}


# About Terminology

* **Device** refers to the Secure Card Reader Authenticator (SCRA) or PIN Entry Device (PED) that receives and responds to the command set specified in this document. Not all devices support PIN entry. Devices include DynaFlex, DynaProx, DynaFlex II, and so on.
* **Host** refers to the piece of general-purpose electronic equipment the device is connected or paired to, which can send data to and receive data from the device. Host types include PC and Mac computers/laptops, tablets, smartphones, teletype terminals, and even test harnesses. In many cases the host may have custom software installed on it that communicates with the device. When “host” must be used differently, it is qualified as something specific, such as “acquirer host” or “USB host.”

Similarly, the word “user” is used in different ways in different contexts. This document separates users into more descriptive categories:

* The **cardholder**
* The **operator** (such as a cashier, bank teller, customer service representative, or server)
* The **developer** or the **administrator** (such as an integrator configuring the device for the first time)

Because some connection types, payment brands, and other vocabulary name spaces (notably Bluetooth® LE, EMV, smart phones, and more recent versions of Windows) use very specific meanings for the term “Application,” this document favors the term **host software** to refer to software on the host that provides a user interface for the operator.

The combination of device(s), host(s), host software, device firmware, device configuration settings, physical mounting and environment, user experience, and documentation is referred to as the **solution**.


# Message Format & Structure

## Message Format & Structure

The host and the device communicate with each other by exchanging blocks of data called messages, which are standardized wrappers containing a payload. This section will detail everything you need to know about using messages.&#x20;

{% hint style="success" %}
Applies to: All DynaFamily products
{% endhint %}

### Information in this group

| **Section**                                                                                                                                                           | **Information**                                                            |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
| [<mark style="color:red;">**About Messages**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/message-format-and-structure/about-messages)       | The basics on messages, what they are, and how they work.                  |
| [<mark style="color:red;">**Message Format**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/message-format-and-structure/message-format)       | Learn about the TLV encoding that make messages work.                      |
| [<mark style="color:red;">**Message Structure**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/message-format-and-structure/message-structure) | .Each message type follows a specific structure described in this section. |

### See Also

| **Section**                                                                                                                      | **Information**                                                                              |
| -------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| [<mark style="color:red;">**Commands**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands)           | Information on device-level commands                                                         |
| [<mark style="color:red;">**Notifications**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/notifications) | Information on notices your device my send and the circumstances under which they send them. |
| [<mark style="color:red;">**Configurations**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/properties)   | Information of configuring your devices in various ways.                                     |

### See Also

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** [support@magtek.com](mailto:support@magtek.com?subject=Support%20Request)
* 📞 **Phone:** 1-562-546-6800 (US)
* 🕐 **Hours:** Monday-Friday, 5:30 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Support Portal:** developer.magtek.com

**Documentation Feedback:**

Help us improve this documentation! [feedback@magtek.com](mailto:feedback@magtek.com?subject=Feedback)
{% endhint %}


# About Messages

The host and the device communicate with each other by exchanging blocks of data called **Messages**, which are standardized wrappers containing a **payload** that is either a command **Request**, a command **Response**, an unsolicited **Notification**, or a **File**. For example, the host may send a command **request** message to the device to change a configuration setting, and the device may send a command **response** message to indicate the command was successful; when a cardholder inserts a card, the device may send a [<mark style="color:$tint;">**notification**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/notifications) message to the host that a cardholder has initiated a transaction; the host may send the device a **file** message to load firmware.

Messages can be nested. For example, a top-level secure wrapper request from the host to the device may contain an encrypted or signed command request for the device to unpack, validate, and execute.

### Requests and Responses

* Requests and responses are two of the message payload types the host and device exchange inside messages. The combination of a message that contains a **request** payload and a message that contains the corresponding **response** payload is referred to generally in this document as a [<mark style="color:red;">**Command**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands).
* The device can only service one command request at a time, and sends each command response within a pre-determined finite amount of time after receiving the request.
* After sending a command request, the host must wait until the device returns a response before sending another request, or until the request is unanswered after a reasonable host-defined timeout period passes.

### Notifications

* [<mark style="color:red;">**Notifications**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/notifications) are a message payload type the host and device exchange inside messages. The device sends notification messages to the host if the device’s state changes or if an external event occurs, such as a cardholder inserting a card.
* The device can send a notification at any time, and does not expect a response or any specific action from the host.
* By default, the device sends all notifications to the USB interface. To configure the device to send notifications on additional connections, use [<mark style="color:red;">**Set Notification Subscriptions - Command 0x1F02**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands/device-control-command-group-0x1fnn/set-notification-subscriptions-command-0x1f02).

### Data Files

* Data Files are a message payload type the host and device exchange inside messages. The device handles them as a stream: it begins storing the payload of the message before it has received the final packet of the message, allowing for much larger payloads than standard requests.
* This streaming behavior is possible because the message is restricted to transferring a file and thus the message payload is primitive data only; it cannot contain composed TLV data objects.

Regardless of connection type, all MMS devices use the same schema for sending and receiving messages, which is documented inMessage Format. For information about transmitting and receiving messages using specific connection types (which involves following connection-specific rules for breaking messages down into transmittable **Message Streams**), see [<mark style="color:red;">**Connection Types**</mark>](https://developer.magtek.com/guides/guides/connection-basics).


# Message Format

### Tag-Length-Value (TLV) Encoding

#### About TLV Encoding

All messages exchanged between the host and the device are formatted using the tag-length-value **Distinguished Encoding Rules** (DER) defined in ***ITU-T X.680 | ISO/IEC 8824-1*** and ***ITU-T X.690 | ISO/IEC 8825-1***. A subset of these standards is also used in ***EMV Integrated Circuit Card Specifications for Payment Systems 4.3, Part IV, Annex B Rules for BER-TLV Data Objects***, so the latter can serve as a useful point of reference.

Summarizing those specifications, each TLV data object follows these basic rules:

* The DER standard designates the least significant bit of a byte as **bit 1**, and the most significant bit of a byte as **bit 8**. This is different from the remainder of the MMS standard, which indexes bit numbers starting at 0 to be consistent with each bit position number representing that bit’s power of 2.
* The **Tag** or **Identifier** portion of a TLV data object identifies the TLV data object. DER assigns the tag portion as follows:
  * Bits 8 and 7 specify whether the TLV data object is universal, application-defined, context-specific, or private. Most messages in this standard contain **context-specific** tags (bits 8 and 7 = **10**), meaning different messages reuse the same tags, and the tags represent sequentially numbered parameters passed in any message.
  * Bit 6 specifies whether the tag is [<mark style="color:red;">**primitive**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/primitive-data-types) (bit 6 = **0**), meaning it contains its values directly, or **constructed** (bit 6 = **1**), meaning the TLV data object contains more TLV data objects.
  * Bits 5 to 1 specify a unique tag number, with 11111 reserved to mean the tag is not a single byte long. In that multi-byte case:
    * Bits 7 to 1 of subsequent bytes with bit 8 set to 1 are also part of the tag identifier with the most significant of the whole tag number in bit 7.
    * Bits 7 to 1 of the final byte with bit 8 set to 0 are also part of the tag identifier.
* The **Length** portion is the total length of the Data portion that follows it. Lengths can be either short form or long form:
  * Short form: one byte long in the range 0x00 to 0x7F.
  * Long form: multiple bytes long, starting with one byte 0x80 or greater, where the lower 7 bits specify how many subsequent bytes are used to indicate the length. Example: length 8201C3 — 0x82 indicates two subsequent bytes (0x01C3) giving the total length of the data block (451 bytes).
  * DER stipulates all TLV objects should be encoded using the smallest length required to fit the data.
* The **Value** or **Data** portion is the actual payload of the TLV data object.

This document provides message definitions in hexadecimal format; when the host constructs or interprets a message, if no additional encode/decode filtering or translation is in place at the platform layer, it should expect each hexadecimal value shown in this document to be represented as binary bytes in the message stream, not as string literals. For example, FF is a single byte with all bits set to 1, not the two-byte string literal "FF."

#### TLV Example

Below is an example of a TLV-encoded request and response for[ <mark style="color:red;">**Echo - Command 0xDF01**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands/diagnostics-and-utilities-command-group-0xdfnn/echo-command-0xdf01), wrapped in the standard message format.

Host sends the device the binary byte stream:

```
AA0081040101DF018407DF018103010203
```

Breakdown:

* AA00 = Standard Start of Message / API Framework Version (not TLV)
* 81, 04, 0101DF01
  * Tag 81 = Request Message Parameter 1, **Message Information**
  * Length 04
  * Value 01 01 DF 01
    * 01 = Request from host to device
    * 01 = Message reference number
    * DF01 = [<mark style="color:red;">**Echo - Command 0xDF01**</mark> ](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands/diagnostics-and-utilities-command-group-0xdfnn/echo-command-0xdf01)
* 84, 07, DF018103010203
  * Tag 84 = Request Message Parameter 4, **Request Payload**
  * Length 07
  * Value DF01 81 03 01 02 03
    * DF01 = Payload format is for Request **Echo 0 Command 0xDF01,** (not TLV)
    * Tag 81 = Payload Parameter 1, **Value to Echo**
    * Length 03
    * Value 01 02 03 = Value to Echo

Device responds with the binary byte stream:

```
AA0081048201DF018204000000008407DF018103010203
```

Breakdown:

* AA00 = Standard Start of Message / API Framework Version (not TLV)
* 81, 04, 8201DF01
  * Tag 81 = Response Message Parameter 1, **Message Information**
  * Length 04
  * Value 82 01 DF 01
    * 82 = Response from device to host
    * 01 = Message reference number
    * DF01 = [<mark style="color:red;">**Echo - Command 0xDF01**</mark> ](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands/diagnostics-and-utilities-command-group-0xdfnn/echo-command-0xdf01)
* 82, 04, 00000000
  * Tag 82 = Response Message Parameter 2, **Response Status** (one byte Operation Status Summary, three bytes Operation Status Detail)
  * Length 04
  * Value 00 00 00 00 = OK / Done, General / All Good / Requested operation was successful
* 84, 07, DF018103010203
  * Tag 84 = Response Message Parameter 4 for **Response Payload**
  * Length 07
  * Value DF01 81 03 01 02 03
    * DF01 = Payload format is for Response [<mark style="color:red;">**Echo - Command 0xDF01**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands/diagnostics-and-utilities-command-group-0xdfnn/echo-command-0xdf01)**,** (not TLV)
    * Tag 81 = Payload Parameter 1, **Value to Echo**
    * Length 03
    * Value 01 02 03 = Value to Echo

## How to Read TLV Tables

Tables that show TLV data objects use slashes in front of the **Tag** identifier to indicate that object’s relative level of nesting/containment within other TLV data objects in the same table. These levels are relative and not absolute: a given TLV object may be nested within other TLV objects at any level.

Example of slash notation:

* Earth contains
  * /North America, which contains
    * //United States, which contains
      * ///California

In TLV tables, a Length of **var** means the length is variable and must be calculated based on nested objects.

See Table MFT-1 below for an example.

#### TLV Table Example

<table><thead><tr><th width="80.33331298828125">Tag</th><th width="72">Len</th><th>Value / Description</th><th width="73.7333984375">Typ</th><th width="87">Req</th><th width="121.00006103515625">Default</th></tr></thead><tbody><tr><td>A1</td><td>var</td><td>TLV data object <strong>A1</strong> contains four directly nested TLV data objects: 81, 82, A3, and 84 (A1/81, A1/82, A1/A3, and A1/84). A1/82 is optional (Req = <strong>O</strong>), so the length of A1 will vary depending on whether or not A1/82 is included (Len = <strong>var</strong>).</td><td>T</td><td>R</td><td></td></tr><tr><td>/81</td><td>01</td><td>TLV data object A1/81 contains one byte and is required. It has no default value because it must be explicitly included.</td><td>B</td><td>R</td><td></td></tr><tr><td>/82</td><td>03</td><td>TLV data object A1/82 contains three bytes but is optional. If not included, the device assumes the default value 0x4D6F6D.</td><td>B</td><td>O</td><td>0x4D6F6D</td></tr><tr><td>/A3</td><td>08</td><td>TLV data object A1/A3 contains two TLV data objects: 81 and 82 (A1/A3/81 and A1/A3/82). Its length is the combined length of its two nested objects.</td><td>T</td><td>R</td><td></td></tr><tr><td>//81</td><td>03</td><td>TLV data object A1/A3/81 contains three bytes and is required.</td><td>B</td><td>R</td><td></td></tr><tr><td>//82</td><td>01</td><td>TLV data object A1/A3/82 contains one byte and is required.</td><td>B</td><td>R</td><td></td></tr><tr><td>/84</td><td>03</td><td>TLV data object A1/84 contains three bytes that represent distinct values stored directly inside A1/84 instead of separate nested TLVs.</td><td>B</td><td>R</td><td></td></tr><tr><td>//null</td><td>(1)</td><td>Raw byte inside 84 (no TLV). Tag shown as <strong>/null</strong>, length in parentheses.</td><td>B</td><td>R</td><td></td></tr><tr><td>//null</td><td>(1)</td><td>Another raw byte inside 84.</td><td>B</td><td>R</td><td></td></tr><tr><td>//null</td><td>(1)</td><td>Another raw byte inside 84.</td><td>B</td><td>R</td><td></td></tr></tbody></table>


# Message Structure

Each message type follows a specific structure described below.

## Request Message

## Request Message Format

<table><thead><tr><th width="79.33331298828125">Tag</th><th width="73.66668701171875">Len</th><th>Value / Description</th><th width="80.66668701171875">Typ</th><th width="85">Req</th><th width="110.66656494140625">Default</th></tr></thead><tbody><tr><td>-</td><td>-</td><td>One byte standard <strong>Start of Message</strong> constant, not in TLV format. 0xAA = Standard start of message byte.</td><td>-</td><td>-</td><td>-</td></tr><tr><td>-</td><td>-</td><td>One-byte standard <strong>API Framework Version</strong>, not TLV. Values: 0x00 = Pre-production, 0x01 = First production release, 0x02 = Second production release, etc.</td><td>-</td><td>-</td><td>-</td></tr><tr><td>81</td><td>var</td><td>Message Information</td><td>B</td><td>R</td><td></td></tr><tr><td>/null</td><td>(1)</td><td><p>Message Type &#x26; Direction: </p><ul><li>0x01 = Request from host to device.</li><li>0x81 = Request from device to host (Reserved).</li></ul></td><td>B</td><td>R</td><td></td></tr><tr><td>/null</td><td>(1)</td><td>Message Reference Number</td><td>B</td><td>R</td><td></td></tr><tr><td>/null</td><td>(2)</td><td>Command ID — fully qualified Command number (Command Group, Command within that group). If the Request Payload contains wrappers, the host should specify the command invoked at the core after wrappers are removed.</td><td>B</td><td>R</td><td></td></tr><tr><td>/null</td><td>(var)</td><td>Reserved</td><td></td><td>O</td><td></td></tr><tr><td>84</td><td>var</td><td>Request Payload — as documented in the message’s Request table in section <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands"><mark style="color:red;"><strong>Commands</strong></mark></a>.</td><td>B</td><td>R</td><td></td></tr><tr><td>9E</td><td>var</td><td>Reserved</td><td>B</td><td>O</td><td></td></tr></tbody></table>

Notes:

* Message Reference Number: host can use any value to match responses; device echoes it in responses. Recommended: incrementing counter per request within a session.

## Response Message

## Response Message Format

## Operation Status Detail Codes

The tables below list operation status detail codes grouped by source and code. (Only a representative subset is shown here; see the full document for all codes.)

## General (group 0x00)

{% hint style="info" %}
The General group 0x00 contains operation status detail codes related to the platform that do not originate from a specific functional module.

Subgroup 0x00 = General
{% endhint %}

<table data-header-hidden><thead><tr><th width="77"></th><th width="59.3636474609375"></th><th width="57.727294921875"></th><th></th></tr></thead><tbody><tr><td>Grp</td><td>Sub</td><td>Cde</td><td>Meaning</td></tr><tr><td>00</td><td>00</td><td>00</td><td>All good / requested operation was successful.</td></tr><tr><td>00</td><td>00</td><td>02</td><td>Requested Operation Failed</td></tr><tr><td>00</td><td>00</td><td>10</td><td>Setting up RTC data and time failure</td></tr><tr><td>00</td><td>00</td><td>11</td><td>Setting up RTC alarm failure</td></tr><tr><td>00</td><td>00</td><td>12</td><td>Key generation failure</td></tr><tr><td>00</td><td>00</td><td>13</td><td>Tamper setting is locked, can’t be changed</td></tr><tr><td>00</td><td>00</td><td>14</td><td>Tamper setting requires system reset to continue</td></tr><tr><td>00</td><td>00</td><td>15</td><td>Tamper status can’t be cleared, failure</td></tr><tr><td>00</td><td>00</td><td>16</td><td>Device has been tampered, need attention</td></tr><tr><td>00</td><td>00</td><td>17</td><td>Tamper module failed for other cases</td></tr><tr><td>00</td><td>00</td><td>18</td><td>Setting WLAN SoftAP password failure</td></tr></tbody></table>

## Message Handler (group 0x01)

{% hint style="info" %}
The Message Handler group 0x01 contains operation status detail codes related to parsing and validating messages.

Subgroup 0x01 = Device issues that prevent Message Processing (e.g., Critical Battery, Pending Reset, System Failure, System Busy).
{% endhint %}

<table data-header-hidden><thead><tr><th width="68.8182373046875"></th><th width="59.6363525390625"></th><th width="76.27276611328125"></th><th></th></tr></thead><tbody><tr><td>Grp</td><td>Sub</td><td>Cde</td><td>Meaning</td></tr><tr><td>01</td><td>01</td><td>01</td><td>Generic Failure.</td></tr><tr><td>01</td><td>01</td><td>02</td><td>Bad message parameter.  The host has sent a message to the device that is not constructed properly.</td></tr><tr><td>01</td><td>01</td><td>09</td><td>Device offline, can not process messages.  For example, the device returns this detail code when it does not have keys injected or has registered a tamper.</td></tr><tr><td>01</td><td>01</td><td>10</td><td>PIN Key Not Mapped.</td></tr><tr><td>01</td><td>01</td><td>13</td><td>Feature Not Available</td></tr></tbody></table>

## Request Handler (group 0x02) — representative entries

{% hint style="info" %}
The Request Handler group 0x02 contains operation status detail codes related to starting actual command requests.

* Subgroup 0x01 = Data issues (bad, missing, unknown…)
* Subgroup 0x02 = Security / permission problems
* Subgroup 0x03 = Device state issues (busy, not permitted, tampered, low battery)
* Subgroup 0x04 = Device issues (missing hardware or features)
* Subgroup 0x05 = TR31 Errors
  {% endhint %}

<table data-header-hidden><thead><tr><th width="56.09088134765625"></th><th width="65.45452880859375"></th><th width="64.81817626953125"></th><th></th></tr></thead><tbody><tr><td>Grp</td><td>Sub</td><td>Cde</td><td>Meaning</td></tr><tr><td>02</td><td>00</td><td>00</td><td>Reserved</td></tr><tr><td>02</td><td>01</td><td>00</td><td>Reserved</td></tr><tr><td>02</td><td>01</td><td>01</td><td>Generic Failure</td></tr><tr><td>02</td><td>01</td><td>02</td><td>Bad Message Parameter</td></tr><tr><td>02</td><td>01</td><td>03</td><td>Response Payload too big</td></tr><tr><td>02</td><td>01</td><td>07</td><td>Internal FW Failure</td></tr><tr><td>02</td><td>01</td><td>0A</td><td>Image Failure</td></tr><tr><td>02</td><td>01</td><td>19</td><td>Key does not exist</td></tr><tr><td>02</td><td>01</td><td>1A</td><td>Not Secured</td></tr><tr><td>02</td><td>01</td><td>1B</td><td>Passcode validation failed</td></tr><tr><td>02</td><td>01</td><td>1C</td><td>Device is locked</td></tr><tr><td>02</td><td>01</td><td>1D</td><td>Device in Restricted mode</td></tr><tr><td>02</td><td>02</td><td>00</td><td>Reserved</td></tr><tr><td>02</td><td>03</td><td>04</td><td>Failed, device state issue, no transaction.</td></tr><tr><td>02</td><td>03</td><td>05</td><td>Failed, device state issue, cannot cancel.</td></tr><tr><td>02</td><td>03</td><td>08</td><td>Failed, device state, Transaction in Progress.</td></tr><tr><td>02</td><td>03</td><td>0C</td><td>Failed, device state, Signature Not allowed</td></tr><tr><td>02</td><td>03</td><td>0D</td><td>Failed, device state, Wrong Transaction State</td></tr><tr><td>02</td><td>03</td><td>0E</td><td>Failed, device state, Invalid PIN Entry State</td></tr><tr><td>02</td><td>03</td><td>0F</td><td>Failed, device state, PIN Entry in Session.</td></tr><tr><td>02</td><td>03</td><td>11</td><td>Failed, device state, Barcode Read in Progress.</td></tr><tr><td>02</td><td>03</td><td>12</td><td>Failed, device state, Pass-through command Not Activated.</td></tr><tr><td>02</td><td>03</td><td>14</td><td>Failed, device state, UI Settings in Progress.</td></tr><tr><td>02</td><td>03</td><td>15</td><td>Failed, device state, Buzzer in Progress</td></tr><tr><td>02</td><td>03</td><td>16</td><td>Failed, device state, Low Battery (5% or less)</td></tr><tr><td>02</td><td>03</td><td>18</td><td>Request is invalid while card emulation is in progress</td></tr><tr><td>02</td><td>03</td><td>1E</td><td>Failed, device state, pass-through mode started</td></tr><tr><td>02</td><td>03</td><td>1F</td><td>Failed, device state, pass-through mode is not started</td></tr><tr><td>02</td><td>03</td><td>20</td><td>Failed, device state, pass-through mode APDU is in progress</td></tr><tr><td>02</td><td>04</td><td>13</td><td>Failed, BCR hardware not found.</td></tr><tr><td>02</td><td>05</td><td>01</td><td>Invalid TR31parameter</td></tr><tr><td>02</td><td>05</td><td>02</td><td>Invalid AES length</td></tr><tr><td>02</td><td>05</td><td>03</td><td>Invalid 16-Byte Boundary</td></tr><tr><td>02</td><td>05</td><td>04</td><td>Invalid Length in Message</td></tr><tr><td>02</td><td>05</td><td>05</td><td>Invalid number of optional KBH</td></tr><tr><td>02</td><td>05</td><td>06</td><td>Error in conversion of data type</td></tr><tr><td>02</td><td>05</td><td>07</td><td>Invalid KCV algorithm</td></tr><tr><td>02</td><td>05</td><td>08</td><td>Invalid KCV length</td></tr><tr><td>02</td><td>05</td><td>09</td><td>Invalid Optional KBH ID</td></tr><tr><td>02</td><td>05</td><td>0A</td><td>Invalid KBH ID</td></tr><tr><td>02</td><td>05</td><td>0B</td><td>Invalid algorithm used in KBH</td></tr><tr><td>02</td><td>05</td><td>0C</td><td>Invalid KBH usage</td></tr><tr><td>02</td><td>05</td><td>0D</td><td>Invalid KBH length</td></tr><tr><td>02</td><td>05</td><td>0E</td><td>Invalid version ID for key derivation</td></tr><tr><td>02</td><td>05</td><td>0F</td><td>Invalid KBH mode of use</td></tr><tr><td>02</td><td>05</td><td>10</td><td>TR31 engine not installed</td></tr><tr><td>02</td><td>05</td><td>11</td><td>Invalid Cryptographic operation</td></tr><tr><td>02</td><td>05</td><td>12</td><td>MAC Verification Failed</td></tr><tr><td>02</td><td>05</td><td>13</td><td>Error in Decrypting Key data</td></tr><tr><td>02</td><td>05</td><td>14</td><td>Error in computing MAC over entire message</td></tr><tr><td>02</td><td>05</td><td>15</td><td>Invalid MAC length</td></tr><tr><td>02</td><td>05</td><td>16</td><td>KDF Error</td></tr><tr><td>02</td><td>05</td><td>17</td><td>Buffer Insufficient</td></tr><tr><td>02</td><td>05</td><td>18</td><td>Invalid Storage KPM</td></tr><tr><td>02</td><td>05</td><td>19</td><td>Invalid Storage Secure RAM</td></tr><tr><td>02</td><td>05</td><td>1A</td><td>Invalid Key ID specified in option block</td></tr><tr><td>02</td><td>05</td><td>1B</td><td>Unsupported Key ID specified in option block</td></tr><tr><td>02</td><td>05</td><td>1C</td><td>Invalid Key ID Relationship</td></tr><tr><td>02</td><td>05</td><td>1D</td><td>Protection Key ID not loaded</td></tr><tr><td>02</td><td>05</td><td>1E</td><td>Invalid Data Tag MagTek Custom option block</td></tr><tr><td>02</td><td>05</td><td>1F</td><td>Invalid Kcv</td></tr><tr><td>02</td><td>05</td><td>20</td><td>Invalid Data</td></tr><tr><td>02</td><td>05</td><td>21</td><td>Invalid DUKPT key derivation</td></tr><tr><td>02</td><td>05</td><td>22</td><td>Invalid Exportability</td></tr><tr><td>02</td><td>05</td><td>23</td><td>Invalid Key Class</td></tr><tr><td>02</td><td>05</td><td>24</td><td>Invalid DSN</td></tr><tr><td>02</td><td>05</td><td>25</td><td>Invalid Challenge</td></tr><tr><td>02</td><td>05</td><td>26</td><td>Key Undeletable</td></tr><tr><td>02</td><td>05</td><td>27</td><td>Key not present</td></tr><tr><td>02</td><td>05</td><td>28</td><td>Unsupported Keyset ID</td></tr><tr><td>02</td><td>05</td><td>29</td><td>KPM Error</td></tr><tr><td>02</td><td>05</td><td>2A</td><td>Secure RAM Error</td></tr><tr><td>02</td><td>05</td><td>2B</td><td>Duplicated Key</td></tr><tr><td>02</td><td>05</td><td>2C</td><td>Invalid Key Usage Rule</td></tr><tr><td>02</td><td>05</td><td>2D</td><td>Selftest Key Corrupted</td></tr><tr><td>02</td><td>05</td><td>2E</td><td>Selftest System Key Bitmap Corrupted</td></tr><tr><td>02</td><td>05</td><td>2F</td><td>Selftest System Key Missing</td></tr><tr><td>02</td><td>05</td><td>30</td><td>Selftest System Key Not Loaded</td></tr><tr><td>02</td><td>05</td><td>31</td><td>Invalid Key Storage Limit</td></tr><tr><td>02</td><td>05</td><td>32</td><td>Duplicated Key set</td></tr><tr><td>02</td><td>05</td><td>33</td><td>Key Restriction</td></tr><tr><td>02</td><td>05</td><td>34</td><td>Key Transported by Weaker key</td></tr><tr><td>02</td><td>05</td><td>35</td><td>Repeat Key Agreement</td></tr><tr><td>02</td><td>05</td><td>36</td><td>Security not activated</td></tr><tr><td>02</td><td>05</td><td>37</td><td>Selftest key relocated</td></tr><tr><td>02</td><td>05</td><td>38</td><td>Invalid Selftest Scanned Versus Saved Bitmap</td></tr></tbody></table>

## Notification Message

## Notification Message Format

<table><thead><tr><th width="76.6666259765625">Tag</th><th width="75.33331298828125">Len</th><th>Value / Description</th><th width="73">Typ</th><th width="74.66668701171875">Req</th><th width="97.66668701171875">Default</th></tr></thead><tbody><tr><td>-</td><td>-</td><td>One byte standard <strong>Start of Message</strong> constant, not TLV. 0xAA = Standard start of message byte.</td><td>-</td><td>-</td><td>-</td></tr><tr><td>-</td><td>-</td><td>One-byte standard <strong>API Framework Version</strong>, not TLV. Values as in requests/responses.</td><td>-</td><td>-</td><td>-</td></tr><tr><td>81</td><td>4</td><td>Message Information</td><td>B</td><td>R</td><td></td></tr><tr><td>/null</td><td>(1)</td><td><p>Message Type &#x26; Direction: </p><ul><li>0x03 = Notification from host to device (Reserved). </li><li>0x83 = Notification from device to host.</li></ul></td><td></td><td>R</td><td></td></tr><tr><td>/null</td><td>(1)</td><td>Reserved, set to 0x00</td><td></td><td>R</td><td></td></tr><tr><td>/null</td><td>(1)</td><td><p>Notification Source — this byte and Notification Type form the first two bytes of a six-byte Notification ID. Use this byte to look up the Notification Group in <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/notifications"><mark style="color:red;"><strong>Notifications</strong>.</mark></a> Example values: </p><ul><li>0x01 = Transaction. </li><li>0x09 = Firmware Update.</li><li>0x10 = Device. </li><li>0x18 = User Interface.</li></ul></td><td></td><td>R</td><td></td></tr><tr><td>/null</td><td>(1)</td><td><p>Notification Type — append to Notification Source to identify specific notification (e.g., </p><ul><li>0x01 = Information Update. </li><li>0x02 = Warning.</li><li>0x03 = Action Request.</li><li>0x04 = Callback. </li><li>0x05 = Operation Complete).</li></ul></td><td></td><td>R</td><td></td></tr><tr><td>/null</td><td>(var)</td><td>Reserved</td><td></td><td>O</td><td></td></tr><tr><td>82</td><td>(4)</td><td>Notification Detail Code — combined with Notification Source and Notification Type to form a unique six-byte Notification ID. See <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/notifications"><mark style="color:red;"><strong>Notifications</strong></mark></a> for notification-specific detail codes.</td><td>B</td><td>R</td><td></td></tr><tr><td>/null</td><td>1</td><td>Category — e.g., 0x00 = Power/Reset</td><td>B</td><td>R</td><td></td></tr><tr><td>/null</td><td>1</td><td>Reason — e.g., 0x02 = Battery</td><td>B</td><td>R</td><td></td></tr><tr><td>/null</td><td>1</td><td>Reason Detail (Subgroup) — e.g., 0x01 = Power Down Imminent</td><td>B</td><td>R</td><td></td></tr><tr><td>/null</td><td>1</td><td>Reserved, set to 0x00</td><td>B</td><td>R</td><td></td></tr><tr><td>83</td><td>var</td><td>Additional Detail — see notification definition in <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/notifications"><mark style="color:red;"><strong>Notifications</strong>.</mark></a></td><td></td><td>O</td><td></td></tr><tr><td>84</td><td>var</td><td>Notification Payload — as documented in the notification’s table in <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/notifications"><mark style="color:red;"><strong>Notifications</strong>.</mark></a></td><td>B</td><td>O</td><td></td></tr><tr><td>9E</td><td>var</td><td>Reserved</td><td>B</td><td>O</td><td></td></tr></tbody></table>

## Data File Message

This message type is used exclusively for transferring larger blocks of data treated as files. It is valid only after successful invocation of the appropriate file operation commands (for example, [<mark style="color:red;">**Start Send File to Device (Secured) - Command 0xD811**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands/file-operations-command-group-0xd8nn/start-send-file-to-device-secured-command-0xd811), [<mark style="color:red;">**Start Send File to Device (Unsecured) - Command 0xD812**</mark><mark style="color:red;">,</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands/file-operations-command-group-0xd8nn/start-send-file-to-device-unsecured-command-0xd812) or [<mark style="color:red;">**Start Get File from Device - Command 0xD821**</mark> ](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands/file-operations-command-group-0xd8nn/start-get-file-from-device-command-0xd821).

## Data File Message Format

<table><thead><tr><th width="78.66668701171875">Tag</th><th width="78.33331298828125">Len</th><th>Value / Description</th><th width="75.6666259765625">Typ</th><th width="79">Req</th><th width="99.0001220703125">Default</th></tr></thead><tbody><tr><td>-</td><td>-</td><td>One byte standard <strong>Start of Message</strong> constant, not TLV. 0xAA = Standard start of message byte.</td><td>-</td><td>-</td><td>-</td></tr><tr><td>-</td><td>-</td><td>One-byte standard <strong>API Framework Version</strong>, not TLV. Values as in requests/responses.</td><td>-</td><td>-</td><td>-</td></tr><tr><td>81</td><td>08</td><td>Message Information</td><td>B</td><td>R</td><td></td></tr><tr><td>/null</td><td>(1)</td><td><p>Message Type &#x26; Direction:</p><ul><li>0x04 = Data file from host to device. </li><li>0x84 = Data file from device to host.</li></ul></td><td>B</td><td>R</td><td></td></tr><tr><td>/null</td><td>(1)</td><td>Message Reference Number — host value to match responses.</td><td>B</td><td>R</td><td></td></tr><tr><td>/null</td><td>(2)</td><td>Command Number that prompted this message (see Command Group 0xD8nn - File Operations).</td><td>B</td><td>R</td><td></td></tr><tr><td>/null</td><td>(4)</td><td>File Type — the file type as defined in <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands/file-operations-command-group-0xd8nn"><mark style="color:red;"><strong>File Operations - Command Group 0xD8nn</strong></mark></a><mark style="color:red;"><strong>.</strong></mark></td><td>B</td><td>R</td><td></td></tr><tr><td>84</td><td>var</td><td>File Payload — as documented in <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands/file-operations-command-group-0xd8nn/about-files"><mark style="color:red;"><strong>About Files</strong></mark></a>.</td><td>B</td><td>R</td><td></td></tr></tbody></table>

## Data File Message Example

Example (Hex)

```
AA 00 81 08 84 08 D8 21 00 00 00 01 84 40 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 
11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 
31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
```

## TR31 / Cryptographic related (Request Handler subgroup 0x05) — representative entries

| Grp | Sub | Cde | Meaning                      |
| --- | --- | --- | ---------------------------- |
| 02  | 05  | 01  | Invalid TR31 parameter       |
| 02  | 05  | 02  | Invalid AES length           |
| 02  | 05  | 0F  | Invalid KBH mode of use      |
| 02  | 05  | 12  | MAC Verification Failed      |
| 02  | 05  | 16  | KDF Error                    |
| 02  | 05  | 21  | Invalid DUKPT key derivation |
| 02  | 05  | 2B  | Duplicated Key               |


# Data Types and Shared TLV Data Objects

### Data Types and Shared TLV Data Objects

This section defines the primitive and composed data types, TLV (Tag-Length-Value) data objects, file structures, and cryptographic key formats used throughout the device command set, including track data, display strings, EMV configuration file types (ARQC, ARPC, Batch, CA Public Keys), security parameters, TR‑31 key blocks, certificate and CSR file structures, and card emulation.

{% hint style="success" %}
Applies to: All Dyna Family products
{% endhint %}

### Information in this group

| **Section**                                                                                                                                                                                                                                                              | **Information available**                                                                                                                                                                                         |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [<mark style="color:red;">**Primitive Data Types**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/primitive-data-types)                                                                                    | A list of primitive data types used by TLV data objects.                                                                                                                                                          |
| [<mark style="color:red;">**About Track Data**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/about-track-data)                                                                                            | Information about parsing EMV ARQC Type or Merchant Data Container data for each track into individual values embedded in the tracks.                                                                             |
| [<mark style="color:red;">**Display Strings**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/display-strings)                                                                                              | A pre-defined set of messages by string ID that the host and device use for various user interface features.                                                                                                      |
| [<mark style="color:red;">**Encryption Type**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/encryption-type)                                                                                              | Information on the key type, variant, and other information the host can use to decrypt encrypted data included in various payloads.                                                                              |
| [<mark style="color:red;">**EMV ARQC Type**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-arqc-type)                                                                                                  | Information on how the device formats ARQC messages.                                                                                                                                                              |
| [<mark style="color:red;">**EMV ARPC Type**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-arpc-type)                                                                                                  | Information on how the device formats ARPC messages                                                                                                                                                               |
| [<mark style="color:red;">**EMV Batch Data Type**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-batch-data-type)                                                                                      | Information on the device formats EMV batch data, such as merchant data and pre-defined EMV batch data tags.                                                                                                      |
| [<mark style="color:red;">**EMV Terminal Configuration Type**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-terminal-configuration-file-type)                                                         | Information on loading this file type to control the behavior of the device’s EMV contact kernel.                                                                                                                 |
| [<mark style="color:red;">**EMV Processing Configuration File Type**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-processing-configuration-file-type)                                                | Information on loading this file type to control the behavior of the device’s EMV kernel.                                                                                                                         |
| [<mark style="color:red;">**EMV Entry Point Configuration File Type**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-entry-point-configuration-file-type)                                              | Information on loading this file type to control the behavior of the device’s EMV kernels.                                                                                                                        |
| [<mark style="color:red;">**EMV Configuration CA Public Keys File Type**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-configuration-ca-public-keys-file-type)                                        | Information on loading this file type to control the behavior of the device’s EMV contact and contactless kernels when the device should support Offline Data Authentication (ODA).                               |
| [<mark style="color:red;">**EMV American Express DRL Configuration Type**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-american-express-drl-configuration-file-type-not-supported-on-expresspay-4.x) | Information on loading  this file type to control the behavior of the device’s American Express contactless kernel when the card sends tag 9F70 and one or more DRL is defined. (Not supported on Expresspay 4.x) |
| [<mark style="color:red;">**Signature Capture File Type**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/signature-capture-file-type-touch-only)                                                           | The signature capture file type produced when the host invokes Request Cardholder Signature - Command 0x1801 (Touch Only)                                                                                         |
| [<mark style="color:red;">**Security Operation Type**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/security-operation-type)                                                                              | This non-TLV data structure consists of four or five bytes that describes a security operation, including the algorithms and methods to be used in that operation.                                                |
| [<mark style="color:red;">**Security Parameters Type**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/security-parameters-type)                                                                            | Information on tags used with security parameters.                                                                                                                                                                |
| [<mark style="color:red;">**Key Information Type**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/key-information-type)                                                                                    | Information on tags used to identify key types.                                                                                                                                                                   |
| [<mark style="color:red;">**NFC UID Type**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/nfc-uid-type-emv-contactless-only)                                                                               | Information on tags used with NFC UID Types. (EMV Contactless Only)                                                                                                                                               |
| [<mark style="color:red;">**GPO Response Type**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/gpo-response-type-emv-contactless-only)                                                                     | Information on tags used with GPORT-1 Types. (EMV Contactless Only)                                                                                                                                               |
| [<mark style="color:red;">**MIFARE Card Data Type**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/mifare-card-data-type-emv-contactless-only)                                                             | Information on tags used with MIFARE Card Data. (EMV Contactless Only).                                                                                                                                           |
| [<mark style="color:red;">**TR-31 Key Block Type**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/tr-31-key-block-type)                                                                                    | Information on tags used with TR-31 Key Blocks.                                                                                                                                                                   |
| [<mark style="color:red;">**DUKPT Key Mapping**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/dukpt-key-mapping)                                                                                          | Information on tags used with DUKPT Keys.                                                                                                                                                                         |
| [<mark style="color:red;">**Miniature Certificate Type**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/miniature-certificate-type)                                                                        | Information on tags used with miniature certificates.                                                                                                                                                             |
| [<mark style="color:red;">**Common File Structure**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/common-file-structure)                                                                                  | Information on file types that conform to the common file structure format.                                                                                                                                       |
| [<mark style="color:red;">**Certificate File Type**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/certificate-file-types)                                                                                 | These file types conform to the Common File Structure format. The File Payload of these files contain a certificate in PEM format.                                                                                |
| [<mark style="color:red;">**Certificate Signing Request (CSR) Files Types**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/certificate-signing-request-csr-file-types)                                     | Information on CSR File Types.                                                                                                                                                                                    |
| [<mark style="color:red;">**Card Emulation**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/card-emulation)                                                                                                | Card emulation enables a DynaFlex/DynaProx device to simulate a Type 4 smart card.                                                                                                                                |

### See Also

* [<mark style="color:red;">**Messages**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/message-format-and-structure) **-->** The basics on messages, what they are, and how they work.&#x20;
* [<mark style="color:red;">**Commands**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands) **-->** Information on device-level commands&#x20;
* [<mark style="color:red;">**Notifications**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/notifications) **-->** Information on notices your device my send and the circumstances under which they send them.&#x20;
* [<mark style="color:red;">**Configurations**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/properties) **-->** Information of configuring your devices in various ways.

### Need More Help

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** [support@magtek.com](mailto:support@magtek.com?subject=Support%20Request)
* 📞 **Phone:** 1-562-546-6800 (US)
* 🕐 **Hours:** Monday-Friday, 5:30 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Support Portal:** developer.magtek.com

**Documentation Feedback:**

Help us improve this documentation! [feedback@magtek.com](mailto:feedback@magtek.com?subject=Feedback)
{% endhint %}


# Primitive Data Types

TLV data objects use the following primitive data types:

* A = Alphabetic (string, no numbers).
* AN = Alphanumeric (string).
* B = Binary value, which includes bit combinations (“OR” types).
* CN = Compressed numeric.
* N = Numeric.
* T = TLV **Constructed** data object (TLV Value contains additional layers of TLV-encoded data the parser should continue to process).


# About Track Data

After the host receives and decrypts [<mark style="color:red;">**EMV ARQC Type**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-arqc-type) data or [<mark style="color:red;">**Merchant Data Container**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-batch-data-type#merchant-data-container) data from the device, it may need to parse each track into individual values embedded in the tracks. The device can read multiple card formats, which vary even between different issuers and payment brands using the same underlying standards. Describing all possible formats is beyond the scope of this document, but this section describes how to parse data from tracks 1, 2, and 3 in a generic ISO/ABA compliant format as an example.

The table below shows an example of ISO/ABA track data the device sends to the host, using unmasked placeholder numbers to make it easier to see the relative positions of the values embedded in the track data. It is important to note that some cards do not include Track 3 data. Manually entered data does not include Track 3.

### Example Generic ISO/ABA Track Data Format

| Generic ISO/ABA Track Data Format                                      |
| ---------------------------------------------------------------------- |
| Track 1 Data %75555555555555555^CARDHOLDER NAME/^33338880004444000006? |
| Track 2 Data ;5555555555555555=33338880004444006?                      |
| Track 3 Data ;5555555555555555=333388800044440000006?                  |

The example track data in the above table can be interpreted as follows:

* The **%**, **?**, and **;** are sentinels / delimiters, and are taken directly from the data on the card.
* The first character at the beginning of Track 1 data is the card format code. For swiped credit / debit cards, this comes from the card and is generally **B**. Manually entered data uses **M**.
* The string of **5**s is the Account Number / License Number / PAN.
* The carets (^) are standard ISO track 1 delimiters surrounding the Cardholder Name.
* The string labeled **CARDHOLDER NAME/** is the Cardholder Name. Manually entered data uses string literal **MANUAL**.
* The string of **3**s is the Expiration Date (YYMM).
* The string of **8**s is the Service Code. For swiped credit / debit cards, this comes from the card. Manually entered data uses **000**.
* The remaining characters ( **0**s, **4**s, and **6**) are Discretionary Data. For swiped debit / credit cards this data is of varying length and content and comes from the card, and must be interpreted according to the standards established by issuers, payment brands, and so on. Manually entered track data uses a MagTek standard for Discretionary Data as follows:
  * The string of **4**s is the CVV2 a cardholder or operator entered on the keypad. This may be 3 or 4 characters long and is not padded, so the host software must find it by using the fixed-length padding and sentinels that surround it.
  * The strings of **0**s are literals of fixed length: Track 1 has three zeroes after the Service Code, and five zeroes after the CVV2; Track 2 has three zeroes after the Service Code, and two zeroes after CVV2.
  * The field option contains either a 0 or a 1. This Field Option tells what data is included in the track data, where:
    * 0 = Acct, Date, CVV
    * 1 = Name on Card, Acct, Date, CVV
  *


# Display Strings

The Display Strings type provides a pre-defined set of messages by string ID that the host and device use for various user interface features.

## Display String IDs and Strings

| Display String ID | Display String (en-US)               |
| ----------------- | ------------------------------------ |
| 0x00              | Reserved, do not use.                |
| 0x01              | “AMOUNT”                             |
| 0x02              | “AMOUNT OK?”                         |
| 0x03              | “APPROVED”                           |
| 0x04              | “CALL YOUR BANK”                     |
| 0x05              | “CANCEL OR ENTER”                    |
| 0x06              | “CARD ERROR”                         |
| 0x07              | “DECLINED”                           |
| 0x08              | “ENTER AMOUNT”                       |
| 0x09              | Reserved, do not use.                |
| 0x0A              | Reserved, do not use.                |
| 0x0B              | “INSERT CARD”                        |
| 0x0C              | “NOT ACCEPTED”                       |
| 0x0D              | Reserved, do not use.                |
| 0x0E              | “PLEASE WAIT”                        |
| 0x0F              | “PROCESSING ERROR”                   |
| 0x10              | “REMOVE CARD”                        |
| 0x11              | “USE CHIP READER”                    |
| 0x12              | “USE MAGSTRIPE”                      |
| 0x13              | “TRY AGAIN”                          |
| 0x14              | “WELCOME”                            |
| 0x15              | “PRESENT CARD”                       |
| 0x16              | “PROCESSING”                         |
| 0x17              | “CARD READ OK - REMOVE CARD”         |
| 0x18              | “INSERT OR SWIPE CARD”               |
| 0x19              | “PRESENT ONE CARD ONLY”              |
| 0x1A              | “APPROVED PLEASE SIGN”               |
| 0x1B              | “AUTHORIZING PLEASE WAIT”            |
| 0x1C              | “INSERT, SWIPE, OR TRY ANOTHER CARD” |
| 0x1D              | “PLEASE INSERT CARD”                 |
| 0x1E              | Null prompt (empty screen)           |
| 0x1F              | Reserved, do not use.                |
| 0x20              | “SEE PHONE”                          |
| 0x21              | “PRESENT CARD AGAIN”                 |
| 0x22              | “INSERT/SWIPE/TRY OTHER CARD”        |
| 0x23              | “TAP or SWIPE CARD”                  |
| 0x24              | “TAP or INSERT CARD”                 |
| 0x25              | “TAP, INSERT or SWIPE CARD”          |
| 0x26              | “TAP CARD”                           |
| 0x27              | “TIMEOUT”                            |
| 0x28              | “TRANSACTION TERMINATED”             |
| 0x29              | “USE CHIP READER or MAGSTRIPE”       |
| 0x2A              | “SCAN BARCODE”                       |
| 0x2B              | “BARCODE READ SUCCESSFULLY”          |
| 0x2C              | “CANCELED”                           |
| 0x2D              | “SWIPE CARD or SCAN BARCODE”         |
| 0x2E              | “INSERT CARD or SCAN BARCODE”        |
| 0x2F              | “INSERT, SWIPE or SCAN BARCODE”      |
| 0x30              | “TAP CARD or SCAN BARCODE”           |
| 0x31              | “TAP, SWIPE or SCAN BARCODE”         |
| 0x32              | “TAP, INSERT or SCAN BARCODE”        |
| 0x33              | “TAP, INSERT, SWIPE or SCAN BARCODE” |
| 0x34              | “TRY ANOTHER INTERFACE”              |
| 0x35              | “NFC TAG DETECTED”                   |
| 0x36              | “ERROR REMOVE CARD”                  |
| 0x37              | “MIFARE CLASSIC 1K DETECTED”         |
| 0x38              | “MIFARE CLASSIC 4K DETECTED”         |
| 0x39              | “MIFARE DESFIRE DETECTED”            |


# Encryption Type

The Encryption Type provides the key type, variant, and other information the host can use to decrypt encrypted data included in various payloads. The possible values are an ORed bitmask using the following elements:

* 0xxx xxxx = Fixed Key (Not used)
* 1xxx xxxx = DUKPT Key
* xx00 xxxx = TDES
* xx01 xxxx = AES128
* xx10 xxxx = AES256
* xxxx 0000 = Data Encrypt/Decrypt Variant
* xxxx 0001 = PIN Variant
* xxxx 0010 = MAC Variant
* xxxx 0011 = Data, Encrypt Variant
* xxxx 0100 = MAC Verify Variant
* xxxx 0101 = RESERVED
* xxxx 0110 = RESERVED
* xxxx 0111 = AES PIN Encrypt
* xxxx 1000 = AES MAC Generate
* xxxx 1001 = AES MAC Verify
* xxxx 1010 = AES MAC Generate/Verify
* xxxx 1011 = AES Data Encrypt
* xxxx 1100 = AES Data Decrypt
* xxxx 1101 = AES Data Encrypt/Decrypt
* xxxx 1110 = RESERVED
* xxxx 1111 = RESERVED


# EMV ARQC Type

The device formats ARQC messages as shown in the EMV ARQC (DynaPro Format) Type table below. The default is an EMV standard list of ARQC message tags. The host may also customize the contents of ARQC messages by setting [<mark style="color:red;">**EMV ARQC Message Tag List - Property 1.1.1.1.1.2**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/configuration/financial-settings-property-group-1.1.nnnn/emv-settings-property-subgroup-1.1.1.nnn-a#emv-arqc-message-tag-list-1.1.1.1.1.2).

## EMV ARQC (DynaPro Format) Type - A

<table data-header-hidden><thead><tr><th valign="top"></th><th width="79.6363525390625" valign="top"></th><th valign="top"></th><th width="77.6363525390625" valign="top"></th><th width="81" valign="top"></th><th width="89.8182373046875" valign="top"></th></tr></thead><tbody><tr><td valign="top">Tag</td><td valign="top">Len</td><td valign="top">Value / Description</td><td valign="top">Typ</td><td valign="top">Req</td><td valign="top">Default</td></tr><tr><td valign="top">2-byte MSB message length excluding padding and CBC-MAC</td><td valign="top"></td><td valign="top"></td><td valign="top"></td><td valign="top"></td><td valign="top"></td></tr><tr><td valign="top">F9</td><td valign="top">var</td><td valign="top">Container for MAC structure and generic data</td><td valign="top">T</td><td valign="top">R</td><td valign="top"> </td></tr><tr><td valign="top">/DFDF54</td><td valign="top">var</td><td valign="top">MAC KSN</td><td valign="top">B</td><td valign="top">R</td><td valign="top"> </td></tr><tr><td valign="top">/DFDF55</td><td valign="top">01</td><td valign="top"><p>MAC Encryption Type</p><p>See <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/encryption-type"><mark style="color:red;"><strong>Encryption Type</strong></mark> </a>for a list of valid values.</p></td><td valign="top">B</td><td valign="top">R</td><td valign="top"> </td></tr><tr><td valign="top">/DFDF25</td><td valign="top">var</td><td valign="top">Device Serial Number (IFD Serial Number)</td><td valign="top">B</td><td valign="top">R</td><td valign="top"> </td></tr><tr><td valign="top">/FA</td><td valign="top">var</td><td valign="top">Container for generic data</td><td valign="top">T</td><td valign="top">R</td><td valign="top"> </td></tr><tr><td valign="top">//70</td><td valign="top">var</td><td valign="top">Container for ARQC</td><td valign="top">T</td><td valign="top">R</td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p> </p><p>///82</p></td><td valign="top"><p> </p><p> </p><p>02</p></td><td valign="top"><p>Application Interchange Profile</p><p>Available on:</p><p>DynaFlex I FW Ver CA1 or newer DynaProx FW Ver A8 or newer DynaFlex II FW Ver A6 or newer</p></td><td valign="top"><p> </p><p> </p><p>B</p></td><td valign="top"><p> </p><p> </p><p>O</p></td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p> </p><p>///9F6E</p></td><td valign="top"><p> </p><p> </p><p>var</p></td><td valign="top"><p>Third Party Data</p><p> </p><p>Available on:</p><p>DynaFlex I FW Ver CA1 or newer DynaProx FW Ver A8 or newer DynaFlex II FW Ver A6 or newer</p></td><td valign="top"><p> </p><p> </p><p>B</p></td><td valign="top"><p> </p><p> </p><p>O</p></td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p>///DFDF53</p></td><td valign="top"><p> </p><p>01</p></td><td valign="top"><p>Fallback Indicator</p><p>·         0x00 = No Fallback</p><p>·         0x01 = Technical Fallback</p><p>·         0x81 = MSR Fallback</p></td><td valign="top"><p> </p><p>B</p></td><td valign="top"><p> </p><p>R</p></td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p>///DFDF33</p></td><td valign="top"><p> </p><p>var</p></td><td valign="top"><p>Masked Track 2 MSR Data</p><p>If the payment method presented by the cardholder provides it</p></td><td valign="top"><p> </p><p>AN</p></td><td valign="top"><p> </p><p>O</p></td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p>///DFDF4D</p></td><td valign="top"><p> </p><p>var</p></td><td valign="top"><p>Masked Track 2 ICC Data</p><p>If the payment method presented by the cardholder provides it</p></td><td valign="top"><p> </p><p>AN</p></td><td valign="top"><p> </p><p>O</p></td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p> </p><p> </p><p> </p><p>///DFDF52</p></td><td valign="top"><p> </p><p> </p><p> </p><p> </p><p>01</p></td><td valign="top"><p>Card Type</p><p>·         0x00 = Other</p><p>·         0x01 = Magnetic Stripe ISO/ABA Financial (MSR)</p><p>·         0x02 = Magnetic Stripe AAMVA (MSR)</p><p>·         0x03 = Manual Entry</p><p>·         0x04 = Unknown</p><p>·         0x05 = Contact Chip Card (ICC)</p><p>·         0x06 = Contactless Chip Card (PICC), EMV</p><p>·         0x07 = MSR Financial and Contact Chip Card (ICC)<br>·        0x08 = Contactless PICC, Magnetic Stripe Data (MSD)</p></td><td valign="top"><p> </p><p> </p><p> </p><p> </p><p>B</p></td><td valign="top"><p> </p><p> </p><p> </p><p> </p><p>R</p></td><td valign="top"> </td></tr></tbody></table>

## EMV ARQC (DynaPro Format) Type - B

<table data-header-hidden><thead><tr><th width="149.727294921875" valign="top"></th><th width="82.27276611328125" valign="top"></th><th valign="top"></th><th width="79.45458984375" valign="top"></th><th width="80.727294921875" valign="top"></th><th width="90.727294921875" valign="top"></th></tr></thead><tbody><tr><td valign="top">Tag</td><td valign="top">Len</td><td valign="top">Value / Description</td><td valign="top">Typ</td><td valign="top">Req</td><td valign="top">Default</td></tr><tr><td valign="top">///FF42</td><td valign="top">var</td><td valign="top">Container for <strong>Selectable Encrypted Card Data Set Up OID 1.1.2.6.1.1</strong> to enable this container.</td><td valign="top">T</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">////DFDFDF37</td><td valign="top">var</td><td valign="top"><p>Selectable Encrypted Data Primitive</p><p>Decrypt the value of this TLV data object using the algorithm and variant specified in the Selectable Encrypted Data KSN parameter and the Selectable Encrypted Data Encryption Type parameter. See <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-arqc-type#table-arqc-9-emv-arqc-dynapro-format-dfdfdf37-decrypted-contents"><mark style="color:red;"><strong>EMV ARQC (DynaPro Format) DFDFDF37 Decrypted Contents</strong></mark></a> for the data structure as it should appear after decryption.</p><p>(This item will be present if 0xFF42 is enabled)</p></td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">////DFDFDF38</td><td valign="top">0C</td><td valign="top"><p>Selectable Encrypted Data KSN</p><p>(This item will be present if 0xFF42 is enabled)</p></td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">////DFDFDF39</td><td valign="top">01</td><td valign="top">Selectable Encrypted Data Encryption Type (This item will be present if 0xFF42 is enabled)</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">///DF2A</td><td valign="top">06</td><td valign="top">Tip Mode Sale Amount Entered</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">///DF2B</td><td valign="top">06</td><td valign="top">Tip Mode Total Amount</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">///DF5D</td><td valign="top">06</td><td valign="top">Tip Amount</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">///DF5E</td><td valign="top">06</td><td valign="top">Tax Amount</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">///F8</td><td valign="top">var</td><td valign="top">Container for Encrypted Data</td><td valign="top">T</td><td valign="top">R</td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p> </p><p> </p><p>////DFDF59</p></td><td valign="top"><p> </p><p> </p><p> </p><p>var</p></td><td valign="top"><p>Encrypted Data Primitive</p><p>Decrypt the value of this TLV data object using the algorithm and variant specified in the Encrypted Transaction Data KSN parameter and the Encrypted Transaction Data Encryption Type parameter to read its contents. See Table for the data structure as it should appear after decryption.</p></td><td valign="top"><p> </p><p> </p><p> </p><p>B</p></td><td valign="top"><p> </p><p> </p><p> </p><p>R</p></td><td valign="top"> </td></tr><tr><td valign="top">////DFDF56</td><td valign="top">var</td><td valign="top">Encrypted Transaction Data KSN</td><td valign="top">B</td><td valign="top">R</td><td valign="top"> </td></tr><tr><td valign="top">////DFDF57</td><td valign="top">01</td><td valign="top"><p>Encrypted Transaction Data Encryption Type</p><p>See <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/encryption-type"><mark style="color:red;"><strong>Encryption Type</strong></mark></a> for a list of valid values.</p></td><td valign="top">B</td><td valign="top">R</td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p>////DFDF58</p></td><td valign="top"><p> </p><p>01</p></td><td valign="top"><p>Number of Padding Bytes</p><p>Number of bytes added to DFDF59 value to force its length to a multiple of 8 bytes for TDES, or 16 bytes for AES.</p></td><td valign="top"><p> </p><p>B</p></td><td valign="top"><p> </p><p>R</p></td><td valign="top"> </td></tr><tr><td valign="top">/FE</td><td valign="top">Var</td><td valign="top"><p>VAS Data Container</p><p>See <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-arqc-type#table-arqc-16-vas-data-container-payload"><mark style="color:red;"><strong>VAS Data Container Payload</strong></mark></a></p></td><td valign="top">T</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">/FF40</td><td valign="top">Var</td><td valign="top"><p>Fleet Data Container (Common Kernel Only)</p><p>See <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-arqc-type#fleet-data-container-payload-common-kernel-only-a"><mark style="color:red;"><strong>Fleet Data Container Payload</strong></mark></a></p></td><td valign="top">T</td><td valign="top">O</td><td valign="top"> </td></tr></tbody></table>

## EMV ARQC (DynaPro Format) Type - C

<table data-header-hidden><thead><tr><th valign="top"></th><th width="65.81817626953125" valign="top"></th><th valign="top"></th><th width="77.45458984375" valign="top"></th><th width="78" valign="top"></th><th width="99.4544677734375" valign="top"></th></tr></thead><tbody><tr><td valign="top">Tag</td><td valign="top">Len</td><td valign="top">Value / Description</td><td valign="top">Typ</td><td valign="top">Req</td><td valign="top">Default</td></tr><tr><td valign="top">Padding to ensure the length of data, starting with the message length at the very beginning, and ending with any additional padding, is a multiple of 8 bytes for TDES, or 16 bytes for AES. This is a requirement of using the CBC-MAC algorithm.</td><td valign="top"></td><td valign="top"></td><td valign="top"></td><td valign="top"></td><td valign="top"></td></tr><tr><td valign="top">Four-byte CBC-MAC. The host should calculate the CBC-MAC and verify that it matches. For details about calculating a CBC-MAC, see About Message Authentication Codes (MAC).</td><td valign="top"></td><td valign="top"></td><td valign="top"></td><td valign="top"></td><td valign="top"></td></tr></tbody></table>

The device encrypts the value inside the Encrypted Data Primitive container using the Encrypted Transaction Data Encryption Type parameter and working key associated with the keyset number currently active in the device’s configuration. As a requirement for using DUKPT encryption algorithms, the device pads it so the length of its value is a multiple of 8 bytes for TDES, or 16 bytes for AES. The device uses container DFDF58 to report how many bytes of data object DFDF59 are padding. Data object DFDF59 itself is formatted like the table below after the host decrypts it.

## EMV ARQC (DynaPro Format) DFDF59 Decrypted Contents - A

<table data-header-hidden><thead><tr><th width="77" valign="top"></th><th width="78.54547119140625" valign="top"></th><th valign="top"></th><th width="79.3636474609375" valign="top"></th><th width="80.7271728515625" valign="top"></th><th width="94.36376953125" valign="top"></th></tr></thead><tbody><tr><td valign="top">Tag</td><td valign="top">Len</td><td valign="top">Value / Description</td><td valign="top">Typ</td><td valign="top">Req</td><td valign="top">Default</td></tr><tr><td valign="top"><p> </p><p> </p><p> </p><p>FC</p></td><td valign="top"><p> </p><p> </p><p> </p><p>var</p></td><td valign="top"><p>Decrypted Data Container</p><p>Inside this container, the device inserts all EMV TLV data objects specified by the setting in Property <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/configuration/financial-settings-property-group-1.1.nnnn/emv-settings-property-subgroup-1.1.1.nnn-a#emv-arqc-message-tag-list-1.1.1.1.1.2"><mark style="color:red;"><strong>EMV ARQC Message Tag List - 1.1.1.1.1.2</strong></mark></a><mark style="color:red;"><strong>.</strong></mark> The remainder of this table shows the basic structure and content of MagTek custom tags. For definitions of all other standard EMV tags that can be included directly under container FC.</p></td><td valign="top"><p> </p><p> </p><p> </p><p>T</p></td><td valign="top"><p> </p><p> </p><p> </p><p>R</p></td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p>/DF29</p></td><td valign="top"><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p>08</p></td><td valign="top"><p>Only if tag DF29 is included in Property <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/configuration/financial-settings-property-group-1.1.nnnn/emv-settings-property-subgroup-1.1.1.nnn-a#emv-arqc-message-tag-list-1.1.1.1.1.2"><mark style="color:red;"><strong>EMV ARQC Message Tag List - 1.1.1.1.1.2</strong></mark></a><mark style="color:red;"><strong>.</strong></mark></p><ul><li><p>Outcome Parameter Set Byte 1 - Outcome</p><ul><li>0x10 = Approved</li><li>0x20 = Declined</li><li>0x30 = Online Request 0x40 = End Application</li><li>0x50 = Select Next Application 0x60 = Try Another Interface 0x70 = Try Again</li><li>0xF0 = N/A</li></ul></li></ul><p> </p><ul><li><p>Byte 2 – Entry Point Start 0x00 = Start A</p><ul><li>0x10 = Start </li><li>B 0x20 = Start </li><li>C 0x30 = Start </li><li>D 0xF0 = N/A</li></ul></li></ul><p> </p><ul><li><p>Byte 3 – Entry Point Online Response</p><ul><li>0x00 = EMV Data </li><li>0x10 = Any</li><li>0xF0 = N/A</li></ul></li></ul><p> </p><ul><li><p>Byte 4 – CVM </p><ul><li>0x00 = No CVM</li><li>0x10 = Obtain Signature </li><li>0x20 = Online PIN</li><li>0x30 = Confirmation Code Verified </li><li>0xF0 = N/A</li></ul></li></ul><p> </p><ul><li><p>Byte 5 – UI/Data/Receipt</p><ul><li>0x80 = UI Request on Outcome Present </li><li>0x40 = UI Request on Restart Present </li><li>0x20 = Data Record Present</li><li>0x10 = Discretionary Data Present </li><li>0x08 = Provide Receipt</li></ul></li><li><p>Byte 6 – Alternate Interface Preference </p><ul><li>0x10 = Contact</li><li>0x20 = MSR</li><li>0xF0 = N/A</li><li>Byte 7 – Field Off Request FF = N/A</li></ul></li><li>Byte 8 – Removal Timeout</li></ul></td><td valign="top"><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p>B</p></td><td valign="top"><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p>O</p></td><td valign="top"> </td></tr></tbody></table>

## EMV ARQC (DynaPro Format) DFDF59 Decrypted Contents - B

<table data-header-hidden><thead><tr><th width="79.54547119140625" valign="top"></th><th width="81.63641357421875" valign="top"></th><th valign="top"></th><th width="80.272705078125" valign="top"></th><th width="78.9090576171875" valign="top"></th><th width="93.272705078125" valign="top"></th></tr></thead><tbody><tr><td valign="top">Tag</td><td valign="top">Len</td><td valign="top">Value / Description</td><td valign="top">Typ</td><td valign="top">Req</td><td valign="top">Default</td></tr><tr><td valign="top">/F4</td><td valign="top">var</td><td valign="top">Container for encrypted MSR data (MSR Only)</td><td valign="top">T</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p> </p><p>//DFDF36</p></td><td valign="top"><p> </p><p> </p><p>01</p></td><td valign="top"><p>Encrypted Track 1 Status (MSR Only)</p><p>·         0x00 = OK</p><p>·         0x01 = Empty</p><p>·         0x02 = Error</p><p>·         0x03 = Disabled</p></td><td valign="top"><p> </p><p> </p><p>B</p></td><td valign="top"><p> </p><p> </p><p>O</p></td><td valign="top"> </td></tr><tr><td valign="top">//DFDF37</td><td valign="top">var</td><td valign="top">Encrypted Track 1 Data (MSR Only)</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p> </p><p>//DFDF38</p></td><td valign="top"><p> </p><p> </p><p>01</p></td><td valign="top"><p>Encrypted Track 2 Status (MSR Only)</p><p>·         0x00 = OK</p><p>·         0x01 = Empty</p><p>·         0x02 = Error</p><p>·         0x03 = Disabled</p></td><td valign="top"><p> </p><p> </p><p>B</p></td><td valign="top"><p> </p><p> </p><p>O</p></td><td valign="top"> </td></tr><tr><td valign="top">//DFDF39</td><td valign="top">var</td><td valign="top">Encrypted Track 2 Data (MSR Only)</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p> </p><p>//DFDF3A</p></td><td valign="top"><p> </p><p> </p><p>01</p></td><td valign="top"><p>Encrypted Track 3 Status (MSR Only)</p><p>·         0x00 = OK</p><p>·         0x01 = Empty</p><p>·         0x02 = Error</p><p>·         0x03 = Disabled</p></td><td valign="top"><p> </p><p> </p><p>B</p></td><td valign="top"><p> </p><p> </p><p>O</p></td><td valign="top"> </td></tr></tbody></table>

## EMV ARQC (DynaPro Format) DFDF59 Decrypted Contents - C&#x20;

<table data-header-hidden><thead><tr><th width="109.09088134765625" valign="top"></th><th width="80.6363525390625" valign="top"></th><th valign="top"></th><th width="77.727294921875" valign="top"></th><th width="82.54541015625" valign="top"></th><th width="85.272705078125" valign="top"></th></tr></thead><tbody><tr><td valign="top">Tag</td><td valign="top">Len</td><td valign="top">Value / Description</td><td valign="top">Typ</td><td valign="top">Req</td><td valign="top">Default</td></tr><tr><td valign="top">//DFDF3B</td><td valign="top">var</td><td valign="top">Encrypted Track 3 Data (MSR Only)</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p>//DFDF3C</p></td><td valign="top"><p> </p><p>var</p></td><td valign="top"><p>Encrypted MagnePrint Data (MSR Only)</p><p></p><p>Only included for MSR swipe transactions and when Track Data and Magneprint are using the same KSN.</p></td><td valign="top"><p> </p><p>B</p></td><td valign="top"><p> </p><p>O</p></td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p>//DFDF43</p></td><td valign="top"><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p>04</p></td><td valign="top"><p>MagnePrint Status Data (MSR Only)</p><p></p><p>Only included for MSR swipe transactions and when Track Data and Magneprint are using the same KSN.</p><p></p><ul><li><p>Bit 0 = MagnePrint Capable Flag</p><ul><li>0 = Device is not MagnePrint capable</li><li>1 = Device is MagnePrint capable</li></ul></li></ul><p></p><ul><li><p>Bits 1 through 3 = Mode</p><ul><li>0 = Standard MagnePrint</li><li>1 = Extended MagnePrint</li></ul></li><li>Bits 4 through 15 = ASIC Revision</li><li>Bit 16 = Reserved</li><li>Bit 17 = Reserved</li><li>Bit 18 = Swipe too slow</li><li>Bit 19 = Swipe too fast</li><li>Bit 20 = Reserved</li><li><p>Bit 21 = Card swipe direction</p><ul><li>0 = Forward</li><li>1 = Reverse Bits 22..31 = Reserved</li></ul></li></ul></td><td valign="top"><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p>B</p></td><td valign="top"><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p>O</p></td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p> </p><p>//DFDF50</p></td><td valign="top"><p> </p><p> </p><p>var</p></td><td valign="top"><p>MSR KSN Data (MSR Only)</p><p></p><p>Key Serial Number for the key the host should use to decrypt Encrypted Track 1 Data, Encrypted Track 2 Data, Encrypted Track 3 Data and Encrypted MagnePrint Data.</p></td><td valign="top"><p> </p><p> </p><p>B</p></td><td valign="top"><p> </p><p> </p><p>O</p></td><td valign="top"> </td></tr><tr><td valign="top">//DFDF51</td><td valign="top">01</td><td valign="top"><p>MSR Encryption Type (MSR Only)</p><p>See <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/encryption-type"><mark style="color:red;"><strong>Encryption Type</strong></mark></a> for a list of valid values.</p></td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p>/FF73</p></td><td valign="top"><p> </p><p>var</p></td><td valign="top"><p>Container for Encrypted </p><p></p><p>MagnePrint Data (MSR Only) Only included when Track Data and MagnePrint encryption keys are using different KSN</p></td><td valign="top"><p> </p><p>T</p></td><td valign="top"><p> </p><p>O</p></td><td valign="top"> </td></tr><tr><td valign="top">//DFDF3C</td><td valign="top">var</td><td valign="top">Encrypted MagnePrint Data (MSR Only) Only included for MSR swipe transactions.</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p> </p><p> </p><p> </p><p>//DFDF43</p></td><td valign="top"><p> </p><p> </p><p> </p><p> </p><p>04</p></td><td valign="top"><p>MagnePrint Status Data (MSR Only)</p><p>Only included for MSR swipe transactions.</p><ul><li><p>Bit 0 = MagnePrint Capable Flag</p><ul><li>0 = Device is not MagnePrint capable</li><li>1 = Device is MagnePrint capable</li></ul></li><li><p>Bits 1 through 3 = Mode</p><ul><li>0 = Standard MagnePrint</li><li>1 = Extended MagnePrint</li></ul></li><li>Bits 4 through 15 = ASIC Revision</li><li>Bit 16 = Reserved</li><li>Bit 17 = Reserved</li><li>Bit 18 = Swipe too slow</li><li>Bit 19 = Swipe too fast</li><li>Bit 20 = Reserved</li><li><p>Bit 21 = Card swipe direction</p><ul><li>0 = Forward</li><li>1 = Reverse Bits 22..31 = Reserved</li></ul></li></ul></td><td valign="top"><p> </p><p> </p><p> </p><p> </p><p>B</p></td><td valign="top"><p> </p><p> </p><p> </p><p> </p><p>O</p></td><td valign="top"> </td></tr></tbody></table>

## EMV ARQC (DynaPro Format) DFDF59 Decrypted Contents - D

<table data-header-hidden><thead><tr><th width="100.45452880859375" valign="top"></th><th width="80.727294921875" valign="top"></th><th valign="top"></th><th width="79.3636474609375" valign="top"></th><th width="92.54541015625" valign="top"></th><th width="79.6363525390625" valign="top"></th></tr></thead><tbody><tr><td valign="top">Tag</td><td valign="top">Len</td><td valign="top">Value / Description</td><td valign="top">Typ</td><td valign="top">Req</td><td valign="top">Default</td></tr><tr><td valign="top"><p> </p><p>//DFDF50</p></td><td valign="top"><p> </p><p>var</p></td><td valign="top"><p>MSR KSN Data (MSR Only)</p><p>Key Serial Number for the key the host should use to decrypt Encrypted MagnePrint Data.</p></td><td valign="top"><p> </p><p>B</p></td><td valign="top"><p> </p><p>O</p></td><td valign="top"> </td></tr><tr><td valign="top">//DFDF51</td><td valign="top">01</td><td valign="top"><p>MSR Encryption Type (MSR Only)</p><p>See <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/encryption-type"><mark style="color:red;"><strong>Encryption Type</strong></mark></a> for a list of valid values.</p></td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p> </p><p>/F5</p></td><td valign="top"><p> </p><p> </p><p>var</p></td><td valign="top"><p>Container for Encrypted PIN Data (Touch Only) Contains ISO PIN Block formatted data in the nested Encrypted PIN Data object, plus supporting information</p><p>to decrypt it. The host should use the current PIN DUKPT working key specified in the supporting information.</p></td><td valign="top"><p> </p><p> </p><p>T</p></td><td valign="top"><p> </p><p> </p><p>O</p></td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p> </p><p>//DF71</p></td><td valign="top"><p> </p><p> </p><p>01</p></td><td valign="top"><p>PIN Block Format (Touch Only)</p><p>·         0x00 = ISO Format 0</p><p>·         0x01 = ISO Format 1</p><p>·         0x03 = ISO Format 3</p><p>·         0x04 = ISO Format 4</p></td><td valign="top"><p> </p><p> </p><p>B</p></td><td valign="top"><p> </p><p> </p><p>O</p></td><td valign="top"> </td></tr><tr><td valign="top">//99</td><td valign="top">08</td><td valign="top">Encrypted PIN Data (Touch Only)</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DFDF41</td><td valign="top">var</td><td valign="top">PIN KSN Data (Touch Only)</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DFDF42</td><td valign="top">01</td><td valign="top"><p>PIN Encryption Type (Touch Only)</p><p>See <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/encryption-type"><mark style="color:red;"><strong>Encryption Type</strong></mark></a> for a list of valid values.</p></td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">Padding to force DFDF59 plus padding to be a multiple of 8 bytes</td><td valign="top"></td><td valign="top"></td><td valign="top"></td><td valign="top"></td><td valign="top"></td></tr></tbody></table>

## EMV ARQC (DynaPro Format) DFDFDF37 Decrypted Contents - E

<table data-header-hidden><thead><tr><th width="79.0909423828125" valign="top"></th><th width="81.45458984375" valign="top"></th><th valign="top"></th><th width="77.9090576171875" valign="top"></th><th width="77.0909423828125" valign="top"></th><th width="81.2725830078125" valign="top"></th></tr></thead><tbody><tr><td valign="top">Tag</td><td valign="top">Len</td><td valign="top">Value / Description</td><td valign="top">Typ</td><td valign="top">Req</td><td valign="top">Default</td></tr><tr><td valign="top"><p> </p><p>FC</p></td><td valign="top"><p> </p><p>var</p></td><td valign="top"><p>Decrypted Data Container</p><p>Inside this container, if the data is not available for a given selected card data, the tag will still get transmitted with a length of ‘1’ and value = ‘*’.</p></td><td valign="top"><p> </p><p>T</p></td><td valign="top"><p> </p><p>R</p></td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p>/5F20</p></td><td valign="top"><p> </p><p>var</p></td><td valign="top"><p>Only if Byte 0 – Bit 0 is set in <strong>Selectable Card Data Encryption Enable - Property 1.1.2.6.1.1.</strong></p><p> </p><p>Cardholder Name</p></td><td valign="top"><p> </p><p>an</p></td><td valign="top"><p> </p><p>O</p></td><td valign="top"> </td></tr><tr><td valign="top">/5A</td><td valign="top">var</td><td valign="top">Only if Byte 0 – Bit 1 is set in <strong>Selectable Card Data Encryption Enable - Property 1.1.2.6.1.1.</strong></td><td valign="top">n15/ n16</td><td valign="top">O</td><td valign="top"> </td></tr></tbody></table>

## EMV ARQC (DynaPro Format) DFDFDF37 Decrypted Contents - F

<table data-header-hidden><thead><tr><th width="74.90911865234375" valign="top"></th><th width="53" valign="top"></th><th valign="top"></th><th width="53.727294921875" valign="top"></th><th width="40" valign="top"></th><th width="83.45458984375" valign="top"></th></tr></thead><tbody><tr><td valign="top">Tag</td><td valign="top">Len</td><td valign="top">Value / Description</td><td valign="top">Typ</td><td valign="top">Req</td><td valign="top">Default</td></tr><tr><td valign="top"> </td><td valign="top"> </td><td valign="top"><p> </p><p>Primary Account Number</p></td><td valign="top"> </td><td valign="top"> </td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p>/5F24</p></td><td valign="top"><p> </p><p>02/</p><p>03</p></td><td valign="top"><p>Only if Byte 0 – Bit 2 is set in Property 1.1.2.6.1.1 Selectable Card Data Encryption Enable.</p><p> </p><p>Expiration Date, YYMM or YYMMDD</p></td><td valign="top"><p> </p><p>n4/ n6</p></td><td valign="top"><p> </p><p>O</p></td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p>/5F30</p></td><td valign="top"><p> </p><p>02</p></td><td valign="top"><p>Only if Byte 0 – Bit 3 is set in Property 1.1.2.6.1.1 Selectable Card Data Encryption Enable.</p><p> </p><p>Service Code</p></td><td valign="top"><p> </p><p>n3</p></td><td valign="top"><p> </p><p>O</p></td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p>/9F1F</p></td><td valign="top"><p> </p><p>var</p></td><td valign="top"><p>Only if Byte 0 – Bit 4 is set in Property 1.1.2.6.1.1 Selectable Card Data Encryption Enable.</p><p> </p><p>T1 Discretionary Data</p></td><td valign="top"><p> </p><p>an</p></td><td valign="top"><p> </p><p>O</p></td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p>/9F20</p></td><td valign="top"><p> </p><p>var</p></td><td valign="top"><p>Only if Byte 0 – Bit 5 is set in Property 1.1.2.6.1.1 Selectable Card Data Encryption Enable.</p><p> </p><p>T2 Discretionary Data</p></td><td valign="top"><p> </p><p>cn</p></td><td valign="top"><p> </p><p>O</p></td><td valign="top"> </td></tr><tr><td valign="top">Padding to force DFDFDF37 plus padding to be a multiple of 16 bytes for AES encryption.</td><td valign="top"></td><td valign="top"></td><td valign="top"></td><td valign="top"></td><td valign="top"></td></tr></tbody></table>

## EMV ARQC Enhanced DFDF59 Decrypted Contents for EMV Data - G

<table data-header-hidden><thead><tr><th valign="top"></th><th width="79" valign="top"></th><th valign="top"></th><th width="76.9090576171875" valign="top"></th><th width="77.0909423828125" valign="top"></th><th width="86.7271728515625" valign="top"></th></tr></thead><tbody><tr><td valign="top">Tag</td><td valign="top">Len</td><td valign="top">Value / Description</td><td valign="top">Typ</td><td valign="top">Req</td><td valign="top">Default</td></tr><tr><td valign="top"><p> </p><p>FC</p></td><td valign="top"><p> </p><p>var</p></td><td valign="top"><p>Decrypted Data Container</p><p>This contains all EMV TLV data objects specified in</p><p><a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/configuration/financial-settings-property-group-1.1.nnnn/emv-settings-property-subgroup-1.1.1.nnn-a#emv-arqc-message-tag-list-1.1.1.1.1.2"> <mark style="color:red;"><strong>EMV ARQC Message Tag List - Property 1.1.1.1.1.2</strong></mark></a></p></td><td valign="top"><p> </p><p>T</p></td><td valign="top"><p> </p><p>R</p></td><td valign="top"> </td></tr><tr><td valign="top">/FE</td><td valign="top">Var</td><td valign="top"><p>VAS Data Container</p><p>See <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-arqc-type#vas-data-container-payload-a"><mark style="color:red;"><strong>VAS Data Container Payload</strong></mark></a></p></td><td valign="top">T</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">Padding to ensure the length of data, starting with the message length at the very beginning, and ending with any additional padding, is a multiple of 8 bytes for TDES, or 16 bytes for AES. This is a requirement of using the CBC-MAC algorithm.</td><td valign="top"></td><td valign="top"></td><td valign="top"></td><td valign="top"></td><td valign="top"></td></tr></tbody></table>

## EMV ARQC Enhanced DFDF59 Decrypted Contents for MSR and MagnePrint Data - A

<table data-header-hidden><thead><tr><th width="78.9090576171875" valign="top"></th><th width="72.90911865234375" valign="top"></th><th valign="top"></th><th width="77.727294921875" valign="top"></th><th width="79.8182373046875" valign="top"></th><th width="86.1817626953125" valign="top"></th></tr></thead><tbody><tr><td valign="top">Tag</td><td valign="top">Len</td><td valign="top">Value / Description</td><td valign="top">Typ</td><td valign="top">Req</td><td valign="top">Default</td></tr><tr><td valign="top"><p> </p><p> </p><p> </p><p>FC</p></td><td valign="top"><p> </p><p> </p><p> </p><p>var</p></td><td valign="top"><p>Decrypted Data Container</p><p>Inside this container, the device inserts all EMV TLV data objects specified by the setting in <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/configuration/financial-settings-property-group-1.1.nnnn/emv-settings-property-subgroup-1.1.1.nnn-a#emv-arqc-message-tag-list-1.1.1.1.1.2"><mark style="color:red;"><strong>EMV ARQC Message Tag List - Property 1.1.1.1.1.2</strong></mark></a>. The remainder of this table shows the basic structure and content of MagTek custom tags. For definitions of all other standard EMV tags that can be included directly under container FC, see <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/configuration/financial-settings-property-group-1.1.nnnn"><mark style="color:red;"><strong>Financial Settings.</strong></mark></a></p></td><td valign="top"><p> </p><p> </p><p> </p><p>T</p></td><td valign="top"><p> </p><p> </p><p> </p><p>R</p></td><td valign="top"> </td></tr><tr><td valign="top">/9F41</td><td valign="top">04</td><td valign="top">Transaction Counter</td><td valign="top">B</td><td valign="top">R</td><td valign="top"> </td></tr></tbody></table>

## EMV ARQC Enhanced DFDF59 Decrypted Contents for MSR and MagnePrint Data - B

<table data-header-hidden><thead><tr><th width="98" valign="top"></th><th width="78.45452880859375" valign="top"></th><th valign="top"></th><th width="77.5455322265625" valign="top"></th><th width="78.9090576171875" valign="top"></th><th width="86" valign="top"></th></tr></thead><tbody><tr><td valign="top">Tag</td><td valign="top">Len</td><td valign="top">Value / Description</td><td valign="top">Typ</td><td valign="top">Req</td><td valign="top">Default</td></tr><tr><td valign="top"> </td><td valign="top"> </td><td valign="top">Starts at 00000000 each time the device powers up or resets, increments for each transaction.</td><td valign="top"> </td><td valign="top"> </td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p> </p><p>/DFDF36</p></td><td valign="top"><p> </p><p> </p><p>01</p></td><td valign="top"><p>MSR Track 1 Status</p><p>·         0x00 = OK</p><p>·         0x01 = Empty</p><p>·         0x02 = Error</p><p>·         0x03 = Disabled</p></td><td valign="top"><p> </p><p> </p><p>B</p></td><td valign="top"><p> </p><p> </p><p>O</p></td><td valign="top"> </td></tr><tr><td valign="top">/DF41</td><td valign="top">var</td><td valign="top">MSR Track 1 Clear Text</td><td valign="top">AN</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p> </p><p>/DFDF38</p></td><td valign="top"><p> </p><p> </p><p>01</p></td><td valign="top"><p>MSR Track 2 Status</p><p>·         0x00 = OK</p><p>·         0x01 = Empty</p><p>·         0x02 = Error</p><p>·         0x03 = Disabled</p></td><td valign="top"><p> </p><p> </p><p>B</p></td><td valign="top"><p> </p><p> </p><p>O</p></td><td valign="top"> </td></tr><tr><td valign="top">/DF42</td><td valign="top">var</td><td valign="top">MSR Track 2 Clear Text</td><td valign="top">AN</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p> </p><p>/DFDF3A</p></td><td valign="top"><p> </p><p> </p><p>01</p></td><td valign="top"><p>MSR Track 3 Status</p><p>·         0x00 = OK</p><p>·         0x01 = Empty</p><p>·         0x02 = Error</p><p>·         0x03 = Disabled</p></td><td valign="top"><p> </p><p> </p><p>B</p></td><td valign="top"><p> </p><p> </p><p>O</p></td><td valign="top"> </td></tr><tr><td valign="top">/DF43</td><td valign="top">var</td><td valign="top">MSR Track 3 Clear Text</td><td valign="top">AN</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p>/DFDF43</p></td><td valign="top"><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p>04</p></td><td valign="top"><p>MagnePrint Status</p><p>The device only includes this if MSR and MagnePrint data are both included in the transaction and the device is configured to encrypt them using the same key, to avoid consuming two DUKPT keys encrypting separate containers. If the device is configured to encrypt MSR and MagnePrint data using different keys, it provides MagnePrint data in the Container for Encrypted MagnePrint Data instead.</p><p></p><ul><li><p>Bit 0 = MagnePrint Capable Flag</p><ul><li>0 = Device is not MagnePrint capable</li><li>1 = Device is MagnePrint capable</li></ul></li><li><p>Bits 1 through 3 = Mode</p><ul><li>0 = Standard MagnePrint</li><li>1 = Extended MagnePrint</li></ul></li><li>Bits 4 through 15 = ASIC Revision</li><li>Bit 16 = Reserved</li><li>Bit 17 = Reserved</li><li>Bit 18 = Swipe too slow</li><li>Bit 19 = Swipe too fast</li><li>Bit 20 = Reserved</li><li><p>Bit 21 = Card swipe direction</p><ul><li>0 = Forward</li><li>1 = Reverse </li></ul></li><li>Bits 22..31 = Reserved</li></ul></td><td valign="top"><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p>B</p></td><td valign="top"><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p>O</p></td><td valign="top"> </td></tr></tbody></table>

## EMV ARQC Enhanced DFDF59 Decrypted Contents for MSR and MagnePrint Data - C

<table data-header-hidden><thead><tr><th valign="top"></th><th width="58.6363525390625" valign="top"></th><th valign="top"></th><th width="57.272705078125" valign="top"></th><th width="56.1817626953125" valign="top"></th><th width="88.818359375" valign="top"></th></tr></thead><tbody><tr><td valign="top">Tag</td><td valign="top">Len</td><td valign="top">Value / Description</td><td valign="top">Typ</td><td valign="top">Req</td><td valign="top">Default</td></tr><tr><td valign="top"><p> </p><p> </p><p>/DF44</p></td><td valign="top"><p> </p><p> </p><p>var</p></td><td valign="top"><p>MagnePrint Data</p><p>The device only includes this if MSR and MagnePrint data are both included in the transaction and the device is configured to encrypt them using the same key. The host can use this data in conjunction with Magensa services to determine whether the swiped card is authentic.</p></td><td valign="top"><p> </p><p> </p><p>B</p></td><td valign="top"><p> </p><p> </p><p>O</p></td><td valign="top"> </td></tr><tr><td valign="top">/FE</td><td valign="top">Var</td><td valign="top"><p>VAS Data Container</p><p>See <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-arqc-type#vas-data-container-payload-a"><mark style="color:red;"><strong>VAS Data Container Payload</strong></mark></a></p></td><td valign="top">T</td><td valign="top">O</td><td valign="top"> </td></tr></tbody></table>

{% hint style="info" %}
Padding to ensure the length of data, starting with the message length at the very beginning, and ending with any additional padding, is a multiple of 8 bytes for TDES, or 16 bytes for AES. This is a requirement of using the CBC-MAC algorithm.
{% endhint %}

## EMV ARQC Enhanced DFDF59 Decrypted Contents for MagnePrint Data - E

<table data-header-hidden><thead><tr><th width="100.45452880859375" valign="top"></th><th width="58.54547119140625" valign="top"></th><th valign="top"></th><th width="55.6363525390625" valign="top"></th><th width="57" valign="top"></th><th width="80.727294921875" valign="top"></th></tr></thead><tbody><tr><td valign="top">Tag</td><td valign="top">Len</td><td valign="top">Value / Description</td><td valign="top">Typ</td><td valign="top">Req</td><td valign="top">Default</td></tr><tr><td valign="top">FC</td><td valign="top">var</td><td valign="top">Decrypted Data Container</td><td valign="top">T</td><td valign="top">R</td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p>/DFDF43</p></td><td valign="top"><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p>var</p></td><td valign="top"><p>MagnePrint Status</p><p>The device only includes this when MSR and MagnePrint data are included in the transaction, but the device is configured to encrypt them using a different key.</p><p></p><ul><li><p>Bit 0 = MagnePrint Capable Flag</p><ul><li>0 = Device is not MagnePrint capable</li><li>1 = Device is MagnePrint capable</li></ul></li><li>Bits 1..15 = Product revision &#x26; mode</li><li>Bit 16 = Reserved</li><li>Bit 17 = Reserved for noise measurement</li><li>Bit 18 = Swipe too slow</li><li>Bit 19 = Swipe too fast</li><li>Bit 20 = Reserved</li><li><p>Bit 21 = Card swipe direction</p><ul><li>0 = Forward</li><li>1 = Reverse</li></ul></li><li>Bits 22..31 = Reserved</li></ul></td><td valign="top"><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p>B</p></td><td valign="top"><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p>R</p></td><td valign="top"> </td></tr><tr><td valign="top"><p> </p><p>/DF44</p></td><td valign="top"><p> </p><p>var</p></td><td valign="top"><p>MagnePrint Data</p><p>The host can use this data in conjunction with Magensa services to determine whether the swiped card is authentic.</p></td><td valign="top"><p> </p><p>B</p></td><td valign="top"><p> </p><p>R</p></td><td valign="top"> </td></tr><tr><td valign="top">/DF4B</td><td valign="top">var</td><td valign="top">MSR PAN</td><td valign="top">B</td><td valign="top">R</td><td valign="top"> </td></tr><tr><td valign="top">/FE</td><td valign="top">Var</td><td valign="top"><p>VAS Data Container</p><p>See <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-arqc-type#vas-data-container-payload-a"><mark style="color:red;"><strong>VAS Data Container Payload</strong></mark></a></p></td><td valign="top">T</td><td valign="top">O</td><td valign="top"> </td></tr></tbody></table>

{% hint style="info" %}
Padding to ensure the length of data, starting with the message length at the very beginning, and ending with any additional padding, is a multiple of 8 bytes for TDES, or 16 bytes for AES. This is a requirement of using the CBC-MAC algorithm.
{% endhint %}

## VAS Data Container Payload - A

<table data-header-hidden><thead><tr><th width="92.272705078125" valign="top"></th><th width="74.6363525390625" valign="top"></th><th valign="top"></th><th width="81.1817626953125" valign="top"></th><th width="80.727294921875" valign="top"></th><th width="89.9090576171875" valign="top"></th></tr></thead><tbody><tr><td valign="top">Tag</td><td valign="top">Len</td><td valign="top">Value / Description</td><td valign="top">Typ</td><td valign="top">Req</td><td valign="top">Default</td></tr><tr><td valign="top">/FE</td><td valign="top">var</td><td valign="top">VAS Data Container</td><td valign="top">T</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//FF01</td><td valign="top">var</td><td valign="top">Apple VAS Container Slot 1 Container</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">///9F27</td><td valign="top">var</td><td valign="top"><p>VAS Data</p><p>Up to 128 bytes.</p></td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">///9F2A</td><td valign="top">var</td><td valign="top">Mobile Token Up to 36 bytes.</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//FF02</td><td valign="top">var</td><td valign="top">Apple VAS Container Slot 2 Container</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">///9F27</td><td valign="top">var</td><td valign="top"><p>VAS Data</p><p>Up to 128 bytes.</p></td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">///9F2A</td><td valign="top">var</td><td valign="top">Mobile Token Up to 36 bytes.</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//FF03</td><td valign="top">var</td><td valign="top">Apple VAS Container Slot 3 Container</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">///9F27</td><td valign="top">var</td><td valign="top"><p>VAS Data</p><p>Up to 128 bytes.</p></td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">///9F2A</td><td valign="top">var</td><td valign="top">Mobile Token Up to 36 bytes.</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//FF04</td><td valign="top">var</td><td valign="top">Apple VAS Container Slot 4 Container</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">///9F27</td><td valign="top">var</td><td valign="top"><p>VAS Data</p><p>Up to 128 bytes.</p></td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">///9F2A</td><td valign="top">var</td><td valign="top">Mobile Token Up to 36 bytes.</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//FF05</td><td valign="top">var</td><td valign="top">Apple VAS Container Slot 5 Container</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">///9F27</td><td valign="top">var</td><td valign="top"><p>VAS Data</p><p>Up to 128 bytes.</p></td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">///9F2A</td><td valign="top">var</td><td valign="top">Mobile Token Up to 36 bytes.</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//FF06</td><td valign="top">var</td><td valign="top">Apple VAS Container Slot 6 Container</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">///9F27</td><td valign="top">var</td><td valign="top"><p>VAS Data</p><p>Up to 128 bytes.</p></td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">///9F2A</td><td valign="top">var</td><td valign="top">Mobile Token Up to 36 bytes.</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//FF41</td><td valign="top">var</td><td valign="top">Google Smart Tap Container</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">///FF01</td><td valign="top">var</td><td valign="top">Collector ID Slot 1 Container</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">////DF7B</td><td valign="top">var</td><td valign="top">Service Response NDEF Record</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">///FF02</td><td valign="top">var</td><td valign="top">Collector ID Slot 2 Container</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">////DF7B</td><td valign="top">var</td><td valign="top">Service Response NDEF Record</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr></tbody></table>

## VAS Data Container Payload - B

<table data-header-hidden><thead><tr><th width="103.8182373046875" valign="top"></th><th width="79.18182373046875" valign="top"></th><th valign="top"></th><th width="80.727294921875" valign="top"></th><th width="80.272705078125" valign="top"></th><th width="99.9091796875" valign="top"></th></tr></thead><tbody><tr><td valign="top">Tag</td><td valign="top">Len</td><td valign="top">Value / Description</td><td valign="top">Typ</td><td valign="top">Req</td><td valign="top">Default</td></tr><tr><td valign="top">///FF03</td><td valign="top">var</td><td valign="top">Collector ID Slot 3 Container</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">////DF7B</td><td valign="top">var</td><td valign="top">Service Response NDEF Record</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">///FF04</td><td valign="top">var</td><td valign="top">Collector ID Slot 4 Container</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">////DF7B</td><td valign="top">var</td><td valign="top">Service Response NDEF Record</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">///FF05</td><td valign="top">var</td><td valign="top">Collector ID Slot 5 Container</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">////DF7B</td><td valign="top">var</td><td valign="top">Service Response NDEF Record</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">///FF06</td><td valign="top">var</td><td valign="top">Collector ID Slot 6 Container</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">////DF7B</td><td valign="top">var</td><td valign="top">Service Response NDEF Record</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr></tbody></table>

## Fleet Data Container Payload (Common Kernel Only)- A

<table data-header-hidden><thead><tr><th width="99.18182373046875" valign="top"></th><th width="78.90911865234375" valign="top"></th><th width="80.727294921875" valign="top"></th><th valign="top"></th><th width="81.636474609375" valign="top"></th><th width="81.6363525390625" valign="top"></th><th valign="top"></th></tr></thead><tbody><tr><td valign="top">Tag</td><td valign="top"> </td><td valign="top">Len</td><td valign="top">Value / Description</td><td valign="top">Typ</td><td valign="top">Req</td><td valign="top">Default</td></tr><tr><td valign="top">/FF40</td><td valign="top"> </td><td valign="top">var</td><td valign="top">Fleet Data Container</td><td valign="top">T</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DF30</td><td valign="top"> </td><td valign="top">var</td><td valign="top">Prompting</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DF32</td><td valign="top"> </td><td valign="top">var</td><td valign="top">Purchase Restrictions</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DF33</td><td valign="top"> </td><td valign="top">var</td><td valign="top"> </td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DF34</td><td valign="top"> </td><td valign="top">var</td><td valign="top">Chip Offline purchase Restrictions for Fuel</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DF35</td><td valign="top"> </td><td valign="top">var</td><td valign="top">Chip Offline purchase Restrictions for Non-fuel</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DF36</td><td valign="top"> </td><td valign="top">var</td><td valign="top">Relationship Codes</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DF37</td><td valign="top"> </td><td valign="top">var</td><td valign="top">3<sup>rd</sup> Party Reference Data Generation 2</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DF38</td><td valign="top"> </td><td valign="top">var</td><td valign="top">Loyalty ID</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DF39</td><td valign="top"> </td><td valign="top">var</td><td valign="top">Purchase Device Sequence Number</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DF40</td><td valign="top"> </td><td valign="top">var</td><td valign="top">Generic Tag</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DF41</td><td valign="top"> </td><td valign="top">var</td><td valign="top">Vehicle/Trailer Number</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DF42</td><td valign="top"> </td><td valign="top">var</td><td valign="top">Vehicle Tag</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DF43</td><td valign="top"> </td><td valign="top">var</td><td valign="top">Driver ID</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DF44</td><td valign="top"> </td><td valign="top">var</td><td valign="top">Driver’s License Number</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DF45</td><td valign="top"> </td><td valign="top">var</td><td valign="top">Driver’s License State/Province Abbreviation</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DF46</td><td valign="top"> </td><td valign="top">var</td><td valign="top">Driver’s License Name Abbreviation</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DF47</td><td valign="top"> </td><td valign="top">var</td><td valign="top">Date of Birth</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DF48</td><td valign="top"> </td><td valign="top">var</td><td valign="top">Zip/Postal Code</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top"><p>//DF49 –</p><p>//DF51</p></td><td valign="top"> </td><td valign="top">var</td><td valign="top">IFSR Reserved for Future Use</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DF52</td><td valign="top"> </td><td valign="top">var</td><td valign="top">Trailer Number</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr></tbody></table>

## Fleet Data Container Payload (Common Kernel Only) - B

<table data-header-hidden><thead><tr><th width="90.18182373046875" valign="top"></th><th width="78" valign="top"></th><th width="82.54547119140625" valign="top"></th><th valign="top"></th><th width="78" valign="top"></th><th width="80.727294921875" valign="top"></th><th valign="top"></th></tr></thead><tbody><tr><td valign="top">Tag</td><td valign="top"> </td><td valign="top">Len</td><td valign="top">Value / Description</td><td valign="top">Typ</td><td valign="top">Req</td><td valign="top">Default</td></tr><tr><td valign="top">//DF53</td><td valign="top"> </td><td valign="top">var</td><td valign="top">Employee Number</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DF54</td><td valign="top"> </td><td valign="top">var</td><td valign="top">Work Order / Purchase Order Number</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DF55</td><td valign="top"> </td><td valign="top">var</td><td valign="top">Additional Prompted Data 1</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DF56</td><td valign="top"> </td><td valign="top">var</td><td valign="top">Additional Prompted Data 2</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//DF57</td><td valign="top"> </td><td valign="top">var</td><td valign="top">Proprietary Data</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//9F5A</td><td valign="top"> </td><td valign="top">var</td><td valign="top"> </td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//9F0A</td><td valign="top"> </td><td valign="top">var</td><td valign="top">ASRPD</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//9F6E</td><td valign="top"> </td><td valign="top">var</td><td valign="top">M/C Fleet</td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//9FD4</td><td valign="top"> </td><td valign="top">var</td><td valign="top"> </td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr><tr><td valign="top">//9F50</td><td valign="top"> </td><td valign="top">var</td><td valign="top"> </td><td valign="top">B</td><td valign="top">O</td><td valign="top"> </td></tr></tbody></table>


# EMV ARPC Type

### EMV ARPC Data

<table><thead><tr><th width="96.66668701171875">Tag</th><th width="73.33331298828125">Len</th><th>Value / Description</th><th width="74">Typ</th><th width="74">Req</th><th width="105">Default</th></tr></thead><tbody><tr><td>FF74</td><td>var</td><td>Container for non-MAC ARPC</td><td>T</td><td>R</td><td></td></tr><tr><td>/DFDF25</td><td>var</td><td>Device Serial Number (IFD Serial Number)</td><td>B</td><td>R</td><td></td></tr><tr><td>/FA</td><td>var</td><td>Container for generic data</td><td>T</td><td>R</td><td></td></tr><tr><td>//70</td><td>var</td><td>Container for ARPC</td><td>T</td><td>R</td><td></td></tr><tr><td>///8A</td><td>02</td><td><p>Authorization Response Code</p><ul><li>‘00’ = Approved</li><li>‘01’ = Issuer Referral</li><li>‘05’ = Declined</li><li>‘12’ = Switch Interface</li><li>‘13’ = Request Online PIN</li></ul></td><td>AN</td><td>R</td><td></td></tr><tr><td>///91</td><td>var</td><td>Issuer Authentication Data As defined in <a href="https://www.emvco.com/emv-technologies/emv-contact-chip/"><mark style="color:red;"><strong>EMV Integrated Circuit Card Specifications for Payment Systems 4.3.</strong></mark></a></td><td>B</td><td>O</td><td></td></tr><tr><td>///71</td><td>var</td><td>Issuer Script Template 1 As defined in <a href="https://www.emvco.com/emv-technologies/emv-contact-chip/"><mark style="color:red;"><strong>EMV Integrated Circuit Card Specifications for Payment Systems 4.3</strong></mark>.</a> The host may include as many instances of this parameter as needed, up to a maximum length of 128 bytes including Tags and Lengths.</td><td>B</td><td>O</td><td></td></tr><tr><td>///72</td><td>var</td><td>Issuer Script Template 2 As defined in <a href="https://www.emvco.com/emv-technologies/emv-contact-chip/"><mark style="color:red;"><strong>EMV Integrated Circuit Card Specifications for Payment Systems 4.3</strong>.</mark> </a>The host may include as many instances of this parameter as needed, up to a maximum length of 128 bytes including Tags and Lengths.</td><td>B</td><td>O</td><td></td></tr></tbody></table>


# EMV Batch Data Type

The device formats EMV batch data, such as merchant data and pre-defined EMV batch data tags, using the format shown in Table . The default is an EMV standard list of batch data message tags. The host may also customize the contents of batch data messages by setting [<mark style="color:red;">**EMV Batch Data Tag List - Property 1.1.1.1.1.3**</mark><mark style="color:red;">.</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/configuration/financial-settings-property-group-1.1.nnnn/emv-settings-property-subgroup-1.1.1.nnn-a#table-emva-11-emv-batch-data-tag-list-property-1.1.1.1.1.3)

(EMV Contact Only) For unsuccessful transactions, this data object can contain additional pre-defined reversal data. It is normally used by the host for data capture. The default is an EMV standard list of reversal data message tags. The host may also customize the contents of reversal data messages by setting [<mark style="color:red;">**EMV Reversal Data Tag List - Property 1.1.1.1.1.4**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/configuration/financial-settings-property-group-1.1.nnnn/emv-settings-property-subgroup-1.1.1.nnn-a#table-emva-11-emv-batch-data-tag-list-property-1.1.1.1.1.3).

As part of successful completion of [<mark style="color:red;">**Start Transaction - Command 0x1001**</mark>](https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/commands/transactions-command-group-0x10nn/start-transaction-command-0x1001#host-sends-start-transaction), this data structure contains the results of the transaction. The set of tags used during a given EMV transaction is a combination of the tags defined in the EMV specification and the tags that are specific to the kernel being used for the transaction.

## EMV Batch Data (DynaPro Format) Type&#x20;

<table><thead><tr><th>Tag</th><th width="79.3333740234375">Len</th><th>Value / Description</th><th width="77.6666259765625">Typ</th><th width="79.00006103515625">Req</th><th width="93.99993896484375">Default</th></tr></thead><tbody><tr><td>2-byte MSB message length excluding padding and CBC-MAC</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>F9</td><td>var</td><td>Container for MAC structure and generic data</td><td>T</td><td>R</td><td></td></tr><tr><td>/DFDF54</td><td>var</td><td>MAC KSN</td><td>B</td><td>R</td><td></td></tr><tr><td>/DFDF55</td><td>01</td><td>MAC Encryption Type See <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/encryption-type"><mark style="color:red;"><strong>Encryption Type</strong></mark></a> for a list of valid values.</td><td>B</td><td>R</td><td></td></tr><tr><td>/DFDF25</td><td>var</td><td>Device Serial Number (IFD Serial Number)</td><td>B</td><td>R</td><td></td></tr><tr><td>/FA</td><td>var</td><td>Container for Generic Data</td><td>T</td><td>R</td><td></td></tr><tr><td>//F0</td><td>var</td><td>Transaction Results</td><td>T</td><td>R</td><td></td></tr><tr><td>///F1</td><td>var</td><td>Container for Status Data</td><td>T</td><td>R</td><td></td></tr><tr><td>////DFDF1A</td><td>01</td><td><p>Transaction Status</p><ul><li>0x00 = Accept</li><li>0x01 = Decline</li><li>0x02 = Error</li></ul></td><td>B</td><td>R</td><td></td></tr><tr><td>////DFDF1B</td><td>01</td><td>Additional Transaction Information 0x00 </td><td>B</td><td>R</td><td></td></tr><tr><td>///F8</td><td>var</td><td>Container for Encrypted Data</td><td>T</td><td>R</td><td></td></tr><tr><td>////DFDF59</td><td>var</td><td>Encrypted Data Primitive Decrypt the value of this TLV data object according to the <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-batch-data-type#table-emvbdt-5-emv-batch-data-dynapro-format-type#emv-batch-data-dynapro-format-type-1"><mark style="color:red;"><strong>Encrypted Transaction Data KSN</strong></mark></a> parameter and the <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/encryption-type"><mark style="color:red;"><strong>Encrypted Transaction Data Encryption Type</strong></mark> </a>parameter to read its contents. See <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-batch-data-type#emv-batch-data-dynapro-format-dfdf59-decrypted-contents-a"><mark style="color:red;"><strong>EMV Batch Data (DynaPro Format) DFDF59 Decrypted Content</strong></mark></a> for the data structure as it should appear after decryption. Use the data variant of the current MSR DUKPT working key used in the relevant transaction.</td><td>B</td><td>R</td><td></td></tr><tr><td>////DFDF56</td><td>var</td><td>Encrypted Transaction Data KSN</td><td>B</td><td>R</td><td></td></tr><tr><td>////DFDF57</td><td>01</td><td>Encrypted Transaction Data Encryption Type See  <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/encryption-type"><mark style="color:red;"><strong>Encryption Type</strong></mark></a> for a list of valid values.</td><td>B</td><td>R</td><td></td></tr><tr><td>////DFDF58</td><td>01</td><td>Number of padding bytes added to DFDF59 value to force length to a multiple of 8 bytes</td><td>B</td><td>R</td><td></td></tr><tr><td>///F7</td><td>var</td><td>Merchant Data This contains an instance of <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-batch-data-type#table-emvbdt-5-emv-batch-data-dynapro-format-type#merchant-data-container"><mark style="color:red;"><strong>Merchant Data Container</strong>.</mark></a></td><td>T</td><td>R</td><td></td></tr><tr><td>/FE</td><td>Var</td><td>VAS Data Container See <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-arqc-type#vas-data-container-payload-a"><mark style="color:red;"><strong>VAS Data Container Payload</strong></mark></a></td><td>T</td><td>O</td><td></td></tr><tr><td>Padding to ensure the length of data, starting with the message length at the very beginning, and ending with any additional padding, is a multiple of 8 bytes for TDES, or 16 bytes for AES. This is a requirement of using the CBC-MAC algorithm.</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Four-byte CBC-MAC. The host should calculate the CBC-MAC and verify that it matches. For details about calculating a CBC-MAC, see <a href="https://developer.magtek.com/guides/guides/security-and-key-management/message-authentication-codes-mac#macs-for-emv-data"><mark style="color:red;"><strong>About Message Authentication Codes (MAC)</strong>.</mark></a></td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## EMV Batch Data (DynaPro Format) DFDF59 Decrypted Contents - A

<table><thead><tr><th width="74.66665649414062">Tag</th><th width="76.66668701171875">Len</th><th width="332">Value / Description</th><th width="81.66668701171875">Typ</th><th width="82.3333740234375">Req</th><th width="99.99984741210938">Default</th></tr></thead><tbody><tr><td>FC</td><td>var</td><td>Decrypted Data Container</td><td>T</td><td></td><td></td></tr><tr><td>/F2</td><td>var</td><td>Container for Batch Data This data object contains the set of EMV TLV data objects specified in <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/configuration/financial-settings-property-group-1.1.nnnn/emv-settings-property-subgroup-1.1.1.nnn-a#table-emva-11-emv-batch-data-tag-list-property-1.1.1.1.1.3"><mark style="color:red;"><strong>EMV Batch Data Tag List - Property 1.1.1.1.1.3</strong></mark></a>.</td><td>T</td><td></td><td></td></tr><tr><td>//DF29</td><td>08</td><td><p>Only if tag DF29 is included in<a data-footnote-ref href="#user-content-fn-1"> </a><a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/configuration/financial-settings-property-group-1.1.nnnn/emv-settings-property-subgroup-1.1.1.nnn-a#table-emva-11-emv-batch-data-tag-list-property-1.1.1.1.1.3"><mark style="color:red;"><strong>EMV Batch Data Tag List - Property 1.1.1.1.1.3</strong></mark></a> </p><ul><li><p>Outcome Parameter Set Byte 1 - </p><ul><li>Outcome 0x10 = Approved </li><li>0x20 = Declined </li><li>0x30 = Online Request </li><li>0x40 = End Application </li><li>0x50 = Select Next Application </li><li>0x60 = Try Another Interface </li><li>0x70 = Try Again </li><li>0xF0 = N/A </li></ul><p>Byte 2 – Entry Point Start</p><ul><li>0x00 = Start A </li><li>0x10 = Start B </li><li>0x20 = Start C </li><li>0x30 = Start D </li><li>0xF0 = N/A </li></ul><p>Byte 3 – Entry Point Online Response </p><ul><li>0x00 = EMV Data </li><li>0x10 = Any </li><li>0xF0 = N/A </li></ul><p>Byte 4 – CVM </p><ul><li>0x00 = No CVM </li><li>0x10 = Obtain Signature </li><li>0x20 = Online PIN </li><li>0x30 = Confirmation Code Verified </li><li>0xF0 = N/A </li></ul><p>Byte 5 – UI/Data/Receipt </p><ul><li>0x80 = UI Request on Outcome Present </li><li>0x40 = UI Request on Restart Present </li><li>0x20 = Data Record Present </li><li>0x10 = Discretionary Data Present </li><li>0x08 = Provide Receipt </li></ul><p>Byte 6 – Alternate Interface Preference </p><ul><li>0x10 = Contact </li><li>0x20 = MSR </li><li>0xF0 = N/A </li></ul><p>Byte 7 – Field Off Request </p><ul><li>FF = N/A </li></ul><p>Byte 8 – Removal Timeout</p></li></ul></td><td>B</td><td>O</td><td></td></tr><tr><td>/F3</td><td>var</td><td>(EMV Contact Only) Container for Reversal Data, if any This data object contains the set of EMV TLV data objects specified in <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/configuration/financial-settings-property-group-1.1.nnnn/emv-settings-property-subgroup-1.1.1.nnn-a#table-emva-16-emv-reversal-data-tag-list-emv-contact-only-property-1.1.1.1.1.4"><mark style="color:red;"><strong>EMV Reversal Data Tag List - Property 1.1.1.1.1.4</strong></mark> </a>.</td><td>T</td><td>O</td><td>null</td></tr><tr><td>/F4</td><td>var</td><td>Container for encrypted MSR data (MSR Only)</td><td>T</td><td>O</td><td></td></tr><tr><td>//DFDF36</td><td>01</td><td><p>Encrypted Track 1 Status (MSR Only)</p><ul><li>0x00 = OK</li><li>0x01 = Empty</li><li>0x02 = Error</li><li>0x03 = Disabled [<a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/configuration/sred-settings-property-subgroup-1.1.2.nnn/sred-settings-property-subgroup-1.1.2.nnn-b#table-sredb-11-track-1-enable-msr-only-property-1.1.2.5.1.2"><mark style="color:red;"><strong>Track 1 Enable (MSR Only) - Property 1.1.2.5.1.2</strong></mark></a> set to <strong>Disabled</strong>]</li></ul></td><td>B</td><td>O</td><td></td></tr><tr><td>//DFDF37</td><td>var</td><td>Encrypted Track 1 Data (MSR Only)</td><td>B</td><td>O</td><td></td></tr><tr><td>//DFDF38</td><td>01</td><td><p>Encrypted Track 2 Status (MSR Only)</p><ul><li>0x00 = OK</li><li>0x01 = Empty</li><li>0x02 = Error</li><li>0x03 = Disabled [<a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/configuration/sred-settings-property-subgroup-1.1.2.nnn/sred-settings-property-subgroup-1.1.2.nnn-b#table-sredb-11-track-1-enable-msr-only-property-1.1.2.5.1.2"><mark style="color:red;"><strong>Track 2 Enable (MSR Only) - Property 1.1.2.5.1.3</strong></mark></a> set to <strong>Disabled</strong>]</li></ul></td><td>B</td><td>O</td><td></td></tr><tr><td>//DFDF39</td><td>var</td><td>Encrypted Track 2 Data (MSR Only)</td><td>B</td><td>O</td><td></td></tr><tr><td>//DFDF3A</td><td>01</td><td><p>Encrypted Track 3 Status (MSR Only)</p><ul><li>0x00 = OK</li><li>0x01 = Empty</li><li>0x02 = Error</li><li>0x03 = Disabled [<a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/configuration/sred-settings-property-subgroup-1.1.2.nnn/sred-settings-property-subgroup-1.1.2.nnn-b#table-sred-21-track-3-enable-msr-only-property-1.1.2.5.1.4"><mark style="color:red;"><strong>Track 3 Enable (MSR Only) - Property 1.1.2.5.1.4</strong></mark></a> set to <strong>Disabled</strong>]</li></ul></td><td>B</td><td>O</td><td></td></tr><tr><td>//DFDF3B</td><td>var</td><td>Encrypted Track 3 Data (MSR Only)</td><td>B</td><td>O</td><td></td></tr><tr><td>//DFDF3C</td><td>var</td><td>Encrypted MagnePrint Data (MSR Only) Only included for MSR swipe transactions and when Track Data and Magneprint are using the same KSN.</td><td>B</td><td>O</td><td></td></tr><tr><td>//DFDF43</td><td>04</td><td>MagnePrint Status Data (MSR Only) Only included for MSR swipe transactions and when Track Data and Magneprint are using the same KSN.</td><td>B</td><td>O</td><td></td></tr><tr><td>//DFDF50</td><td>var</td><td>MSR KSN Data (MSR Only)</td><td>B</td><td>O</td><td></td></tr><tr><td>//DFDF51</td><td>01</td><td>MSR Encryption Type (MSR Only) See <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/encryption-type"><mark style="color:red;"><strong>Encryption Type</strong></mark></a> for a list of valid values.</td><td>B</td><td>O</td><td></td></tr><tr><td>/FF73</td><td>var</td><td>Container for Encrypted MagnePrint Data (MSR Only) Only included when Track Data and MagnePrint encryption keys are using different KSN</td><td>T</td><td>O</td><td></td></tr><tr><td>//DFDF3C</td><td>var</td><td>Encrypted MagnePrint Data (MSR Only) Only included for MSR swipe transactions.</td><td>B</td><td>O</td><td></td></tr><tr><td>//DFDF43</td><td>04</td><td>MagnePrint Status Data (MSR Only) Only included for MSR swipe transactions.</td><td>B</td><td>O</td><td></td></tr><tr><td>//DFDF50</td><td>var</td><td>MSR KSN Data (MSR Only) Key Serial Number for the key the host should use to decrypt <strong>Encrypted MagnePrint Data</strong>.</td><td>B</td><td>O</td><td></td></tr><tr><td>//DFDF51</td><td>01</td><td>MSR Encryption Type (MSR Only) See <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/encryption-type"><mark style="color:red;"><strong>Encryption Type</strong></mark></a>  for a list of valid values.</td><td>B</td><td>O</td><td></td></tr><tr><td>/F5</td><td>00</td><td>Container for Encrypted PIN Data (Touch Only)</td><td>T</td><td>O</td><td></td></tr><tr><td>//DF71</td><td>00</td><td><p>PIN Block Format (Touch Only)</p><ul><li>0x00 = ISO Format 0</li><li>0x01 = ISO Format 1</li><li>0x03 = ISO Format 3</li><li>0x04 = ISO Format 4</li></ul></td><td>B</td><td>O</td><td></td></tr><tr><td>//99</td><td>00</td><td>Encrypted PIN Data (Touch Only)</td><td>B</td><td>O</td><td></td></tr><tr><td>//DFDF41</td><td>00</td><td>PIN KSN Data (Touch Only)</td><td>B</td><td>O</td><td></td></tr><tr><td>//DFDF42</td><td>00</td><td>PIN Encryption Type (Touch Only) See <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/encryption-type"><mark style="color:red;"><strong>Encryption Type</strong></mark></a> for a list of valid values.</td><td>B</td><td>O</td><td></td></tr><tr><td>null</td><td>(var)</td><td>Padding to force DFDF59 plus padding to be a multiple of 8 bytes</td><td>B</td><td></td><td></td></tr></tbody></table>

## EMV Batch Data (DynaPro Format) DFDF59 Decrypted Contents - B

<table><thead><tr><th width="68.6666259765625">Tag</th><th width="71">Len</th><th>Value / Description</th><th width="75.33331298828125">Typ</th><th width="77.66668701171875">Req</th><th width="101">Default</th></tr></thead><tbody><tr><td>FC</td><td>var</td><td>Decrypted Data Container</td><td>T</td><td></td><td></td></tr><tr><td>/F2</td><td>var</td><td>Container for Batch Data This data object contains the set of EMV TLV data objects specified in <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/configuration/financial-settings-property-group-1.1.nnnn/emv-settings-property-subgroup-1.1.1.nnn-a#table-emva-11-emv-batch-data-tag-list-property-1.1.1.1.1.3"><mark style="color:red;"><strong>EMV Batch Data Tag List - Property 1.1.1.1.1.3</strong></mark></a>.</td><td>T</td><td></td><td></td></tr><tr><td>/F3</td><td>var</td><td>Container for Reversal Data, if any This data object contains the set of EMV TLV data objects specified in <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/configuration/financial-settings-property-group-1.1.nnnn/emv-settings-property-subgroup-1.1.1.nnn-a#table-emva-16-emv-reversal-data-tag-list-emv-contact-only-property-1.1.1.1.1.4"><mark style="color:red;"><strong>EMV Reversal Data Tag List - Property 1.1.1.1.1.4</strong> .</mark></a></td><td>T</td><td>O</td><td>null</td></tr><tr><td>null</td><td>(var)</td><td>Padding to force DFDF59 plus padding to be a multiple of 8 bytes or 16 bytes depending on the cipher block size of the algorithm being used.</td><td>B</td><td></td><td></td></tr><tr><td>/FE</td><td>Var</td><td>VAS Data Container See <strong>Table  –</strong> <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/emv-arqc-type#vas-data-container-payload-a"><mark style="color:red;"><strong>VAS Data Container Payload</strong></mark></a></td><td>T</td><td>O</td><td>/FE</td></tr></tbody></table>

## Merchant Data Container

Merchant Data is normally used by the host for receipt printing. The contents of this container are not customizable.

## EMV Batch Data (DynaPro Format) Type &#x20;

<table><thead><tr><th>Tag</th><th width="79.3333740234375">Len</th><th>Value / Description</th><th width="77.6666259765625">Typ</th><th width="79.00006103515625">Req</th><th width="93.99993896484375">Default</th></tr></thead><tbody><tr><td>2-byte MSB message length excluding padding and CBC-MAC</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>F9</td><td>var</td><td>Container for MAC structure and generic data</td><td>T</td><td>R</td><td></td></tr><tr><td>/DFDF54</td><td>var</td><td>MAC KSN</td><td>B</td><td>R</td><td></td></tr><tr><td>/DFDF55</td><td>01</td><td>MAC Encryption Type See <a href="https://developer.magtek.com/api-and-command-reference/scra-dynafamily-programmers-manual/data-types-and-shared-tlv-data-objects/encryption-type"><mark style="color:red;"><strong>Encryption Type</strong></mark></a> for a list of valid values.</td><td>B</td><td>R</td><td></td></tr><tr><td>/DFDF25</td><td>var</td><td>Device Serial Number (IFD Serial Number)</td><td>B</td><td>R</td><td></td></tr><tr><td>/FA</td><td>var</td><td>Container for Generic Data</td><td>T</td><td>R</td><td></td></tr><tr><td>//F0</td><td>var</td><td>Transaction Results</td><td>T</td><td>R</td><td></td></tr><tr><td>///F1</td><td>var</td><td>Container for Status Data</td><td>T</td><td>R</td><td></td></tr><tr><td>////DFDF1A</td><td>01</td><td><p>Transaction Status</p><ul><li>0x00 = Accept</li><li>0x01 = Decline</li><li>0x02 = Error</li></ul></td><td>B</td><td>R</td><td></td></tr><tr><td>///F8</td><td>var</td><td>Container for Encrypted Data</td><td>T</td><td>R</td><td></td></tr><tr><td>////DFDF59</td><td>var</td><td>Encrypted Data Primitive Decrypt the value of this TLV data object according to the <strong>Encrypted Transaction Data KSN</strong> parameter and the <strong>Encrypted Transaction Data Encryption Type</strong> parameter to read its contents. See Table XX for the data structure as it should appear after decryption. Use the data variant of the current MSR DUKPT working key used in the relevant transaction.</td><td>B</td><td>R</td><td></td></tr><tr><td>////DFDF56</td><td>var</td><td>Encrypted Transaction Data KSN</td><td>B</td><td>R</td><td></td></tr><tr><td>////DFDF57</td><td>01</td><td>Encrypted Transaction Data Encryption Type See <strong>Encryption Type</strong> for a list of valid values.</td><td>B</td><td>R</td><td></td></tr><tr><td>////DFDF58</td><td>01</td><td>Number of padding bytes added to DFDF59 value to force length to a multiple of 8 bytes</td><td>B</td><td>R</td><td></td></tr><tr><td>///F7</td><td>var</td><td>Merchant Data This contains an instance of <strong>Merchant Data Container</strong>.</td><td>T</td><td>R</td><td></td></tr><tr><td>/FE</td><td>Var</td><td>VAS Data Container See <strong>Table XX – VAS Data Container Payload</strong></td><td>T</td><td>O</td><td></td></tr><tr><td>Padding to ensure the length of data, starting with the message length at the very beginning, and ending with any additional padding, is a multiple of 8 bytes for TDES, or 16 bytes for AES. This is a requirement of using the CBC-MAC algorithm.</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Four-byte CBC-MAC. The host should calculate the CBC-MAC and verify that it matches. For details about calculating a CBC-MAC, see <strong>About Message Authentication Codes (MAC)</strong>.</td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

[^1]:


# EMV Terminal Configuration File Type

The host uses **Start Send File to Device (Unsecured)**  - **Command 0xD812** to load this file type to control the behavior of the device’s EMV contact kernel. The configuration loaded using this file type must be designed to work together with all instances of **EMV Processing Configuration File Type** and **EMV Entry Point Configuration File Type** the host loads into the device.

MagTek provides tools that allow these settings to be loaded using a Microsoft Excel spreadsheet for more convenient authoring, review, and change tracking. For a reference sample spreadsheet that contains EMVCo approved configurations, contact MagTek Support Services.

This document shows one example of the available Contact Level 2 certified configurations (***DynaFlex C01, Merchant, Attended, ODA***). To see which configurations are supported on the devices you are using, see the list of **Vendor Config IDs** in the device’s ***Letter of Approval for Contact Level 2*** posted in the list of ***Approved / Evaluated*** products on the EMVCo web site. For detailed descriptions of the tags included in this file type, including possible valid values and their effects on device behavior, see ***EMV Integrated Circuit Card Specifications for Payment Systems v4.3***.

## EMV Configuration Terminal File Type

<table><thead><tr><th>Tag</th><th>Len</th><th>Value / Description</th><th width="76">Typ</th><th width="78.66668701171875">Req</th><th width="101.33331298828125">Example</th></tr></thead><tbody><tr><td>File Type Version</td><td>One byte indicating the version of the file type format being used.</td><td></td><td></td><td></td><td>0xAA</td></tr><tr><td>SHA-1 Hash</td><td>20-byte hash of all values that follow.</td><td></td><td></td><td></td><td></td></tr><tr><td>9F1A</td><td>02</td><td>Terminal Country Code</td><td>B</td><td>R</td><td>08 40</td></tr><tr><td>DF79</td><td>01</td><td>Cardholder Confirmation</td><td>B</td><td>R</td><td>01</td></tr><tr><td>9F35</td><td>01</td><td>Terminal Type</td><td>B</td><td>R</td><td>21</td></tr><tr><td>DF0A</td><td>01</td><td>EMV Contact Supported</td><td>B</td><td>R</td><td>01</td></tr><tr><td>9F33</td><td>03</td><td>Terminal Capabilities</td><td>B</td><td>R</td><td>E0 28 C8</td></tr><tr><td>9F40</td><td>05</td><td>Additional Terminal Capabilities</td><td>B</td><td>R</td><td>EF 80 F0 A0 01</td></tr><tr><td>DF55</td><td>01</td><td>EMV Contactless Supported</td><td>B</td><td>R</td><td>01</td></tr><tr><td>DF0B</td><td>01</td><td>Magnetic Stripe Supported</td><td>B</td><td>R</td><td>01</td></tr><tr><td>DF27</td><td>01</td><td>Time allocated to enter a PIN</td><td>B</td><td>R</td><td>0A</td></tr><tr><td>DF06</td><td>01</td><td>Batch / Online Data Capture managed</td><td>B</td><td>R</td><td>01</td></tr><tr><td>DF08</td><td>00</td><td>Advice Managed</td><td>B</td><td>R</td><td>00</td></tr><tr><td>DF7A</td><td>01</td><td>PSE Supported</td><td>B</td><td>R</td><td>01</td></tr><tr><td>DF0D</td><td>00</td><td>AutoRun Mode</td><td>B</td><td>R</td><td>00</td></tr><tr><td>DF10</td><td>03</td><td>Predefined amount for AutoRun mode</td><td>B</td><td>R</td><td>00 00 00</td></tr><tr><td>DF7B</td><td>01</td><td>PIN Bypass Supported</td><td>B</td><td>R</td><td>00</td></tr><tr><td>DF07</td><td>01</td><td>Referral Managed</td><td>B</td><td>R</td><td>01</td></tr><tr><td>DF09</td><td>01</td><td>Default TAC supported when regular TACs are not present</td><td>B</td><td>R</td><td>01</td></tr><tr><td>DF73</td><td>05</td><td>Default TAC default</td><td>B</td><td>R</td><td>00 00 00 00 00</td></tr><tr><td>DF74</td><td>05</td><td>Default TAC denial</td><td>B</td><td>R</td><td>00 00 00 00 00</td></tr><tr><td>DF75</td><td>05</td><td>Default TAC online</td><td>B</td><td>R</td><td>00 00 00 00 00</td></tr><tr><td>DF53</td><td>01</td><td>Random Transaction Selection not supported</td><td>B</td><td>R</td><td>00</td></tr><tr><td>DF54</td><td>01</td><td>Velocity Checking not supported</td><td>B</td><td>R</td><td>00</td></tr><tr><td>DF7C</td><td>01</td><td>CDA Mode</td><td>B</td><td>R</td><td>01</td></tr></tbody></table>


# EMV Processing Configuration File Type

The host uses **Start Send File to Device (Unsecured) - Command 0xD812** to load this file type to control the behavior of the device’s EMV kernels. The host must compile a single instance of this file type containing multiple instances of the **AID Delimiter Container**, one for each contact or contactless AID the device should support. For each instance of the **AID Delimiter Container** where tag 9F01 is set to a contactless AID, the host must load a corresponding instance of an Entry Point Table when it loads the **EMV Entry Point Configuration File Type**.

## EMV Configuration Processing File Type

|                   |                                                                          |
| ----------------- | ------------------------------------------------------------------------ |
| File Type Version | One byte indicating the version of the file type format being used. 0xAA |
| SHA-1 Hash        | 20-byte hash of all values that follow.                                  |
| FF33              | var                                                                      |

### Inside each AID Delimiter Container:

<table><thead><tr><th width="113.99996948242188">Tag</th><th width="72">Len</th><th>Value / Description</th><th width="75.66668701171875">Typ</th><th width="79.33331298828125">Req</th><th width="168.99996948242188">Example</th></tr></thead><tbody><tr><td>/9F01</td><td>06</td><td><p>Payment Brand Identifier This serves as supporting information to clarify whether this instance of the AID Delimiter Container is for Contact or Contactless. Byte 1 upper nibble must be set to a value flagging that it corresponds to a Contactless AID, generally by using 0xC0 or 0xF0. For Contact AID, the value of Byte 1 is 00. Byte 1 lower nibble:</p><ul><li>0 = Contact</li><li>1 = Interac (Common Kernel Only)</li><li>2 = Mastercard Contactless</li><li>3 = Visa payWave</li><li>4 = Expresspay</li><li>5 = JCB (Common Kernel Only)</li><li>6 = Discover D-PAS</li><li>7 = China UnionPay (Common Kernel Only)</li></ul><p>Bytes 2..5 Reserved for future use</p></td><td>B</td><td>R</td><td>F2 00 00 00 00 00</td></tr><tr><td>/4F</td><td>0..16</td><td>Application Identifier (AID)</td><td>B</td><td>R</td><td>A0 00 00 00 04 10 10</td></tr><tr><td>/DF7E</td><td>01</td><td>ASI</td><td>B</td><td>R</td><td>01</td></tr><tr><td>/9F09</td><td>02</td><td>Application Version Only applies when Payment Brand Identifier indicates Contact.</td><td>B</td><td>R</td><td>00 00</td></tr><tr><td>/DF11</td><td>01</td><td>Skip TAC/IAC default supported Only applies when Payment Brand Identifier indicates Contact.</td><td>B</td><td>R</td><td>00</td></tr><tr><td>/DF12</td><td>01</td><td>Random transaction selection supported Only applies when Payment Brand Identifier indicates Contact.</td><td>B</td><td>R</td><td>00</td></tr><tr><td>/DF13</td><td>01</td><td>Velocity checking supported Only applies when Payment Brand Identifier indicates Contact.</td><td>B</td><td>R</td><td>00</td></tr><tr><td>/DF14</td><td>01</td><td>Floor limit checking supported Only applies when Payment Brand Identifier indicates Contact.</td><td>B</td><td>R</td><td>00</td></tr><tr><td>/DF15</td><td>01</td><td>TAC supported Only applies when Payment Brand Identifier indicates Contact.</td><td>B</td><td>R</td><td>00</td></tr><tr><td>/DF20</td><td>05</td><td>TAC default Only applies when Payment Brand Identifier indicates Contact.</td><td>B</td><td>R</td><td>00 00 00 00 00</td></tr><tr><td>/DF21</td><td>05</td><td>TAC denial Only applies when Payment Brand Identifier indicates Contact.</td><td>B</td><td>R</td><td>00 00 00 00 00</td></tr><tr><td>/DF22</td><td>05</td><td>TAC online Only applies when Payment Brand Identifier indicates Contact.</td><td>B</td><td>R</td><td>00 00 00 00 00</td></tr><tr><td>/9F1B</td><td>04</td><td>Floor limit Only applies when Payment Brand Identifier indicates Contact.</td><td>B</td><td>R</td><td>00 00 00 00</td></tr><tr><td>/DF70</td><td>01</td><td>Target percentage Only applies when Payment Brand Identifier indicates Contact.</td><td>B</td><td>R</td><td>00</td></tr><tr><td>/DF6E</td><td>03</td><td>Threshold value Only applies when Payment Brand Identifier indicates Contact.</td><td>B</td><td>R</td><td>00 00 00</td></tr><tr><td>/DF6F</td><td>01</td><td>Maximum target percentage Only applies when Payment Brand Identifier indicates Contact.</td><td>B</td><td>R</td><td>00</td></tr><tr><td>/DF01</td><td>01</td><td>Default DDOL supported Only applies when Payment Brand Identifier indicates Contact.</td><td>B</td><td>R</td><td>00</td></tr><tr><td>/DF71</td><td>0..FC</td><td>DDOL Only applies when Payment Brand Identifier indicates Contact.</td><td>B</td><td>R</td><td></td></tr><tr><td>/DF02</td><td>01</td><td>Default TDOL supported Only applies when Payment Brand Identifier indicates Contact.</td><td>B</td><td>R</td><td>00</td></tr><tr><td>/DF72</td><td>0..252</td><td>TDOL Only applies when Payment Brand Identifier indicates Contact.</td><td>B</td><td>R</td><td></td></tr><tr><td>/5F2A</td><td>02</td><td>Currency Code Only applies when Payment Brand Identifier indicates Contact.</td><td>B</td><td>R</td><td>00 00</td></tr><tr><td>/5F36</td><td>01</td><td>Transaction currency exponent Only applies when Payment Brand Identifier indicates Contact.</td><td>B</td><td>R</td><td>00</td></tr><tr><td>Additional instances of the <strong>AID Delimiter Container</strong> parameter, one per Application Identifier (AID) the device should support.</td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>


# EMV Entry Point Configuration File Type

The host uses **Start Send File to Device (Unsecured) - Command 0xD812** to load this file type to control the behavior of the device’s EMV kernels.

## EMV Entry Point Configuration File Type Header

<table><thead><tr><th>Tag</th><th>Value (hex)</th><th width="126.3636474609375">Description</th></tr></thead><tbody><tr><td>File Type Version</td><td>One byte indicating the version of the file type format being used.</td><td>0xAA</td></tr><tr><td>SHA-1 Hash</td><td>20-byte hash of all values that follow</td><td></td></tr><tr><td>One or more instances of the following entry point tables for supported contactless payment brands. The host should include an Entry Point Table for each transaction type to be supported by each contactless payment brand AID listed in the loaded EMV Processing Configuration File Type.</td><td></td><td></td></tr></tbody></table>

## Mastercard MCL Entry Point Table

<table><thead><tr><th width="80.6666259765625">Tag</th><th width="78.3333740234375">Len</th><th>Value / Description</th><th width="79">Typ</th><th width="76.66668701171875">Req</th><th width="111.99993896484375">Example</th></tr></thead><tbody><tr><td>FF35</td><td>var</td><td>AID Delimiter Container There can be multiple instances of this in sequence. The contents of the first instance are loaded into Entry Point Table Slot 1, the contents of the second are loaded into Entry Point Table Slot 2, etc.</td><td>T</td><td>R</td><td></td></tr><tr><td>/DF0E</td><td>03</td><td><p>Kernel ID, Processing Slot, Transaction Type Byte 1 Kernel ID</p><ul><li>0x02 = MasterCard Contactless (MCL)</li></ul><p>Byte 2 Processing Slot to Use See the <strong>AID Delimiter Container</strong> parameter in EMV Processing Configuration File Type for information about how to identify slots. Byte 3 Transaction Type</p><ul><li>0x00 = Purchase</li><li>0x01 = Cash</li><li>0x02 = Purchase with cashback</li><li>0x03 = Refund</li></ul></td><td>B</td><td>R</td><td>02 01 00</td></tr><tr><td>/DF0F</td><td>var</td><td>Payload Delimiter Container Include only one of these containers inside each <strong>AID Delimiter Container</strong>.</td><td>T</td><td>R</td><td></td></tr><tr><td>//9F1A</td><td>02</td><td>Terminal Country Code</td><td>B</td><td>R</td><td>08 40</td></tr><tr><td>//9F35</td><td>01</td><td>Terminal Type</td><td>B</td><td>R</td><td>21</td></tr><tr><td>//9F40</td><td>05</td><td>Additional Terminal Capabilities</td><td>B</td><td>R</td><td>00 00 00 00 00</td></tr><tr><td>//9F7E</td><td>01</td><td>Mobile Support Indicator</td><td>B</td><td>R</td><td>01</td></tr><tr><td>//DF0C</td><td>01</td><td>Kernel ID</td><td>B</td><td>R</td><td>02</td></tr><tr><td>//DF1B</td><td>01</td><td><p>Kernel Configuration</p><ul><li>Bit 8 = MSD Mode Not Supported</li><li>Bit 7 = EMV Mode contactless transaction not supported</li><li>Bit 6 = On-Device-CVM Supported</li><li>Bit 5 = Relay Resistance Protocol Supported</li><li>Bit 4..1 = Reserved for future use</li></ul></td><td>B</td><td>R</td><td>20</td></tr><tr><td>//DF2D</td><td>03</td><td>Message Hold Time (100 of ms)</td><td>B</td><td>R</td><td>00 00 0D</td></tr><tr><td>//9F6D</td><td>02</td><td>Magnetic Stripe Application Version Number This value only applies when the Kernel Configuration parameter is set to support MSD. The device ignores this value.</td><td>B</td><td>R</td><td>00 01</td></tr><tr><td>//DF1A</td><td>03</td><td>Magnetic Stripe Default UDOL This value only applies when the Kernel Configuration parameter is set to support MSD. The device ignores this value.</td><td>B</td><td>R</td><td>9F 6A 04</td></tr><tr><td>//DF1E</td><td>01</td><td>CVM Capability - CVM Required This value only applies when the Kernel Configuration parameter is set to support MSD. The device ignores this value.</td><td>B</td><td>R</td><td>00</td></tr><tr><td>//DF2C</td><td>01</td><td>CVM Capability - No CVM Required This value only applies when the Kernel Configuration parameter is set to support MSD. The device ignores this value.</td><td>B</td><td>R</td><td>00</td></tr><tr><td>//9F09</td><td>02</td><td>EMV Application Version Number</td><td>B</td><td>R</td><td>00 02</td></tr><tr><td>//DF03</td><td>01</td><td><p>Security Capabilities</p><ul><li>Bit 8 = SDA</li><li>Bit 7 = DDA</li><li>Bit 6 = Card Capture</li><li>Bit 5 = Reserved for future use</li><li>Bit 4 = CDA</li><li>Bits 3..1 = Reserved for future use</li></ul></td><td>B</td><td>R</td><td>08</td></tr><tr><td>//DF17</td><td>01</td><td><p>Card Data Input Capabilities</p><ul><li>Bit 8 = Manual Key Entry</li><li>Bit 7 = MSR</li><li>Bit 6 = ICC</li><li>Bits 5..1 = Reserved for future use</li></ul></td><td>B</td><td>R</td><td>60</td></tr><tr><td>//DF18</td><td>01</td><td><p>CVM Capability - CVM Required</p><ul><li>Bit 8 = Offline Plaintext PIN</li><li>Bit 7 = Enciphered Online PIN</li><li>Bit 6 = Signature</li><li>Bit 5 = Enciphered Offline PIN</li><li>Bit 4 = No CVM</li><li>Bits 3..1 = Reserved for future use</li></ul></td><td>B</td><td>R</td><td>28</td></tr><tr><td>//DF19</td><td>01</td><td><p>CVM Capability - No CVM Required</p><ul><li>Bit 8 = Offline Plaintext PIN</li><li>Bit 7 = Enciphered Online PIN</li><li>Bit 6 = Signature</li><li>Bit 5 = Enciphered Offline PIN</li><li>Bit 4 = No CVM</li><li>Bits 3..1 = Reserved for future use</li></ul></td><td>B</td><td>R</td><td>08</td></tr><tr><td>//DF1C</td><td>02</td><td>Max Lifetime Torn Transaction(s)</td><td>B</td><td>R</td><td>01 2C</td></tr><tr><td>//DF1D</td><td>01</td><td>Max Number Torn Transaction</td><td>B</td><td>R</td><td>00</td></tr><tr><td>//DF20</td><td>05</td><td>Terminal Action Code - Default</td><td>B</td><td>R</td><td>00 00 00 00 00</td></tr><tr><td>//DF21</td><td>05</td><td>Terminal Action Code - Denial</td><td>B</td><td>R</td><td>00 00 00 00 00</td></tr><tr><td>//DF22</td><td>05</td><td>Terminal Action Code - Online</td><td>B</td><td>R</td><td>00 00 00 00 00</td></tr><tr><td>//DF04</td><td>0</td><td>Balance Read Before GenAC</td><td>B</td><td>R</td><td></td></tr><tr><td>//DF05</td><td>0</td><td>Balance Read After GenAC</td><td>B</td><td>R</td><td></td></tr><tr><td>//DF23</td><td>06</td><td>Reader Contactless Floor Limit</td><td>B</td><td>R</td><td>00 00 00 01 00 00</td></tr><tr><td>//DF24</td><td>06</td><td>Reader Contactless Transaction Limit (No On-Device CVM)</td><td>B</td><td>R</td><td>00 00 00 03 00 00</td></tr><tr><td>//DF25</td><td>06</td><td>Reader Contactless Transaction Limit (On-Device CVM)</td><td>B</td><td>R</td><td>00 00 00 05 00 00</td></tr><tr><td>//DF26</td><td>06</td><td>Reader CVM Required Limit</td><td>B</td><td>R</td><td>00 00 00 00 10 00</td></tr><tr><td>//DF27</td><td>02</td><td>Timeout Value (ms)</td><td>B</td><td>R</td><td>13 88</td></tr><tr><td>//DF30</td><td>01</td><td>Hold time value before field off (100 of ms)</td><td>B</td><td>R</td><td>0D</td></tr><tr><td>//DF32</td><td>02</td><td>Minimum Relay Resistance Grace Period (100 of micro sec)</td><td>B</td><td>R</td><td>00 14</td></tr><tr><td>//DF33</td><td>02</td><td>Maximum Relay Resistance Grace Period (100 of micro seconds)</td><td>B</td><td>R</td><td>00 32</td></tr><tr><td>//DF34</td><td>02</td><td>Terminal Expected Transmission Time for Relay Resistance C-APDU (100 of micro seconds)</td><td>B</td><td>R</td><td>00 12</td></tr><tr><td>//DF35</td><td>02</td><td>Terminal Expected Transmission Time for Relay Resistance R-APDU (100 of micro seconds)</td><td>B</td><td>R</td><td>00 18</td></tr><tr><td>//DF36</td><td>02</td><td>Relay Resistance Accuracy Threshold (100 of micro seconds)</td><td>B</td><td>R</td><td>01 2C</td></tr><tr><td>//DF37</td><td>01</td><td>Relay Resistance Transmission Time Mismatch Threshold (%)</td><td>B</td><td>R</td><td>32</td></tr></tbody></table>

## Visa payWave Entry Point Table

<table><thead><tr><th width="79.99996948242188">Tag</th><th width="74.3333740234375">Len</th><th>Value / Description</th><th width="78">Typ</th><th width="75">Req</th><th width="103.99990844726562">Example</th></tr></thead><tbody><tr><td>FF35</td><td>var</td><td>AID Delimiter Container There can be multiple instances of this in sequence. The contents of the first instance are loaded into Entry Point Table Slot 1, the contents of the second are loaded into Entry Point Table Slot 2, etc.</td><td>T</td><td>R</td><td></td></tr><tr><td>/DF0E</td><td>03</td><td><p>Kernel ID, Processing Slot, Transaction Type Byte 1 Kernel ID</p><ul><li>0x03 = Visa payWave</li></ul><p>Byte 2 Processing Slot to Use See the <strong>AID Delimiter Container</strong> parameter in EMV Processing Configuration File Type for information about how to identify slots. Byte 3 Transaction Type</p><ul><li>0x00 = Purchase</li><li>0x01 = Cash</li><li>0x02 = Purchase with cashback</li><li>0x03 = Refund</li></ul></td><td>B</td><td>R</td><td>03 05 00</td></tr><tr><td>/DF0F</td><td>var</td><td>Payload Delimiter Container Include only one of these containers inside each <strong>AID Delimiter Container</strong>.</td><td>T</td><td>R</td><td></td></tr><tr><td>//9F35</td><td>01</td><td>Terminal Type</td><td>B</td><td>R</td><td>21</td></tr><tr><td>//9F1A</td><td>02</td><td>Terminal Country Code</td><td>B</td><td>R</td><td>08 40</td></tr><tr><td>//9F33</td><td>03</td><td>Terminal Capabilities</td><td>B</td><td>R</td><td>00 00 00</td></tr><tr><td>//9F40</td><td>05</td><td>Additional Terminal Capabilities</td><td>B</td><td>R</td><td>00 00 00 00 00</td></tr><tr><td>//9F66</td><td>04</td><td>Terminal Transaction Qualifier</td><td>B</td><td>R</td><td>22 00 40 00</td></tr><tr><td>//DF1B</td><td>03</td><td>Kernel Configuration Byte 1 and further bytes as documented.</td><td>B</td><td>R</td><td>00 00 06</td></tr><tr><td>//DF2D</td><td>03</td><td>Message Hold Time (100 of ms)</td><td>B</td><td>R</td><td>00 00 0F</td></tr><tr><td>//9F09</td><td>02</td><td>EMV Application Version Number</td><td>B</td><td>R</td><td>00 01</td></tr><tr><td>//DF30</td><td>01</td><td><p>Bitmap Entry Point</p><ul><li>Bit 8 = Status Check Support Flag</li><li>Bit 7 = Zero Amount Allowed Flag</li><li>Bit 6 = Reader Contactless Transaction Limit</li><li>Bit 5 = Reader Contactless Floor Limit</li><li>Bit 4 = Reader CVM Required Limit</li></ul></td><td>B</td><td>R</td><td>F8</td></tr><tr><td>//DF32</td><td>01</td><td><p>Status Zero Amount Allowed Flag</p><ul><li>0x01 = Option 1, Online Cryptogram Request</li><li>0x02 = Option 2, Not Allowed</li></ul></td><td>B</td><td>R</td><td>02</td></tr><tr><td>//9F1B</td><td>04</td><td>Terminal Floor Limit</td><td>B</td><td>R</td><td>00 00 00 00</td></tr><tr><td>//DF23</td><td>06</td><td>Reader Contactless Floor Limit</td><td>B</td><td>R</td><td>00 00 00 00 20 00</td></tr><tr><td>//DF24</td><td>06</td><td>Reader Contactless Transaction Limit</td><td>B</td><td>R</td><td>00 00 00 00 50 00</td></tr><tr><td>//DF26</td><td>06</td><td>Reader CVM Required Limit</td><td>B</td><td>R</td><td>00 00 00 00 10 00</td></tr></tbody></table>

## American Express Expresspay Entry Point Table

<table><thead><tr><th width="77.33331298828125">Tag</th><th width="75.3333740234375">Len</th><th>Value / Description</th><th width="72.66668701171875">Typ</th><th width="76">Req</th><th width="110.333251953125">Example</th></tr></thead><tbody><tr><td>FF35</td><td>var</td><td>AID Delimiter Container There can be multiple instances of this in sequence. The contents of the first instance are loaded into Entry Point Table Slot 1, the contents of the second are loaded into Entry Point Table Slot 2, etc.</td><td>T</td><td>R</td><td></td></tr><tr><td>/DF0E</td><td>03</td><td><p>Kernel ID, Processing Slot, Transaction Type Byte 1 Kernel ID</p><ul><li>0x04 = Expresspay</li></ul><p>Byte 2 Processing Slot to Use See the <strong>AID Delimiter Container</strong> parameter in EMV Processing Configuration File Type for information about how to identify slots. Byte 3 Transaction Type</p><ul><li>0x00 = Purchase</li><li>0x01 = Cash</li><li>0x02 = Purchase with cashback</li><li>0x03 = Refund</li></ul></td><td>B</td><td>R</td><td>04 04 00</td></tr><tr><td>/DF0F</td><td>var</td><td>Payload Delimiter Container Include only one of these containers inside each <strong>AID Delimiter Container</strong>.</td><td>T</td><td>R</td><td></td></tr><tr><td>//9F09</td><td>02</td><td>EMV Application Version Number</td><td>B</td><td>R</td><td>00 01</td></tr><tr><td>//9F1A</td><td>02</td><td>Terminal Country Code</td><td>B</td><td>R</td><td>08 40</td></tr><tr><td>//9F33</td><td>03</td><td>Terminal Capabilities</td><td>B</td><td>R</td><td>60 28 00</td></tr><tr><td>//9F35</td><td>01</td><td>Terminal Type</td><td>B</td><td>R</td><td>21</td></tr><tr><td>//9F40</td><td>05</td><td>Additional Terminal Capabilities</td><td>B</td><td>R</td><td>00 00 00 00 00</td></tr><tr><td>//9F6D</td><td>01</td><td><p>Contactless Reader Capability Bits 8..7</p><ul><li>00 = Expresspay 1.0</li><li>01 = Expresspay 2.0 and Expresspay >= 3.x (MSD)</li><li>11 = Expresspay >= 3.x(MSD)</li></ul><p>Bits 6..1 = 0 (Reserved, not to be configured)</p></td><td>B</td><td>R</td><td>C0</td></tr><tr><td>//DF1B</td><td>06</td><td>Kernel Configuration (detailed bit definitions)</td><td>B</td><td>R</td><td>31 01 00 00 00 00</td></tr><tr><td>//DF27</td><td>01</td><td>Timeout, Field off request (100 of ms)</td><td>B</td><td>R</td><td>20</td></tr><tr><td>//DF2D</td><td>03</td><td>Message Hold Time (100 of ms)</td><td>B</td><td>R</td><td>00 00 0F</td></tr><tr><td>//DF30</td><td>01</td><td>Bitmap Entry Point</td><td>B</td><td>R</td><td>F8</td></tr><tr><td>//DF32</td><td>01</td><td>Status Zero Amount Allowed</td><td>B</td><td>R</td><td>01</td></tr><tr><td>//DF20</td><td>05</td><td>Terminal Action Code - Default</td><td>B</td><td>R</td><td>00 00 00 00 00</td></tr><tr><td>//DF21</td><td>05</td><td>Terminal Action Code - Denial</td><td>B</td><td>R</td><td>00 00 00 00 00</td></tr><tr><td>//DF22</td><td>05</td><td>Terminal Action Code - Online</td><td>B</td><td>R</td><td>00 00 00 00 00</td></tr><tr><td>//DF23</td><td>06</td><td>Reader Contactless Floor Limit</td><td>B</td><td>R</td><td>00 00 00 00 20 00</td></tr><tr><td>//DF24</td><td>06</td><td>Reader Contactless Transaction Limit</td><td>B</td><td>R</td><td>00 00 00 01 00 00</td></tr><tr><td>//DF26</td><td>06</td><td>Reader CVM Required Limit</td><td>B</td><td>R</td><td>00 00 00 01 00 00</td></tr></tbody></table>

## Discover D-PAS Entry Point Table

<table><thead><tr><th width="79.33331298828125">Tag</th><th width="75.66668701171875">Len</th><th>Value / Description</th><th width="80">Typ</th><th width="76.51507568359375">Req</th><th width="46.33331298828125">Example</th></tr></thead><tbody><tr><td>FF35</td><td>var</td><td>AID Delimiter Container There can be multiple instances of this in sequence. The contents of the first instance are loaded into Entry Point Table Slot 1, the contents of the second are loaded into Entry Point Table Slot 2, etc.</td><td>T</td><td>R</td><td></td></tr><tr><td>/DF0E</td><td>03</td><td><p>Kernel ID, Processing Slot, Transaction Type Byte 1 Kernel ID</p><ul><li>0x06 = Discover D-PAS</li></ul><p>Byte 2 Processing Slot to Use See the <strong>AID Delimiter Container</strong> parameter in EMV Processing Configuration File Type for information about how to identify slots. Byte 3 Transaction Type</p><ul><li>0x00 = Purchase</li><li>0x01 = Cash</li><li>0x02 = Purchase with cashback</li><li>0x03 = Refund</li></ul></td><td>B</td><td>R</td><td>06 06 00</td></tr><tr><td>/DF0F</td><td>var</td><td>Payload Delimiter Container Include only one of these containers inside each <strong>AID Delimiter Container</strong>.</td><td>T</td><td>R</td><td></td></tr><tr><td>//9F09</td><td>02</td><td>EMV Application Version Number</td><td>B</td><td>R</td><td>00 01</td></tr><tr><td>//9F1A</td><td>02</td><td>Terminal Country Code</td><td>B</td><td>R</td><td>08 40</td></tr><tr><td>//9F33</td><td>03</td><td>Terminal Capabilities</td><td>B</td><td>R</td><td>00 00 00</td></tr><tr><td>//9F35</td><td>01</td><td>Terminal Type</td><td>B</td><td>R</td><td>21</td></tr><tr><td>//9F66</td><td>04</td><td>Terminal Transaction Qualifier</td><td>B</td><td>R</td><td>B6 00 C0 00</td></tr><tr><td>//DF1B</td><td>01</td><td>Kernel Configuration (bit definitions)</td><td>B</td><td>R</td><td>60</td></tr><tr><td>//DF1B</td><td>02</td><td>Kernel Configuration (Common Kernel Only)</td><td>B</td><td>R</td><td>60 00</td></tr><tr><td>//DF30</td><td>02</td><td>Bitmap Entry Point</td><td>B</td><td>R</td><td>F8</td></tr><tr><td>//DF32</td><td>01</td><td>Status Zero Amount Allowed Flag</td><td>B</td><td>R</td><td>01</td></tr><tr><td>//9F1B</td><td>06</td><td>Terminal Floor Limit</td><td>B</td><td>R</td><td>00 00 00 00</td></tr><tr><td>//DF23</td><td>06</td><td>Reader Contactless Floor Limit</td><td>B</td><td>R</td><td>00 00 00 01 50 00</td></tr><tr><td>//DF24</td><td>06</td><td>Reader Contactless Transaction Limit</td><td>B</td><td>R</td><td>00 00 00 03 00 00</td></tr><tr><td>//DF26</td><td>06</td><td>Reader CVM Required Limit</td><td>B</td><td>R</td><td>00 00 00 00 20 00</td></tr></tbody></table>

## China Unionpay Entry Point Table

<table><thead><tr><th width="84">Tag</th><th width="73.3333740234375">Len</th><th>Value / Description</th><th width="74.33331298828125">Typ</th><th width="74">Req</th><th width="106.66656494140625">Example</th></tr></thead><tbody><tr><td>FF35</td><td>var</td><td>AID Delimiter Container There can be multiple instances of this in sequence. The contents of the first instance are loaded into Entry Point Table Slot 1, the contents of the second are loaded into Entry Point Table Slot 2, etc.</td><td>T</td><td>R</td><td></td></tr><tr><td>/DF0E</td><td>03</td><td><p>Kernel ID, Processing Slot, Transaction Type Byte 1 Kernel ID</p><ul><li>0x07 = China Unionpay</li></ul><p>Byte 2 Processing Slot to Use See the <strong>AID Delimiter Container</strong> parameter in EMV Processing Configuration File Type for information about how to identify slots. Byte 3 Transaction Type</p><ul><li>0x00 = Purchase</li><li>0x01 = Cash</li><li>0x02 = Purchase with cashback</li><li>0x03 = Refund</li></ul></td><td>B</td><td>R</td><td>07 05 00</td></tr><tr><td>/DF0F</td><td>var</td><td>Payload Delimiter Container Include only one of these containers inside each <strong>AID Delimiter Container</strong>.</td><td>T</td><td>R</td><td></td></tr><tr><td>//9F09</td><td>02</td><td>EMV Application Version Number</td><td>B</td><td>R</td><td>00 30</td></tr><tr><td>//9F1A</td><td>02</td><td>Terminal Country Code</td><td>B</td><td>R</td><td>01 56</td></tr><tr><td>//9F33</td><td>03</td><td>Terminal Capabilities</td><td>B</td><td>R</td><td>60 08 00</td></tr><tr><td>//9F35</td><td>01</td><td>Terminal Type</td><td>B</td><td>R</td><td>21</td></tr><tr><td>//9F66</td><td>04</td><td>Terminal Transaction Qualifier</td><td>B</td><td>R</td><td>36 00 00 80</td></tr><tr><td>//DF1B</td><td>02</td><td>Kernel Configuration Byte1 and Byte2 (bit definitions)</td><td>B</td><td>R</td><td>00 00</td></tr><tr><td>//DF20</td><td>05</td><td>Terminal Action Code - Default</td><td>B</td><td>R</td><td>00 00 00 00 00</td></tr><tr><td>//DF21</td><td>05</td><td>Terminal Action Code - Denial</td><td>B</td><td>R</td><td>00 00 00 00 00</td></tr><tr><td>//DF22</td><td>05</td><td>Terminal Action Code - Online</td><td>B</td><td>R</td><td>00 00 00 00 00</td></tr><tr><td>//DF23</td><td>06</td><td>Reader Contactless Floor Limit</td><td>B</td><td>R</td><td>00 00 00 01 50 00</td></tr><tr><td>//DF24</td><td>06</td><td>Reader Contactless Transaction Limit</td><td>B</td><td>R</td><td>00 00 00 03 00 00</td></tr><tr><td>//DF26</td><td>06</td><td>Reader CVM Required Limit</td><td>B</td><td>R</td><td>00 00 00 01 20 00</td></tr><tr><td>//DF30</td><td>01</td><td>Bitmap Entry Point</td><td>B</td><td>R</td><td>78</td></tr><tr><td>9F1B</td><td>04</td><td>Terminal Floor Limit</td><td>B</td><td>R</td><td>00 00 3a 98</td></tr></tbody></table>

## JCB Entry Point Table (Common Kernel Only)

<table><thead><tr><th width="75.33331298828125">Tag</th><th width="78">Len</th><th>Value / Description</th><th width="77.33331298828125">Typ</th><th width="76">Req</th><th width="104.666748046875">Example</th></tr></thead><tbody><tr><td>FF35</td><td>var</td><td>AID Delimiter Container There can be multiple instances of this in sequence. The contents of the first instance are loaded into Entry Point Table Slot 1, the contents of the second are loaded into Entry Point Table Slot 2, etc.</td><td>T</td><td>R</td><td></td></tr><tr><td>/DF0E</td><td>03</td><td><p>Kernel ID, Processing Slot, Transaction Type Byte 1 Kernel ID</p><ul><li>0x05 = JCB</li></ul><p>Byte 2 Processing Slot to Use See the <strong>AID Delimiter Container</strong> parameter in EMV Processing Configuration File Type for information about how to identify slots. Byte 3 Transaction Type</p><ul><li>0x00 = Purchase</li><li>0x01 = Cash</li><li>0x02 = Purchase with cashback</li><li>0x03 = Refund</li></ul></td><td>B</td><td>R</td><td>05 06 00</td></tr><tr><td>/DF0F</td><td>var</td><td>Payload Delimiter Container Include only one of these containers inside each <strong>AID Delimiter Container</strong>.</td><td>T</td><td>R</td><td></td></tr><tr><td>//9F01</td><td>06</td><td>Acquirer Identifier</td><td>B</td><td>R</td><td>00 00 00 00 00 01</td></tr><tr><td>//9F15</td><td>02</td><td>Merchant Category Code</td><td>B</td><td>R</td><td>70 32</td></tr><tr><td>//9F09</td><td>02</td><td>EMV Application Version Number</td><td>B</td><td>R</td><td>00 01</td></tr><tr><td>//9F1A</td><td>02</td><td>Terminal Country Code</td><td>B</td><td>R</td><td>03 92</td></tr><tr><td>//9F33</td><td>03</td><td>Terminal Capability</td><td>B</td><td>R</td><td>60 68 08</td></tr><tr><td>//9F35</td><td>01</td><td>Terminal Type</td><td>B</td><td>R</td><td>21</td></tr><tr><td>//9F4E</td><td>var</td><td>Merchant Name and Location</td><td>B</td><td>R</td><td>(example hex provided)</td></tr><tr><td>//DF1B</td><td>03</td><td>Kernel Configuration Byte1..Byte3 (bit definitions)</td><td>B</td><td>R</td><td>7B 00 80</td></tr><tr><td>//DF20</td><td>05</td><td>Terminal Action Code - Default</td><td>B</td><td>R</td><td>90 40 20 80 20</td></tr><tr><td>//DF21</td><td>05</td><td>Terminal Action Code - Denial</td><td>B</td><td>R</td><td>04 10 20 20 20</td></tr><tr><td>//DF22</td><td>05</td><td>Terminal Action Code - Online</td><td>B</td><td>R</td><td>90 60 20 90 20</td></tr><tr><td>//DF23</td><td>06</td><td>Reader Contactless Floor Limit</td><td>B</td><td>R</td><td>00 00 00 01 50 00</td></tr><tr><td>//DF24</td><td>06</td><td>Reader Contactless Transaction Limit</td><td>B</td><td>R</td><td>00 00 00 03 00 00</td></tr><tr><td>//DF25</td><td>06</td><td>On Device CVM Contactless Transaction Limit</td><td>B</td><td>R</td><td>00 00 00 02 50 00</td></tr><tr><td>//DF26</td><td>06</td><td>Reader CVM Required Limit</td><td>B</td><td>R</td><td>00 00 00 01 20 00</td></tr><tr><td>//9F1B</td><td>04</td><td>Terminal Floor Limit</td><td>B</td><td>R</td><td>00 00 3a 98</td></tr></tbody></table>

## Interac Flash Entry Point Table (Common Kernel Only)

<table><thead><tr><th width="77.33334350585938">Tag</th><th width="74.6666259765625">Len</th><th>Value / Description</th><th width="75.66668701171875">Typ</th><th width="77.66668701171875">Req</th><th width="106.33328247070312">Example</th></tr></thead><tbody><tr><td>FF35</td><td>var</td><td>AID Delimiter Container There can be multiple instances of this in sequence. The contents of the first instance are loaded into Entry Point Table Slot 1, the contents of the second are loaded into Entry Point Table Slot 2, etc.</td><td>T</td><td>R</td><td></td></tr><tr><td>/DF0E</td><td>03</td><td><p>Kernel ID, Processing Slot, Transaction Type Byte 1 Kernel ID</p><ul><li>0x41 = Interac Flash</li></ul><p>Byte 2 Processing Slot to Use See the <strong>AID Delimiter Container</strong> parameter in EMV Processing Configuration File Type for information about how to identify slots. Byte 3 Transaction Type</p><ul><li>0x00 = Purchase</li><li>0x01 = Cash</li><li>0x02 = Purchase with cashback</li><li>0x03 = Refund</li></ul></td><td>B</td><td>R</td><td>41 05 00</td></tr><tr><td>/DF0F</td><td>var</td><td>Payload Delimiter Container Include only one of these containers inside each <strong>AID Delimiter Container</strong>.</td><td>T</td><td>R</td><td></td></tr><tr><td>//9F09</td><td>02</td><td>EMV Application Version Number</td><td>B</td><td>R</td><td>00 02</td></tr><tr><td>//9F1A</td><td>02</td><td>Terminal Country Code</td><td>B</td><td>R</td><td>01 24</td></tr><tr><td>//9F33</td><td>03</td><td>Terminal Capabilities</td><td>B</td><td>R</td><td>60 68 08</td></tr><tr><td>//9F35</td><td>01</td><td>Terminal Type</td><td>B</td><td>R</td><td>21</td></tr><tr><td>//9F40</td><td>05</td><td>Additional Terminal Capabilities</td><td>B</td><td>R</td><td>E0 00 E0 F0 01</td></tr><tr><td>//9F58</td><td>01</td><td>Merchant Type Indicator</td><td>B</td><td>R</td><td>03</td></tr><tr><td>//9F5D</td><td>06</td><td>Receipt Limit</td><td>B</td><td>R</td><td>00 00 00 00 50 00</td></tr><tr><td>//9F5E</td><td>02</td><td>Terminal Option Status Byte1/Byte2 (bit definitions)</td><td>B</td><td>R</td><td>E0 00</td></tr><tr><td>//9F5F</td><td>06</td><td>Reader Contactless Floor Limit</td><td>B</td><td>R</td><td>00 00 00 01 00 00</td></tr><tr><td>//DF1B</td><td>02</td><td>Kernel Configuration Byte1/Byte2 (bit definitions)</td><td>B</td><td>R</td><td>02 34</td></tr><tr><td>//DF20</td><td>05</td><td>Terminal Action Code - Default</td><td>B</td><td>R</td><td>00 00 00 00 00</td></tr><tr><td>//DF21</td><td>05</td><td>Terminal Action Code - Denial</td><td>B</td><td>R</td><td>00 00 00 00 00</td></tr><tr><td>//DF22</td><td>05</td><td>Terminal Action Code - Online</td><td>B</td><td>R</td><td>00 00 00 00 00</td></tr><tr><td>//9F1B</td><td>04</td><td>Terminal Floor Limit</td><td>B</td><td>R</td><td>00 00 1F 40</td></tr></tbody></table>


# EMV Configuration CA Public Keys File Type

The host can load this file type to control the behavior of the device’s EMV contact and contactless kernels when the device should support Offline Data Authentication (ODA). Populate all values from information provided by each payment brand that should be supported by the device. The host can load this file using **Start Send File to Device (Unsecured) - Command 0xD812**.

MagTek provides tools that allow these settings to be loaded using a Microsoft Excel spreadsheet in xlsx format for more convenient authoring, review, and change tracking. For a reference sample spreadsheet,

contact MagTek Support Services. The MagTek tools expect the spreadsheet to be formatted format as shown in **Table XX**. Each CA Key to be supported is defined in a tab of the Excel file.

## **EMV Configuration CA Keys File Type**

<table><thead><tr><th width="115.18182373046875">Tag</th><th width="95.3636474609375">Len</th><th>Value / Description</th><th width="74.9090576171875">Typ</th><th width="75.272705078125">Req</th><th>Example</th></tr></thead><tbody><tr><td>DFDF79</td><td>05</td><td>Registered Application ID (RID)</td><td>B</td><td>R</td><td>A0 00 00 00 04</td></tr><tr><td>DFDF7A</td><td>01</td><td>CA Public Key Index</td><td>B</td><td>R</td><td>05</td></tr><tr><td>DFDF7B</td><td>var</td><td>CA Public key Modulus</td><td>B</td><td>R</td><td>B8 04 8A … D5 97</td></tr><tr><td>DFDF7C</td><td>01 or 03</td><td>CA Public Key Exponent</td><td>B</td><td>R</td><td>03</td></tr><tr><td>DFDF7D</td><td>14</td><td>CA Public Key Checksum</td><td>B</td><td>R</td><td>EB FA 0D 5D 06 D8 CE 70 2D A3 EA E8 90 70 1D 45 E2 74 C8 45</td></tr></tbody></table>

The MagTek tool converts the spreadsheet data into the format shown in **CA Keys Raw Format.**

## **CA Keys Raw Format**

| CA Keys Raw Format                                                    |
| --------------------------------------------------------------------- |
| RID (5 Bytes) As defined by the payment brand.                        |
| Index (1 Byte) As defined by the payment brand.                       |
| <p>Exponent Length (1 Byte)</p><ul><li>0x01</li><li>0x03</li></ul>    |
| Key Length (1 Byte), Max of 248 bytes per EMVCo specifications        |
| <p>Exponent (1 or 3 Bytes)</p><ul><li>0x03</li><li>0x010001</li></ul> |
| Modulus As defined by the payment brand.                              |
| Additional CA Keys, repeating from RID through Modulus, as needed.    |
| SHA-1 hash of all data in the file                                    |


# EMV American Express DRL Configuration File Type (Not Supported on Expresspay 4.x)

The host can load this file type to control the behavior of the device’s American Express contactless kernel when the card sends tag 9F70 and one or more DRL is defined.

The host can load it using **Start Send File to Device (Unsecured) - Command 0xD812**. See the ***Expresspay 4.0.2*** specification for functional details.

MagTek provides tools that allow these settings to be loaded using a Microsoft Excel spreadsheet in xlsx format for more convenient authoring, review, and change tracking. For a reference sample spreadsheet, contact MagTek Support Services. The MagTek tools expect the spreadsheet to be formatted as shown in **Table 43**. Each DRL to be supported is defined in a tab of the Excel file.

## **EMV Configuration American Express DRL Set File Type**

<table><thead><tr><th width="93.33331298828125">Tag</th><th width="82.66668701171875">Len</th><th>Value / Description</th><th width="79">Typ</th><th width="83.3333740234375">Req</th><th>Example</th></tr></thead><tbody><tr><td>DF23</td><td>06</td><td>Reader Contactless Floor Limit</td><td>B</td><td>R</td><td>00 00 00 00 15 00</td></tr><tr><td>DF24</td><td>06</td><td>Reader Contactless Transaction Limit</td><td>B</td><td>R</td><td>00 00 00 00 05 00</td></tr><tr><td>DF26</td><td>06</td><td>Reader CVM Required Limit</td><td>B</td><td>R</td><td>00 00 00 00 10 00</td></tr></tbody></table>

The MagTek tool converts the spreadsheet data into the raw format shown in [**Table 44**:](#_bookmark24)

## **Raw EMV Configuration American Express DRL Set File Type**

<table><thead><tr><th>Tag</th><th width="74">Len</th><th width="122.66668701171875">Value / Description</th><th width="75">Typ</th><th width="78">Req</th><th width="111.99993896484375">Example</th></tr></thead><tbody><tr><td><p>File Type Version One byte indicating the version of the file type format being used.</p><ul><li>0xAA</li></ul></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>SHA-1 Hash 20 byte hash of all values that follow</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>FF37</td><td>var</td><td>DRL Configuration Container</td><td>T</td><td>R</td><td></td></tr><tr><td>/FF36</td><td>var</td><td>DRL Set Container</td><td>T</td><td>R</td><td></td></tr><tr><td>//DF23</td><td>06</td><td>Reader Contactless Floor Limit</td><td>B</td><td>R</td><td>00 00 00 00 15 00</td></tr><tr><td>//DF24</td><td>06</td><td>Reader Contactless Transaction Limit</td><td>B</td><td>R</td><td>00 00 00 00 05 00</td></tr><tr><td>//DF26</td><td>06</td><td>Reader CVM Required Limit</td><td>B</td><td>R</td><td>00 00 00 00 10 00</td></tr><tr><td>Additional instances of DRL Set Container as needed</td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>


# Signature Capture File Type (Touch Only)

The signature capture file type produced when the host invokes Command 0x1801 - Request Cardholder Signature (Touch Only) is a TLV data object in the format below. If the encryption is enabled in Command 0x1801, please refer to Encrypted Signature Capture File Type below.

## **Signature Capture File Type**

<table><thead><tr><th width="76">Tag</th><th width="74.6666259765625">Len</th><th>Value / Description</th><th width="74.3333740234375">Typ</th><th width="77.51507568359375">Req</th><th>Default</th></tr></thead><tbody><tr><td>81</td><td>08</td><td>Signature Window Width and Height Bytes 0..1 = Left edge (minimum value of all X coordinates) Bytes 2..3 = Right edge (maximum value of all X coordinates) Bytes 4..5 = Top edge (minimum value of all Y coordinates) Bytes 6..7 = Bottom edge (maximum value of all Y coordinates)</td><td>B</td><td>R</td><td>0000 00FD 0000 0078 (landscape) 0000 00C8 0000 00B9 (portrait)</td></tr><tr><td>82</td><td>var</td><td>Signature Coordinate Values List This is a blob that consists of a raw list of point coordinates representing the signature. Each coordinate is 4 bytes long, where the first 2 bytes are the X coordinate of that point and the second 2 bytes are the Y coordinate of that point.</td><td>B</td><td>O</td><td></td></tr></tbody></table>

## **Encrypted Signature Capture File Type**

<table><thead><tr><th width="102.99996948242188">Tag</th><th width="80">Len</th><th>Value / Description</th><th width="78.33331298828125">Typ</th><th width="83.33331298828125">Req</th><th width="109.66677856445312">Default</th></tr></thead><tbody><tr><td>F9</td><td>var</td><td>Container for MAC structure and generic data, length excludes MAC padding and MAC checksum</td><td>T</td><td>R</td><td></td></tr><tr><td>/DFDF54</td><td>var</td><td>MAC KSN</td><td>B</td><td>R</td><td></td></tr><tr><td>/DFDF55</td><td>var</td><td>MAC Encryption Type</td><td>B</td><td>R</td><td></td></tr><tr><td>/F8</td><td>var</td><td>Container for Encrypted Data</td><td>T</td><td>R</td><td></td></tr><tr><td>//DFDF59</td><td>var</td><td>Encrypted Data Primitive ( length includes padding) Decrypt the value of this TLV data object using the algorithm and variant specified in the Encrypted Data KSN parameter and the Encryption Type parameter below to read its contents.</td><td>B</td><td>R</td><td></td></tr><tr><td>//DFDF56</td><td>var</td><td>Encrypted Data KSN</td><td>B</td><td>R</td><td></td></tr><tr><td>//DFDF57</td><td>01</td><td>Encrypted Data Encryption Type See <strong>Encryption Type</strong> for a list of valid values.</td><td>B</td><td>R</td><td></td></tr><tr><td>PKCS7 padding for MAC calculation, maximum 16 bytes, minimum 1 byte</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Four-byte MAC checksum. The host should calculate the MAC and verify that it matches.</td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## **Encrypted Signature Capture File Type (after decryption)**

<table><thead><tr><th width="76">Tag</th><th width="78.66668701171875">Len</th><th>Value / Description</th><th width="75.33331298828125">Typ</th><th width="74.66668701171875">Req</th><th width="99">Default</th></tr></thead><tbody><tr><td>F9</td><td>var</td><td>Container for MAC structure and generic data, length excludes MAC padding and MAC checksum</td><td>T</td><td>R</td><td></td></tr><tr><td>/DFDF55</td><td>var</td><td>MAC Encryption Type</td><td>B</td><td>R</td><td></td></tr><tr><td>/F8</td><td>var</td><td>Container for Encrypted Data</td><td>T</td><td>R</td><td></td></tr><tr><td>//DFDF59</td><td>var</td><td>Encrypted Data Primitive, length includes padding</td><td>T</td><td>R</td><td></td></tr><tr><td>///FC</td><td>var</td><td>Decrypted Data Container, length excludes padding</td><td>T</td><td>R</td><td></td></tr><tr><td>////A1</td><td>var</td><td>Signature file container, maximum 4,000 bytes</td><td>T</td><td>R</td><td></td></tr><tr><td>/////81</td><td>08</td><td>Signature Window Width and Height, refer to <strong>Table SCF-1 - Signature Capture File Type.</strong></td><td>B</td><td>R</td><td></td></tr><tr><td>/////82</td><td>var</td><td>Signature Coordinate Values List, refer to <strong>Table SCF-1 - Signature Capture File Type.</strong></td><td>B</td><td>R</td><td></td></tr><tr><td>////81</td><td>04</td><td>Real Time Clock, Epoch Time in seconds, unsigned 32 bits. The date and time shall be Universal Time Coordinated (UTC).</td><td>B</td><td>R</td><td></td></tr><tr><td>////82</td><td>04</td><td>Device Serial Number</td><td>B</td><td>R</td><td></td></tr><tr><td>////A3</td><td>var</td><td>User data parameters for item #0 to item #3. The maximum total size of 0xA3 TLV is 4,000 bytes.</td><td>T</td><td>O</td><td></td></tr><tr><td>/////81</td><td>var</td><td>User data item #0, optional</td><td>B</td><td>O</td><td></td></tr><tr><td>/////82</td><td>var</td><td>User data item #1, optional</td><td>B</td><td>O</td><td></td></tr><tr><td>/////83</td><td>var</td><td>User data item #2, optional</td><td>B</td><td>O</td><td></td></tr><tr><td>/////84</td><td>var</td><td>User data item #3, optional</td><td>B</td><td>O</td><td></td></tr><tr><td>PKCS7 padding for encryption, maximum 16 bytes, minimum 1 byte</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>//DFDF56</td><td>var</td><td>Encrypted Data KSN</td><td>B</td><td>R</td><td></td></tr><tr><td>//DFDF57</td><td>01</td><td>Encrypted Data Encryption Type See <strong>Encryption Type</strong> for a list of valid values.</td><td>B</td><td>R</td><td></td></tr><tr><td>PKCS7 padding for MAC calculation, maximum 16 bytes, minimum 1 byte</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Four-byte MAC checksum. The host should calculate the MAC and verify that it matches.</td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>


# Security Operation Type

This non-TLV data structure consists of four or five bytes that describes a security operation, including the algorithms and methods to be used in that operation.

## **Security Operation Type**

<table><thead><tr><th width="89">Offset</th><th>Description</th><th width="75.33331298828125">Typ</th><th width="74.84857177734375">Req</th><th width="97.7574462890625">Default</th></tr></thead><tbody><tr><td>0</td><td><p></p><p>Operation Type</p><ul><li>0x01 = Key Agreement</li><li>0x02 = Command Authorization Using Signature</li><li>0x03 = Command Authorization Using MAC</li><li>0x05 = Data Authentication Using MAC</li><li>0x07 = Data Encryption</li><li>0x10 = Data Signature</li></ul></td><td>B</td><td>R</td><td></td></tr><tr><td>1</td><td><p></p><p>Operation Algorithm If <strong>Operation Type</strong> is Key Agreement type:</p><ul><li>0x01 = ECDHE</li></ul><p>If <strong>Operation Type</strong> is a Signature type:</p><ul><li>0x01 = ECDSA (indeterministic)</li></ul><p>If <strong>Operation Type</strong> is a MAC type:</p><ul><li>0x01 = HMAC</li><li>0x02 = CBC-MAC</li><li>0x03 = CMAC</li></ul><p>If <strong>Operation Type</strong> is an Encryption type:</p><ul><li>0x01 = DEA</li><li>0x02 = 2TDEA</li><li>0x03 = 3TDEA</li><li>0x04 = AES-128</li><li>0x05 = AES-192</li><li>0x06 = AES-256</li></ul></td><td>B</td><td>R</td><td></td></tr><tr><td>2</td><td><p>Operation Curve/Mode/Hash/Cipher If <strong>Operation Type</strong> is a Key Agreement type, this specifies the Curve:</p><ul><li>0x01 = P192</li><li>0x02 = P224</li><li>0x03 = P256</li><li>0x04 = P384</li><li>0x05 = P521</li></ul><p>If <strong>Operation Type</strong> is a Signature type, this specifies the Hash:</p><ul><li>0x01 = MD5</li><li>0x02 = SHA-1</li><li>0x03 = SHA-224</li><li>0x04 = SHA-256</li><li>0x05 = SHA-384</li><li>0x06 = SHA-512</li><li>0x07 = SHA-512/224</li><li>0x08 = SHA-512/256</li><li>0x09 = SHA3-224</li><li>0x0A = SHA3-256</li><li>0x0B = SHA3-384</li><li>0x0C = SHA3-512</li></ul><p>If <strong>Operation Type</strong> is a MAC type, this specifies the Encryption Algorithm:</p><ul><li>0x01 = DEA</li><li>0x02 = 2TDEA</li><li>0x03 = 3TDEA</li><li>0x04 = AES-128</li><li>0x05 = AES-192</li><li>0x06 = AES-256</li></ul><p>If <strong>Operation Type</strong> is an Encryption type, this specifies the Mode:</p><ul><li>0x01 = ECB (Block)</li><li>0x02 = CBC (Block)</li><li>0x03 = CFB (Stream)</li><li>0x04 = OFB (Stream)</li><li>0x05 = CTR (Stream)</li></ul></td><td>B</td><td>R</td><td></td></tr><tr><td>3</td><td><p></p><p>KDF/Curve/Padding If <strong>Operation Type</strong> is a Key Agreement type, this specifies the KDF:</p><ul><li>0x01 = SP800-56A / X9.63</li></ul><p>If <strong>Operation Type</strong> is a Signature type, this specifies the Curve:</p><ul><li>0x01 = P192</li><li>0x02 = P224</li><li>0x03 = P256</li><li>0x04 = P384</li><li>0x05 = P521</li></ul><p>If <strong>Operation Type</strong> is a MAC type, this specifies the Padding:</p><ul><li>0x00 = None (for streaming modes)</li><li>0x01 = Zeros (ISO 9797 Padding Method 1)</li><li>0x02 = One and zeros (ISO 9797 Method 2)</li><li>0x03 = Length + zeros (ISO 9797 Method 3)</li><li>0x10 = PKCS7 (pad # = pad length)</li><li>0x11 = X9.23 (random + pad length)</li><li>0x20 = Random (when length is known)</li></ul><p>If <strong>Operation Type</strong> is an Encryption type, this specifies the Padding:</p><ul><li>0x00 = None (for streaming modes)</li><li>0x01 = Zeros (ISO 9797 Padding Method 1)</li><li>0x02 = One and zeros (ISO 9797 Method 2)</li><li>0x03 = Length + zeros (ISO 9797 Method 3)</li><li>0x10 = PKCS7 (pad # = pad length)</li><li>0x11 = X9.23 (random + pad length)</li><li>0x20 = Random (when length is known)</li></ul></td><td>B</td><td>R</td><td></td></tr><tr><td>4</td><td>MAC Block Size If <strong>Operation Type</strong> is a MAC type, this specifies the data to be MACed must be padded to a multiple of this many bytes. For all other Operation Types, do not include this byte.</td><td>B</td><td>O</td><td></td></tr></tbody></table>


# Security Parameters Type

## **Security Parameters Type**

<table><thead><tr><th width="73.99996948242188">Tag</th><th width="78.66668701171875">Len</th><th>Value / Description</th><th width="79.33331298828125">Typ</th><th width="74.66668701171875">Req</th><th width="97.33334350585938">Default</th></tr></thead><tbody><tr><td>81</td><td>var</td><td>Operation This contains an instance of a <strong>- Encrypted Signature Capture File</strong>Type structure specifying the operation to be performed.</td><td>B</td><td>R</td><td></td></tr><tr><td>84</td><td>var</td><td>Data Reserved for future use. Do not include this parameter. It is reserved for Initialization Vector or nonce, if needed.</td><td>B</td><td>O</td><td></td></tr><tr><td>85</td><td>var</td><td>Extra Data Item Reserved for future use. Do not include.</td><td>B</td><td>O</td><td></td></tr><tr><td>A8</td><td>var</td><td>Key Information This specifies the key used in the operation. Populate with a <strong>Key Information Type</strong> TLV data object. For ECDSA operations, do not include this parameter.</td><td>T</td><td>O</td><td></td></tr><tr><td>A9</td><td>var</td><td>Second Key Information (Reserved, do not include) This specifies a second key used in the operation. If needed, populate with a <strong>Key Information Type</strong> TLV data object.</td><td>T</td><td>O</td><td></td></tr></tbody></table>


# Key Information Type

## **Key Information Type**

<table><thead><tr><th width="76">Tag</th><th width="77.33331298828125">Len</th><th>Value / Description</th><th width="72.66668701171875">Typ</th><th width="76.66668701171875">Req</th><th width="104.66668701171875">Default</th></tr></thead><tbody><tr><td>81</td><td>02</td><td>Key Slot ID Identifies the key being used for operation. See <strong>Table 59 -Key Slot IDs</strong>.</td><td>B</td><td>R</td><td></td></tr><tr><td>82</td><td>var</td><td>Key Label The label that indicates the key type. For example, <strong>DEVTK</strong>.</td><td>AN</td><td>O</td><td></td></tr><tr><td>86</td><td>var</td><td>Key Derivation Details Use Key Serial Number (KSN) in requests, Key Derivation Information in responses.</td><td>B</td><td>O</td><td></td></tr><tr><td>88</td><td>var</td><td>Additional Information Reserved for future use. Do not include.</td><td>B</td><td>O</td><td></td></tr></tbody></table>


# NFC UID Type (EMV Contactless Only)

## **NFC UID Type**

| Tag  | Len | Value / Description | Typ | Req | Default |
| ---- | --- | ------------------- | --- | --- | ------- |
| DF79 | var | NFC UID             | B   | R   |         |


# GPO Response Type (EMV Contactless Only)

## **NFC UID Type**

| Tag | Len | Value / Description | Typ | Req | Default |
| --- | --- | ------------------- | --- | --- | ------- |
| 81  | var | GPO Response        | B   | R   |         |


# MIFARE Card Data Type (EMV Contactless Only)

## **MIFARE Card Data Type**

<table><thead><tr><th width="119.54541015625">Tag</th><th width="71.63641357421875">Len</th><th>Value / Description</th><th width="74.45458984375">Typ</th><th width="80">Req</th><th width="104.09088134765625">Default</th></tr></thead><tbody><tr><td>DFDFDF40</td><td>var</td><td>MIFARE Card Data in ASCII terminated with NULL character</td><td>B</td><td>O</td><td></td></tr><tr><td>DFDFDF41</td><td>var</td><td>MIFARE Card Data in Binary</td><td></td><td>O</td><td></td></tr></tbody></table>


# TR-31 Key Block Type

A ***TR-31***(***X9.143***) key block consists of three parts:

The **Key Block Header**(KBH) which contains attribute information about the key and the key block and is not encrypted. It is always treated as ASCII.

* The first section is 16 bytes with a fixed format defined below.
* The second section is optional within the standard, but required for current products.

The **Confidential Data**, which is encrypted and always binary.

* Two bytes indicating the key length (in bits, AES-128 is 128 bits, so length will be 0080).
* The secret key and/or sensitive data.
* Padding as required (random bytes 0x00 to 0xFF).

The **MAC**, which is of varying length as follows:

* 64 bits if the TDEA key derivation method is used (typically not used for this device).
* 128 bits if the AES key derivation method is used.

<table><thead><tr><th width="96">Header</th><th width="112.6666259765625">Header (optional)</th><th>Key Length</th><th>Key</th><th>Key Padding</th><th>Block Padding</th><th>MAC</th></tr></thead><tbody><tr><td></td><td></td><td>&#x3C;-----------</td><td>Encrypted</td><td>--------------</td><td>------------></td><td></td></tr><tr><td>&#x3C;--------</td><td>------------</td><td>MAC</td><td>--------------</td><td>--------------</td><td>------------></td><td></td></tr></tbody></table>

Symmetric keys are padded with **Block Padding** to the maximum length for the algorithm, 192 bits for TDEA or 256 bits for AES, to hide the true length of short keys.

The data to be encrypted and the MAC are always binary for calculation purposes. The encrypted data and the MAC are converted to ASCII hex as the last step.

Date and time strings specified within the TR-31 block are represented according to the rules described in ***ISO 8601*** and ***TR-31***. Year is 4 digits. Time uses UTC 24 hour clock. Some functions like ‘toISOString()’ will produce a string of format **yyyy-mm-ddThh:mm:ss.fffZ**where fff is a decimal fraction of a second, Z is UTC time zone. The device ignores ‘Z’ and ‘.fff’ if they are present. Seconds ‘:ss’ are optional. Date, hours, and minutes are required. For example, March 23, 2020 4:19PM is encoded as **2020-03-23T16:19**at minimum, but could also be **2020-03-23T16:19:00.000Z**.

## **TR-31 Block Fixed Header**

<table><thead><tr><th width="93.66668701171875">Offset</th><th width="188.6666259765625">Name</th><th width="95">Fixed Value</th><th>Variable</th></tr></thead><tbody><tr><td>0</td><td>Key Block V ID</td><td>‘D’</td><td></td></tr><tr><td>1..4</td><td>Key Block Length</td><td></td><td>Calculated (in decimal, e.g. 138 bytes shown as ‘0138’</td></tr><tr><td>5..6</td><td>Usage</td><td></td><td>Look up the desired <strong>Key Type</strong> in <strong>Table TKB-2  below</strong> and select this value from the <strong>Usage</strong> column.</td></tr><tr><td>7</td><td>Algorithm</td><td></td><td>Look up the desired <strong>Key Type</strong> in <strong>Table TKB-2 below</strong> and select this value from the <strong>Algorithm</strong> column.</td></tr><tr><td>8</td><td>Mode of Use</td><td></td><td>Look up the desired <strong>Key Type</strong>in <strong>Table TKB-2 below</strong> and select this value from the <strong>Mode of Use</strong>column.</td></tr><tr><td>9..10</td><td>Key Version #</td><td>‘00’</td><td>Always ‘00’</td></tr><tr><td>11</td><td>Exportability</td><td>‘N’</td><td>Always no export allowed</td></tr><tr><td>12..13</td><td># option blocks</td><td></td><td>Calculated</td></tr><tr><td>14..15</td><td>Reserved</td><td>‘00’</td><td></td></tr></tbody></table>

## **TR-31 Key Type Table - Usage/Algorithm/Mode**

<table><thead><tr><th>Key Type</th><th width="105">Usage</th><th>Algorithm AES/TDEA</th><th>Mode of Use (Both, To, From)</th></tr></thead><tbody><tr><td>Transport (KBPK)</td><td>‘K1’</td><td>‘A’ / ‘T’</td><td>‘D’</td></tr><tr><td>Initial DUKPT Key</td><td>‘B1’</td><td>‘A’ / ‘T’</td><td>‘X’</td></tr><tr><td>Fixed MAC (CMAC)</td><td>‘M6’</td><td>‘A’ / ‘T’</td><td>(‘C’, ’G’, ’V’)</td></tr><tr><td>Fixed Encrypt</td><td>‘D0’</td><td>‘A’ / ‘T’</td><td>(‘B’, ‘E’, ‘D’)</td></tr></tbody></table>

## **TR-31 Optional Blocks**

<table><thead><tr><th width="88.66668701171875">ID</th><th>Purpose</th></tr></thead><tbody><tr><td>‘IK’</td><td>DUKPT KSID</td></tr><tr><td>‘KS’</td><td>Key Set Identifier (e.g. data used by host to find and/or derive this key).</td></tr><tr><td>‘KC’</td><td>Key Check Value (KCV) (Legacy or CMAC)</td></tr><tr><td>‘PB’</td><td>Padding Field</td></tr><tr><td>‘TS’</td><td>Current Time Stamp (optional) see description in previous section.</td></tr><tr><td>‘KP’</td><td>KCV of KBPK that created this Key Block (optional-preferred)</td></tr><tr><td>‘21’</td><td>MagTek Additional Key Info From <a href="https://magtek.gitbook.io/magtek-pilot-gitbooks/internal-documentation/index/4.0-data-types-and-shared-tlv-data-objects/4.20-tr-31-key-block-type#table-57-magtek-custom-tr-31-small-optional-block"><strong>Table  - MagTek Custom TR-31 Small Optional Block</strong></a></td></tr></tbody></table>

## **MagTek Custom TR-31 Small Optional Block**

<table><thead><tr><th width="88.33331298828125">Offset</th><th width="133.3333740234375">Name</th><th width="106.3333740234375">Value</th><th>Variable</th></tr></thead><tbody><tr><td>0.1</td><td>Block ID</td><td>'21'</td><td>MagTek Added Key Info Block</td></tr><tr><td>2..3</td><td>Block Length</td><td>var</td><td>ASCII Hex (Length 01-FF from offset 0)</td></tr><tr><td>4..7</td><td>Owner Tag</td><td>‘MGTK’</td><td>Avoid collision with others using Block ID ‘21’</td></tr><tr><td>8..9</td><td>Data Tag</td><td>‘10’</td><td>Field ID</td></tr><tr><td>10..11</td><td>Data Len</td><td>‘01’</td><td>Field Length (ASCII Hex 00-FF)</td></tr><tr><td>12</td><td>Data</td><td>‘T’,’P’, or ‘0’</td><td><p>Field Data for Key Environment</p><ul><li>T = Test</li><li>P = Production</li><li>0 = Erase Key</li></ul></td></tr><tr><td>13…</td><td>Added elements</td><td></td><td>More Fields (Tags, Lengths, and Data)</td></tr><tr><td></td><td></td><td></td><td></td></tr></tbody></table>

## **MagTek Custom Key Data Fields**

<table><thead><tr><th width="98.33331298828125">Field ID</th><th width="98">Length</th><th>Purpose</th></tr></thead><tbody><tr><td>‘10’</td><td>‘01’</td><td><p>Key Environment</p><ul><li>T = Test</li><li>P = Production</li><li>0 = Erase Key</li></ul></td></tr><tr><td>‘11’</td><td>‘04’</td><td>Key Slot ID See <strong>Table 59 - Key Slot ID</strong>.</td></tr><tr><td>‘12’</td><td>‘04’</td><td>Key Slot ID of Transport Key</td></tr><tr><td>‘20’</td><td>--</td><td>Reserved</td></tr><tr><td>‘21’</td><td>‘04’</td><td>DUKPT Data Type Restriction Bitmask This is for Transport Keys and DUKPT keys. Default to 0.</td></tr><tr><td>‘31’</td><td>‘07’</td><td>Device Serial Number</td></tr><tr><td>‘32’</td><td>‘10’</td><td>Challenge Token 10h = 16 characters</td></tr><tr><td>‘33’</td><td>‘10’ ..‘18’</td><td>Expiration Date/Time This is in UTC format, use short form if possible. Reserved.</td></tr></tbody></table>

## **Key Slot IDs - A**

<table><thead><tr><th width="79.66668701171875">ID</th><th width="104.3333740234375">Label</th><th>Description</th><th>Load Transport Key</th><th>TR31-F</th></tr></thead><tbody><tr><td>10xx</td><td></td><td>Transport Keys (KBPK)</td><td></td><td></td></tr><tr><td>1000</td><td>TMPTK</td><td>Temporary KBPK</td><td>Key agreement process from <strong>Command 0xF017 - Establish Ephemeral KBPK</strong></td><td>N/A</td></tr><tr><td>1001</td><td>MTK</td><td>Master Transport Key</td><td>TMPTK</td><td>K1AD</td></tr><tr><td>1002</td><td>DEVTK</td><td>Device Master Transport Key</td><td>MTK</td><td>K1AD</td></tr><tr><td>1003</td><td>FINTK</td><td>Financial Master Transport Key</td><td>MTK</td><td>K1AD</td></tr></tbody></table>

## **Key Slot IDs - B**

| ID               | Label             | Description                                            | Load Transport Key | TR31-F |
| ---------------- | ----------------- | ------------------------------------------------------ | ------------------ | ------ |
| 1021             | PRODTK            | (MAGTEK INTERNAL ONLY) Production Transport Key        | DEVTK              | K1AD   |
| 1022             | MFGTK             | (MAGTEK INTERNAL ONLY) Manufacturing Transport Key     | DEVTK              | K1AD   |
| 1081             | MKIFTK            | MagTek KIF Financial Transport Keys                    | FINTK              | K1AD   |
| 1101             | FREQMK            | Factory Request MAC Key                                | PRODTK             | M6AV   |
| 1102             | MREQMK            | Manufacturer Device Request MAC Key                    | MFGTK              | M6AV   |
| 1111             | MFRQMK            | Manufacturer Financial Request MAC (Configuration) Key | MKIFTK             | M6AV   |
| 0x2000 to 0x201F | DKPTM0 to DKPTM1F | DUKPT Initial Keys,                                    | MKIFTK             | B1TX   |

### DUKPT Key Mapping

#### Terms and Definitions&#x20;

**DUKPT** – Derived Unique Key Per Transaction **OID**– Object Identifier

**SRED**- Secure Reading and Exchange of Data

There are 7 new OIDs defined for these 7 SRED Data IDs.

Each OID value contains a two-byte DUKPT slot ID and a one-byte transformation ID.

## **SRED Data IDs and OIDs**

<table data-header-hidden><thead><tr><th></th><th width="211"></th><th width="140.6666259765625"></th></tr></thead><tbody><tr><td><strong>SRED Data ID</strong></td><td><strong>OID</strong></td><td><strong>OID Size</strong></td></tr><tr><td>0: Not assigned</td><td>N/A</td><td>N/A</td></tr><tr><td>1: PIN-TDES (supported on PED devices Only)</td><td>0x010102040101</td><td>3</td></tr><tr><td>2: Account Data</td><td>0x010102040102</td><td>3</td></tr><tr><td>3: MAC</td><td>0x010102040103</td><td>3</td></tr><tr><td>4: Magneprint (supported on devices with MSR Only)</td><td>0x010102040104</td><td>3</td></tr><tr><td>5: MagTek Token</td><td>0x010102040105</td><td>3</td></tr><tr><td>6: User Data 1</td><td>0x010102040106</td><td>3</td></tr><tr><td>7: PIN-AES (supported on PED devices Only)</td><td>0x010102040107</td><td>3</td></tr></tbody></table>

#### *DUKPT Slot IDs*

The existing TR31 Module supports 32 MagTek DUKPT Slot IDs, from 0x2000 to 0x201F. The Key Injection Software Tool shall inject DUKPT keys through these DUKPT Slot IDs.

#### *Transformation IDs*

This is the list of DUKPT transformations defined in both the Legacy and AES specifications.

### Restrictions of a DUKPT Slot ID

## **Transformation IDs for DUKPT Legacy and AES**

<table data-header-hidden><thead><tr><th></th><th></th><th width="124.33331298828125"></th><th></th></tr></thead><tbody><tr><td><strong>Transformation ID #</strong></td><td><strong>Usage Name</strong></td><td><strong>Type</strong></td><td><strong>Data for calculation</strong></td></tr><tr><td>0</td><td>Reserved</td><td></td><td></td></tr><tr><td>1</td><td>PIN Encryption</td><td>Legacy</td><td>00 00 00 00 00 00 00 FF</td></tr><tr><td>2</td><td>MAC Generate/Verify</td><td>Legacy</td><td>00 00 00 00 00 00 FF 00</td></tr><tr><td>3</td><td>MAC Verify</td><td>Legacy</td><td>00 00 00 00 FF 00 00 00</td></tr><tr><td>4</td><td>Data Enc/Decryption</td><td>Legacy</td><td>00 00 00 00 00 FF 00 00</td></tr><tr><td>5</td><td>Data Encryption</td><td>Legacy</td><td>00 00 00 FF 00 00 00 00</td></tr><tr><td>6</td><td>Reserved</td><td></td><td></td></tr><tr><td>7</td><td>PIN Encryption</td><td>AES</td><td>0x1000</td></tr><tr><td>8</td><td>MAC Generate</td><td>AES</td><td>0x2000</td></tr><tr><td>9</td><td>MAC Verify</td><td>AES</td><td>0x2001</td></tr><tr><td>A</td><td>MAC Generate/Verify</td><td>AES</td><td>0x2002</td></tr><tr><td>B</td><td>Data Encryption</td><td>AES</td><td>0x3000</td></tr><tr><td>C</td><td>Data Decryption</td><td>AES</td><td>0x3001</td></tr><tr><td>D</td><td>Data Enc/Decryption</td><td>AES</td><td>0x3002</td></tr></tbody></table>

## **The Definition of Restriction Bit Map**

| **Bit #**     | **5**           | **4**       | **3**      | **2** | **1**        | **0** |
| ------------- | --------------- | ----------- | ---------- | ----- | ------------ | ----- |
| **Data Type** | User Data (RFU) | Token (RFU) | Magneprint | MAC   | Account Data | PIN   |

During TR31 Key Injection, each DUKPT Slot ID contains a parameter indicates the purpose of a Key Set.&#x20;

Example 1: The restriction value is 0x3F

This Key Set can be used for all purposes.

Example 2: The restriction value is 0x3E

This Key Set can be used for all purposes, except PIN Encryption.

Example 3: The restriction value is 0x01

This Key Set can be used for PIN Encryption only.

### The Rules of Key Mapping

SRED Data ID map configuration values (Slot ID and Transformation ID) must be checked and rejected if they don’t meet the following conditions.

1. The DUKPT Slot ID must be loaded. [(**Table 63**)](https://magtek.gitbook.io/magtek-pilot-gitbooks/internal-documentation/index/4.0-data-types-and-shared-tlv-data-objects/4.20-tr-31-key-block-type#table-63-settings-of-injected-dukpt-slot-ids)
2. The loaded DUKPT Slot ID must allows this type of SRED Data ID. [**(Table 62)**](https://magtek.gitbook.io/magtek-pilot-gitbooks/internal-documentation/index/4.0-data-types-and-shared-tlv-data-objects/4.20-tr-31-key-block-type#table-62-the-definition-of-restriction-bit-map)
3. The transformation must be allowed by [(**Table 64)**](https://magtek.gitbook.io/magtek-pilot-gitbooks/internal-documentation/index/4.0-data-types-and-shared-tlv-data-objects/4.20-tr-31-key-block-type#table-64-allowed-key-mapping-table).

### The settings of DUKPT Slot IDs injected through TR31

Here is the list of parameters of 4 DUKPT Slot IDs based on the existing Key Injection Tool.

## **Settings of Injected DUKPT Slot IDs**

| DUKPT Slot ID | Key Type | Restrictions |
| ------------- | -------- | ------------ |
| DKPTM0-2000   | TDES     | 0x3E         |
| DKPTM2-2002   | AES-128  | 0x3F         |
| DKPTM3-2003   | AES-256  | 0x3F         |
| DKPTM7-2007   | TDES     | 0x3F         |

## **Allowed Key Mapping Table**

<table><thead><tr><th width="120.3333740234375">SRED Data ID</th><th>Data Type (Working Key Purpose)</th><th>Allowed Legacy DUKPT Transforms</th><th>Allowed AES DUKPT Transforms</th></tr></thead><tbody><tr><td>0</td><td>Not assigned</td><td>-</td><td>-</td></tr><tr><td>1</td><td>PIN-TDES (supported on PED devices Only)</td><td>01</td><td>Not allowed</td></tr><tr><td>2</td><td>Account Data</td><td>01, 04, 05</td><td>0B, 0D</td></tr><tr><td>3</td><td>Transaction MAC</td><td>02</td><td>08, 0A</td></tr><tr><td>4</td><td>MagnePrint (supported on devices with MSR Only)</td><td>01, 04, 05</td><td>0B, 0D</td></tr><tr><td>5</td><td>MagTek Token (RFU)</td><td>RFU</td><td>RFU</td></tr><tr><td>6</td><td>User Data #1 (RFU)</td><td>RFU</td><td>RFU</td></tr><tr><td>7</td><td>PIN-AES (supported on PED devices Only)</td><td>Not allowed</td><td>07</td></tr><tr><td>…</td><td>RFU</td><td>-</td><td>-</td></tr></tbody></table>

Note: If SRED Data ID 2 and 4 are mapped to the same Key Set, then they must have the same Transformation ID. If the Transformation ID of the latest key mapping request is different, then the original OID setting of the other SRED Data ID will be forced to match the latest OID setting. For example, SRED Data ID 2 has been mapped to 0x2007 0x04, user wants to map SRED Data ID 4 to 0x2007 0x05, then the OID setting of SRED Data ID 2 will be forced to 0x2007 0x05.

## Examples of Key Mapping

The following OID Values indicate that:

1. 200701: Map PIN-TDES to DKPTM7-2007 PIN Encryption Variant.
2. 20020B: Map Account Data to DKPTM2-2002 Data Encryption Usage.
3. 200702: Map MAC to DKPTM7-2007 MAC Generate/Verify Variant.
4. 20030B: Map MangePrint to DKPTM3-2003 Data Encryption Usage.
5. 000004: MagTek Token is RFU, 0000 ID does not exist (this is default value).
6. 000004: User Data is RFU, 0000 ID does not exist (this is default value).
7. 200207: Map PIN-AES to DKPTM2-2002 PIN Encryption Usage.

![Graphical user interface, text, application, email Description automatically generated](/files/cd34eea35938efd25b1a091b1914c5d4dbaca342)

<p align="center"><strong>Figure 1 - Configuration Usage Values</strong></p>


# DUKPT Key Mapping

## **Terms and Definitions**

* DUKPT – Derived Unique Key Per Transaction
* OID – Object Identifier
* SRED - Secure Reading and Exchange of Data

There are 7 OIDs defined for these 7 SRED Data IDs.

Each OID value contains a two-byte DUKPT slot ID and a one-byte transformation ID.

## SRED Data IDs and OIDs

<table data-header-hidden><thead><tr><th></th><th width="184.6363525390625"></th><th width="104.54541015625"></th></tr></thead><tbody><tr><td>SRED Data ID</td><td>OID</td><td>OID Size</td></tr><tr><td>0: Not assigned</td><td>N/A</td><td>N/A</td></tr><tr><td>1: PIN-TDES (supported on PED devices Only)</td><td>0x010102040101</td><td>3</td></tr><tr><td>2: Account Data</td><td>0x010102040102</td><td>3</td></tr><tr><td>3: MAC</td><td>0x010102040103</td><td>3</td></tr><tr><td>4: Magneprint (supported on devices with MSR Only)</td><td>0x010102040104</td><td>3</td></tr><tr><td>5: MagTek Token</td><td>0x010102040105</td><td>3</td></tr><tr><td>6: User Data 1</td><td>0x010102040106</td><td>3</td></tr><tr><td>7: PIN-AES (supported on PED devices Only)</td><td>0x010102040107</td><td>3</td></tr></tbody></table>

**DUKPT Slot IDs**

The existing TR31 Module supports 32 MagTek DUKPT Slot IDs, from 0x2000 to 0x201F.

The Key Injection Software Tool shall inject DUKPT keys through these DUKPT Slot IDs.

**Transformation IDs**

This is the list of DUKPT transformations defined in both the Legacy and AES specifications.

## Restrictions of a DUKPT Slot ID <a href="#toc195691465" id="toc195691465"></a>

## Transformation IDs for DUKPT Legacy and AES

<table data-header-hidden><thead><tr><th width="146.0909423828125"></th><th width="203.63641357421875"></th><th width="92.1817626953125"></th><th></th></tr></thead><tbody><tr><td><p>Transformation</p><p>ID #</p></td><td>Usage Name</td><td>Type</td><td>Data for calculation</td></tr><tr><td>0</td><td>Reserved</td><td> </td><td> </td></tr><tr><td>1</td><td>PIN Encryption</td><td>Legacy</td><td>00 00 00 00 00 00 00 FF</td></tr><tr><td>2</td><td>MAC Generate/Verify</td><td>Legacy</td><td>00 00 00 00 00 00 FF 00</td></tr><tr><td>3</td><td>MAC Verify</td><td>Legacy</td><td>00 00 00 00 FF 00 00 00</td></tr><tr><td>4</td><td>Data Enc/Decryption</td><td>Legacy</td><td>00 00 00 00 00 FF 00 00</td></tr><tr><td>5</td><td>Data Encryption</td><td>Legacy</td><td>00 00 00 FF 00 00 00 00</td></tr><tr><td>6</td><td>Reserved</td><td> </td><td> </td></tr><tr><td>7</td><td>PIN Encryption</td><td>AES</td><td>0x1000</td></tr><tr><td>8</td><td>MAC Generate</td><td>AES</td><td>0x2000</td></tr><tr><td>9</td><td>MAC Verify</td><td>AES</td><td>0x2001</td></tr><tr><td>A</td><td>MAC Generate/Verify</td><td>AES</td><td>0x2002</td></tr><tr><td>B</td><td>Data Encryption</td><td>AES</td><td>0x3000</td></tr><tr><td>C</td><td>Data Decryption</td><td>AES</td><td>0x3001</td></tr><tr><td>D</td><td>Data Enc/Decryption</td><td>AES</td><td>0x3002</td></tr></tbody></table>

## The Definition of Restriction Bitmap

<table data-header-hidden><thead><tr><th width="71.18182373046875"></th><th width="73.90911865234375"></th><th width="73.45458984375"></th><th width="113.4544677734375"></th><th width="67.0909423828125"></th><th width="92.54541015625"></th><th width="147.272705078125"></th></tr></thead><tbody><tr><td>Bit #</td><td>5</td><td>4</td><td>3</td><td>2</td><td>1</td><td>0</td></tr><tr><td>Data Type</td><td><p>User Data</p><p>(RFU)</p></td><td><p>Token</p><p>(RFU)</p></td><td>Magneprint</td><td>MAC</td><td>Account Data</td><td>PIN</td></tr></tbody></table>

During TR31 Key Injection, each DUKPT Slot ID contains a parameter indicates the purpose of a Key Set.

* Example 1:  The restriction value is 0x3F
  * This Key Set can be used for all purposes.
* Example 2:  The restriction value is 0x3E
  * This Key Set can be used for all purposes, except PIN Encryption.
* Example 3:  The restriction value is 0x01
  * This Key Set can be used for PIN Encryption only.

## The Rules of Key Mapping <a href="#toc195691466" id="toc195691466"></a>

SRED Data ID map configuration values (Slot ID and Transformation ID) must be checked and rejected if they don’t meet the following conditions.

* The DUKPT Slot ID must be loaded. (Table - Settings of Injected DUKPT Slot IDs)
* The loaded DUKPT Slot ID must allows this type of SRED Data ID. (Table - The Definition of Restriction Bitmap).&#x20;
* The transformation must be allowed by Table - Allowed Key Mapping Table.

## The settings of DUKPT Slot IDs injected through TR31 <a href="#toc195691467" id="toc195691467"></a>

Here is the list of parameters of 4 DUKPT Slot IDs based on the existing Key Injection Tool.

## Settings of Injected DUKPT Slot IDs

<table data-header-hidden><thead><tr><th width="168.0909423828125"></th><th width="131.72735595703125"></th><th></th></tr></thead><tbody><tr><td>DUKPT Slot ID</td><td>Key Type</td><td>Restrictions</td></tr><tr><td>DKPTM0-2000</td><td>TDES</td><td>0x3E</td></tr><tr><td>DKPTM2-2002</td><td>AES-128</td><td>0x3F</td></tr><tr><td>DKPTM3-2003</td><td>AES-256</td><td>0x3F</td></tr><tr><td>DKPTM7-2007</td><td>TDES</td><td>0x3F</td></tr></tbody></table>

## Allowed Key Mapping Table

<table data-header-hidden><thead><tr><th width="73.3636474609375"></th><th></th><th width="145.8182373046875"></th><th width="147.54541015625"></th></tr></thead><tbody><tr><td><p>SRED</p><p>Data ID</p></td><td><p>Data Type</p><p>(Working Key Purpose)</p></td><td><p>Allowed Legacy</p><p>DUKPT</p><p>Transforms</p></td><td><p>Allowed AES</p><p>DUKPT</p><p>Transforms</p></td></tr><tr><td>0</td><td>Not assigned</td><td>-</td><td>-</td></tr><tr><td>1</td><td>PIN-TDES (supported on PED devices Only)</td><td>01</td><td>Not allowed</td></tr><tr><td>2</td><td>Account Data</td><td>01, 04, 05</td><td>0B, 0D</td></tr><tr><td>3</td><td>Transaction MAC</td><td>02</td><td>08, 0A</td></tr><tr><td>4</td><td>MagnePrint (supported on devices with MSR Only)</td><td>01, 04, 05</td><td>0B, 0D</td></tr><tr><td>5</td><td>MagTek Token (RFU)</td><td>RFU</td><td>RFU</td></tr><tr><td>6</td><td>User Data #1 (RFU)</td><td>RFU</td><td>RFU</td></tr><tr><td>7</td><td>PIN-AES (supported on PED devices Only)</td><td>Not allowed</td><td>07</td></tr><tr><td>…</td><td>RFU</td><td>-</td><td>-</td></tr></tbody></table>

{% hint style="info" %}
**Note**: If SRED Data ID 2 and 4 are mapped to the same Key Set, then they must have the same Transformation ID.
{% endhint %}

If the Transformation ID of the latest key mapping request is different, then the original OID setting of the other SRED Data ID will be forced to match the latest OID setting. For example, SRED Data ID 2 has been mapped to 0x2007 0x04, user wants to map SRED Data ID 4 to 0x2007 0x05, then the OID setting of SRED Data ID 2 will be forced to 0x2007 0x05.

## **Examples of Key Mapping**

The following OID Values indicate that:

* 200701:  Map PIN-TDES to DKPTM7-2007 PIN Encryption Variant.
* 20020B:  Map Account Data to DKPTM2-2002 Data Encryption Usage.
* 200702:  Map MAC to DKPTM7-2007 MAC Generate/Verify Variant.
* 20030B:  Map MangePrint to DKPTM3-2003 Data Encryption Usage.
* 000004:  MagTek Token is RFU, 0000 ID does not exist (this is default value).
* 000004:  User Data is RFU, 0000 ID does not exist (this is default value).
* 200207:  Map PIN-AES to DKPTM2-2002 PIN Encryption Usage.

<p align="center"> <img src="/files/b2LVGpFKaMhAknGQRytT" alt=""></p>

<p align="center"><strong>Figure 1 - Configuration Usage Values</strong></p>


# Miniature Certificate Type

## **Miniature Certificate Type**

<table><thead><tr><th>Tag</th><th width="77.33331298828125">Len</th><th>Value / Description</th><th width="76.66668701171875">Typ</th><th width="81.3333740234375">Req</th><th>Example</th></tr></thead><tbody><tr><td><strong>FF01</strong>= Start Of Miniature Certificate Marker</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>81</td><td>08</td><td>Miniature Certificate Info and ID</td><td>B</td><td>R</td><td>81 08 50 01 01 00 C2 C2 C2 C2</td></tr><tr><td>83</td><td>02</td><td>Public Key Info</td><td>B</td><td>R</td><td>83 02 10 04</td></tr><tr><td>84</td><td>40</td><td>Public Key, 64 bytes for ECDSA Curve P-256</td><td>B</td><td>R</td><td>84 40 then 64 bytes</td></tr><tr><td>86</td><td>00</td><td>Reserved for RSA cipher</td><td>B</td><td>O</td><td>86 00</td></tr><tr><td>90</td><td>04</td><td>Signing Miniature Certificate ID Signed by Base Miniature Certificate</td><td>B</td><td>R</td><td>90 04 CA CA CA CA</td></tr><tr><td>91</td><td>01</td><td>Signing Algorithm SHA-256, ECDSA Curve P-256</td><td>B</td><td>R</td><td>91 01 01</td></tr><tr><td>9E</td><td>40</td><td>Signature (64 bytes for ECDSA P-256)</td><td>B</td><td>R</td><td>9E 40 then 64 bytes</td></tr><tr><td>Padding Pad with 0xCA to make the total length of the data object 512 bytes.</td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>


# Common File Structure

Some files types conform to the common file structure format that follows.\
The following is a list of file types that conform to this format.

1. EMV file types
2. Certificate File Types
3. Certificate Signing Request (CSR) File Types

## **Common File Structure**

<table><thead><tr><th>Tag</th><th width="78.66668701171875">Len</th><th>Value / Description</th><th width="73">Typ</th><th width="79.6666259765625">Req</th><th>Default</th></tr></thead><tbody><tr><td><strong>MGTKAP10</strong>= Start Of File Marker</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>C1</td><td>4</td><td>File Type See Table 206</td><td>B</td><td>R</td><td>N/A</td></tr><tr><td>CE</td><td>var</td><td>File Payload See the “File Type” subsections of section -  <strong>Data Types andShared TLV Data Objects</strong>.</td><td>B</td><td>R</td><td>N/A</td></tr></tbody></table>


# Certificate File Types

These file types conform to the **Common File Structure** format. The File Payload of these files contain a certificate in PEM format.

Certificates must be loaded into the device in the order of trust starting with the root CA, next intermediate CA(s) and ending with the leaf (server or client for example) so that the device can verify the signature of each certificate. If the certificates are not loaded in order, they will be rejected.

When loading a server cert, the associated key pair must already exist in the device as the CSR keys or as the existing server or client cert and will be used to verify that the public key contained in the certificate is correct. If the keys don’t match the certificate will be rejected. If the certificate is associated with the CSR keys, the CSR keys will be associated with the certificate and will no longer be available for other certificates until re-generated.

Initial server or client certificates can not be loaded until the respective CSR keys and CSR is generated. To generate a CSR see **Generate CSR (WLAN Only) - Command 0xEF03**.


# Certificate Signing Request (CSR) File Types

These file types conform to the **Common File Structure** format.

The File Payload of these files contain a certificate signing request in PEM format. To generate a CSR see **Generate CSR (WLAN Only) - Command 0xEF03**.

The device will erase the CSR file from volatile memory after the host fetches it with **Command 0xD821.**

**- Start Get File from Device**. After fetching the CSR, the keys used to generate the CSR will still exist in non-volatile memory associated with a CSR and can be used to generate a new CSR if needed.


# Card Emulation

### Card Emulation Overview

Card emulation enables a DynaFlex/DynaProx device to simulate a Type 4 smart card. The emulated card has the following characteristics:

* Compliance: Card emulation conforms to ISO/IEC 14443 Type-A and NFC Forum Type 4 standards.
* Passive Operation: The emulated card functions in passive mode. The phone is responsible for generating the magnetic field required to activate the simulated card.
* Read-Only: The emulated card is read-only and does not support writing.
* Supported Data Type: Supports the URI (URL) data type.

### Device Compatibility

* iPhone Support: NFC card reading was introduced on Apple iPhones starting with the iPhone 7.
* Android Support: Android added NFC support in 2012; however, compatibility depends on the specific phone model and hardware capabilities. Most Android phones released since 2016 support NFC. Verify with the phone’s manufacturer to confirm compatibility.

Google Pay Indicator: If a phone supports Google Pay, it is likely capable of reading NFC tags.


# Commands

## Commands

The DynaFamily card readers accept the Multi-Interface Card Reader Platform (MMS) command set — the messages you send to run transactions, read cards, drive the display and prompts, manage keys and files, and query or configure the reader. Full syntax, parameters, responses, and examples are maintained in the shared reference.

{% hint style="success" %}
Applies to: All Dyna Family products
{% endhint %}

### Information in this group

| **Section**                                                                                                                                                                                                           | **Information**                                                                                                                                                                                                                                              |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [<mark style="color:red;">**Transactions**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/transactions-command-group-0x10nn)                                                          | Start, resume, and cancel EMV, contactless, and magnetic-stripe payment transactions. This is the core command group for running a sale or authorization on the device.                                                                                      |
| [<mark style="color:red;">**NFC/MIFARE Pass-Through Commands**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/nfc-mifare-pass-through-commands-contactless-only-command-group-0x11nn) | Send native card commands to read and write NFC tags and MIFARE cards (Ultralight, Classic, Plus, DESFire). Used for non-payment contactless applications such as loyalty, access, and ticketing. (Contactless Only)                                         |
| [<mark style="color:red;">**User Interface**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn)                                                      | Control the device's cardholder- and operator-facing features: prompts and messages, LEDs, the buzzer, barcode scanning, personal-info entry, and card emulation. Use these to guide the user through a transaction and capture input.                       |
| [<mark style="color:red;">**Device Control**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/device-control-command-group-0x1fnn)                                                      | Manage the device's operational and connection state: reset the device, set notification subscriptions, and manage Bluetooth LE sessions and bonds. These govern how the device runs and communicates rather than how it processes cards.                    |
| [<mark style="color:red;">**Banking Functions**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/banking-functions-touch-display-only-command-group-0x20nn)                             | Prompt the cardholder for a PIN and generate the encrypted PIN block for online-PIN debit and banking, using host-supplied or card-supplied account data. Available only on devices with a PIN-entry surface. (Touch/Display Only)                           |
| [<mark style="color:red;">**Generic Pass-Through Commands**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/generic-pass-through-commands-command-group-0x30nn)                        | Open a direct channel to a contactless card and exchange raw ISO 14443-4 APDUs, with control over card polling. Use this for custom or proprietary contactless schemes not covered by the dedicated command groups.                                          |
| [<mark style="color:red;">**Settings and Information**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/settings-and-information-command-group-0xd1nn)                                  | Read and change the device's configuration by getting and setting individual properties, in both secured and unsecured forms. This is how you query device state and adjust its behavior.                                                                    |
| [<mark style="color:red;">**File Operations**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/file-operations-command-group-0xd8nn)                                                    | Transfer files to and from the device: send firmware, configuration, and certificate files, retrieve them, query file info, and delete them. Handles moving files; applying them is covered under Process Files.                                             |
| [<mark style="color:red;">**Process Files**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/process-files-command-group-0xd9nn)                                                        | Act on files already loaded onto the device, such as committing a transferred firmware file to activate it. These commands complete operations that begin as a transfer in File Operations.                                                                  |
| [<mark style="color:red;">**Diagnostics and Utilities**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/diagnostics-and-utilities-command-group-0xdfnn)                                | General-purpose troubleshooting utilities, such as Echo to verify host-to-device communication. Use these to test connectivity and confirm the device is responding.                                                                                         |
| [<mark style="color:red;">**Security**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/security-command-group-0xennn)                                                                  | Perform cryptographic and device-security operations: challenge/response authentication, sending secured commands, loading keys via TR-31, retrieving key information, and managing the device lock. These establish and maintain the device's secure state. |
| [<mark style="color:red;">**Manufacturing**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/manufacturing-command-group-0xfnnn)                                                        | Provisioning and production-time operations, such as establishing an ephemeral key block protection key (KBPK) for secure key injection. Typically used during manufacturing and key loading rather than day-to-day integration.                             |

### See Also

* <mark style="color:red;">​</mark>[<mark style="color:red;">**Messages**</mark>](https://app.gitbook.com/o/M1bZIjbUULXeTfuFxR7G/s/EX5FnWhqBiMGA8wVt4Kn/messages-requests-responses-notifications-and-files) **-->** The basics on messages, what they are, and how they work.
* [<mark style="color:red;">**Notifications**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/notifications) **-->** Information *on notices your device my send and the circumstances under which they send them.*&#x20;
* [*<mark style="color:red;">**Configurations**</mark>*](/api-and-command-reference/scra-dynafamily-programmers-manual/properties) ***-->** Information of configuring your devices in various ways.*


# Transactions - Command Group 0x10nn

## Transactions

This section of the DynaFamily Programmer's Manual lists available commands to initiate various ransactions in the device.

{% hint style="success" %}
Applies to: All Dyna Family products
{% endhint %}

### Information in this group

| **Section**                                                                                                                                                                                          | **Information**                                                                                                                  |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| [<mark style="color:red;">**Start Transaction**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/transactions-command-group-0x10nn/command-0x1001-start-transaction)   | The host uses this command to start a payment transaction.                                                                       |
| [<mark style="color:red;">**Resume Transaction**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/transactions-command-group-0x10nn/resume-transaction-command-0x1004) | The host uses this command to provide the device with additional/modified data to resume a transaction that is currently paused. |
| [<mark style="color:red;">**Cancel Transaction**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/transactions-command-group-0x10nn/cancel-transaction-command-0x1008) | The host can use this command to cancel a transaction in progress that it initiated using Start Transaction.                     |

### Need More Help

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** [support@magtek.com](mailto:support@magtek.com?subject=Support%20Request)
* 📞 **Phone:** 1-562-546-6800 (US)
* 🕐 **Hours:** Monday-Friday, 5:30 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Support Portal:** developer.magtek.com

**Documentation Feedback:**

Help us improve this documentation! [feedback@magtek.com](mailto:feedback@magtek.com?subject=Feedback)
{% endhint %}


# Command 0x1001 - Start Transaction

The host uses this command to start a payment transaction.

The sequence of events for transactions with card readers enabled is roughly as follows.

{% stepper %}
{% step %}

### Initial conditions / Pre-start

* (MCE Only) The sequence for Manual Entry Mode is provided further below.
* If the device is configured to enable user action event notifications using <mark style="color:red;">**Property 1.2.7.1.2.1 - User Event Notification Controls Enable**</mark>, the cardholder may present a card or payment device before the host calls this command. In that case the device sends Device Information Update - Notification 0x1001 to the host to indicate it should call this command to start a transaction.
  * (MSR Only) If the cardholder swiped before the transaction started, the device temporarily stores the card swipe data for the period specified by User Event Notification MSR Data Timeout (MSR Only) - Property 1.2.7.1.2.2 to make it available during the transaction. Later, when the device would ordinarily prompt the cardholder to swipe/insert/tap, the device briefly shows the same prompt and then proceeds automatically using the stored card data.
  * (EMV Contact Only | EMV Contactless Only) If the cardholder inserted or tapped before the transaction started, the host should call this command as quickly as possible while the card is still in the slot or within tap range. The device does not begin contact or contactless reads until the host invokes this command and does not store any data from the pre-start action.
    {% endstep %}

{% step %}

### Host sends Start Transaction

* The host composes a command request in the format defined for Command 0x1001 and sends it to the device.
* The host may cancel the transaction in process by calling Cancel Transaction - Command 0x1008.
  {% endstep %}

{% step %}

### Device response and waiting for cardholder

* The device sends a response to the host and waits for the cardholder to present payment using one of the enabled payment technologies.
  {% endstep %}

{% step %}

### BCR (Barcode) flow

* (BCR Only) If the cardholder scans a barcode, the device sends Transaction Information Update - Notification 0x0101 to report Barcode / Barcode Event / Type / Data Attached with the barcode data attached and terminates the transaction.
  {% endstep %}

{% step %}

### Card presented event

* After the cardholder presents payment, the device sends Notification 0x0101 - Transaction Information Update to report the payment technology being used / Card Event.
* (MSR Only) If Device-Driven Fallback Behavior (MSR Only) - Property 1.2.1.1.1.1 is configured so the device automatically performs fallback operations, it performs them at this time (device-driven fallback occurs within one iteration of this command).
  {% endstep %}

{% step %}

### EMV contact — application selection

* (EMV Contact Only) If the cardholder inserted a chip card and there is more than one application the device and card mutually support:
  * (Display Only) The device prompts the cardholder to select the application to use.
  * (No Display Only) The device sends User Interface Host Action Request - Notification 0x1803 to report Cardholder Selection Request / Notification Payload. The host should show the prompt, receive input from the cardholder, and call Report Cardholder Selection - Command 0x1802 to report the selection result to the device.
    {% endstep %}

{% step %}

### Device reports ARQC / Data update

* The device sends Transaction Information Update - Notification 0x0101 to report the payment technology being used / Data Update / ARQC Update / Data Attached.
  {% endstep %}

{% step %}

### Quick Chip Transaction Flow (if specified by host)

* If the host specified Quick Chip Transaction Flow in the Transaction Flow parameter:
  * The device immediately constructs its own internal ARPC Response (with tag 8A set to 'Z3') and sends Transaction Operation Complete - Notification 0x0105 to report the payment technology being used / Kernel Outcome / Quick Chip Deferred / outcome detail. A Transaction Option parameter can be set to display on amount or not.
  * The device notifies the cardholder that the card can be removed:
    * (Display Only) The device shows the message "REMOVE CARD".
    * (No Display Only) The device sends User Interface Host Action Request - Notification 0x1803 to report Display / Display Message / Data Attached with message to notify the cardholder the card can be removed.
  * The host should then process the ARQC message data, replace the default amount with the final transaction amount as needed, and coordinate with the transaction processor to retrieve a final transaction result. Because the device is not involved in determining the final transaction result, it does not send a notification to the host to show APPROVED or DECLINED.
    * (Display Only) The host should call Display Message (Display Only) - Command 0x1803  to show APPROVED or DECLINED based on the final transaction result.
    * (No Display Only) The host should use its local display to show the appropriate APPROVED or DECLINED message to the cardholder.
      {% endstep %}

{% step %}

### EMV Transaction Flow (if specified by host)

* If the host specified EMV Transaction Flow in the Transaction Flow parameter:
  * The host processes the ARQC message data and uses it to coordinate with the transaction processor to receive an ARPC Response, which it processes and sends to the device using Resume Transaction - Command 0x1004.
  * The device waits up to the period specified in ARPC Receive Timeout - Property 1.1.1.1.1.5. If an ARPC timeout occurs, the device will send the ARQC again based on ARPC Retry Attempts - Property 1.1.1.1.1.6 .
  * (EMV Contact Only) If the cardholder inserted a contact chip card, the device communicates with the card to determine whether to approve or decline the transaction.
  * The device sends Transaction Operation Complete - Notification 0x0105  to report the payment technology being used / Kernel Outcome / Approved or Declined / outcome.
    * (Display Only) The device shows the transaction result to notify the cardholder (APPROVED or DECLINED).
    * (No Display Only) The device sends User Interface Host Action Request - Notification 0x1803 to report Display / Display Message / Data Attached with the message to notify the cardholder of the transaction result.
      {% endstep %}

{% step %}

### Signature capture

* (Touch Only) If the card requires a signature and Signature Capture Control - Property 1.2.1.1.2.1 is set to Device-driven Signature Capture (and if Signature Capture Control (MSR Only) command parameter does not apply), the device prompts the cardholder to sign.
* The device sends Transaction Information Update - Notification 0x0101 to report the payment technology used / Data Update / Batch Data / Data Attached. (Touch Only) Depending on Include Signature Data in EMV Batch Data (Touch Only) - Property 1.2.1.1.2.2 the device includes any acquired signature data with the batch data.
  {% endstep %}

{% step %}

### Transaction completion

* The device sends Transaction Operation Complete - Notification 0x0105  to report the payment technology used / Outcome / the final result of the transaction.
* (MSR Only) If Device-Driven Fallback Behavior (MSR Only) - Property 1.2.1.1.1.1 is configured so the device does not perform fallback operations, and if the solution design requires payment brand fallback logic, the host may implement fallback flow using the contents of notifications above. The rules below mimic automatic fallback; the primary difference is the host must track its own final Fallback Indicator instead of receiving it from the device in the EMV ARQC Type.
  * If the transaction was successful and notification indicates Payment Technology is EMV Contact or EMV Contactless: no fallback required.
  * If successful and notification indicates Payment Technology is Magnetic Stripe Reader:
    * Check Card Type (tag DFDF52 in EMV ARQC Type):
      * If Card Type is NOT "MSR Financial and Contact Chip Card (ICC)", continue with the current transaction using magnetic stripe data.
      * If Card Type is "MSR Financial and Contact Chip Card (ICC)" and the host has restarted the same transaction because a previous attempt failed with notification indicating MSR Fallback, the chip card and device already communicated and determined they are not compatible — the host may continue current transaction using magnetic stripe data.
      * If Card Type is "MSR Financial and Contact Chip Card (ICC)" and the host has NOT restarted the same transaction three times and failed with notification indicating Technical Fallback, the host should guide the cardholder to use the chip reader: send Display Message - Command 0x1803 to display "USE CHIP READER", then repeat Start Transaction - Command 0x1001 and arm the device with contact interface enabled (optionally arm contactless).
      * If Card Type is "MSR Financial and Contact Chip Card (ICC)" and the host has restarted the same transaction three times and failed with notification indicating Technical Fallback, the host may continue current transaction using magnetic stripe data.
  * If the transaction failed and notification indicates Payment Technology is None: something failed at the very beginning (e.g., host canceled). The host may end attempts or repeat the original transaction with the same payment technologies enabled.
  * If the transaction failed and notification indicates Payment Technology is EMV Contact:
    * If notification indicates MSR Fallback: the chip card and the device have determined they are not compatible. The host should guide the cardholder to use the magnetic stripe interface by sending - Command 0x1803, then repeat Start Transaction - Command 0x1001 and arm the device with MSR interface enabled (optionally arm contactless).
    * If the host has NOT restarted the same transaction three times and failed with notification indicating a Technical Fallback: the host should guide the cardholder to re-insert the chip card by sending Command 0x1803 - to display "AGAIN", then repeat Start Transaction - Command 0x1001 and arm the device with the contact interface enabled (optionally arm contactless).
    * If the host has restarted the same transaction three times and failed with notification reporting Technical Fallback: guide the cardholder to use the magnetic stripe reader by sending Display Message to display "MAGSTRIPE" - Command 0x1803, then repeat Start Transaction - Command 0x1001 and arm the device with MSR interface enabled (optionally arm contactless).
      {% endstep %}

{% step %}

### Host-driven signature capture (Touch Only)

* If Signature Capture Control - Property 1.2.1.1.2.1 is set to Host-driven Signature Capture and the card requires a signature, the host should perform host-driven signature capture at this time.
* The device waits for the time specified by Signature Timing Window (Touch Only) - Property 1.2.1.1.2.3, providing a window for the host to end the transaction by sending Request Cardholder Signature - Command 0x1801. If the host does not call that command before the window ends, the device returns to idle.
  {% endstep %}

{% step %}

### EMV Contactless / NFC Tag (EMV Contactless Only)

* For NFC Tag:
  * Use Start Transaction command with NFC enabled in Contactless Reader Mode.
  * If an NFC Tag is detected:
    1. The terminal sends a notification that identifies the NFC card type (Transaction Information Update - Notification 0x0101).
    2. The terminal sends another notification with the UID as payload (see Table 314 - Notification Payload for Data Update, ARQC Update (Quick Chip), Data Attached). If a card is configured with a random ID, its value will change each detection; the host is responsible to retrieve the real UID.
  * No ARQC or BATCH data will be sent for NFC Tag interactions.
  * The host application can continue interfacing with the NFC tag by sending pass-through commands.
    * When the NFC Tag leaves the field, the terminal sends 20 05 00 00 (PICC, NFC Tag, Tag Removed, Reserved) - Notification 0x0105 indicating the tag has been removed.
      {% endstep %}

{% step %}

### MCE (Manual Card Entry) flow

* (MCE Only) For manual card entry:
  * The host composes a command request with Manual Entry Mode parameters defined and other reader modes empty and sends it to the device. The host may cancel the transaction by calling Cancel Transaction - Command 0x1008.
  * The device creates Track 1 and Track 2 data based on entered values.
  * The device sends instances of Transaction Information Update - Notification 0x0101 to report each of the following:
    1. Manual Card Entry, Card Event, Data Entered, Reserved
    2. Manual Card Entry, Data Update, ARQC Update, Data Attached
    3. Manual Card Entry, Data Update, Batch Update, Data Attached
  * The device sends Transaction Operation Complete - Notification 0x0105 to report Manual Card Entry, Transaction Completed, Reserved, Reserved.
    {% endstep %}
    {% endstepper %}

### Tip Feature (Touch Only)

Tip operations have multiple use cases and modes.

{% stepper %}
{% step %}

#### Tip Operation Use Case Mode 1A

* Use Tag A4 for Tip and Tax Options.
* Use Byte 1 of Tag 81 under A4 to specify Tip mode:
  * 0x01 = Use % mode
  * 0x02 = Use Amount mode
* Bytes 2 through 31 of Tag 81 specify the % or $ values to show for Buttons 1 thru 6. There is a button mode to control whether the button will show $/%, CUSTOM, NO TIP, or is disabled.
* Tag 82 is the Tax Amount to display.
* DF5D = Tip Amount, DF5E = Tax Amount are used for reporting back to the host application.
* If available, tags DF5D and DF5E will be sent in the ARQC Data (see Table 19 - EMV ARQC (DynaPro Format) Type).
* The value of Tag 9F02 provided in command 0x1001 will be updated by the Device by adding TIP and TAX before passing that value to the kernels.
* See Tip & Tax Display Limits (Touch Only) for display limitations.
  {% endstep %}

{% step %}

#### Tip Operation Use Case Mode 1B

* If Interac Contact Card Terminal Capability - Property 1.1.1.1.1.1  ONLINE PIN Support Disable is Enabled, and there is a socket connection with the host, the device will show the START SALE button.
  * When the cardholder touches the button, the device will automatically start a START SALE transaction by asking the cardholder to enter the transaction amount. The device will show the CUSTOM AMOUNT screen. Press ENTER to set transaction amount. The Start Transaction ENTER parameters are taken from the settings of these properties.
    {% endstep %}
    {% endstepper %}

#### Relevant properties (Touch Only)

* Tip Mode (Touch Only) - Property 1.1.1.1.2.2&#x20;
  * Tip Mode Enable Submit on Amount Button Press - Property 1.1.1.1.2.6 \`
* Reader Options (Touch Only) - Property 1.1.1.1.3.2&#x20;
  * Transaction Options (Touch Only) - Property 1.1.1.1.3.3&#x20;

Flow summary (Touch Only):

* The device automatically sends a Notification – Transaction Information Update when a transaction has started (Table XX - Notification Detail Codes).
* If the button is touched, the device automatically sends a Notification – Transaction Information Update that a transaction is canceled (Table XX - Notification Detail Codes).
* After amount is entered, the device checks Tip Mode (Touch Only) - Property 1.1.1.1.2.2 to determine if TIP mode is enabled and the TIP parameters. The device will show TIP / CUSTOM AMT / SUBMIT or SUMMARY SCREEN per cardholder selection.
* The device checks Tax Rate (Touch Only) - Property 1.1.1.1.2.3 to determine if taxes need to be calculated. If enabled, device calculates Taxes per the tax rate specified.
* If tax function is enabled, the device checks Display Tax or Surcharge (Touch Only) - Property 1.1.1.1.2.4 to determine whether to label it tax or surcharge in the SUMMARY SCREEN.
* Tax is calculated only on the entered amount (excluding TIP).
* Total Amount = Amount + Tip + Tax. Total Amount is used for Tag 9F02 of the transaction flow.
* See Tip & Tax Display Limits (Touch Only) for display limitations.

#### Audio transducer / NFC beep flow (notes)

* Upon NFC tag detection, notify host.
* Host sends 0x1001 to Start Transaction.
* After NFC is activated - No beep.
* Host goes through several pass-through commands to read/write NFC.
* A parameter will be added to the Pass-Through command API to indicate if this is the last command.
  * If this is the last command, Device -> Single Beep to indicate "CARD CAN BE REMOVED" and Turn-Off RF to shut down card.
  * If an error condition is detected, the device will end session, double-beep, Turn-Off RF to shut down the card.

The host uses this command to start a payment transaction with an option to display a page and a green functional button Right (e.g. Service Request button).

#### Present a Card

![](/files/9f0a7a3dd4d743e4d9f5030c47d32e08ff9b0d20)

When the cardholder presses the button, the device will send a notification, show:

Service Request, and await the next command from the host.

PLEASE WAIT

If the battery charge is five percent or less, a response is returned indicating that the command has not been executed. See Table XX - Response Example for Command 0x1001 – Start Transaction Command not executed due to Battery Charge State.

## Request Data for Start Transaction - Command 0x1001

<table><thead><tr><th width="115">Tag</th><th width="77">Len</th><th width="318">Value / Description</th><th width="77">Typ</th><th width="77">Req</th><th width="99">Default</th></tr></thead><tbody><tr><td>— wrappers —</td><td></td><td>Beginning of any wrappers, at minimum including <strong>Request Message</strong> </td><td></td><td></td><td></td></tr><tr><td>1001</td><td></td><td><strong>Start Transaction - Command 0x1001</strong></td><td></td><td></td><td></td></tr><tr><td>81</td><td>01</td><td>Reserved</td><td></td><td>O</td><td></td></tr><tr><td>82</td><td>01</td><td><p>Transaction Timeout, in seconds. This parameter defines how long the device waits for the cardholder to take action on any cardholder input, for example, when waiting for the cardholder to present payment after the host starts the transaction.</p><ul><li>0x00 = No timeout</li><li>0x01 to 0xFF = 1 to 255 seconds</li></ul></td><td>B</td><td>R</td><td></td></tr><tr><td>A3</td><td>var</td><td>Reader Options. The parameters inside this TLV data object allow the host to enable and disable the various payment method interfaces.</td><td>T</td><td>O</td><td></td></tr><tr><td>/82</td><td>01</td><td><p>Contact Reader Mode (EMV Contact Only)</p><ul><li>0x00 = Disabled</li><li>0x01 = EMV</li></ul></td><td>B</td><td>O</td><td>0x01</td></tr><tr><td>/83</td><td>01</td><td><p>Contactless Reader Mode (EMV Contactless Only)</p><ul><li>0x00 = Disabled</li><li>0x01 = EMV</li><li>0x02 = NFC</li><li>0x03 = EMV and NFC</li></ul></td><td>B</td><td>O</td><td>0x01</td></tr><tr><td>/84</td><td>03</td><td><p>Manual Entry Mode (Touch Only). Populate this parameter to enable manual card entry. When using this feature, all other Reader Mode parameters must be set to <strong>Disabled</strong>.<br>Byte 1 Card Number Valid Format</p><ul><li>0x00 = PAN min 8, max 21 digits</li></ul><p>Byte 2 User Interface Sequence</p><ul><li>0x00 = Based on the setting of <strong>MCE Mode Setting - Property 1.2.1.1.5.1</strong></li></ul><p>Byte 3 Beeper Feedback</p><ul><li>0x00 = On keypress sound disabled</li><li>0x01 = On keypress sound enabled</li></ul></td><td>B</td><td>O</td><td></td></tr><tr><td>/85</td><td>02</td><td><p>Barcode Reader Mode (BCR Only). Populate this parameter to enable the device’s barcode reader. This feature can be enabled alongside all other reader modes except Manual Entry Mode.<br>Byte 1 Barcode Reader Enable</p><ul><li>0x00 = Disabled</li><li>0x01 = Enabled</li></ul><p>Byte 2 Encrypt Non-EMV Barcode Data</p><ul><li>0x00 = Disabled</li><li>0x01 = Enabled</li></ul></td><td>B</td><td>O</td><td>0x0000</td></tr><tr><td>A4</td><td>var</td><td>Tip and Tax Options</td><td>B</td><td>O</td><td></td></tr><tr><td>/81</td><td>1F</td><td><p>Byte 1 Tip Mode</p><ul><li>0x00 – Disable Tip Mode</li><li>0x01 – Show Tip GUI immediately using % value</li><li>0x02 – Show Tip GUI immediately using $ amount</li><li>0x11 - Enable Read Channel(s), with +Tip Button, %value</li><li>0x12 - Enable Read Channel(s), with +Tip Button, $ Amount</li></ul><p>Other bytes define display modes and values for up to 6 buttons. See <strong>Tip Mode (Touch Only) - Property 1.1.1.1.2.2</strong> for suggested defaults.</p></td><td>B</td><td>O</td><td></td></tr><tr><td>/82</td><td>06</td><td>Tax or Surcharge Amount to Display. See <strong>Display Tax or Surcharge (Touch Only) - Property 1.1.1.1.2.4</strong> to configure display Tax or Surcharge.</td><td>B</td><td>O</td><td></td></tr><tr><td>A5</td><td>var</td><td>Customer Options.</td><td></td><td></td><td></td></tr><tr><td>/81</td><td>2</td><td><p><strong>Transact</strong> transaction flow. Do not configure this tag if the Host wants to run NFC passthrough commands. Byte 1 Transaction Mode bits:</p><ul><li>Bit 0 = Enable Mifare Classic (1K/4K) Physical Card</li><li>Bit 1 = Enable Mifare DESFire EV1/EV2/EV3 Physical Card</li><li>Bit 2 = Enable Apple Wallet Mobile DESfire Card (when set, set Transaction Option Tag 84 to Apple ECP2 Mode)</li><li>Bit 3 = Enable Mifare2Go Mobile DESFire Card</li></ul><p>Byte 2 Read Data Mode</p><ul><li>0x00 = Read ASCII Number</li><li>0x01 = Read Binary Card Number</li></ul></td><td>B</td><td>O</td><td>0x0000</td></tr><tr><td>84</td><td>02</td><td>Bitmask that sets device behaviors affecting transaction flow and result reporting. Details include Apple/Google VAS modes, wallet modes, protocol mode, and transaction flow control (e.g., Quick Chip). See table content for full bit definitions.<br><br>Byte 1 Apple VAS Mode (Apple / Google VAS Only, set to 0 if not supported)<br><br>Bits 0, 1<br>•	0x00 = Apple/Google VAS Support Disabled<br>•	0x01 = VAS App OR Payment Mode (Single Mode). The<br>device reads only Apple/Google VAS data from a tapped<br>smartphone, or reads EMV payment data from a tapped<br>card. When the device sends ARQC to conclude the<br>transaction, it only includes either EMV payment data in<br>container FC for cards, or includes VAS data in container<br>FE for smartphones<br>•	0x02 = VAS App and Payment Mode (Dual Mode). The<br>device reads both Apple/Google VAS data and EMV payment data<br>from a tapped smartphone, or reads EMV payment data<br>from a tapped card. When device sends ARQC to the host<br>to conclude the transaction, it includes EMV payment data<br>in container FC and includes VAS data, if available, in<br>container FE<br>•	0x03 = VAS App Only Mode (VAS Mode). The device<br>reads only Apple/Google VAS data from a tapped smartphone, and<br>does not read data from a tapped card. If the tapped<br>smartphone does not support VAS, the device does not<br>detect or read from the smartphone. When the device send<br>ARQC to conclude the transaction, it includes VAS data in<br>container FE and does not include EMV payment data in<br>container FC<br>•	0x04 = Payment Only Mode (Payment Mode). The<br>device operates the same as EMV mode (01). It reads only<br>EMV payment data from a tapped smartphone or a tapped<br>card. When the device sends ARQC to conclude the<br>transaction, it includes EMV payment data in container FC<br>and does not include VAS data in container FE. <br><br>Bits 4, 5, 6 Wallet Mode<br>4 -Apple<br>5 - Google<br>6 - Reserved<br>•	0x000 = Wallet Support Disabled<br>•	0x001 = Apple VAS Enable <br>•	0x002 = Google VAS Enabled <br>•	0x003 = –Apple and Google VAS Enabled<br><br>Bit 7 Apple VAS Protocol Mode<br>o Value 0 – URL VAS Protocol<br>o Value 1 – FULL VAS Protocol<br><br>Byte 2 Transaction Flow Control<br>•	Bit 0 Transaction Flow <br>o	Value 1 = Quick Chip Transaction Flow<br>o	Value 0 = EMV Transaction Flow<br>•	Bit 1 Response Format<br>o	Value 1 = DynaPro Response Format.  For sending ARQC data and batch data, the device uses EMV ARQC (DynaPro Format) Type and EMV Batch Data (DynaPro Format) Type.<br>o	Value 0 = Reserved.<br>•	Bit 3 Display Amount for Quick Chip Transaction Flow<br>o	Value 1 = Display Amount<br>o	Value 0 = Do not Display Amount	</td><td>B</td><td>O</td><td>0x0003</td></tr><tr><td>85</td><td>var</td><td>Apple ECP2 frame from Byte 2 to Byte N (Min N = 4, Max N = 19). By default Byte 2-N = 0xC3020003FFFF. Host can configure this parameter to set Apple ECP2 frame. See Apple ECP2.0 spec.<br></td><td>B</td><td>O</td><td></td></tr><tr><td>86</td><td>var</td><td><p>Transaction TLV. A list of TLV data objects defining basic transaction parameters. May contain EMV tags; at minimum must contain 9C and 9F02 (and 9F03 if cash back). Optional for Manual Entry; include 9F02 and 5F2A to show transaction amount for Manual Entry. Common tags:</p><ul><li>9C Transaction Type</li><li>9F02 Amount Authorized</li><li>9F03 Amount Other</li><li>9F7C Merchant Custom Data</li><li>5F2A Transaction Currency Code</li><li>5F36 Transaction Currency Exponent</li><li>9F53 Transaction Category Code</li><li>9F15 Merchant Category Code</li><li>9F16 Merchant ID</li></ul></td><td>B</td><td>R/O</td><td></td></tr><tr><td>AC</td><td>var</td><td>User Interface Options</td><td>T</td><td>O</td><td>null</td></tr><tr><td>/81</td><td>00</td><td>Suppress Thank You Message. By default devices with a display show “THANK YOU,” then “WELCOME.” Include this to suppress “THANK YOU” for this transaction.</td><td>T</td><td>O</td><td>null</td></tr><tr><td>/82</td><td>01</td><td>Override Final Transaction Message. Choose a Display String ID (see section 4.3 Display Strings). Overrides idle page behavior until next transaction, power cycle, or similar state change.</td><td>B</td><td>O</td><td>null</td></tr><tr><td>/83</td><td>02</td><td>Functional button Right option. String ID = enable the present card page with a green functional Right button (label is a String ID, ~15 chars). When user presses this button, device sends notification to host: <strong>User Interface Host Action Request - Notification 0x1803</strong>. If host wants to disable this button, do not include this tag.</td><td>B</td><td>O</td><td>null</td></tr><tr><td>— wrappers —</td><td></td><td>End of any wrappers, at minimum including <strong>Response Message</strong> </td><td></td><td></td><td></td></tr></tbody></table>

## Start Transaction - Response Data for Command 0x1001

<table><thead><tr><th>Tag</th><th width="71.33331298828125">Len</th><th>Value / Description</th><th width="76.33331298828125">Typ</th><th width="77.33331298828125">Req</th><th width="98.33343505859375">Default</th></tr></thead><tbody><tr><td>— wrappers —</td><td></td><td>Beginning of any wrappers, at minimum including <strong>Request Message</strong> </td><td></td><td></td><td></td></tr><tr><td>1001</td><td></td><td><strong>Start Transaction - Command 0x1001</strong></td><td></td><td></td><td></td></tr><tr><td>—</td><td>—</td><td>No parameters.</td><td></td><td></td><td></td></tr><tr><td>— wrappers —</td><td></td><td>End of any wrappers, at minimum including <strong>Response Message</strong> </td><td></td><td></td><td></td></tr></tbody></table>

## Response Example for Start Transaction Command - Command 0x1001 not executed due to Battery Charge State

```
AA 00 81 04 82 01 10 01 82 04 80 02 03 16
```

If the request started successfully, the Request Status in the message wrapper is: **OK, Started / Running, All good / requested operation was successful**

## Request Examples

```
AA 00 81 04 01 00 10 01 84 3D 10 01 82 01 3C A3 09 81 01 01 82 01 01 83 01 01 84 02 00 03 86 27 9C 01 00 9F 02 06 00 00 00 00 01 00 9F 03 06 00 00 00 00 00 00 5F 2A 02 08 40 5F 36 01 02 9F 15 02 00 00 9F 53 01 00
```

## Request Example:

```
AA 00 81 04 01 00 10 01 84 3D 10 01 82 01 3C A3 09 81 01 00 82 01 00 83 01 01 84 02 00 03 86 27 9C 01 00 9F 02 06 00 00 00 00 01 00 9F 03 06 00 00 00 00 00 00 5F 2A 02 08 40 5F 36 01 02 9F 15 02 00 00 9F 53 01 00
```

## Response Example

Example (Hex):

```
AA 00 81 04 82 01 10 01 82 04 01 00 00 00
```


# Resume Transaction - Command 0x1004

The host uses this command to provide the device with additional/modified data to resume a transaction that is currently paused.

## Resume Transaction - Request Data for Command 0x1004 -&#x20;

<table><thead><tr><th>Tag</th><th width="76.66668701171875">Len</th><th>Value / Description</th><th width="74.6666259765625">Typ</th><th width="77.66668701171875">Req</th><th width="97.666748046875">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including Request Message </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1004 = <strong>Resume Transaction - Command 0x1004</strong> </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>81</td><td>01</td><td><p>Resume Code. Indicates the pause state the transaction will resume from:</p><ul><li>0x00 = Waiting for ARPC</li></ul></td><td>B</td><td>R</td><td></td></tr><tr><td>83</td><td>var</td><td>Reserved</td><td>B</td><td>O</td><td></td></tr><tr><td>84</td><td>var</td><td>ARPC Data. This contains an <strong>EMV ARPC Type</strong>.</td><td>B</td><td>R</td><td></td></tr><tr><td>86</td><td>var</td><td>Transaction TLV Update. Not applicable when Resume Code = <strong>Waiting for ARPC</strong></td><td>B</td><td>O</td><td></td></tr><tr><td>End of any wrappers, at minimum including <strong>Request Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## Response Data for Command 0x1004 - Resume Transaction

<table><thead><tr><th>Tag</th><th width="73.33331298828125">Len</th><th width="125.33331298828125">Value / Description</th><th width="76.33331298828125">Typ</th><th width="74.3333740234375">Req</th><th width="95.66668701171875">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including <strong>Response Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1004 = <strong>Resume Transaction - Command 0x1004</strong></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>No parameters.</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>End of any wrappers, at minimum including <strong>Response Message</strong></td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

{% hint style="info" %}
If the request started successfully, the Request Status in the message wrapper is: **OK, Started / Running, All good / requested operation was successful**.
{% endhint %}

## Request Example

{% code title="Request Example (Hex)" %}

```
AA 00 81 04 01 00 10 04 84 21 10 04 81 01 00 82 01 78 84 17 FF 74 14 DF DF 25 08 99 26 90 E1 16
12 07 10 FA 06 70 04 8A 02 30 30
```

{% endcode %}

## Response Example

{% code title="Response Example (Hex)" %}

```
AA 00 81 04 82 06 10 04 82 04 00 00 00 00 84 02 10 04
```

{% endcode %}


# Cancel Transaction - Command 0x1008

The host can use this command to cancel a transaction in progress that it initiated using Start Transaction - Command 0x1001.

Sequence of events:

{% stepper %}
{% step %}

### Host has already started a transaction

The host has already called Start Transaction - Command 0x1001 and the transaction is still in process.
{% endstep %}

{% step %}

### Construct the command request

The host constructs the command request in the format below.
{% endstep %}

{% step %}

### Send the command request

The host sends the command request to the device.
{% endstep %}

{% step %}

### Device sends a response

The device sends a response in the format below to the host:

* If the transaction is in a state where it cannot be canceled, the device’s response returns operation status detail: Failed, Device State Issue, Cannot Cancel.
* If there is no transaction in progress, the device’s response returns operation status detail: Failed, Device State Issue, No Transaction.
* If the device successfully cancels the transaction, the device’s response returns operation status detail: All Good, Requested Operation Was Successful, shows "CANCELED" and returns to the idle state. The display (if any) shows "CANCELED".
  {% endstep %}
  {% endstepper %}

## Request Data for Cancel Transaction - Command 0x1008

<table><thead><tr><th width="288.54541015625">Tag</th><th width="73.33331298828125">Len</th><th width="124.66668701171875">Value / Description</th><th width="74.33331298828125">Typ</th><th width="76.66668701171875">Req</th><th width="94.666748046875">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including Request Message</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1008 = Command 0x1008 - Cancel Transaction</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>No parameters.</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>End of any wrappers, at minimum including Request Message</td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## Response Data for Cancel Transaction - Command 0x1008

<table><thead><tr><th width="300">Tag</th><th width="74">Len</th><th width="124.66668701171875">Value / Description</th><th width="76.33331298828125">Typ</th><th width="78.33331298828125">Req</th><th width="94.33331298828125">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including <a href="https://magtek.gitbook.io/magtek-pilot-gitbooks/internal-documentation/index/3.0-messages-requests-responses-notifications-and-files/3.3-message-structure#response-message">Response Message</a></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1008 = Cancel Transaction - Command 0x1008 </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>No parameters.</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>End of any wrappers, at minimum including <a href="https://magtek.gitbook.io/magtek-pilot-gitbooks/internal-documentation/index/3.0-messages-requests-responses-notifications-and-files/3.3-message-structure#response-message">Response Message</a></td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## Request Example

Example (Hex)

```hex
AA 00 81 04 01 13 10 08 84 02 10 08
```

## Response Example

Example (Hex)

```hex
AA 00 81 04 82 13 10 08 82 04 00 00 00 00
```


# NFC/MIFARE Pass Through Commands (Contactless Only) - Command Group 0x11nn

## NFC/MIFARE Pass Through Commands (Contactless Only)

After an NTag/MIFARE Ultralight is activated, the host uses this command to send commands and receive responses to and from a NTag/MIFARE Ultralight.

{% hint style="success" %}
Applies to: All Dyna Family products
{% endhint %}

### Information in this group

| **Section**                                                                                                                                                                                                                                                                                                                                            | **Information**                                                                                                                                                |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [<mark style="color:red;">**Pass Through Command For NTag/MIFARE Ultralight, Type 2**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/nfc-mifare-pass-through-commands-contactless-only-command-group-0x11nn/pass-through-command-for-ntag-mifare-ultralight-type-2-command-0x1100)                                     | After an NTag/MIFARE Ultralight is activated, the host uses this command to send commands and receive responses to and from a NTag/MIFARE Ultralight.          |
| [<mark style="color:red;">**Pass Through Command for MIFARE Classic/MINI®/Plus SL1 (Security Level 1)**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/nfc-mifare-pass-through-commands-contactless-only-command-group-0x11nn/pass-through-command-for-mifare-classic-mini-r-plus-sl1-security-level-1-command-0x1101) | After a MIFARE Tag is activated, the host uses this command to send commands and receive responses to and from a MIFARE tag.                                   |
| [<mark style="color:red;">**Pass Through Command for MIFARE DESFire, Type 4**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/nfc-mifare-pass-through-commands-contactless-only-command-group-0x11nn/pass-through-command-for-mifare-classic-mini-r-plus-sl1-security-level-1-command-0x1101)                           | After a MIFARE DESFire Light/EV1/EV2/EV3 Tag is activated, the host uses this command to send commands and receive responses to and from a MIFARE DESFire Tag. |
| [<mark style="color:red;">**Pass Through Command for MIFARE Plus, Type 2**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/nfc-mifare-pass-through-commands-contactless-only-command-group-0x11nn/pass-through-command-for-mifare-plus-type-2-command-0x1103)                                                           | After a MIFARE Plus EV1/EV2/SE/X Tag is activated, the Host uses this command to send commands and receive responses to and from a MIFARE Plus tag.            |

### Need More Help

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** [support@magtek.com](mailto:support@magtek.com?subject=Support%20Request)
* 📞 **Phone:** 1-562-546-6800 (US)
* 🕐 **Hours:** Monday-Friday, 5:30 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Support Portal:** developer.magtek.com

**Documentation Feedback:**

Help us improve this documentation! [feedback@magtek.com](mailto:feedback@magtek.com?subject=Feedback)
{% endhint %}


# Pass Through Command For NTag/MIFARE Ultralight, Type 2 - Command 0x1100

After an NTag/MIFARE Ultralight is activated, the host uses this command to send commands and receive responses to and from a NTag/MIFARE Ultralight. Do not change the address 0x00 for read protection of Ultralight C/AES card because the device will fail to access the card if the address 0x00 is read protected.

## Request Data for Command 0x1100&#x20;

<table><thead><tr><th width="130">Tag</th><th width="75">Len</th><th width="312">Value / Description</th><th width="78" align="right">Typ</th><th width="80" align="right">Req</th><th width="97">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including <strong>Request Message</strong> </td><td></td><td></td><td align="right"></td><td align="right"></td><td></td></tr><tr><td>1100</td><td></td><td><strong>Pass Through Command For NTag/MIFARE Ultralight, Type 2 - Command 0x1100</strong></td><td align="right"></td><td align="right"></td><td></td></tr><tr><td>81</td><td>var</td><td><p>Command to Send. </p><p>See <strong>Table XX – NTag Commands</strong> </p><p>See <strong>Table XX – MIFARE Ultralight EV1 Commands</strong> </p><p>See <strong>Table XX – MIFARE Ultralight C Commands</strong> </p><p>See <strong>Table XX – MIFARE Ultralight AES Commands</strong></p></td><td align="right">B</td><td align="right">R</td><td></td></tr><tr><td>82</td><td>01</td><td><p>00 – No Encrypt </p><p>01 - Encrypt</p></td><td align="right">B</td><td align="right">R</td><td></td></tr><tr><td>83</td><td>01</td><td><p>00 – Expect More Commands </p><p>01 – FF (Last Command). </p><p>If the pass-through command is the last successful command, the device will end the transaction with a single beep, indicating success. </p><p></p><p>If an error arises, the device will end the transaction but will sound two beeps to indicate the error. The user should then remove the card.</p></td><td align="right">B</td><td align="right">R</td><td></td></tr><tr><td>End of any wrappers, at minimum including Request Message</td><td></td><td></td><td align="right"></td><td align="right"></td><td></td></tr></tbody></table>

## NTag Commands

<table><thead><tr><th width="121">Command</th><th width="92" align="right">Length</th><th>Field Value</th></tr></thead><tbody><tr><td>Get Version</td><td align="right">1</td><td>The GET_VERSION command is used to retrieve information on the NTAG family, the product version, storage size and other product data required to identify the specific NTAG21x. Byte 0 = 0x60</td></tr><tr><td>Read</td><td align="right">2-3</td><td>The READ command requires a start page address, and returns the 16 bytes of four NTAG21x pages. For example, if address is 03h then pages 03h, 04h, 05h, 06h are returned. Special conditions apply if the READ command address is near the end of the accessible memory area. The special conditions also apply if at least part of the addressed pages is within a password protected area. The READ command with an option of end page address returns the all n*4 bytes of the addressed pages. For example if the start address is 03h and the end address is 07h then pages 03h, 04h, 05h, 06h and 07h are returned. Byte 0 = 0x30 Byte 1 = Start Page Address Byte 2 = (optional) End Page Address</td></tr><tr><td>Fast Read</td><td align="right">3</td><td>The FAST_READ command requires a start page address and an end page address and returns the all n*4 bytes of the addressed pages. For example, if the start address is 03h and the end address is 07h then pages 03h, 04h, 05h, 06h and 07h are returned. Byte 0 = 0x3A Byte 2 = Start Page Address Byte 3 = End Page Address</td></tr><tr><td>Write</td><td align="right">6</td><td>The WRITE command requires a block address, and writes 4 bytes of data into the addressed NTAG21x page. Byte 0 = 0xA2 Byte 1 = Address to Write Byte 2 to 5 = 4 Bytes of Data to Write</td></tr><tr><td>Compatibility Write</td><td align="right">18</td><td>The COMPATIBILITY_WRITE command is implemented to guarantee interoperability with the established MIFARE Classic PCD infrastructure, in case of coexistence of ticketing and NFC applications. Even though 16 bytes are transferred to NTAG21x, only the least significant 4 bytes (bytes 0 to 3) are written to the specified address. Set all the remaining bytes, 04h to 0Fh, to logic 00h. Byte 0 = 0xA0 Byte 1 = Address to Write Byte 2 to 17 = 16 Bytes of Data to Write (only least significant 4 bytes are written) Note: This command is sent in 2 steps, which the Firmware will handle</td></tr><tr><td> READ_CNT</td><td align="right">2</td><td> The READ_CNT command is used to read out the current value of the NFC one-way counter of the NTAG213, NTAG215 and NTAG216. The command has a single argument specifying the counter number and returns the 24-bit counter value of the corresponding counter. If the NFC_CNT_PWD_PROT bit is set to 1b the counter is password protected and can only be read with the READ_CNT command after a previous valid password authentication Byte 0 = 0x39 Byte 1 = 0x02 (NFC Counter Address)</td></tr><tr><td>PWD_AUTH</td><td align="right">5</td><td>A protected memory area can be accessed only after a successful password verification using the PWD_AUTH command. The AUTH0 configuration byte defines the protected area. It specifies the first page that the password mechanism protects. The level of protection can be configured using the PROT bit either for write protection or read/write protection. The PWD_AUTH command takes the password as parameter and, if successful, returns the password authentication acknowledge, PACK. By setting the AUTHLIM configuration bits to a value larger than 000b, the number of unsuccessful password verifications can be limited. Each unsuccessful authentication is then counted in a counter featuring anti-tearing support. After reaching the limit of unsuccessful attempts, the memory access specified in PROT, is no longer possible. Byte 0 = 0x1B Byte 1..4 = password (4 bytes)</td></tr><tr><td>READ_SIG</td><td align="right">2</td><td>The READ_SIG command returns an IC specific, 32-byte ECC signature, to verify NXP Semiconductors as the silicon vendor. The signature is programmed at chip production and cannot be changed afterwards. Byte 0 = 0x3C Byte 1 = 0x00, RFU</td></tr></tbody></table>

## MIFARE Ultralight EV1 Commands

<table><thead><tr><th width="126">Command</th><th width="95" align="right">Length</th><th>Field Value</th></tr></thead><tbody><tr><td>Get Version</td><td align="right">1</td><td>The GET_VERSION command is used to retrieve information on the MIFARE family, product version, storage size and other product data required to identify the MF0ULx1. Byte 0 = 0x60</td></tr><tr><td>Read</td><td align="right">2-3</td><td>The READ command requires a start page address, and returns the 16 bytes of four MIFARE Ultralight pages. For example if address (Addr) is 03h then pages 03h, 04h, 05h, 06h are returned. A rollover mechanism is implemented if the READ command address is near the end of the accessible memory area. This rollover mechanism is also used when at least part of the addressed pages is within a password protected area. The READ command with an option of end page address returns the all n*4 bytes of the addressed pages. For example if the start address is 03h and the end address is 07h then pages 03h, 04h, 05h, 06h and 07h are returned. Byte 0 = 0x30 Byte 1 = Start Page Address Byte 2 = (optional) End Page Address</td></tr><tr><td>Fast Read</td><td align="right">3</td><td>The FAST_READ command requires a start page address and an end page address and returns the all n*4 bytes of the addressed pages. For example, if the start address is 03h and the end address is 07h then pages 03h, 04h, 05h, 06h and 07h are returned. Byte 0 = 0x3A Byte 2 = Start Page Address Byte 3 = End Page Address</td></tr><tr><td>Write</td><td align="right">6</td><td>The WRITE command requires a block address, and writes 4 bytes of data into the addressed MIFARE Ultralight EV1 page. Byte 0 = 0xA2 Byte 1 = Address to Write Byte 2 to 5 = 4 Bytes of Data to Write</td></tr><tr><td>Compatibility Write</td><td align="right">18</td><td>The COMPATIBILITY_WRITE command is implemented to accommodate the established MIFARE Classic PCD infrastructure. Even though 16 bytes are transferred to the MF0ULx1, only the least significant 4 bytes (bytes 0 to 3) are written to the specified address. Set all the remaining bytes, 04h to 0Fh, to logic 00h Byte 0 = 0xA0 Byte 1 = Address to Write Byte 2 to 17 = 16 Bytes of Data to Write (only least significant 4 bytes are written) Note: This command is sent in 2 steps, which the Firmware will handle</td></tr><tr><td>READ_CNT</td><td align="right">2</td><td>The READ_CNT command is used to read out the current value of one of the 3 one-way counters of the MF0ULx1. The command has a single argument specifying the counter number and returns the 24-bit counter value of the corresponding counter. The counters are always readable, independent on the password protection settings. Byte 0 = 0x39 Byte 1 = 0x00..0x02 (counter number from 0x00 to 0x02)</td></tr><tr><td>INCR_CNT </td><td align="right">6</td><td> The INCR_CNT command is used to increment one of the 3 one-way counters of the MF0ULx1. The two arguments are the counter number and the increment value. Byte 0 = 0xA5 Byte 1 = 0x00..0x02 (counter number from 0x00 to 0x02) Byte 2 to 5 = 4 bytes increment value (only the 3 least significant bytes are relevant)</td></tr><tr><td>PWD_AUTH</td><td align="right">5</td><td>A protected memory area can be accessed only after a successful password verification using the PWD_AUTH command. The AUTH0 configuration byte defines the protected area. It specifies the first page that the password mechanism protects. The level of protection can be configured using the PROT bit either for write protection or read/ write protection. The PWD_AUTH command takes the password as parameter and, if successful, returns the password authentication acknowledge, PACK. By setting the AUTHLIM configuration bits to a value larger than 000b, the number of unsuccessful password verifications can be limited. Each unsuccessful authentication is then counted in a counter featuring anti-tearing support. After reaching the limit of unsuccessful attempts, the memory access specified in PROT, is no longer possible. Byte 0 = 0x1B Byte 1..4 = password (4 bytes)</td></tr><tr><td>READ_SIG</td><td align="right">2</td><td>The READ_SIG command returns an IC specific, 32-byte ECC signature, to verify NXP Semiconductors as the silicon vendor. The signature is programmed at chip production and cannot be changed afterwards. Byte 0 = 0x3C Byte 1 = 0x00, RFU</td></tr><tr><td>CHECK TEARING_EVENT</td><td align="right">2</td><td>The CHECK_TEARING_EVENT command enables the application to identify if a tearing event happened on a specified counter element. It takes the counter number as single argument and returns a specified valid flag for this counter. If the returned valid flag is not equal to the predefined value, a tearing event happened. Note, although a tearing event might have happened on the counter, a valid value corresponding to the last valid counter status is still available using the READ_CNT command. Byte 0 = 0x3E Byte 1 = 0x00..0x02 (counter number from 0x00 to 0x02)</td></tr><tr><td>VCSL</td><td align="right">21</td><td>The VCSL command is used to enable a unique identification and selection process across different MIFARE product-based cards and card implementations on mobile devices. The command requires a 16-byte installation identifier IID and a 4-byte PCD capability value as parameters. The parameters are present to support compatibility to other MIFARE product-based devices but are not used or checked inside the MF0ULx1. Nevertheless, the number of bytes is checked for correctness. The answer to the VCSL command is the virtual card type identifier VCTID. This identifier indicates the type of card or ticket. Using this information, the reader can decide whether the ticket belongs to the installation or not. Byte 0 = 0x4B Byte 1 to 16 = 16-byte IID (installation identifier, can be any number) Byte 17 to 20 = 4-byte PCDCAPS (PCD capabilities, can be any number)</td></tr></tbody></table>

## MIFARE Ultralight C Commands

<table><thead><tr><th width="116">Command</th><th width="96" align="right">Length</th><th>Field Value</th></tr></thead><tbody><tr><td>Read</td><td align="right">2-3</td><td><p>The READ command takes the page address as a parameter. Only addresses 00h to 2Bh are decoded. For higher addresses the MF0ICU2 returns a NAK. The MF0ICU2 responds to the READ command by sending 16 bytes starting from the page address defined in the command (e.g. if ADR is 03h, pages 03h, 04h, 05h, 06h are returned) A roll-over mechanism is implemented to continue reading from page 00h once the end of the accessible memory is reached. For example, reading from address 29h on a MF0ICU2 results in pages 29h, 2Ah, 2Bh and 00h being returned. The following conditions apply if part of the memory is protected by the 3DES authentication for read access:</p><ul><li>if the MF0ICU2 is in the ACTIVE state – addressing a page which is equal or higher than AUTH0 results in a NAK response – addressing a page lower than AUTH0 results in data being returned with the roll-over mechanism occurring just before the AUTH0 defined page</li><li>if the MF0ICU2 is in the AUTHENTICATED state – the READ command behaves like on a MF0ICU2 without access protection. The READ command with an option of end page address returns the all n*4 bytes of the addressed pages. For example if the start address is 03h and the end address is 07h then pages 03h, 04h, 05h, 06h and 07h are returned. Byte 0 = 0x30 Byte 1 = Start Page Address Byte 2 = (optional) End Page Address </li></ul><p>The READ command with an option of end page address returns the all n*4 bytes of the addressed pages. For example if the start address is 03h and the end address is 07h then pages 03h, 04h, 05h, 06h and 07h are returned.</p><p></p><p>Byte 0 = 0x30</p><p>Byte 1 = Start Page Address</p><p>Byte 2 = (optional) End Page Address</p></td></tr><tr><td>Write</td><td align="right">6</td><td><p>The WRITE command is used to program the lock bytes in page 02h, the OTP bytes in page 03h, data bytes in pages 04h to 27h, configuration data from page 28h to 2B and keys from page 2Ch to 2Fh. A WRITE command is performed page-wise, programming 4 bytes in a page. </p><p></p><p>Byte 0 = 0xA2 </p><p>Byte 1 = Address to Write </p><p>Byte 2 to 5 = 4 Bytes of Data to Write</p></td></tr><tr><td>Compatibility Write</td><td align="right">18</td><td><p>The COMPATIBILITY_WRITE command was implemented to accommodate the established MIFARE PCD infrastructure. Even though 16 bytes are transferred to the MF0ICU2, only the least significant 4 bytes (bytes 0 to 3) will be written to the specified address. It is recommended to set the remaining bytes 4 to 15 to all 0. </p><p></p><p>Byte 0 = 0xA0 </p><p>Byte 1 = Address to Write </p><p>Byte 2 to 17 = 16 Bytes of Data to Write (only least significant 4 bytes are written) </p><p></p><p>Note: This command is sent in 2 steps, which the Firmware will handle</p><ul><li>&#x3C;CMD>&#x3C;Address to Write>&#x3C;CRCH>&#x3C;CRCL></li><li>&#x3C;16 Bytes of Data to Write>&#x3C;CRCH>&#x3C;CRCL></li></ul><p></p></td></tr><tr><td>AUTHENTICATE</td><td align="right">2</td><td><p>The AUTHENTICATE command is used to authenticate the MF0ICU2 using 2 keys 3DES encryption in Cipher-Block Chaining (CBC) mode as described in ISO/IEC 10116.</p><ul><li>The 16-byte of the 2keys 3DES are programmed to card memory pages from 2Ch to 2Fh. The key itself can be written during personalization or at any later stage using the WRITE or COMPATIBILITY WRITE with Byte 0 is always sent first. On example of Key1 = 0001020304050607h and Key2 = 08090A0B0C0D0E0Fh, the command sequence needed for key programming with WRITE command is:</li></ul><p>•  A2 2C 07 06 05 04</p><p>•  A2 2D 03 02 01 00</p><p>•  A2 2E 0F 0E 0D 0C</p><p>•  A2 2F 0B 0A 09 08</p><ul><li>The 16-byte of the same 2keys 3DES are programed to the Device using Property 1.2.1.1.4.1 MIFARE Ultralight C 2keys3DES</li></ul><p> </p><p>Byte 0 = 0x1A </p><p>Byte 1 = 0x00</p></td></tr></tbody></table>

## MIFARE Ultralight AES Commands

<table><thead><tr><th width="115">Command</th><th width="101" align="right">Length</th><th>Field Value</th></tr></thead><tbody><tr><td>Get Version</td><td align="right">1</td><td><p>The GET_VERSION command is used to retrieve information on the MIFARE family, product version, storage size and other product data required to identify the MIFARE Ultralight AES. </p><p></p><p>Byte 0 = 0x60</p></td></tr><tr><td>Read</td><td align="right">2-3</td><td><p>The READ command requires a start page address, and returns the 16 bytes of four pages. For example, if address (Addr) is 03h then pages 03h, 04h, 05h, 06h are returned. So called roll-over mechanism (described later) applies if the READ command address is near the end of the accessible memory area. Same mechanism applies if at least part of the addressed pages is within an authentication protected area. </p><p></p><p>In the default state of MIFARE Ultralight AES, all memory pages in the range from 00h to 3Bh are allowed as Addr parameter to the READ command. Addressing a memory page above the limit results in a NAK response. A roll-over mechanism is implemented to continue reading from page 00h once the end of the accessible memory is reached if at least first addressed page is within allowed limit. </p><p></p><p><strong>Remark:</strong> AES key values can never be directly read out of the memory. When reading from the pages holding key values, all 00h bytes are returned. </p><p></p><p>The READ command with an option of end page address returns the all n*4 bytes of the addressed pages. For example if the start address is 03h and the end address is 07h then pages 03h, 04h, 05h, 06h and 07h are returned. </p><p></p><p>Byte 0 = 0x30 </p><p>Byte 1 = Start Page Address </p><p>Byte 2 = (optional) End Page Address</p></td></tr><tr><td>Fast Read</td><td align="right">3</td><td><p>The FAST_READ command requires a start page address and an end page address and returns bytes of addressed pages. For example if the start address is 03h and the end address is 07h then pages 03h, 04h, 05h, 06h, and 07h are returned. If either start or end address is outside accessible area, then MIFARE Ultralight AES replies with a NAK. </p><p></p><p>Byte 0 = 0x3A </p><p>Byte 2 = Start Page Address </p><p>Byte 3 = End Page Address</p></td></tr><tr><td>Write</td><td align="right">6</td><td><p>The WRITE command requires a block address, and writes 4 bytes of data into the addressed MIFARE Ultralight AES page. </p><p></p><p>Byte 0 = 0xA2 </p><p>Byte 1 = Address to Write Byte </p><p>2 to 5 = 4 Bytes of Data to Write</p></td></tr><tr><td>READ_CNT</td><td align="right">2</td><td><p>The READ_CNT command is used to read out the current value of one of the 3 one-way counters of MIFARE Ultralight AES. The command has a single argument specifying the counter number and returns the 24-bit counter value of the corresponding counter. Counters are always readable, except in case of the counter "0x02" with the optional AES authentication protection enabled. In that case, the counter 0x02 is readable only in the AUTHENTICATE state. </p><p>Byte 0 = 0x39 </p><p>Byte 1 = 0x00..0x02 (counter number from 0x00 to 0x02)</p></td></tr><tr><td>INCR_CNT</td><td align="right">6</td><td><p>The INCR_CNT command is used to increment one of the 3x one-way counters of the MIFARE Ultralight AES. Two arguments are the counter number and the increment value. Counters are always incrementable, except in case of the counter "0x02" with the optional AES authentication protection enabled. In that case, the counter 0x02 can be incremented only in the AUTHENTICATE state. </p><p></p><p>Byte 0 = 0xA5 </p><p>Byte 1 = 0x00..0x02 (counter number from 0x00 to 0x02) </p></td></tr><tr><td>READ_SIG</td><td align="right">2</td><td><p>The READ_SIG command returns an IC-specific, 48-byte ECC signature. The originality signature can be changed if it has been unlocked with the LOCK_SIG command. </p><p></p><p>Byte 0 = 0x3C </p><p>Byte 1 = 0x00, RFU</p></td></tr><tr><td>WRITE_SIG</td><td align="right">6</td><td><p>The WRITE_SIG command allows the writing of a customized originality signature into the dedicated originality signature memory. The WRITE_SIG command requires an originality signature block address, and writes 4 bytes of data into the addressed originality signature block.</p><p></p><p>In the initial state of MIFARE Ultralight AES, the following originality signature blocks 00h to 0Bh are valid Addr parameters to the WRITE_SIG command. Addressing a memory block beyond the limits above results in a NAK response from MIFARE Ultralight AES.</p><p></p><p>If the originality signature is locked or permanently locked, a WRITE_SIG command results in a NAK response from the MIFARE Ultralight AES.</p><p> </p><p>Byte 0 = 0xA9</p><p>Byte 1 = signature block address</p><p>Byte 2 to 5 = signature bytes to be written</p></td></tr><tr><td>LOCK_SIG</td><td align="right">2</td><td><p>The LOCK_SIG command allows the user to unlock, lock or permanently lock the dedicated originality signature memory.</p><p>The originality signature can only be unlocked, if the originality signature is not permanently locked.</p><p>There is no command to unlock the originality signature, if the originality signature is permanently locked.</p><p> </p><p>Byte 0 = 0xAC</p><p>Byte 1 = lock option</p><ul><li>0x00 = unlock</li><li>0x01 = lock</li><li>0x02 = permanently lock</li></ul></td></tr><tr><td>VCSL</td><td align="right">21</td><td><p>The VCSL command is used to enable a unique identification and selection process across different physical MIFARE product-based cards and virtual MIFARE implementations. The command requires a 16-byte installation identifier IID and a 4-byte PCD capability value as parameters. The parameters are present to support compatibility to other MIFARE product-based devices, but are not used or checked inside the MIFARE Ultralight AES. Nevertheless, the number of bytes is checked for correctness. The answer to the VCSL command is the VCTID value stored in the user configuration segment. This identifier indicates the type of card or ticket. Using this information, the contactless reader can decide whether the ticket belongs to the installation or not.</p><p> </p><p>Byte 0 = 0x4B</p><p>Byte 1 to 16 = 16-byte IID (installation identifier, can be any number) Byte 17 to 20 = 4-byte PCDCAPS (PCD capabilities, can be any number)</p></td></tr><tr><td>AUTHENTICATE</td><td align="right">2</td><td><p>The AUTHENTICATE command is used to authenticate with a 3-pass mutual authentication the MIFARE Ultralight AES and PCD. The cryptographic method is based on AES in Cipher-Block chaining (CBC) mode according to NIST Special Publication 800-38A. The used key is a 128-bit AES Key. Remark: To reduce the risk on card- only side channel attack to the AES keys, a failed authentication limit (AUTH_LIM) can be set.</p><ul><li>The 16 bytes of the AES [DataProtKey] are programmed to memory pages from 30h to 33h. Keys themselves can be written during personalization or at any later stage in a secure environment, as long as the key is not locked for update in the user configuration segment. AES [UIDRetrKey] is stored in memory addresses from 34h until 37h. In case keys are not locked, MIFARE Ultralight AES allows to change AES-keys without authentication as long as AUTH0 is not set to a page address before or at page address where keys bytes are stored. Otherwise MIFARE Ultralight AES requires to be in the AUTHENTICATED state to allow to write AES keys.</li></ul><p>The key itself can be written using the WRITE with Byte 0 is always sent first.</p><p></p><p>On example of AES [DataProtKey] = 000102030405060708090A0B0C0D0E0Fh, the command</p><p>sequence needed for key programming with WRITE command is:</p><p>•  A2 30 0F 0E 0D 0C</p><p>•  A2 31 0B 0A 09 08</p><p>•  A2 32 07 06 05 04</p><p>•  A2 33 03 02 01 00</p><p></p><p>On example of AES [UIDRetrKey] = 000102030405060708090A0B0C0D0E0Fh, the command</p><p>sequence needed for key programming with WRITE command is:</p><p>•  A2 34 0F 0E 0D 0C</p><p>•  A2 35 0B 0A 09 08</p><p>•  A2 36 07 06 05 04</p><p>•  A2 37 03 02 01 00</p><p></p><ul><li>The 16-byte of the same AES [DataProtKey] are programed to the Device using Property 1.2.1.1.4.2 MIFARE Ultralight AES DataProtKey.</li><li>The 16-byte of the same AES [UIDRetrKey] are programed to the Device using Property 1.2.1.1.4.3 MIFARE Ultralight AES UIDRetrKey.</li><li>The 16-byte of the AES [OriginalityKey] are programed to the Device using Property 1.2.1.1.4.4 MIFARE Ultralight AES OriginalityKey. This key value is only known by NXP.</li></ul><p> </p><p>Byte 0 = 0x1A</p><p>Byte 1 = Key option </p><ul><li>0x00 = DataProtKey </li><li>0x01 = UIDRetrKey</li><li>0x02 = OriginalityKey</li></ul><p></p></td></tr></tbody></table>

## Pass Through Command For NTag/MIFARE Ultralight, Type 2 - Response Data for Command 0x1100

<table><thead><tr><th width="116">Tag</th><th width="82" align="right">Len</th><th width="330">Value / Description</th><th width="75" align="right">Typ</th><th width="80" align="right">Req</th><th width="101">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including Response Message </td><td align="right"></td><td></td><td align="right"></td><td align="right"></td><td></td></tr><tr><td>1100</td><td align="right"></td><td>Pass Through Command For NTag/MIFARE Ultralight, Type 2 Command For NFC Tag - Command 0x1100</td><td align="right"></td><td align="right"></td><td></td></tr><tr><td>81</td><td align="right">01</td><td>Tag Response Code 0x00 = Success 0x01 = Failed</td><td align="right">B</td><td align="right">R</td><td>N/A</td></tr><tr><td>82</td><td align="right">var</td><td>Encryption Control. If encrypted, see Table XX - Payload for Encrypted NFC/MIFARE Data. If unencrypted see Table 94 – Unencrypted NFC/MIFARE Data.</td><td align="right">B</td><td align="right">O</td><td>N/A</td></tr><tr><td>End of any wrappers, at minimum including Response Message </td><td align="right"></td><td></td><td align="right"></td><td align="right"></td><td></td></tr></tbody></table>

If the request started successfully, the Request Status in the message wrapper is **OK, Started / Running, All good / requested operation was successful**.

## Request Example (Get Version)

{% code title="Example (Hex)" %}

```
AA 00 81 04 01 39 11 00 84 0B 11 00 81 01 60 82 01 00 83 01 00
```

{% endcode %}

## Response Example (Get Version)

{% code title="Request Example (Hex)" %}

```
AA 00 81 04 82 39 11 00 82 04 01 00 00 00 84 14 11 00 81 01 00 82 0D FC 0B DF 7A 
08 01 02 03 04 05 06 07 08
```

{% endcode %}

## Encrypted Data Format

## Payload for Encrypted NFC/MIFARE Data

<table><thead><tr><th width="101">Tag</th><th width="76" align="right">Len</th><th width="355">Value / Description</th><th width="74" align="right">Typ</th><th width="75" align="right">Req</th><th width="99">Default</th></tr></thead><tbody><tr><td>/DFDF59</td><td align="right">var</td><td><p>Encrypted Data Primitive. </p><p></p><p>Decrypt the value of this TLV data object using the algorithm and variant specified in the <strong>Encrypted Data KSN</strong> parameter and the <strong>Encrypted Data Encryption Type</strong> parameter to read its contents. The format of the decrypted data is shown in <strong>Table 94 – Unencrypted NFC/MIFARE Data</strong>.</p></td><td align="right">B</td><td align="right">R</td><td></td></tr><tr><td>/DFDF50</td><td align="right">var</td><td>Encrypted Data KSN</td><td align="right">B</td><td align="right">R</td><td></td></tr><tr><td>/DFDF51</td><td align="right">01</td><td>Encrypted Data Encryption Type. See section 4.4 Encryption Type for a list of valid values.</td><td align="right">B</td><td align="right">R</td><td></td></tr><tr><td>End of Notification Message </td><td align="right"></td><td></td><td align="right"></td><td align="right"></td><td></td></tr></tbody></table>

## Unencrypted NFC/MIFARE Data

| Tag   | Len | Value / Description | Typ | Req | Default |
| ----- | --: | ------------------- | --: | --: | ------- |
| FC    | var | NFC Data Container  |   T |   R |         |
| /DF7A | var | NFC Data            |   B |   O |         |


# Pass Through Command for MIFARE Classic/MINI®/Plus SL1 (Security Level 1) - Command 0x1101

### Pass Through Command for MIFARE Classic/MINI®/Plus SL1 (Security Level 1), Type 2 - Command 0x1101&#x20;

After a MIFARE Tag is activated, the host uses this command to send commands and receive responses to and from a MIFARE tag.

For MIFARE Plus EV1/EV2/SE/X at SL1 (Security Level 1), the tag is discovered as MIFARE Classic, and can use the same functionality as MIFARE Classic 1K/4K commands in **Table XX – MIFARE Classic/MINI® Commands**. Furthermore, an additional optional AES authentication is available in this level without affecting the MIFARE Classic 1K/4K functionality. The authenticity of the card can be proven using strong cryptographic means with this additional functionality. In addition to the backwards compatibility mode, MIFARE Plus card can be switched to higher security levels. After MIFARE Plus is authenticated with AES Security Level 1 Key, the Device doesn’t auto detect an error from the MIFARE Tag has been removed to end the pass-through session. To end the pass-through session, the Host application can send the last command, the CANCEL command (0xFF), or receive an error response from the MIFARE Tag.

## Pass Through Command for MIFARE Classic/MINI®/Plus SL1 (Security Level 1) - Request Data for Command 0x1101

<table><thead><tr><th width="112">Tag</th><th width="68.66668701171875">Len</th><th width="341">Value / Description</th><th width="77.00006103515625">Typ</th><th width="77.3333740234375">Req</th><th width="96">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including <strong>Request Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1101 = <strong>Command 0x1101 – Pass Through Command for MIFARE Classic/MINI®/Plus SL1 (Security Level 1), Type 2</strong></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>81</td><td>var</td><td>Command to Send. See <strong>Table XX – MIFARE Classic/MINI® Commands</strong> See <strong>Table XX – MIFARE Plus EV1/EV2/SE/X SL1 (Security Level 1) Commands</strong></td><td>B</td><td>R</td><td></td></tr><tr><td>82</td><td>01</td><td>00 – No Encrypt 01 - Encrypt</td><td></td><td></td><td></td></tr><tr><td>83</td><td>01</td><td>00 – Expect More Commands 01 – FF (Last Command). If last command, Device will provide a single beep after receiving a successful response from tag, otherwise, device will provide a double beep.</td><td>B</td><td>R</td><td></td></tr><tr><td>End of any wrappers, at minimum including Request Message </td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## MIFARE Classic/MINI® Commands

<table><thead><tr><th width="135.6666259765625">Command</th><th width="94.66668701171875">Length</th><th>Field Value</th></tr></thead><tbody><tr><td>MIFARE Read</td><td></td><td>Byte 0 – 0x30 – Read Command<br>Byte 1 – Sector Number to Read<br>Byte 2 – Start Block Number<br>Byte 3 – End Block Number<br>Byte 4 – Key Type, 0 = A, 1 = B<br>Byte 5 to 10 = 6 Byte Key</td></tr><tr><td>MIFARE Write</td><td></td><td>Byte 0 – 0xA0 – Write Command<br>Byte 1 – Sector Number to Write<br>Byte 2 – Start Block Number<br>Byte 3 – End Block Number<br>Byte 4 – Key Type 0 = A, 1 = B<br>Byte 5 to 10 = 6 Byte Key<br>Byte 11 to x = Variable length Byte Data (16 bytes per block)</td></tr><tr><td>MIFARE Increment</td><td></td><td>Byte 0 – 0xC1 – Increment Command<br>Byte 1 – Source Sector Number<br>Byte 2 – Source Block Number<br>Byte 3 – Key Type 0 = A, 1 = B<br>Byte 4 to 9 = 6 Byte Key<br>Byte 10 to 13 = 4 Byte Operand</td></tr><tr><td>MIFARE Decrement</td><td></td><td>Byte 0 – 0xC0 – Decrement Command<br>Byte 1 – Source Sector Number<br>Byte 2 – Source Block Number<br>Byte 3 – Key Type 0 = A, 1 = B<br>Byte 4 to 9 = 6 Byte Key<br>Byte 10 to 13 = 4 Byte Operand</td></tr><tr><td>MIFARE Restore</td><td></td><td>Byte 0 – 0xC2 – Restore Command<br>Byte 1 – Source Sector Number<br>Byte 2 – Source Block Number<br>Byte 3 – Key Type 0 = A, 1 = B<br>Byte 4 to 9 = 6 Byte Key</td></tr><tr><td>MIFARE Transfer</td><td></td><td>Byte 0 – 0xB0 – Write the value from the Transfer Buffer into destination block number<br>Byte 1 – Destination Sector Number<br>Byte 2 – Destination Block Number<br>Byte 3 – Key Type 0 = A, 1 = B<br>Byte 4 to 9 = 6 Byte Key</td></tr></tbody></table>

## MIFARE Plus EV1/EV2/SE/X SL1 (Security Level 1) Commands

<table><thead><tr><th width="116">Command</th><th width="93.33331298828125">Length</th><th width="266.33331298828125">Field Value</th><th width="76">EV1</th><th width="76.6666259765625">EV2</th><th width="66.66668701171875">SE</th><th width="59.6666259765625">X</th></tr></thead><tbody><tr><td>First Authenticate (part1 and part2)</td><td>3</td><td><p>First Authenticate. Use this command to switch to higher security levels. This command is behaved as the last command. Device will provide a single beep after receiving a successful response from a card, otherwise, device will provide a double beep.</p><p><br>Byte 0 = 0x70<br>Byte 1-2 = Level 2 Switch Key (MIFARE Plus X only), or Level 3 Switch Key. See NXP doc ds206234, table 113.<br>Byte 3 = MIFARE Plus AES_Key#<br>- 0x01 = AES_Key1 = 16 bytes value stored in Property 1.2.1.1.4.5 MIFARE Plus AES_Key1.<br>- 0x02 = AES_Key2 = 16 bytes value stored in Property 1.2.1.1.4.6 MIFARE Plus AES_Key2.<br>- 0x03 = AES_Key3 = 16 bytes value stored in Property 1.2.1.1.4.7 MIFARE Plus AES_Key3.<br>- 0x04 = AES_Key4 = 16 bytes values stored in Property 1.2.1.1.4.8 MIFARE Plus AES_Key4.<br>- 0x05 = AES_Key5 = 16 bytes values stored in Property 1.2.1.1.4.9 MIFARE Plus AES_Key5.<br>- 0x06 = AES_Key6 = 16 bytes values stored in Property 1.2.1.1.4.A MIFARE Plus AES_Key6.</p></td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Following Authenticate (part 1 and part 2)</td><td>3</td><td>Following Authenticate. Use this command for an option to put the NFC tag in Security Level 1 AES Authenticated before sending MIFARE Classic commands.<br>Byte 0 = 0x76<br>Byte 1-2 = Security Level 1 Card Authentication Key. See NXP doc ds206234, table 113.<br>Byte 3 = MIFARE Plus AES_Key# (same key numbering as First Authenticate)</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>READ_SIG</td><td>2</td><td>The READ_SIG command returns an IC-specific, 48-byte ECC originality check signature.<br>Byte 0 = 0x3C<br>Byte 1 = 0x00, RF</td><td>Y</td><td>Y</td><td>N</td><td>N</td></tr><tr><td>Personalize UID</td><td>2</td><td><p>Set anti-collision, selection and authentication behavior. The execution of this command requires an authentication to MF Classic sector 0 (use MIFARE Read command sector 0 from <strong>Table 96 – MIFARE Classic/MINI® Commands</strong>). </p><p></p><p>Once this command has been issued and accepted by the PICC, the configuration is automatically locked. A subsequently issued ‘Personalize UID Usage’ command is not executed and fails.<br></p><p>Byte 0 = 0x40<br>Byte 1 = Encoded type of UID usage:<br>- 0x00 = UIDF0 = anti-collision and selection with the double size UID (7-byte) according to ISO/IEC14443-3<br>- 0x40 = UIDF1 = anti-collision and selection with the double size UID (7-byte) according to ISO/IEC14443-3 and optional usage of a selection process shortcut<br>- 0x20 = UIDF2 = anti-collision and selection with a single size random ID (4-byte) according to ISO/IEC14443-3. After the card is configured with random ID, it won’t be able to perform any MF Classic authentication since MF Classic authentication requires UID.<br>- 0x60 = UIDF3 = anti-collision and selection with a single size NUID (4-byte) according to ISO/IEC14443-3 where the NUID is calculated out of the 7-byte UID</p></td><td>Y</td><td>Y</td><td>N</td><td>N</td></tr><tr><td>CANCEL</td><td>1</td><td><p>This command is used to terminate the pass-through command session.</p><p><br>Byte 0 = 0xFF</p></td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr></tbody></table>

## Response Data for Command 0x1101 – Pass Through Command for MIFARE Classic/MINI®/Plus SL1 (Security Level 1), Type 2

<table><thead><tr><th width="110.66665649414062">Tag</th><th width="75.3333740234375">Len</th><th width="366">Value / Description</th><th width="77.66668701171875">Typ</th><th width="79.333251953125">Req</th><th width="102.0001220703125">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including Response Message </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1101 = <strong>Command 0x1101 – Pass Through Command for MIFARE Classic/MINI®/Plus SL1 (Security Level 1), Type 2</strong></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>81</td><td>var</td><td><p>Tag Response Code</p><p><br>Byte 0 = 0x00 = Success</p><p><br>Byte 0 = 0x01 = I/O Failed<br>Byte 0 = 0x02 = Authentication Failed<br>Byte 1 = 0x01 = Block that Failed (optional)</p></td><td>B</td><td>R</td><td>N/A</td></tr><tr><td>82</td><td>var</td><td>Encryption Control. If encrypted, see <strong>Table XX - Payload for Encrypted NFC/MIFARE Data</strong>. If unencrypted see <strong>Table XX – Unencrypted NFC/MIFARE Data</strong>.</td><td>B</td><td>O</td><td>N/A</td></tr><tr><td>End of any wrappers, at minimum including Response Message </td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

{% hint style="info" %}
If the request started successfully, the Request Status in the message wrapper is: OK, Started / Running, All good / requested operation was successful.
{% endhint %}

## Request Example (Read Sector 0, Block Number Start 0 - End 0, KeyType A, Key = FFFFFFFFFFFF)

{% code title="Example (Hex)" %}

```
AA 00 81 04 01 19 11 01 84 15 11 01 81 0B 30 00 00 00 00 FF FF FF FF FF FF 82 01 00 83 01 00
```

{% endcode %}

## Response Example (Read Sector 0, Block Number Start 0 - End 0, KeyType A, Key = FFFFFFFFFFFF)

{% code title="Example (Hex)" %}

```
AA 00 81 04 82 19 11 01 82 04 01 00 00 00 84 1C 11 01 81 01 00 82 15 FC 13 DF 7A 10 A4 FB 0D 3E
6C 08 04 00 03 0D C0 90 EE BF BB 1D

```

{% endcode %}

## Payload for Encrypted NFC/MIFARE Data

<table><thead><tr><th width="101.99996948242188">Tag</th><th width="75.33331298828125">Len</th><th>Value / Description</th><th width="73.3333740234375">Typ</th><th width="77">Req</th><th>Default</th></tr></thead><tbody><tr><td>/DFDF59</td><td>var</td><td>Encrypted Data Primitive. Decrypt the value of this TLV data object using the algorithm and variant specified in the <strong>Encrypted Data KSN</strong> parameter and the <strong>Encrypted Data Encryption Type</strong> parameter to read its contents. The format of the decrypted data is shown in <strong>Table XXX</strong>.</td><td>B</td><td>R</td><td></td></tr><tr><td>/DFDF50</td><td>var</td><td>Encrypted Data KSN</td><td>B</td><td>R</td><td></td></tr><tr><td>/DFDF51</td><td>01</td><td>Encrypted Data Encryption Type. See Encryption Type for a list of valid values.</td><td>B</td><td>R</td><td></td></tr><tr><td>End of any wrappers, at minimum including Response Message </td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## Unencrypted NFC/MIFARE Data

| Tag   | Len | Value / Description       | Typ | Req | Default |
| ----- | --- | ------------------------- | --- | --- | ------- |
| FC    | var | NFC/MIFARE Data Container | T   | R   |         |
| /DF7A | var | NFC/MIFARE Data           | B   | O   |         |


# Pass Through Command for MIFARE DESFire, Type 4 - Command 0x1102

After a MIFARE DESFire Light/EV1/EV2/EV3 Tag is activated, the host uses this command to send commands and receive responses to and from a MIFARE DESFire Tag.

There will be a fixed 30 second timeout for commands that require multiple command/responses.

{% hint style="info" %}
Timeout: 30 seconds for commands that require multiple command/responses.
{% endhint %}

## Request Data for Pass Through Command for MIFARE DESFire, Type 4 - Command 0x1102

<table><thead><tr><th>Tag</th><th width="74.66668701171875">Len</th><th width="301.66668701171875">Value / Description</th><th width="75">Typ</th><th width="72.99993896484375">Req</th><th width="97.99993896484375">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including <strong>Request Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1102</td><td></td><td>Pass Through Command for MIFARE DESFire, Type 4 - Command 0x1102</td><td></td><td></td><td></td></tr><tr><td>81</td><td>var</td><td><p>Command to Send. See DESFire Data Sheet (MF2DLHX0). Should follow ISO 7816-4 APDU format:</p><ul><li><p>C-APDU</p><ul><li>CLA INS P1 P2 Lc Data Le</li></ul></li></ul></td><td>B</td><td>R</td><td></td></tr><tr><td>82</td><td>01</td><td>00 – No Encrypt 01 - Encrypt</td><td></td><td></td><td></td></tr><tr><td>83</td><td>01</td><td>00 – Expect More Commands 01 – FF (Last Command). If last command, Device will provide a single beep after receiving a successful response from tag; otherwise, device will provide a double beep.</td><td>B</td><td>R</td><td></td></tr><tr><td>End of any wrappers, at minimum including <strong>Request Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## Response Data for Command Pass Through Command for MIFARE DESFire, Type 4 - 0x1102

<table><thead><tr><th>Tag</th><th width="74.66668701171875">Len</th><th width="290">Value / Description</th><th width="76.3333740234375">Typ</th><th width="76">Req</th><th width="96.00006103515625">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including <strong>Response Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1102</td><td></td><td>Pass Through Command for MIFARE DESFire, Type 4 - Command 0x1102</td><td></td><td></td><td></td></tr><tr><td>81</td><td>02</td><td><p>Tag Response (SW1 SW2). See DESFire Data Sheet (MF2DLHX0). Should follow ISO 7816-4 APDU format:</p><ul><li>SW1 and SW2 of R-APDU</li></ul><p>If card is not able to respond:</p><ul><li>SW1 = 0x64, SW2 = 0x00</li></ul></td><td>B</td><td>R</td><td>N/A</td></tr><tr><td>82</td><td>var</td><td><p>Tag Data:</p><ul><li>Data of R-APDU</li></ul><p>Encryption Control: If encrypted, see <strong>Table XXX- Payload for Encrypted NFC/MIFARE Data</strong>. If unencrypted, see <strong>Table XXX– Unencrypted NFC/MIFARE Data</strong>.</p></td><td>B</td><td>O</td><td>N/A</td></tr><tr><td>End of any wrappers, at minimum including <strong>Response Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

If the request started successfully, the Request Status in the message wrapper is: OK, Started / Running, All good / requested operation was successful.

## Request Example (Get Version Part 1)

{% code title="Example (Hex)" %}

```
AA 00 81 04 01 13 11 02 84 0F 11 02 81 05 90 60 00 00 00 82 01 00 83 01 00
```

{% endcode %}

## Response Example (Get Version Part 1)

{% code title="Example (Hex)" %}

```
AA 00 81 04 82 13 11 02 82 04 01 00 00 00 84 14 11 02 81 02 91 AF 82 0C FC 0A DF 7A 07 04 08 01
30 00 13 05
```

{% endcode %}

## Encrypted Data Format

## Payload for Encrypted NFC/MIFARE Data

<table><thead><tr><th width="82.66665649414062">Tag</th><th width="69">Len</th><th width="383.66668701171875">Value / Description</th><th width="73">Typ</th><th width="75">Req</th><th width="98.66671752929688">Default</th></tr></thead><tbody><tr><td>/DFDF59</td><td>var</td><td>Encrypted Data Primitive. Decrypt the value of this TLV data object using the algorithm and variant specified in the <strong>Encrypted Data KSN</strong> parameter and the <strong>Encrypted Data Encryption Type</strong> parameter to read its contents. The format of the decrypted data is shown in <strong>Table XXX</strong>.</td><td>B</td><td>R</td><td></td></tr><tr><td>/DFDF50</td><td>var</td><td>Encrypted Data KSN</td><td>B</td><td>R</td><td></td></tr><tr><td>/DFDF51</td><td>01</td><td>Encrypted Data Encryption Type. See <strong>Encryption Type</strong> for a list of valid values.</td><td>B</td><td>R</td><td></td></tr><tr><td>End of Notification Message</td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## Unencrypted NFC/MIFARE Data

| Tag   | Len | Value / Description       | Typ | Req | Default |
| ----- | --- | ------------------------- | --- | --- | ------- |
| FC    | var | NFC/MIFARE Data Container | T   | R   |         |
| /DF7A | var | NFC/MIFARE Data           | B   | O   |         |


# Pass Through Command for MIFARE Plus, Type 2 - Command 0x1103

After a MIFARE Plus EV1/EV2/SE/X Tag is activated, the Host uses this command to send commands and receive responses to and from a MIFARE Plus tag.

For MIFARE Plus SE/X, the Device will not auto detect an error from the MIFARE Tag that has been removed to end the pass-through session. To end the pass-through session, the Host application can send the last command, CANCEL command (0xFF), or receive error response from the MIFARE Tag.

For MIFARE Plus EV1/EV2 at Security Level 3, after the first Read/Write/Value operation, the Device will not auto detect an error from the MIFARE Tag that has been removed to end the pass-through session. To end the pass-through session, the Host application can send the last command, CANCEL command (0xFF), or receive error response from the MIFARE Tag.

After the card is configured to successfully switch to Security Level 1, the card will be discovered as MIFARE Classic 1K/4K and can use the same functionality as MIFARE Classic 1K/4K commands.

For more details, please refer to NXP NDA documentation ds206234-Product data sheet MIFARE Plus Functionality of implementations on smart card controllers (3.4)

## Pass Through Command for MIFARE Plus, Type 2 - Command 0x1103

<table><thead><tr><th>Tag</th><th width="76.33331298828125">Len</th><th width="319">Value / Description</th><th width="74">Typ</th><th width="80">Req</th><th width="98.666748046875">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including <strong>Request Message</strong></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td><strong>1103 =</strong> Pass Through Command for MIFARE Plus, Type 2 - Command 0x1103 – </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>81</td><td>var</td><td>Command to Send. See Table 110 - MIFARE Plus EV1/EV2/SE/X SL0 (Security Level 0) Commands. See Table 111 – MIFARE Plus EV1/EV2/SE/X SL3 (Security Level 3) Commands</td><td>B</td><td>R</td><td></td></tr><tr><td>82</td><td>01</td><td>00 – No Encrypt 01 - Encrypt</td><td></td><td></td><td></td></tr><tr><td>83</td><td>01</td><td>00 – Expect More Commands 01 – FF (Last Command) If this is the last command, the Device will provide a single beep after receiving a successful response from the tag, otherwise, the device will provide a double beep</td><td>B</td><td>R</td><td></td></tr><tr><td>End of any wrappers, at minimum including Request Message</td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## MIFARE Plus EV1/EV2/SE/X SL0 (Security Level 0) Commands

<table><thead><tr><th width="117.33331298828125">Command</th><th width="98">Length</th><th width="295.66668701171875">Field Value</th><th width="75">EV1</th><th width="77.9998779296875">EV2</th><th width="66.6666259765625">SE</th><th width="59.3333740234375">X</th></tr></thead><tbody><tr><td>GET_VERSION</td><td>1</td><td>The GET_VERSION command is used to retrieve manufacturing related data of the MIFARE Plus EV1/EV2 cards Byte 0 = 0x60</td><td>Y</td><td>Y</td><td>N</td><td>N</td></tr><tr><td>READ_SIG</td><td>2</td><td>The READ_SIG command returns an IC-specific, 48-byte ECC originality check signature of MIFARE Plus EV1/EV2 cards. Byte 0 = 0x3C Byte 1 = 0x00, RFU</td><td>Y</td><td>Y</td><td>N</td><td>N</td></tr><tr><td>WRITE_PERSO</td><td>19</td><td><p>The WRITE_PERSO command is used to pre-personalize AES keys and data from the initial delivery configuration to a customer specific value. </p><p></p><p>Byte 0 = 0xA8 </p><p>Byte 1-2 = Number of Block or Key to be written to (MSB first). See NXP doc ds206234, table 113. </p><p>Byte 3 to 18 = 16 bytes value of the key or data which shall be written (in plain)</p></td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>COMMIT_PERSO</td><td>2</td><td><p>The COMMIT_PERSO command is used to finalize the personalization and switch up to security level 1 or security level 3. </p><p></p><p>For MIFARE Plus EV1/EV2, the following mandatory AES keys must be written using the WRITE_PERSO command before it can be switched to security level 1 or security level 3.</p><ul><li>Card Configuration Key</li><li>Card Master Key</li><li>Level 2 Switch Key</li><li>Level 3 Switch Key</li></ul><p></p><p>For MIFARE Plus SE, the following mandatory AES keys must be written using the WRITE_PERSO command before it can be switched to security level 1 (for L1 card) or security level 3 (for L3 card).</p><ul><li>Card Configuration Key</li><li>Card Master Key</li><li>Level 3 Switch Key</li></ul><p></p><p>For MIFARE Plus X, the following mandatory AES keys must be written using the WRITE_PERSO command before it can be switched to security level 1 (for L1 card) or security level 3 (for L3 card).</p><ul><li>Card Configuration Key</li><li>Card Master Key</li><li>Level 2 Switch Key (for L1 card)</li><li>Level 3 Switch Key (for L1 card)</li></ul><p></p><p>Byte 0 = 0xAA </p><p>Byte 1 = Security Level Option for EV1 and EV2 cards</p><ul><li>0x01 = Security Level 1</li><li>0x03 = Security Level 3</li><li>Other values = Invalid. Device will return error.</li></ul><p></p><p>Byte 1 = 0x00 for SE and X cards. The Device will return error for other values. </p><p></p><p>It is also highly recommended to change all sector AES keys as well as the data within this security level in a secure environment.</p><p></p><p>This command is behaved as the last command. The Device will provide a single beep after receiving a successful response from a card, otherwise, device will provide a double beep.</p></td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>CANCEL</td><td>1</td><td><p>This command is used to terminate the pass-through command session. </p><p></p><p>Byte 0 = 0xFF</p></td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr></tbody></table>

## MIFARE Plus EV1/EV2/SE/X SL3 (Security Level 3) Commands

<table><thead><tr><th width="130.33331298828125">Command</th><th width="96">Length</th><th width="327">Field Value</th><th width="74">EV1</th><th width="77.99993896484375">EV2</th><th width="67.33331298828125">SE</th><th width="42.6666259765625">X</th></tr></thead><tbody><tr><td>MIFARE Plus Authenticate commands</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>First Authenticate (part1 and part2)</td><td>3</td><td><p>First Authenticate Byte 0 = 0x70 Byte 1-2 = Key Number of the key to be authenticated (MSB first). See NXP doc ds206234, table 113. Byte 3 = MIFARE Plus AES_Key#</p><ul><li>0x01 = AES_Key1 = 16 bytes value stored in Property 1.2.1.1.4.5 MIFARE Plus AES_Key1.</li><li>0x02 = AES_Key2 = 16 bytes value stored in Property 1.2.1.1.4.6 MIFARE Plus AES_Key2.</li><li>0x03 = AES_Key3 = 16 bytes value stored in Property 1.2.1.1.4.7 MIFARE Plus AES_Key3.</li><li>0x04 = AES_Key4 = 16 bytes values stored in Property 1.2.1.1.4.8 MIFARE Plus AES_Key4.</li><li>0x05 = AES_Key5 = 16 bytes values stored in Property 1.2.1.1.4.9 MIFARE Plus AES_Key5.</li><li>0x06 = AES_Key6 = 16 bytes values stored in Property 1.2.1.1.4.A MIFARE Plus AES_Key6.</li></ul></td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Following Authenticate (part 1 and part 2)</td><td>3</td><td>Following Authenticate Byte 0 = 0x76 Byte 1-2 = Key Number of the key to be authenticated (MSB first). See NXP doc ds206234, table 113. Byte 3 = MIFARE Plus AES_Key# (same AES_Key# options as First Authenticate)</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>ResetAuth</td><td>1</td><td>Reset the authentication Byte 0 = 0x78</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>READ commands</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Read</td><td>4</td><td>Reading encrypted, no MAC on response, MAC on command. This command offers the possibility to read the data from one or multiple blocks in an encrypted way. A MAC is only used on the command sent to the PICC, no MAC is attached to the response. Byte 0 = 0x30 Byte 1-2 = Block number of the 1st block to be read (MSB first). See NXP doc ds206234, table 113. Byte 3 = 0x01 – 0x0F = Number of blocks to be read. Sector Trailers do not count if Byte 3 > 1. Use Byte 3 = 1 for reading Sector Trailer.</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Read MACed</td><td>4</td><td>Reading encrypted, MAC on response, MAC on Command. This command offers the possibility to read the data from one or multiple blocks in an encrypted way. A MAC is used on the command sent to the PICC and on the response received. Byte 0 = 0x31 Byte 1-2 = Block number of the 1st block to be read (MSB first). See NXP doc ds206234, table 113. Byte 3 = 0x01 – 0x0F = Number of blocks to be read. Sector Trailers do not count if Byte 3 > 1. Use Byte 3 = 1 for reading Sector Trailer.</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Read Plain</td><td>4</td><td>Reading in plain, no MAC on response, MAC on command. This command offers the possibility to read the data in plain from one or multiple blocks. A MAC is used on the command and not on the response. Byte 0 = 0x32 Byte 1-2 = Block number of the 1st block to be read (MSB first). See NXP doc ds206234, table 113. Byte 3 = 0x01 – 0x0F = Number of blocks to be read. Sector Trailers do not count if Byte 3 > 1. Use Byte 3 = 1 for reading Sector Trailer.</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Read Plain MACed</td><td>4</td><td>Reading in plain, MAC on response, MAC on command. This command offers the possibility to read the data in plain from one or multiple blocks. A MAC is used on the command sent to the PICC as well as on the response from the PICC Byte 0 = 0x33 Byte 1-2 = Block number of the 1st block to be read (MSB first). See NXP doc ds206234, table 113. Byte 3 = 0x01 – 0x0F = Number of blocks to be read. Sector Trailers do not count if Byte 3 > 1. Use Byte 3 = 1 for reading Sector Trailer.</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Read UnMACed</td><td>4</td><td>Reading encrypted, no MAC on response, no MAC on command. This command offers the possibility to read the data from one or multiple blocks in an encrypted way. By default, Read with MAC on command is required. To Read with no MAC on command, needs to modify the card MFP Configuration Block. Byte 0 = 0x34 Byte 1-2 = Block number of the 1st block to be read (MSB first). See NXP doc ds206234, table 113. Byte 3 = 0x01 – 0x0F = Number of blocks to be read. Sector Trailers do not count if Byte 3 > 1. Use Byte 3 = 1 for reading Sector Trailer.</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Read UnMACed, Response MACed</td><td>4</td><td>Reading encrypted, MAC on response, no MAC on command. This command offers the possibility to read the data from one or multiple blocks in an encrypted way. A MAC is used only on the response received. By default, Read with MAC on command is required. To Read with no MAC on command, needs to modify the card MFP Configuration Block. Byte 0 = 0x35 Byte 1-2 = Block number of the 1st block to be read (MSB first). See NXP doc ds206234, table 113. Byte 3 = 0x01 – 0x0F = Number of blocks to be read. Sector Trailers do not count if Byte 3 > 1. Use Byte 3 = 1 for reading Sector Trailer.</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Read Plain UnMACed</td><td>4</td><td>Reading in plain, no MAC on response, no MAC on command. This command offers the possibility to read the data in plain from one or multiple blocks. A MAC is not used on the response and not on the command. By default, Read with MAC on command is required. To Read with no MAC on command, needs to modify the card MFP Configuration Block. Byte 0 = 0x36 Byte 1-2 = Block number of the 1st block to be read (MSB first). See NXP doc ds206234, table 113. Byte 3 = 0x01 – 0x0F = Number of blocks to be read. Sector Trailers do not count if Byte 3 > 1. Use Byte 3 = 1 for reading Sector Trailer.</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Read Plain UnMACed, Response MACed</td><td>4</td><td>Reading in plain, MAC on response, no MAC on command. This command offers the possibility to read the data in plain from one or multiple blocks. A MAC is used on the response and not on the command. By default, Read with MAC on command is required. To Read with no MAC on command, needs to modify the card MFP Configuration Block. Byte 0 = 0x37 Byte 1-2 = Block number of the 1st block to be read (MSB first). See NXP doc ds206234, table 113. Byte 3 = 0x01 – 0x0F = Number of blocks to be read. Sector Trailers do not count if Byte 3 > 1. Use Byte 3 = 1 for reading Sector Trailer.</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>WRITE commands</td><td></td><td></td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Write</td><td>20/36/52</td><td>Writing encrypted, no MAC on response, MAC on Command. This command offers the possibility to write the data to up to three blocks in an encrypted way. MAC is only used on the command sent to the PICC. Byte 0 = 0xA0 Byte 1-2 = Block number of the 1st to be written block (MSB first). See NXP doc ds206234, table 113. Byte 3 = 0x01/0x02/0x03 = number of blocks (16 byte) of the data to be written Byte 4 – n = Data to be written, equal to number of blocks * 16.</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Write MACed</td><td>20/36/52</td><td>Writing encrypted, MAC on response, MAC on command. This command offers the possibility to write the data to up to three blocks in an encrypted way. A MAC is used on the command sent to the PICC and on the response received from the PICC. Byte 0 = 0xA1 Byte 1-2 = Block number of the 1st to be written block (MSB first). See NXP doc ds206234, table 113. Byte 3 = 0x01/0x02/0x03 = number of blocks (16 byte) of the data to be written Byte 4 – n = Data to be written, equal to number of blocks * 16.</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Write Plain</td><td>20/36/52</td><td>Writing in plain, no MAC on response, MAC on command. This command offers the possibility to write the data to up to three blocks in plain. A MAC is only used on the command sent to the PICC. Byte 0 = 0xA2 Byte 1-2 = Block number of the 1st to be written block (MSB first). See NXP doc ds206234, table 113. Byte 3 = 0x01/0x02/0x03 = number of blocks (16 byte) of the data to be written Byte 4 – n = Data to be written, equal to number of blocks * 16.</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Write Plain MACed</td><td>20/36/52</td><td>Writing in plain, MAC on response, MAC on command. This command offers the possibility to write the data to up to three blocks in plain. A MAC is used on the command sent to the PICC as well as on the response from the PICC Byte 0 = 0xA3 Byte 1-2 = Block number of the 1st to be written block (MSB first). See NXP doc ds206234, table 113. Byte 3 = 0x01/0x02/0x03 = number of blocks (16 byte) of the data to be written Byte 4 – n = Data to be written, equal to number of blocks * 16.</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>VALUE operations</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Increment</td><td>7</td><td>Increment encrypted, no MAC on response, MAC on command. This command offers the possibility to increment a value block where the command is secured by a MAC calculated, but not on the response. Byte 0 = 0xB0 Byte 1-2 = Source Block number (MSB first). Byte 3-6 = The 4 bytes value to be incremented in LSB order. Example for increment by 1: 0x01 00 00 00</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Increment MACed</td><td>7</td><td>Increment encrypted, MAC on response, MAC on command. Byte 0 = 0xB1 Byte 1-2 = Source Block number (MSB first). Byte 3-6 = The 4 bytes value to be incremented in LSB order. Example for increment by 1: 0x01 00 00 00</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Decrement</td><td>7</td><td>Decrement encrypted, no MAC on response, MAC on command. Byte 0 = 0xB2 Byte 1-2 = Source Block number (MSB first). Byte 3-6 = The 4 bytes value to be decremented in LSB order. Example for decrement by 1: 0x01 00 00 00</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Decrement MACed</td><td>7</td><td>Decrement encrypted, MAC on response, MAC on command. Byte 0 = 0xB3 Byte 1-2 = Source Block number (MSB first). Byte 3-6 = The 4 bytes value to be decremented in LSB order. Example for decrement by 1: 0x01 00 00 00</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Transfer</td><td>3</td><td>Transfer, no MAC on response, MAC on command. The Transfer command stores the content of the Transfer Buffer to the specified address. The Transfer command can be applied to any block. The Transfer command can only be executed after an Increment, Decrement, IncrementTransfer, DecrementTransfer or Restore command has been successfully executed since the latest authentication. The command is secured by a MAC on a command. No MAC is calculated on the response. Byte 0 = 0xB4 Byte 1-2 = Destination Block number (MSB first).</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Transfer MACed</td><td>3</td><td>Transfer, MAC on response, MAC on command. Byte 0 = 0xB5 Byte 1-2 = Destination Block number (MSB first).</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Increment Transfer</td><td>9</td><td>Increment Transfer encrypted, no MAC on response, MAC on Command. Combined increment and transfer. Byte 0 = 0xB6 Byte 1-2 = Source Block number (MSB first). Byte 3-4 = Destination Block number (MSB first). Byte 5-8 = The 4 bytes value to be incremented in LSB order. Example for increment by 1: 0x01 00 00 00</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Increment Transfer MACed</td><td>9</td><td>Increment Transfer encrypted, MAC on response, MAC on command. Byte 0 = 0xB7 Byte 1-2 = Source Block number (MSB first). Byte 3-4 = Destination Block number (MSB first). Byte 5-8 = The 4 bytes value to be incremented in LSB order.</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Decrement Transfer</td><td>9</td><td>Decrement Transfer encrypted, no MAC on response, MAC on command. Byte 0 = 0xB8 Byte 1-2 = Source Block number (MSB first). Byte 3-4 = Destination Block number (MSB first). Byte 5-8 = The 4 bytes value to be decremented in LSB order. Example for decrement by 1: 0x01 00 00 00</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Decrement Transfer MACed</td><td>9</td><td>Decrement Transfer encrypted, MAC on response, MAC on command. Byte 0 = 0xB9 Byte 1-2 = Source Block number (MSB first). Byte 3-4 = Destination Block number (MSB first). Byte 5-8 = The 4 bytes value to be decremented in LSB order. Example for decrement by 1: 0x01 00 00 00</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Restore</td><td>3</td><td>Restore encrypted, no MAC on response, MAC on command. The Restore command copies the Content found in the Value Block at the given address to the Transfer Buffer. The Restore command can only be applied to value blocks. Byte 0 = 0xC2 Byte 1-2 = Source Block number (MSB first).</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Restore MACed</td><td>3</td><td>Restore encrypted, MAC on response, MAC on command. Byte 0 = 0xC3 Byte 1-2 = Source Block number (MSB first).</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Others</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>GET_VERSION</td><td>1</td><td>The GET_VERSION command is used to retrieve manufacturing related data of the MIFARE Plus EV1/EV2 cards. This command can be sent before Read/Write/Value commands. Byte 0 = 0x60</td><td>Y</td><td>Y</td><td>N</td><td>N</td></tr><tr><td>READ_SIG</td><td>2</td><td>The READ_SIG command returns an IC-specific, 48-byte ECC originality check signature of MIFARE Plus EV1/EV2 cards. This command can be sent before Read/Write/Value commands. Byte 0 = 0x3C Byte 1 = 0x00, RFU</td><td>Y</td><td>Y</td><td>N</td><td>N</td></tr><tr><td>CANCEL</td><td>1</td><td>This command is used to terminate the pass-through command session. Byte 0 = 0xFF</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr></tbody></table>

## Response Data for Command 0x1103 – Pass Through Command for MIFARE Plus, Type 2

<table><thead><tr><th>Tag</th><th width="76.66668701171875">Len</th><th width="252.66668701171875">Value / Description</th><th width="75">Typ</th><th width="74.66668701171875">Req</th><th width="97.3333740234375">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including Response Message</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1103 = Command 0x1103 – Pass Through Command for MIFARE Plus, Type 2</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>81</td><td>01</td><td>Tag Response Code 0x00 = Success 0x01 = Failed</td><td>B</td><td>R</td><td>N/A</td></tr><tr><td>82</td><td>Var</td><td>Encryption Control If encrypted, see Table 93 - Payload for Encrypted NFC/MIFARE Data. If unencrypted see Table 94 – Unencrypted NFC/MIFARE Data.</td><td>B</td><td>O</td><td>N/A</td></tr><tr><td>End of any wrappers, at minimum including Response Message</td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

If the request started successfully, the Request Status in the message wrapper is OK, Started / Running, All good / requested operation was successful.

## Request Example (Get Version)

{% code title="Example (Hex)" %}

```
AA 00 81 04 01 DA 11 03 84 0B 11 03 81 01 60 82 01 00 83 01 00
```

{% endcode %}

## Response Example (Get Version)

{% code title="Example (Hex)" %}

```
AA 00 81 04 82 DA 11 03 82 04 01 00 00 00 84 28 11 03 81 01 00 82 21 FC 1F DF 
7A 1C 04 02 01 11 00 16 04 04 02 01 01 01 16 04 04 4D 59 5A 3E 18 90 CF 8D 15 
61 51 21 23
```

{% endcode %}

## Encrypted Data Format

## Payload for Encrypted NFC/MIFARE Data

<table><thead><tr><th width="96">Tag</th><th width="73.66668701171875">Len</th><th width="373">Value / Description</th><th width="73.66668701171875">Typ</th><th width="74.3333740234375">Req</th><th width="100.666748046875">Default</th></tr></thead><tbody><tr><td>/DFDF59</td><td>var</td><td>Encrypted Data Primitive. Decrypt the value of this TLV data object using the algorithm and variant specified in the <strong>Encrypted Data KSN</strong> parameter and the <strong>Encrypted Data Encryption Type</strong> parameter to read its contents. The format of the decrypted data is shown in Table 360.</td><td>B</td><td>R</td><td></td></tr><tr><td>/DFDF50</td><td>var</td><td>Encrypted Data KSN</td><td>B</td><td>R</td><td></td></tr><tr><td>/DFDF51</td><td>01</td><td>Encrypted Data Encryption Type. See Encryption Type for a list of valid values.</td><td>B</td><td>R</td><td></td></tr><tr><td>End of Notification Message</td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## Unencrypted NFC/MIFARE Data

| Tag   | Len | Value / Description       | Typ | Req | Default |
| ----- | --- | ------------------------- | --- | --- | ------- |
| FC    | var | NFC/MIFARE Data Container | T   | R   |         |
| /DF7A | var | NFC/MIFARE Data           | B   | O   |         |


# User Interface - Command Group 0x18nn

## User Interface

The host uses these commands to interact with various areas of the device's user interface.

{% hint style="success" %}
Applies to: All Dyna Family products
{% endhint %}

### Information in this group

| **Section**                                                                                                                                                                                                                                        | **Information**                                                                                                                                                                                                                 |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [<mark style="color:red;">**Request Cardholder Signature (Touch Only)**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/request-cardholder-signature-touch-only-command-0x1801) | The host uses this command to prompt a cardholder for a signature.                                                                                                                                                              |
| [<mark style="color:red;">**Report Cardholder Selection**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/report-cardholder-selection-command-0x1802)                           | The host uses this command to provide a cardholder selection to the device when the device itself does not have a display or inputs to prompt the cardholder for a selection.                                                   |
| [<mark style="color:red;">**Display Message (Display Only)**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/display-message-display-only-command-0x1803)                       | The host uses this command to request that the device display a message for the cardholder.                                                                                                                                     |
| [<mark style="color:red;">**Read Barcode (BCR Only)**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/read-barcode-bcr-only-command-0x1804)                                     | The host uses this command to direct the device to arm or disarm the barcode reader for reading a barcode outside the scope of a transaction.                                                                                   |
| [<mark style="color:red;">**Buzzer**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/buzzer-command-0x1805)                                                                     | The host uses this command to start a buzzer for playing a sequence of tones.                                                                                                                                                   |
| [<mark style="color:red;">**Personal Info Entry**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/personal-info-entry-command-0x1806)                                           | The host uses this command to prompt a cardholder for customer information.                                                                                                                                                     |
| [<mark style="color:red;">**LED Control**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/led-control-command-0x1807)                                                           | The host uses this command to control the 4 LEDs of the device when the device is not in non-User Control LED states.                                                                                                           |
| [<mark style="color:red;">**Show Image (Display Only)**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/show-image-display-only-command-0x1821)                                 | The host uses this command to trigger the device to immediately show a pre-loaded image on the display, provided the device is not in a mode that has exclusive use of the display (such as during a transaction).              |
| [<mark style="color:red;">**Show QR Code (Display Only)**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/show-qr-code-display-only-command-0x1822)                             | The host uses this command to direct the device to immediately show a QR code on the display, provided the device is not in a mode that has exclusive use of the display (such as during a transaction).                        |
| [<mark style="color:red;">**Show Bitmap Image (Display Only)**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/show-image-display-only-command-0x1821)                          | The host uses this command to trigger the device to immediately show a bitmap file the host includes as a parameter, provided the device is not in a mode that has exclusive use of the display (such as during a transaction). |
| [<mark style="color:red;">**Display Flexible UI Pages (Display Only)**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/display-flexible-ui-pages-display-only-command-0x1830)   | This command allows the host to bring up standalone pages.                                                                                                                                                                      |
| [<mark style="color:red;">**Card Emulation**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/user-interface-command-group-0x18nn/card-emulation-command-0x1840)                                                     | Card emulation is initiated by receiving a 0x1840 command from the host.                                                                                                                                                        |

### Need More Help

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** [support@magtek.com](mailto:support@magtek.com?subject=Support%20Request)
* 📞 **Phone:** 1-562-546-6800 (US)
* 🕐 **Hours:** Monday-Friday, 5:30 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Support Portal:** developer.magtek.com

**Documentation Feedback:**

Help us improve this documentation! [feedback@magtek.com](mailto:feedback@magtek.com?subject=Feedback)
{% endhint %}


# Request Cardholder Signature (Touch Only) - Command 0x1801

The host uses this command to prompt a cardholder for a signature.

The sequence of events is as follows:

{% stepper %}
{% step %}

### Transaction completed / Host may request signature

The device completes a transaction after the host invokes **Start Transaction - Command 0x1001**. At the end of the transaction, the device has provided data to the host in **Transaction Operation Complete - Notification 0x0105**. The host may send Command 0x1801 to the device to get a signature file without doing a transaction. The signature file can be encrypted if enabled.
{% endstep %}

{% step %}

### Host decides whether to request a signature

The host decides whether to request a signature from the cardholder. For example:

* If the Notification Detail in **Transaction Operation Complete**  - **Notification 0x0105** indicates Signature Capture Requested.
* If an application-specific rule requires requesting a signature.
  {% endstep %}

{% step %}

### Host composes command

If the host determines it should request a signature, it composes a command request in the format shown below.
{% endstep %}

{% step %}

### Device presents signature UI

The device presents a signature capture interface to the cardholder on the display.
{% endstep %}

{% step %}

### Device notifies host of completion or issues

The device sends **User Interface Operation Complete - Notification 0x1805** to the host to report data available, timeout, or hardware failure.
{% endstep %}

{% step %}

### Host retrieves signature file (if data available)

If the device reported data available, the host uses **Start Get File from Device - Command 0xD821** to request file type **Signature Capture File** to retrieve the data as a **Signature Capture File Type**.
{% endstep %}
{% endstepper %}

## Request Data for Request Cardholder Signature (Touch Only) - Command 0x1801

<table><thead><tr><th>Tag</th><th width="76">Len</th><th width="264.3333740234375">Value / Description</th><th width="75.66668701171875">Typ</th><th width="75.33331298828125">Req</th><th width="98">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including <strong>Request Message</strong></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1801 = <strong>Request Cardholder Signature (Touch Only) - Command 0x1801</strong></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>81</td><td>01</td><td>Timeout — Timeout in seconds that the device should wait for the cardholder to sign and confirm completion.</td><td>B</td><td>R</td><td></td></tr><tr><td>82</td><td>01</td><td>Encryption on signature and user data. 0=disabled, 1=enabled.</td><td>B</td><td>O</td><td>0</td></tr><tr><td>A3</td><td>var</td><td>User data parameters for item #0 to item #3. The maximum total size of 0xA3 TLV is 4,000 bytes. This TLV may be present only if encryption is enabled.</td><td>T</td><td>O</td><td></td></tr><tr><td>/81</td><td>var</td><td>User data item #0, optional</td><td>B</td><td>O</td><td></td></tr><tr><td>/82</td><td>var</td><td>User data item #1, optional</td><td>B</td><td>O</td><td></td></tr><tr><td>/83</td><td>var</td><td>User data item #2, optional</td><td>B</td><td>O</td><td></td></tr><tr><td>/84</td><td>var</td><td>User data item #3, optional</td><td>B</td><td>O</td><td></td></tr><tr><td>End of any wrappers, at minimum including <strong>Request Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## Response Data for Command 0x1801 - Request Cardholder Signature (Touch Only)

<table><thead><tr><th>Tag</th><th width="75">Len</th><th width="253">Value / Description</th><th width="74.66668701171875">Typ</th><th width="74">Req</th><th width="98">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including <strong>Response Message</strong></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1801 = <strong>Request Cardholder Signature (Touch Only) - Command 0x1801</strong></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>No parameters.</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>End of any wrappers, at minimum including <strong>Response Message</strong></td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

If the request started successfully, the Request Status in the message wrapper is **OK, Started / Running, All good / requested operation was successful**.

## Request Example

{% code title="Example (Hex)" %}

```
AA 00 81 04 01 00 18 01 84 05 18 01 81 01 1E
```

{% endcode %}

## Response Example

{% code title="Example (Hex)" %}

```
AA 00 81 04 82 00 18 01 82 04 01 00 00 00
```

{% endcode %}


# Report Cardholder Selection - Command 0x1802

The host uses this command to provide a cardholder selection to the device when the device itself does not have a display or inputs to prompt the cardholder for a selection.

Sequence of events:

{% stepper %}
{% step %}

### Transaction already started

The host has already invoked Start Transaction - Command 0x1001  and the transaction is still in process.
{% endstep %}

{% step %}

### Device requests host UI action

During the transaction, if the device does not have a display or touchscreen but needs to show information to the cardholder or needs the cardholder to make a selection, it sends the host **User Interface Host Action Request** - **Notification 0x1803** to report Display / Cardholder Selection and supporting information.
{% endstep %}

{% step %}

### Host prompts cardholder

The host uses its user interface to request a selection from the cardholder based on the information and selectable items provided by the notification message.
{% endstep %}

{% step %}

### Host reports the selection to the device

The host sends the user selection to the device by sending Command 0x1802 in the format described below.
{% endstep %}
{% endstepper %}

## Request Data for Report Cardholder Selection - Command 0x1802

Beginning of any wrappers, at minimum including **Request Message**.

<table><thead><tr><th width="74.66665649414062">Tag</th><th width="74">Len</th><th width="437.33331298828125">Value / Description</th><th width="75.66668701171875">Typ</th><th width="75.33331298828125">Req</th><th width="97.3333740234375">Default</th></tr></thead><tbody><tr><td>1802</td><td></td><td> <strong>Report Cardholder Selection = Command 0x1802</strong></td><td></td><td></td><td></td></tr><tr><td>81</td><td>01</td><td>Cardholder Selection Request Status<br>- 0x00 = Cardholder Selection Request completed, see Selection Result parameter.<br>- 0x01 = Cardholder Selection Request canceled by cardholder, Transaction Aborted.<br>- 0x02 = Cardholder Selection Request timed out, Transaction Aborted.</td><td>B</td><td>R</td><td></td></tr><tr><td>82</td><td>01</td><td>Selection Result — Menu item index the cardholder selected. If the cardholder made no selection or the operation terminated abnormally, the device does not include this parameter.</td><td>B</td><td>O</td><td></td></tr><tr><td></td><td></td><td>End of any wrappers, at minimum including <strong>Request Message</strong>.</td><td></td><td></td><td></td></tr></tbody></table>

If the request started successfully, the Request Status in the message wrapper is **OK, Started / Running, All good / requested operation was successful**.

Response Data for Report Cardholder Selection - Command 0x1802

Beginning of any wrappers, at minimum including **Response Message**.

<table><thead><tr><th width="73.66665649414062">Tag</th><th width="77.3333740234375">Len</th><th>Value / Description</th><th width="75.33331298828125">Typ</th><th width="73.33331298828125">Req</th><th width="97.3333740234375">Default</th></tr></thead><tbody><tr><td>1802</td><td></td><td><strong>Report Cardholder Selection - Command 0x1802</strong> </td><td></td><td></td><td></td></tr><tr><td></td><td></td><td>No parameters.</td><td></td><td></td><td></td></tr><tr><td></td><td></td><td>End of any wrappers, at minimum including <strong>Response Message</strong>.</td><td></td><td></td><td></td></tr></tbody></table>

## Request Example (Hex)

{% code title="Request (hex)" %}

```
AA 00 81 04 01 00 18 02 84 08 18 02 81 01 00 82 01 00
```

{% endcode %}

## Response Example (Hex)

{% code title="Response (hex)" %}

```
AA 00 81 04 82 00 18 02 82 04 01 00 00 00
```

{% endcode %}


# Display Message (Display Only) - Command 0x1803

The host uses this command to request that the device display a message for the cardholder.

The sequence of events is as follows:

{% stepper %}
{% step %}
The host ensures the device is not currently running another command, for example, that it is not running a transaction using **Start Transaction - Command 0x1001**.
{% endstep %}

{% step %}
The host selects the message it wants to display from the list of available pre-determined strings.
{% endstep %}

{% step %}
The host composes a command request in the format below, and sends it to the device.
{% endstep %}

{% step %}
The device displays the requested message.

* If the Timeout parameter is set to Infinite, the device returns a command response message with Response Status, Operation Status Summary byte set to 0x00 (OK, Done) after which the host is free to send further commands.
* If the Timeout parameter is not set to Infinite:
  * The device returns a command response message with its Response Status, Operation Status Summary byte set to 0x01 (OK, Started / Running).
  * While the host is waiting for the timeout to expire, it should not send any commands to the device, because the device is busy processing the current command.
  * After the timeout period expires, the device blanks the display and sends **User Interface Operation Complete - Notification 0x1805** to inform the host.
    {% endstep %}
    {% endstepper %}

## Request Data for Command 0x1803 - Display Message (Display Only)

<table><thead><tr><th>Tag</th><th width="75">Len</th><th width="239">Value / Description</th><th width="76.33331298828125">Typ</th><th width="75.333251953125">Req</th><th width="92.666748046875">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including <strong>Request Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1803 = <strong>Display Message (Display Only) - Command 0x1803</strong> </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>81</td><td>01</td><td>Timeout<br>- 0x00 = Infinite. Device leaves the requested message on the display until the host initiates a change.</td><td>B</td><td>O</td><td>0x00</td></tr><tr><td></td><td></td><td>- All other values = Timeout in seconds for the device to display the message.</td><td></td><td></td><td></td></tr><tr><td>82</td><td>01</td><td>Message ID. Specify a Display String ID from <strong>Display Strings</strong>.</td><td>B</td><td>O</td><td>0x14</td></tr><tr><td>End of any wrappers, at minimum including <strong>Request Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## Response Data for Display Message (Display Only) - Command 0x1803

<table><thead><tr><th width="196.6666259765625">Tag</th><th width="73.3333740234375">Len</th><th width="263.66668701171875">Value / Description</th><th width="76.3333740234375">Typ</th><th width="76.6666259765625">Req</th><th width="96">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including <strong>Response Message</strong></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1803 = <strong>Display Message (Display Only) - Command 0x1803</strong></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>No parameters.</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>End of any wrappers, at minimum including <strong>Response Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## Request Example

Example (Hex):

```
AA00 810401551803 8408 1803 810102 820116
```

## Response Example

{% code title="Example (Hex)" %}

```
AA00 810482551803 820401000000 84021803
```

{% endcode %}


# Read Barcode (BCR Only) - Command 0x1804

The host uses this command to direct the device to arm or disarm the barcode reader for reading a barcode outside the scope of a transaction. This is an immediate directive. To read barcodes within the scope of a transaction, use **Start Transaction - Command 0x1001** and its barcode reader parameters instead.

The sequence of events is as follows:

{% stepper %}
{% step %}
The host ensures the device is not currently running another command, for example, that it is not running a transaction using **Start Transaction - Command 0x1001**.
{% endstep %}

{% step %}
The host composes a command request in the format below and sends it to the device.
{% endstep %}

{% step %}
If the device has a display, it shows a prompt **SCAN BARCODE**.
{% endstep %}

{% step %}
The device enables the barcode reader.

#### If the Timeout parameter is set to Infinite:

* The device returns a command response message with Response Status, Operation Status Summary byte set to 0x00 (OK, Done) after which the host is free to send further commands.
* The host may end the barcode reading session by calling this command again with the **Enable** parameter set to **Disable**.

#### If the Timeout parameter is set to a value other than Infinite:

* The device returns a command response message with its Response Status, Operation Status Summary byte set to 0x01 (OK, Started / Running).
* While the host is waiting for the timeout to expire, it should not send any commands to the device, because the device is busy processing the current command.
* After the device reads a barcode or the timeout period expires, the device sends **User Interface Operation Complete - Notification 0x1805** to report Barcode Reader / Read Barcode Result and additional supporting information.
  {% endstep %}
  {% endstepper %}

## Request Data for Command 0x1804 - Read Barcode (BCR Only)

<table><thead><tr><th>Tag</th><th width="75.3333740234375">Len</th><th width="256.66668701171875">Value / Description</th><th width="74.33331298828125">Typ</th><th width="76">Req</th><th width="96.666748046875">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including <strong>Request Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1804 = <strong>Command 0x1804 -</strong> </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>81</td><td>01</td><td>Enable<br>- 0x00 = Disable. The device disables the barcode reader. In this case, the device ignores all other parameters.<br>- 0x01 = Enable. The device enables the barcode reader.</td><td>B</td><td>R</td><td>0x00</td></tr><tr><td>82</td><td>01</td><td>Timeout<br>- 0x00 = Infinite. The device leaves the barcode reader enabled until it reads a barcode, or until the host sends this command again to disable the barcode reader.<br>- All other values = Timeout in seconds for the device to leave the barcode reader enabled without reading a barcode.</td><td>B</td><td>O</td><td>0x00</td></tr><tr><td>83</td><td>01</td><td>Encrypt Barcode Data<br>- 0x00 = Do Not Encrypt. The device does not encrypt the barcode data when it sends <strong>User Interface Operation Complete</strong>. - <strong>Notification 0x1805</strong><br>- 0x01 = Encrypt. The device encrypts the barcode data when it sends <strong>User Interface Operation Complete</strong>. - <strong>Notification 0x1805</strong></td><td>B</td><td>O</td><td>0x00</td></tr><tr><td>End of any wrappers, at minimum including <strong>Request Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## Response Data for Command 0x1804 - Read Barcode (BCR Only)

<table><thead><tr><th>Tag</th><th width="74.6666259765625">Len</th><th>Value / Description</th><th width="75">Typ</th><th width="75.33331298828125">Req</th><th width="98">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including <strong>Response Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1804 = <strong>Read Barcode (BCR Only) - Command 0x1804</strong></td><td></td><td>No parameters.</td><td></td><td></td><td></td></tr><tr><td>End of any wrappers, at minimum including <strong>Response Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## Request Example

{% code title="Example (Hex)" %}

```
AA00 810401031804 840B 1804 810101 82010F 830101
```

{% endcode %}

## Response Example

{% code title="Example (Hex)" %}

```
AA00 810482031804 820401000000
```

{% endcode %}


# Buzzer - Command 0x1805

The host uses this command to start a buzzer for playing a sequence of tones. Each sequence can have a minimum of 1 to maximum of 10 tones.

{% stepper %}
{% step %}
The sequence of events is as follows:

* The host ensures the device is not currently running another command, for example, that it is not running a transaction using **Start Transaction - Command 0x1001**.
  {% endstep %}

{% step %}

* The host composes a command request in the format below and sends it to the device.
  {% endstep %}

{% step %}

* The device plays a specific tone sequence as the command specified. After finish, the device sends **User Interface Operation Complete - Notification 0x1805** to report Buzzer/Buzzer Result.

The host should wait for **User Interface Operation Complete - Notification 0x1805 -** before sending another command.
{% endstep %}
{% endstepper %}

{% hint style="warning" %}
If the buzzer is currently playing a sequence of tones and any transaction that uses the buzzer to make a sound is started, the device will stop the buzzer for that transaction to take over.
{% endhint %}

## Request Data for Buzzer - Command 0x1805

<table><thead><tr><th>Tag</th><th width="75.33331298828125">Len</th><th width="263.33331298828125">Value / Description</th><th width="78">Typ</th><th width="73.33331298828125">Req</th><th width="96.6666259765625">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including <strong>Request Message</strong></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1805 = <strong>Command 0x1805</strong></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>81</td><td>N*4</td><td><p>N = Number of tones</p><ul><li>0x01 – Min (1 tone)</li><li>0x0A – Max (10 tones)</li></ul><p>4 = 4 bytes data parameter for each tone in the sequence Byte0-Byte1 – Frequency in units of 1 Hz</p><ul><li>0x0000..0x0031 (&#x3C; 50 Hz, Silent)</li><li>0x0032 - Min (50 Hz)</li><li>0x0FA0 - Max (4000 Hz)</li><li>0x0FA1..0xFFFF (> 4000 Hz, Error)</li></ul><p>Byte 2-Byte3 – Duration of tone in units of 1 millisecond</p></td><td>B</td><td>R</td><td></td></tr><tr><td></td><td></td><td><ul><li>0x0001 – Min (1 ms)</li><li>0xFFFF – Max (65535 ms)</li></ul></td><td></td><td></td><td></td></tr><tr><td>End of any wrappers, at minimum including <strong>Request Message</strong></td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## Response Data for Command 0x1805 - Buzzer

<table><thead><tr><th>Tag</th><th width="73.66668701171875">Len</th><th width="167">Value / Description</th><th width="75.3333740234375">Typ</th><th width="74">Req</th><th width="96.6666259765625">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including <strong>Response Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1805 = <strong>Buzzer - Command 0x1805</strong></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>No parameters.</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>End of any wrappers, at minimum including <strong>Response Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## Request Example for a sequence of 5 tones

{% code title="Example (Hex)" %}

```
AA00 810401031805 8418 1805 8114 00C8 01F4 0190 01F4 0258 01F4 0190 01F4 00C8 01F4
```

{% endcode %}

## Response Example

{% code title="Example (Hex)" %}

```
AA00 810482031805 820401000000
```

{% endcode %}


# Personal Info Entry - Command 0x1806

The host uses this command to prompt a cardholder for customer information.

{% stepper %}
{% step %}

### Ensure device is idle

The host ensures the device is not currently running another command (for example, it is not running a transaction using [Command 0x1001 - Start Transaction](https://magtek.gitbook.io/magtek-pilot-gitbooks/internal-documentation/index/6.0-commands/6.1-command-group-0x10nn-transactions/6.1.1-command-0x1001-start-transaction).
{% endstep %}

{% step %}

### Compose command

If the host determines it should request customer information, it composes a command request in the format described below.
{% endstep %}

{% step %}

### Present keypad

The device presents a keypad interface to the cardholder on the display.
{% endstep %}

{% step %}

### Device notifies host

The device sends 7.5.3 Notification 0x1805 - User Interface Operation Complete to the host to report data available, or hardware failure.
{% endstep %}

{% step %}

### Host retrieves data

If the device reported data available, the host can retrieve the data as defined in Table 350 – Notification Detail Codes and Table 352 – Notification Payload for Personal Info Entry.
{% endstep %}
{% endstepper %}

## Request Data for Command 0x1806 – Personal Info Entry

<table><thead><tr><th>Tag</th><th width="74">Len</th><th width="244.33331298828125">Value / Description</th><th width="72.66668701171875">Typ</th><th width="73.333251953125">Req</th><th width="98">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including <strong>Request Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1806 = <strong>Command 0x1806 –</strong> Personal Info Entry</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>81</td><td>01</td><td><p>Capture Type </p><p>0x01 = Phone Number: Capture the phone number<br>0x02 = Social: Capture the social security number</p><p>0x03 = Zip code: Capture the zip code<br>0x04 = Employee ID: Capture Employee ID number<br>0x05 = Birth Date: Capture birth date in USA format<br>0xFF = Cancel Capture: Cancel any of the capture commands</p></td><td>B</td><td>R</td><td></td></tr><tr><td>82</td><td>01</td><td><p>Encryption for user data (Optional) <br>00 – No Encrypt </p><p>01 - Encrypt </p></td><td>B</td><td>R</td><td></td></tr><tr><td>Beginning of any wrappers, at minimum including <strong>Request Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## Response Data for Personal Info Entry

| Tag                                                                  | Len | Value / Description | Typ | Req | Default |
| -------------------------------------------------------------------- | --- | ------------------- | --- | --- | ------- |
| Beginning of any wrappers, at minimum including **Response Message** |     |                     |     |     |         |
| 1806 = **Command 0x1806 –** Personal Info Entry                      |     |                     |     |     |         |
| No parameters.                                                       |     |                     |     |     |         |
| Beginning of any wrappers, at minimum including **Response Message** |     |                     |     |     |         |

If the request started successfully, the Request Status in the message wrapper is: OK, Started / Running, All good / requested operation was successful.

## Request Example

{% code title="Example (Hex)" %}

```
AA00 810401031806 8405 1806 8101 01
```

{% endcode %}

## Response Example

{% code title="Example (Hex)" %}

```
AA00 810482031806 8204 01000000
```

{% endcode %}


# LED Control - Command 0x1807

The host uses this command to control the 4 LEDs of the device when the device is not in non-User Control LED states. If the host sets an LED timer, the device reports completion via Notification User Interface Operation Complete - 0x1805 after the LED operation finishes.

Non-User Control LED state is when the device is in tamper, or currently running transaction with these commands:

* Start Transaction - Command 0x1001
* Card Emulation - Command 0x1840
* Request PIN with Host Supplied Account Data - Command 0x2001
* Request PIN with Card Supplied Account Data - Command 0x2002

When the device is in non-User Control LED states, it will return error if the host sends this command.

When the device is in the User Control LED state, and if there is any transaction that uses LEDs for the transaction status, the device will stop the User Control LEDs for that transaction to take over, and resume to the current system’s LED status after finishing that transaction.

The host is responsible for stopping the User Control LEDs so the device can get back to the system’s LEDs status if the device is in the User Control LEDs.

{% hint style="info" %}
Note:

* DynaFlex II PED and DynaFlexII LEDs color can be GREEN, RED, AMBER, or BLUE.
* DynaProx, DynaFlex II GO LEDs color is GREEN only.  Setting other colors is the same as GREEN.
  {% endhint %}

## &#x20;                                                                                                                     LED Control - Request Data for Command 0x1807 –&#x20;

<table data-header-hidden><thead><tr><th width="163.27276611328125"></th><th width="58"></th><th></th><th width="58"></th><th width="56.181884765625"></th><th width="83.818115234375"></th></tr></thead><tbody><tr><td>Tag</td><td>Len</td><td>Value / Description</td><td>Typ</td><td>Req</td><td>Default</td></tr><tr><td>Beginning of any wrappers, at minimum including Request Message</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1807 = LED Control - ‎Command 0x1807 – </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>81                                                                                                                                                                                                                                                                                                       bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb</td><td>02</td><td><p>Byte 1 - User Control LED</p><ul><li>0x00 – Stop User Control LED.  This will stop User control LED and resume the current system’s LED status.</li><li>0x01 – Start User Control LED.</li></ul><p> Byte 2 – Duration in unit of second</p><ul><li>0x00 – Continuous</li><li>0x01 to 0xFF = 1 to 255 seconds</li></ul></td><td>B</td><td>R</td><td> </td></tr><tr><td>82</td><td>02</td><td><p>Byte 1 - LED number</p><ul><li>Bit 1 = LED 1</li><li>Bit 2 = LED 2</li><li>Bit 3 = LED 3</li><li>Bit 4 = LED 4</li></ul><p> </p><p>Where the LEDs are numbered 1, 2, 3, 4 counting from the left.</p><p>Example: 0x01 = LED 1, 0x03 = LED 1 and LED 2.</p><p> </p><p>Byte 2 - LED Status</p><ul><li>0x00 = OFF</li><li>0x01 = GREEN ON</li><li>0x02 = GREEN BLINK FAST (1/4 second on, 1/4 second off)</li><li>0x03 = GREEN BLINK SLOW (1/2 second on, 1/2 second off)</li><li>0x04 = GREEN FLASH (1/4 second on, 3/4 second off)</li><li>0x05 = GREEN FLASH QUICK (1/8 second on, 7/8 second off)</li></ul><p> </p><ul><li>0x11 = RED ON</li><li>0x12 = RED BLINK FAST (1/4 second on, 1/4 second off)</li><li>0x13 = RED BLINK SLOW (1/2 second on, 1/2 second off)</li><li>0x14 = RED FLASH (1/4 second on, 3/4 second off)</li><li>0x15 = RED FLASH QUICK (1/8 second on, 7/8 second off)</li></ul><p> </p><ul><li>0x21 = AMBER ON</li><li>0x22 = AMBER BLINK FAST (1/4 second on, 1/4 second off)</li><li>0x23 = AMBER BLINK SLOW (1/2 second on, 1/4 second off)</li><li>0x24 = AMBER FLASH (1/4 second on, 3/4 second off)</li><li>0x25 = AMBER FLASH QUICK (1/8 second on, 7/8 second off)</li><li>0x31 = BLUE ON</li><li>0x32 = BLUE BLINK FAST (1/4 second on, 1/4 second off)</li><li>0x33 = BLUE BLINK SLOW (1/2 second on, 1/4 second off)</li><li>0x34 = BLUE FLASH (1/4 second on, 3/4 second off)</li><li>0x35 = BLUE FLASH QUICK (1/8 second on, 7/8 second off)</li></ul><p> </p></td><td>B</td><td>R</td><td> </td></tr><tr><td>End of any wrappers, at minimum including Request Message</td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## LED Control - Response Data for Command 0x1807

<table data-header-hidden><thead><tr><th></th><th width="65.272705078125"></th><th></th><th width="60.54541015625"></th><th width="64.0909423828125"></th><th width="84.272705078125"></th></tr></thead><tbody><tr><td>Tag</td><td>Len</td><td>Value / Description</td><td>Typ</td><td>Req</td><td>Default</td></tr><tr><td>Beginning of any wrappers, at minimum including Response Message</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>No parameters.</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>End of any wrappers, at minimum including Response Message</td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## Request Example

```
AA 00 81 04 82 8D 18 07 82 04 01 00 00 00
```

## Response Example

```
AA 00 81 04 82 8D 18 07 82 04 01 00 00 00
```


# Show Image (Display Only) - Command 0x1821

The host uses this command to trigger the device to immediately show a pre-loaded image on the display, provided the device is not in a mode that has exclusive use of the display (such as during a transaction). This is an immediate and temporary directive. For a solution that affects the device’s idle page behavior on a more permanent basis, see **Property 1.2.3.1.1.1 Custom Idle Page Image**. This command is different from **Show Bitmap Image - Command 0x1823** in that the bitmaps are pre-loaded and persistently stored in the device and can not be composited with each other.

The sequence of events is as follows:

{% stepper %}
{% step %}

### Prepare the image slot

The host makes sure it has loaded the image into at least one of the device’s Custom Idle Page Image slots using **Start Send File to Device (Unsecured) - Command 0xD812**.
{% endstep %}

{% step %}

### Ensure device is in Active/Idle

The host makes sure the device is in Active/Idle state (meaning the display is fully powered on and is not in a mode that has exclusive use of the display, such as processing a transaction).
{% endstep %}

{% step %}

### Call the Show Image command

The host calls this command to show the image loaded into the desired slot number.
{% endstep %}

{% step %}

### Display behavior

The device shows the specified image on the display until the device is no longer in Active/Idle.
{% endstep %}
{% endstepper %}

## Show Image (Display Only) - Request Data for Command 0x1821

<table><thead><tr><th>Tag</th><th width="74.33331298828125">Len</th><th width="256.3333740234375">Value / Description</th><th width="73.6666259765625">Typ</th><th width="74.3333740234375">Req</th><th width="98.666748046875">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including <strong>Request Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1821 = <strong>Show Image (Display Only) - Command 0x1821</strong></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>81</td><td>01</td><td><p>Custom Idle Page Image Number</p><ul><li>0x01 = Show custom image 1</li><li>0x02 = Show custom image 2</li><li>0x03 = Show custom image 3</li><li>0x04 = Show custom image 4</li></ul></td><td>B</td><td>R</td><td></td></tr><tr><td>82</td><td>01</td><td><p>Display Option</p><ul><li>0x00 = Default to cover/uncover the top status bar depends on the current status of the display. If the current display shows the top status bar, the Show Image command won’t cover the top status bar. If the current display doesn’t show the top status bar, the Show Image command will cover the top status bar.</li><li>0x01 = Cover the top status bar regardless of the current status of the display.</li><li>0x02 = Not cover the top status bar regardless of the current status of the display.</li></ul></td><td>B</td><td>O</td><td>0</td></tr><tr><td>83</td><td>01</td><td><p>Display Time</p><ul><li>0x00 = Show image until device changes state</li></ul></td><td>B</td><td>O</td><td>0</td></tr><tr><td>End of any wrappers, at minimum including <strong>Request Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## Show Image (Display Only) - Response Data for Command 0x1821

<table><thead><tr><th>Tag</th><th width="76.33331298828125">Len</th><th width="244">Value / Description</th><th width="77.66668701171875">Typ</th><th width="75.333251953125">Req</th><th width="97.3333740234375">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including <strong>Response Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1821 = <strong>Show Image (Display Only) - Command 0x1821</strong></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>No parameters.</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>End of any wrappers, at minimum including <strong>Response Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

If the request started successfully, the Request Status in the message wrapper is **All Good, Requested Operation Was Successful**.

## Request Example

{% code title="Example (Hex)" %}

```
AA 00 81 04 01 2C 18 21 84 08 18 21 81 01 03 83 01 00
```

{% endcode %}

## Response Example

{% code title="Example (Hex)" %}

```
AA 00 81 04 82 2C 18 21 82 04 00 00 00 00
```

{% endcode %}


# Show QR Code (Display Only) - Command 0x1822

The host uses this command to direct the device to immediately show a QR code on the display, provided the device is not in a mode that has exclusive use of the display (such as during a transaction).

{% stepper %}
{% step %}

### Prepare and send the request

* Ensure the device is not currently running another command (for example, not running a transaction such as Start Transaction - Command 0x1001.
* Select the data for the QR code to display.
* Compose a command request in the format described below and send it to the device.
  {% endstep %}

{% step %}

### Device generates and displays the QR code

* The device generates and displays the QR code.
* If the Display Time parameter is set to Indefinite:
  * The device returns a command response message with Response Status, Operation Status Summary byte set to 0x00 (OK, Done). After this response the host is free to send further commands.
* If the Display Time parameter is set to a number of seconds:
  * The device returns a command response message with its Response Status, Operation Status Summary byte set to 0x01 (OK, Started / Running).
  * While the host is waiting for the timeout to expire, it should not send any commands to the device because the device is busy processing the current command.
  * After the timeout period expires, the device unlocks to allow other commands and sends User Interface Operation Complete - Notification 0x1805 to report Display / Display Message / Timed Out / Reserved.
    {% endstep %}
    {% endstepper %}

## Show QR Code (Display Only) - Request Data for Command 0x1822

<table><thead><tr><th width="122.06060791015625">Tag</th><th width="81.33331298828125">Len</th><th width="365.33331298828125">Value / Description</th><th width="79">Typ</th><th width="77.3333740234375">Req</th><th width="98">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including Request Message.</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1822 = Show QR Code (Display Only) - Command 0x1822</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>81</td><td>01</td><td>Display Time<br>- 0x00 = Indefinite<br>- 0x01 to 0xFF = 1 to 255 seconds</td><td>B</td><td>O</td><td>0x00</td></tr><tr><td>82</td><td>var</td><td>Data to Encode — See ISO/IEC 18004:2015</td><td>B</td><td>R</td><td></td></tr><tr><td>83</td><td>01</td><td>Error Correction<br>- 0x00 = Low<br>- 0x01 = Medium<br>- 0x02 = Quartile<br>- 0x03 = High<br>See ISO/IEC 18004:2015</td><td>B</td><td>O</td><td>0x00</td></tr><tr><td>84</td><td>01</td><td>Mask Pattern<br>- 0x00 to 0x07 = Mask Pattern<br>- 0xFF = Device Select Optimal Mask Pattern — See ISO/IEC 18004:2015</td><td>B</td><td>O</td><td>0xFF</td></tr><tr><td>85</td><td>01</td><td>Minimum Version — Must be less than or equal to Maximum Version<br>- 0x01 to 0x28 = Version 1 to Version 40 — See ISO/IEC 18004:2015</td><td>B</td><td>O</td><td>0x01</td></tr><tr><td>86</td><td>01</td><td><p>Maximum Version — Must be greater than or equal to Minimum Version<br>- 0x01 to 0x28 = Version 1 to Version 40</p><p>See <em>ISO/IEC 18004:2015</em></p></td><td>B</td><td>O</td><td>0x28</td></tr><tr><td>87</td><td>03</td><td>Block Color — Use RRGGBB format.</td><td>B</td><td>O</td><td>0x000000 (Black)</td></tr><tr><td>88</td><td>03</td><td>Background Color — Use RRGGBB format.</td><td>B</td><td>O</td><td>0xFFFFFF (White)</td></tr><tr><td>89</td><td>var</td><td><p>Prompt </p><p>Text for the device to display below the QR code. Because the device shows the Prompt using a proportional font, the maximum length that fits the display depends on the text and the device’s orientation set by Property 1.2.3.1.1.2 Custom Idle Page Image Device Locked (Display Only). In Landscape orientation, the upper limit is approximately 30 characters. In Portrait orientation, the limit is approximately 22 characters.</p></td><td>B</td><td>)</td><td>No prompt</td></tr><tr><td>End of any wrappers, at minimum including Request Message</td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## Show QR Code (Display Only) - Response Data for Command 0x1822

<table><thead><tr><th width="104.787841796875">Tag</th><th width="81.33331298828125">Len</th><th width="365.33331298828125">Value / Description</th><th width="79">Typ</th><th width="77.3333740234375">Req</th><th width="98">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including Request Message.</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1822 = Show QR Code (Display Only) - Command 0x1822</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>No parameters</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>End of any wrappers, at minimum including Request Message</td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

If the request started successfully, the Request Status in the message wrapper is **All Good, Requested Operation Was Successful.**

{% code title="Example (Hex)" %}

```hex
AA 00 81 04 01 05 18 22 84 41 18 22 81 01 3C 82 0F 54 68 69 73 20 69 73 20 61 20 74 65
73 74 21 83 01 00 84 01 FF 85 01 01 86 01 28 87 03 00 00 00 88 03 FF FF FF 89 13 50 6c 
65 61 73 65 20 73 63 61 6e 20 51 52 20 63 6f 64 65
```

{% endcode %}

## Response Example

{% code title="Example (Hex)" %}

```hex
AA 00 81 04 82 2C 18 22 82 04 00 00 00 00
```

{% endcode %}

## Notification Example

{% code title="Example (Hex)" %}

```hex
AA 00 81 04 83 00 18 05 82 04 02 01 00 00
```

{% endcode %}


# Show Bitmap Image (Display Only) - Command 0x1823

The host uses this command to trigger the device to immediately show a bitmap file the host includes as a parameter, provided the device is not in a mode that has exclusive use of the display (such as during a transaction).

This is an immediate and temporary directive. For a solution that affects the device’s idle page behavior on a more permanent basis, see Custom Idle Page Image - Property 1.2.3.1.1.1.

This command is different from Personal Info Entry - Command 0x1806.

The host uses Command 0x1806 to prompt a cardholder for customer information.&#x20;

The sequence of events for Command 0x1806 is:

{% stepper %}
{% step %}
The host ensures the device is not currently running another command, for example, that it is not running a transaction using Start Transaction - Command 0x1001.
{% endstep %}

{% step %}
If the host determines it should request customer information, it composes a command request in the format below.
{% endstep %}

{% step %}
The device presents a keypad interface to the cardholder on the display.
{% endstep %}

{% step %}
The device sends User Interface Operation Complete - Notification 0x1805 to the host to report data available, or hardware failure.
{% endstep %}

{% step %}
If the device reported data available, the host can retrieve the data as defined in the Notification Detail Codes and Notification Payload for Personal Info Entry.
{% endstep %}
{% endstepper %}

## Request Data for Command 0x1806 – Personal Info Entry

<table><thead><tr><th>Tag</th><th width="73">Len</th><th width="268.3333740234375">Value / Description</th><th width="78.33331298828125">Typ</th><th width="76">Req</th><th width="97.333251953125">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including Request Message (see message wrapper definition)</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1806 = Personal Info Entry - Command 0x1806</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>81</td><td>01</td><td>Capture Type: 0x01 = Phone Number; 0x02 = Social; 0x03 = Zip code; 0x04 = Employee ID; 0x05 = Birth Date (USA format); 0xFF = Cancel Capture</td><td>B</td><td>R</td><td></td></tr><tr><td>Beginning of any wrappers, at minimum including Request Message</td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

Response Data for Personal Info Entry

<table><thead><tr><th>Tag</th><th width="73">Len</th><th width="236.66668701171875">Value / Description</th><th width="74.6666259765625">Typ</th><th width="74.6666259765625">Req</th><th width="97.3333740234375">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including Response Message (see message wrapper definition)</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1806 = Personal Info Entry - Command 0x1806</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>No parameters.</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Beginning of any wrappers, at minimum including Response Message</td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

If the request started successfully, the Request Status in the message wrapper is **OK, Started / Running (All good / requested operation was successful).**

## Request Example

{% code title="Example (Hex)" %}

```
AA00 810401031806 8405 1806 8101 01
```

{% endcode %}

## Response Example&#x20;

{% code title="Example (Hex)" %}

```
AA00 810482031806 8204 01000000
```

{% endcode %}

Show Bitmap Image (Display Only) - Command 0x1823 differs from Show Image (Display Only) - Command 0x1821 in that the host sends bitmaps as parameters instead of pre-loading them, and the host can call this command multiple times without clearing the display to show multiple bitmaps on the display at the same time.

The sequence of events for Command 0x1823 is:

{% stepper %}
{% step %}

### Step: Ensure device availability

The host ensures the device is not currently running another command, for example, that it is not running a transaction using Start Transaction - Command 0x1001.
{% endstep %}

{% step %}

### Step: Select bitmap

The host selects a bitmap file it wants to display.
{% endstep %}

{% step %}

### Step: Compose and send command

The host composes a command request in the format below and sends it to the device.
{% endstep %}

{% step %}

### Step: Optional background clear

If the host includes the Background Color parameter, the device clears the display using the specified color. If the host does not include that parameter, the device does not clear the display.
{% endstep %}

{% step %}

### Step: Display placement and timing

* The device shows the bitmap with the upper left corner at the specified X Position and Y Position. If the host omits either parameter, the device centers the bitmap along the unspecified axis.
* If the Display Time parameter is Indefinite or is not included, the device returns a command response message with Response Status, Operation Status Summary byte set to 0x00 (OK, Done) after which the host is free to send further commands.
* If the timeout parameter is set to a specific number of seconds:
  * The device returns a command response message with its Response Status, Operation Status Summary byte set to 0x01 (OK, Started / Running).
  * While the host is waiting for the timeout to expire, it should not send any commands to the device, because the device is busy processing the current command.
  * After the timeout period expires, the device unlocks to allow other commands and sends Notification 0x1805 - User Interface Operation Complete to inform the host.
    {% endstep %}
    {% endstepper %}

## Show Bitmap Image (Display Only) - Request Data for Command 0x1823 -&#x20;

<table><thead><tr><th>Tag</th><th width="73.3333740234375">Len</th><th width="239.66668701171875">Value / Description</th><th width="73.33331298828125">Typ</th><th width="73.99993896484375">Req</th><th width="97.3333740234375">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including Request Message</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1823 = Show Bitmap Image (Display Only) - Command 0x1823</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>81</td><td>01</td><td>Display Time: 0x00 = Indefinite; 0x01 to 0xFF = 1 to 255 seconds</td><td>B</td><td>O</td><td>0x00</td></tr><tr><td>82</td><td>03</td><td>Background Color. Use RRGGBB format.</td><td>B</td><td>O</td><td>N/A</td></tr><tr><td>83</td><td>02</td><td><p>X Position. </p><p>The device places the left edge of the image at this pixel position relative to the left edge of the display, which is position 0x0000. This parameter plus the pixel width of the image must be less than the pixel width of the display. The display’s pixel width depends on the device’s orientation set by Custom Idle Page Image Device Locked (Display Only) - Property 1.2.3.1.1.2. For information about the resolution of the display, see the specifications in the device’s Installation and Operation Manual.</p></td><td>B</td><td>O</td><td>Centered</td></tr><tr><td>84</td><td>02</td><td><p>Y Position. </p><p>The device places the top edge of the image at this pixel position relative to the top edge of the display, which is position 0x0000. This parameter plus the pixel height of the image must be less than the pixel height of the display. The display’s pixel height depends on the device’s orientation set by Custom Idle Page Image Device Locked (Display Only) - Property 1.2.3.1.1.2. For information about the resolution of the display, see the specifications in the device’s Installation and Operation Manual.</p></td><td>B</td><td>O</td><td>Centered</td></tr><tr><td>85</td><td>var</td><td><p>Bitmap </p><p>Image encoded in full BMP file format as defined by Microsoft (e.g., starting with “BM”) or Magtek signed image file format</p></td><td>B</td><td>R</td><td></td></tr><tr><td>86</td><td>01</td><td><p>Display Option: </p><ul><li>0x00 = Default (cover/uncover the top status bar depends on the current status of the display). If the current display shows the top status bar, the Show Bitmap Image command won’t cover the top status bar. If the current display doesn’t show the top status bar, the Show Bitmap Image command will cover the top status bar. </li><li>0x01 = Cover the top status bar regardless of the current status of the display. </li><li>0x02 = Not cover the top status bar regardless of the current status of the display.</li></ul></td><td>B</td><td>O</td><td>0</td></tr><tr><td>End of any wrappers, at minimum including Request Message</td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## Show Bitmap Image (Display Only) - Response Data for Command 0x1823

<table><thead><tr><th>Tag</th><th width="81.6666259765625">Len</th><th>Value / Description</th><th width="72.33331298828125">Typ</th><th width="77.333251953125">Req</th><th width="96.666748046875">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including Response Message</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1823 = Show Bitmap Image (Display Only) - Command 0x1823</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>No parameters.</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>End of any wrappers, at minimum including Response Message</td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

If the request started successfully, the Request Status in the message wrapper is **All Good, Requested Operation Was Successful.**

## Request Example (Hex)

{% code title="Example (Hex)" %}

```
AA 00 81 04 01 05 18 22 84 41 18 22 81 01 3C 82 0F 54 68 69 73 20 69 73 20 61 20 74 
65 73 74 21 83 01 00 84 01 FF 85 01 01 86 01 28 87 03 00 00 00 88 03 FF FF FF 89 13 
50 6c 65 61 73 65 20 73 63 61 6e 20 51 52 20 63 6f 64 65
```

{% endcode %}

## Response Example

{% code title="Example (Hex)" %}

```
AA 00 81 04 82 2C 18 22 82 04 00 00 00 00
```

{% endcode %}

## Notification Example (Hex)

{% code title="Example (Hex)" %}

```
AA 00 81 04 83 00 18 05 82 04 02 01 00 00
```

{% endcode %}


# Display Flexible UI Pages (Display Only) - Command 0x1830

This command allows the host to bring up standalone pages. A page is considered standalone if it’s stateless, meaning it will be:

* Shown on the display.
* Can allow user input.
* Returns user input result to the host.
* Operation ends.

## **Request Data for Command 0x1831**

<table><thead><tr><th>Tag</th><th width="73">Len</th><th width="268.33331298828125">Value / Description</th><th width="72.6666259765625">Typ</th><th width="75.333251953125">Req</th><th width="96.666748046875">Default</th></tr></thead><tbody><tr><td>1830 = Display Flexible UI Pages (Display Only) - Command 0x1830</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>81</td><td>01</td><td><p>Display Time</p><ul><li>0x00 – Infinite. Device leaves the requested page on the display until the host initiates a change.</li></ul></td><td>B</td><td>R</td><td></td></tr><tr><td>82</td><td>01</td><td><p>UI page option</p><ul><li>0x00 – Enter Sale Amount page. Device responds with User Interface Host Action Request with ‘Touchscreen, $Amount button selected’  content - Notification 0x1803.</li></ul></td><td>B</td><td>R</td><td></td></tr></tbody></table>

## **Request Example – (Display Enter Sale Amount Page)**

| Example (Hex)                                         |
| ----------------------------------------------------- |
| AA 00 81 04 01 2C 18 31 84 08 18 31 81 01 00 82 01 00 |

## **Response Example**

| Example (Hex)                             |
| ----------------------------------------- |
| AA 00 81 04 82 2C 18 31 82 04 00 00 00 00 |

<div align="center"><img src="/files/700a886bd53861451878a2e0cc865f51fa356910" alt="A diagram of a device Description automatically generated"></div>

<div align="center"><img src="/files/ede3593418e9e55a86931803a99b53f8013496a9" alt="A screenshot of a diagram Description automatically generated"></div>

<figure><img src="/files/ICnTHfc5cQcJJWZBHiDh" alt=""><figcaption></figcaption></figure>

## **Sequence for Flexible UI Gen. 2 mode**

The host sends the 0x1830 command with UI Page Option set to 0x06 (Flexible UI Gen. 2 page), which displays a bitmap. The device sends User Event Notifications for each tap on the touchscreen (requires signed image).

The host uses this command to display Flexible UI pages in the following layout:


# UI Page Option 0x00 Layout

The host uses this option to display a maximum of 5 lines of host-provided text, and 1 optional green functional button, Middle – label with a String ID that associates it with a configured String message. See **Table – Default User Interface String IDs and Strings**.&#x20;

When the user presses this button, the device sends a notification to the host to indicate this button is pressed. See **User Interface Host Action Request - Notification 0x1803.** After that, the host will decide what to do next.

Recommend maximum number of characters setting for this page:

## Landscape Screen Orientation

* Each text line can fit about:
  * 18 Upper case wide size characters (example: “WM”)
  * 23 Upper case regular size characters (example: “ABC”)
  * 21 lower case wide size characters (example: “wm”)
  * 30 lower case regular size characters (example: “abc”)
* Button text can fit about:
  * 5 Upper case wide size characters (example: “WM”)
  * 8 Upper case regular size characters (example: “ABC”)
  * 6 lower case wide size characters (example: “wm”)
  * 9 lower case regular size characters (example: “abc”)

## Portrait Screen Orientation

* Each text line can fit about:
  * 13 Upper case wide size characters (example: “WM”)
  * 17 Upper case regular size characters (example: “ABC”)
  * 14 lower case wide size characters (example: “wm”)
  * 20 lower case regular size characters (example: abc)
* Button text can fit about:
  * 4 Upper case wide size characters (example: “WM”)
  * 6 Upper case regular size characters (example: “ABC”)
  * 5 lower case wide size characters (example: “wm”)
  * 7 lower case regular size characters (example: “abc”)

<figure><img src="/files/3GF9EmlbFP0MzNytoviK" alt=""><figcaption></figcaption></figure>


# UI Page Option 0x01 and 0x02 Layout

The host uses UI Page Option **0x01** to display a page with a title, a maximum of 6 data buttons (2 rows and 3 columns in Landscape Screen Orientation, 3 rows and 2 columns in Portrait Screen Orientation) with text, and maximum 3 functional buttons with a color option of red, green, or yellow.

The host uses UI Page Option **0x01** to display a page with a title, maximum of 4 data buttons (2 rows and 2 columns in Landscape Screen Orientation, 2 rows and 2 columns in Portrait Screen Orientation) with text, and maximum 3 functional buttons with a color option of red, green, or yellow.

The host uses UI Page Option **0x02** to display a page with a title, maximum of 6 data buttons (2 rows and 3 columns in Landscape Screen Orientation, 3 rows and 2 columns in Portrait Screen Orientation) with $Amount, and maximum 3 functional buttons with a color option of red, green, or yellow.

The host uses UI Page Option **0x02** to display a page with a title, maximum of 4 data buttons (2 rows and 2 columns in Landscape Screen Orientation, 2 rows and 2 columns in Portrait Screen Orientation) with $Amount, and maximum 3 functional buttons with a color option of red, green, or yellow.

The button with \*\*$\*\*Amount value is host provided. The title, data buttons text, and functional buttons are labeled with String IDs associated with configured String messages. See **Table – Default User Interface String IDs and Strings**. When the user presses any button, the device sends a notification to the host to indicate the corresponding button is pressed. See **User Interface Host Action Request - Notification 0x1803.** After that, the host will decide what to do next.

## Recommended maximum number of characters for this page

* Landscape Screen Orientation:
  * Title text:
    * \~18 Upper case wide size characters (example: “WM”)
    * \~23 Upper case regular size characters (example: “ABC”)
    * \~21 lower case wide size characters (example: “wm”)
    * \~30 lower case regular size characters (example: “abc”)
  * 3-columns data button text:
    * \~5 Upper case wide size characters (example: “WM”)
    * \~8 Upper case regular size characters (example: “ABC”)
    * \~6 lower case wide size characters (example: “wm”)
    * \~9 lower case regular size characters (example: “abc”)
  * 2-columns data button text:
    * \~9 Upper case wide size characters (example: “WM”)
    * \~13 Upper case regular size characters (example: “ABC”)
    * \~9 lower case wide size characters (example: “wm”)
    * \~15 lower case regular size characters (example: “abc”)
  * Functional button text:
    * \~5 Upper case wide size characters (example: “WM”)
    * \~8 Upper case regular size characters (example: “ABC”)
    * \~6 lower case wide size characters (example: “wm”)
    * \~9 lower case regular size characters (example: “abc”)
* Portrait Screen Orientation:
  * Title text:
    * \~13 Upper case wide size characters (example: “WM”)
    * \~17 Upper case regular size characters (example: “ABC”)
    * \~14 lower case wide size characters (example: “wm”)
    * \~20 lower case regular size characters (example: “abc”)
  * 2-columns data button text:
    * \~6 Upper case wide size characters (example: “WM”)
    * \~10 Upper case regular size characters (example: “ABC”)
    * \~7 lower case wide size characters (example: “wm”)
    * \~11 lower case regular size characters (example: “abc”)
  * Functional button text:
    * \~4 Upper case wide size characters (example: “WM”)
    * \~6 Upper case regular size characters (example: “ABC”)
    * \~5 lower case wide size characters (example: “wm”)
    * \~7 lower case regular size characters (example: “abc”)

### The Layout for a page with a title, a maximum of 4 data buttons with text/$Amount, and a maximum of 3 functional buttons:

<figure><img src="/files/y3KmgiXVY3nXBHZwwHu5" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/0qxtoJifpS9YZpeEsKxu" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/czzjYJxlBInxHfzSyfnH" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/5Fj5KkQGF7PdNLO8c6pX" alt=""><figcaption></figcaption></figure>


# UI Page Option 0x03 Layout

The host uses this option to display a page with the following elements: a title, a section for uploading a custom image, an option at the bottom-left corner to display either the Device Serial Number or host-provided text, and a maximum of one functional green button positioned on the right.

The title and functional button are labeled with String IDs associated with configured String messages. See Table – Default User Interface String IDs and Strings.&#x20;

When the user presses this button, the device sends a notification to the host to indicate the corresponding button is pressed. See User Interface Host Action Request - Notification 0x1803. After that, the host will decide what to do next.

Recommend maximum number of characters and bitmap image setting for this page:

{% stepper %}
{% step %}

### Landscape Screen Orientation

* Title text can fit about:
  * 18 Upper case wide size characters like “WM”
  * 23 Upper case regular size characters like “ABC”
  * 21 lower case wide size characters like “wm”
  * 30 lower case regular size characters like “abc”
* Bottom left corner text can fit about:
  * 8 Upper case wide size characters like “WM”
  * 12 Upper case regular size characters like “ABC”
  * 9 lower case wide size characters like “wm”
  * 15 lower case regular size characters like “abc”
* Functional button text can fit about:
  * 5 Upper case wide size characters like “WM”
  * 8 Upper case regular size characters like “ABC”
  * 6 lower case wide size characters like “wm”
  * 9 lower case regular size characters like “abc”
* Bitmap image
  * Maximum width: 320px
  * Maximum height: 140px
  * Color depth: 24-bit (True Color, RGB), 16-bit (5:5:5:1, RGB Hi Color), 8-bit (256 Color), 4-bit (16 Color), or 1-bit (monochrome)
    {% endstep %}

{% step %}

### Portrait Screen Orientation

* Title text can fit about:
  * 13 Upper case wide size characters like “WM”
  * 17 Upper case regular size characters like “ABC”
  * 14 lower case wide size characters like “wm”
  * 20 lower case regular size characters like “abc”
* Bottom left corner text can fit about:
  * 8 Upper case wide size characters like “WM”
  * 12 Upper case regular size characters like “ABC”
  * 9 lower case wide size characters like “wm”
  * 15 lower case regular size characters like “abc”
* Functional button text can fit about:
  * 4 Upper case wide size characters like “WM”
  * 6 Upper case regular size characters like “ABC”
  * 5 lower case wide size characters like “wm”
  * 7 lower case regular size characters like “abc”
* Bitmap image
  * Maximum width: 240px
  * Maximum height: 220px
  * Color depth: 24-bit (True Color, RGB), 16-bit (5:5:5:1, RGB Hi Color), 8-bit (256 Color), 4-bit (16 Color), or 1-bit (monochrome)
    {% endstep %}
    {% endstepper %}

<figure><img src="/files/lugNDpk4CvJsGF4bytLh" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/ufeXLKMv2RIyYFxiCDST" alt=""><figcaption></figcaption></figure>

## Request Data for Command 0x1830

<table><thead><tr><th>Tag</th><th width="77">Len</th><th width="253">Value / Description</th><th width="78.3333740234375">Typ</th><th width="74.333251953125">Req</th><th width="98.6666259765625">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including <strong>Response Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1830 = <strong>Display Flexible UI Pages (Display Only) - Command 0x1830</strong></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>81</td><td>01</td><td><p>Display Time</p><ul><li>0x00 – Infinitive. Device leaves the requested page on the display until the host initiates a change.</li><li>0x01 to 0xFF = RFU</li></ul></td><td>B</td><td>R</td><td></td></tr><tr><td>82</td><td>01</td><td><p>UI page option</p><ul><li>0x00 – Page with up to 5 lines of text and up to 1 functional button Middle. See Tag A1.</li><li>0x01 – Page with a title, up to 6 buttons with text, and up to 3 functional buttons. See Tag 83, A2 and A4.</li><li>0x02 – Page with a title, up to 6 buttons with $Amount, and up to 3 functional buttons. See Tag 83, A3 and A4.</li><li>0x03 – Page with a title, a custom image, an optional bottom left corner with SN or Text, and up to 1 functional button Right. See Tag 83 and A5.</li><li>0x06 – Flexible UI Gen. 2 page. Displays an image and sends touch notifications. See tag 83, A8.</li></ul></td><td>B</td><td>R</td><td></td></tr><tr><td>83</td><td>02</td><td>Text String ID for a tile of UI page option: 0x01, 0x02, 0x03 See <strong>Table 361 – Default User Interface String IDs and Strings</strong> If host wants to disable this title, do not include this tag.</td><td>B</td><td>O</td><td></td></tr></tbody></table>

## Request Data for Command 0x1830 - A1–A8 and sub-tags:

<table><thead><tr><th width="74.33331298828125">Tag</th><th width="75.66668701171875">Len</th><th>Value / Description</th><th width="80.66668701171875">Typ</th><th width="74.6666259765625">Req</th><th width="96">Default</th></tr></thead><tbody><tr><td>A1</td><td>var</td><td>Text string parameters for UI page option: 0x00 The parameter in this TLV data object allow the host to enable and disable the data base for UI page option 0x00</td><td>B</td><td>O</td><td></td></tr><tr><td>/81</td><td>var</td><td>Text string (&#x3C;= 30 characters) for line 1, end with NULL char. If host wants to disable this line, do not include this tag.</td><td>B</td><td>O</td><td></td></tr><tr><td>/82</td><td>var</td><td>Text string (&#x3C;= 30 characters) for line 2, end with NULL char. If host wants to disable this line, do not include this tag.</td><td>B</td><td>O</td><td></td></tr><tr><td>/83</td><td>var</td><td>Text string (&#x3C;= 30 characters) for line 3, end with NULL char. If host wants to disable this line, do not include this tag.</td><td>B</td><td>O</td><td></td></tr><tr><td>/84</td><td>var</td><td>Text string (&#x3C;= 30 characters) for line 4, end with NULL char. If host wants to disable this line, do not include this tag.</td><td>B</td><td>O</td><td></td></tr><tr><td>/85</td><td>var</td><td>Text string (&#x3C;= 30 characters) for line 5, end with NULL char. If host wants to disable this line, do not include this tag.</td><td>B</td><td>O</td><td></td></tr><tr><td>/86</td><td>02</td><td>Function button Middle option. String ID = Enable functional button Middle with a String ID associated with a configured String message. See <strong>Table XXX – Default User Interface String IDs and Strings</strong> When user presses this button, device sends notification to the host to indicate the functional button Middle is pressed. See <strong>User Interface Host Action Request - Notification 0x1803</strong> If host wants to disable this button, do not include this tag</td><td>B</td><td>O</td><td></td></tr><tr><td>A2</td><td>var</td><td>Button text String ID parameters for UI page option: 0x01 and 0x02. The parameter in this TLV data object allows the host to enable and disable the data base. When user presses any button, device sends notification to the host to indicate which button is pressed. See <strong>User Interface Host Action Request - Notification 0x1803</strong></td><td>B</td><td>O</td><td></td></tr><tr><td>/81</td><td>02</td><td>Text String ID for button 1. See <strong>Table XXX – Default User Interface String IDs and Strings</strong>. If host wants to disable this button, don’t include this tag.</td><td>B</td><td>O</td><td></td></tr><tr><td>/82</td><td>02</td><td>Text String ID for button 2. See <strong>Table XXX – Default User Interface String IDs and Strings</strong>. If host wants to disable this button, don’t include this tag.</td><td>B</td><td>O</td><td></td></tr><tr><td>/83</td><td>02</td><td>Text String ID for button 3. See <strong>Table XXX – Default User Interface String IDs and Strings</strong>. If host wants to disable this button, don’t include this tag.</td><td>B</td><td>O</td><td></td></tr><tr><td>/84</td><td>02</td><td>Text String ID for button 4. See <strong>Table XXX – Default User Interface String IDs and Strings</strong>. If host wants to disable this button, don’t include this tag.</td><td>B</td><td>O</td><td></td></tr><tr><td>/85</td><td>02</td><td>Text String ID for button 5. See <strong>Table XXX – Default User Interface String IDs and Strings</strong>. If host wants to disable this button, don’t include this tag.</td><td>B</td><td>O</td><td></td></tr><tr><td>/86</td><td>02</td><td>Text String ID for button 6. See <strong>Table XXX – Default User Interface String IDs and Strings</strong>. If host wants to disable this button, don’t include this tag.</td><td>B</td><td>O</td><td></td></tr><tr><td>A3</td><td>var</td><td>Button $Amount parameters for UI page option: 0x01, 0x02 The parameter in this TLV data object allows the host to enable and disable the data base for UI page option 0x01 and 0x02 When user presses any button, device sends notification to the host to indicate which amount button is pressed. See <strong>User Interface Host Action Request - Notification 0x1803</strong></td><td>B</td><td>O</td><td></td></tr><tr><td>/81</td><td>04</td><td>Value $Amount for button 1. If host wants to disable this button, don’t include this tag.</td><td>B</td><td>O</td><td></td></tr><tr><td>/82</td><td>04</td><td>Value $Amount for button 2. If host wants to disable this button, don’t include this tag.</td><td>B</td><td>O</td><td></td></tr><tr><td>/83</td><td>04</td><td>Value $Amount for button 3. If host wants to disable this button, don’t include this tag.</td><td>B</td><td>O</td><td></td></tr><tr><td>/84</td><td>04</td><td>Value $Amount for button 4. If host wants to disable this button, don’t include this tag.</td><td>B</td><td>O</td><td></td></tr><tr><td>/85</td><td>04</td><td>Value $Amount for button 5. If host wants to disable this button, don’t include this tag.</td><td>B</td><td>O</td><td></td></tr><tr><td>/86</td><td>04</td><td>Value $Amount for button 6. If host wants to disable this button, don’t include this tag.</td><td>B</td><td>O</td><td></td></tr><tr><td>A4</td><td>var</td><td>Functional buttons parameters for UI page option: 0x01 and 0x02. The parameter in this TLV data object allows the host to enable and disable the data base. When user presses any button, the device sends notification to the host to indicate which functional button is pressed. See <strong>User Interface Host Action Request - Notification 0x1803</strong></td><td>B</td><td>O</td><td></td></tr><tr><td>/81</td><td>03</td><td>Text String ID and color option for functional button Left. See <strong>Table XXX – Default User Interface String IDs and Strings</strong>. Byte 0-1: String ID Byte 2: color option 0x00 = red 0x01 = green 0x02 = yellow If host wants to disable this button, don’t include this tag.</td><td>B</td><td>O</td><td></td></tr><tr><td>/82</td><td>03</td><td>Text String ID and color option for functional button Middle. See <strong>Table XXX – Default User Interface String IDs and Strings</strong>. Byte 0-1: String ID Byte 2: color option 0x00 = red 0x01 = green 0x02 = yellow If host wants to disable this button, don’t include this tag.</td><td>B</td><td>O</td><td></td></tr><tr><td>/83</td><td>03</td><td>Text String ID and color option for functional button Right. See <strong>Table XXX – Default User Interface String IDs and Strings</strong>. Byte 0-1: String ID Byte 2: color option 0x00 = red 0x01 = green 0x02 = yellow If host wants to disable this button, don’t include this tag.</td><td>B</td><td>O</td><td></td></tr><tr><td>A5</td><td>var</td><td>Parameters for UI page option 0x03 The parameter in this TLV data object allow the host to enable and disable the data base</td><td>B</td><td>O</td><td></td></tr><tr><td>/81</td><td>02</td><td>Text String ID for green functional button Right. See <strong>Table XXX – Default User Interface String IDs and Strings</strong>. When user presses this button, device sends notification to the host to indicate the functional button Right is pressed. See <strong>User Interface Host Action Request - Notification 0x1803</strong> If host wants to disable this button, don’t include this tag.</td><td>B</td><td>O</td><td></td></tr><tr><td>/82</td><td>02</td><td>X Position. If host wants device to display the image in the center of the loading image area, don’t include this tag.</td><td>B</td><td>O</td><td></td></tr><tr><td>/83</td><td>02</td><td>Y Position. If host want device to display the image in the center of the loading image area, don’t include this tag Note: Y pos >= 50px Y pos + Image Height &#x3C;= 190px Landscape Screen Orientation Y pos + Image Height &#x3C;= 270px Portrait Screen Orientation</td><td>B</td><td>O</td><td></td></tr><tr><td>/84</td><td>var</td><td>Bitmap Image encoded in full BMP file format as defined by Microsoft (e.g, starting with “BM”) Image Width Max = 320px Landscape Screen Orientation Image Height Max = 140px Landscape Screen Orientation Image Width Max = 240px Portrait Screen Orientation Image Height Max = 220px Portrait Screen Orientation</td><td>B</td><td>O</td><td></td></tr><tr><td>/85</td><td>var</td><td><p>Bottom left corner option Byte 0 = option</p><ul><li>0x00 = Disable</li><li>0x01 = show Device Serial Number</li><li>0x02 = show text</li><li>0x03..0x0F = invalid</li></ul><p>Byte 1 = length of the text, should be less than 16 characters. Byte 2..N = text string value.</p></td><td>B</td><td>0</td><td></td></tr><tr><td>A8</td><td>Var</td><td>Parameters for UI page option 0x06</td><td>B</td><td>O</td><td></td></tr><tr><td>/81</td><td>2</td><td>Image X position (omit for default centered position)</td><td>B</td><td>O</td><td></td></tr><tr><td>/82</td><td>2</td><td>Image Y position (omit for default centered position)</td><td>B</td><td>O</td><td></td></tr><tr><td>/83</td><td>1</td><td>Image ID (for image stored on device). Value is 0-3 for the 4 available image ‘slots’. Must be signed image for touch notifications to be sent. Cannot be used in the same command as /84.</td><td>B</td><td>O</td><td></td></tr><tr><td>/84</td><td>var</td><td>Image data. Image encoded in full BMP file format as defined by Microsoft (e.g, starting with “BM”) <strong>OR</strong> contents of .bin file for Magtek signed image file. Must be signed .bin data for touch notifications to be sent. Cannot be used in the same command as /83.</td><td>B</td><td>O</td><td></td></tr><tr><td>End of any wrappers, at minimum <strong>Response Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## Display Flexible UI Pages (Display Only) - Response Data for Command 0x1830

<table><thead><tr><th>Tag</th><th width="79.66668701171875">Len</th><th width="125.3333740234375">Value / Description</th><th width="74.3333740234375">Typ</th><th width="74.66668701171875">Req</th><th width="98">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including <strong>Response Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1830 = <strong>Display Flexible UI Pages (Display Only) - Command 0x1830</strong></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>No parameters</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>End of any wrappers, at minimum including <strong>Response Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

If the request started successfully, the Request Status in the message wrapper is **All good / requested operation was successful**.

## Request Example

{% code title="Example (Hex)" %}

```
AA 00 81 04 01 2C 18 30 84 1A 18 30 81 01 00 82 01 00 83 02 00 05 A1 0C 83 0A 54 48 41 
4E 4B 20 59 4F 55 00
```

{% endcode %}

## Response Example

{% code title="Example (Hex)" %}

```
AA008104822C1830820400000000
```

{% endcode %}


# Card Emulation - Command 0x1840

Card emulation is initiated by receiving a 0x1840 command from the host. The device will prepare card emulation with the parameters provided in the command and start card emulation.

The sequence of events is as follows:

{% stepper %}
{% step %}

### Host ensures device is idle

The host ensures the device is not currently running another command, for example, that it is not running a transaction or PIN entry.
{% endstep %}

{% step %}

### Host composes and sends command

The host composes a command request in the format described below and sends it to the device.
{% endstep %}

{% step %}

### Device validates and prepares

The device receives the command and verifies that the parameters are valid and the device is in a state that allows the execution of card emulation.
{% endstep %}

{% step %}

### Device prompts customer (if display available)

If the device has a display, a prompt will be displayed asking the customer to tap their phone to the device.
{% endstep %}

{% step %}

### Timeout behavior and response

* If the timeout parameter is not included or set to 0x00, then there is no timeout.
* If the timeout parameter is set to a specific number of seconds, the device returns a command response message with its Operation Status Summary byte set to 0x01 (OK, Started / Running).
  {% endstep %}

{% step %}

### Host can cancel emulation

The host may issue a 0x1840 command with Tag 0x81 set to 0x00 to cancel the execution of card emulation.
{% endstep %}

{% step %}

### Completion notification

After the timeout expires, host cancel or the card is read, the device sends a 0x1805 notification to inform the host.
{% endstep %}
{% endstepper %}

## Card Emulation - Request Data for Command 0x1840

<table><thead><tr><th width="72.33334350585938">Tag</th><th width="81.3333740234375">Len</th><th>Value / Description</th><th width="76">Req</th><th width="98.6666259765625">Default</th></tr></thead><tbody><tr><td>/81</td><td>01</td><td><p>Start/Cancel</p><ul><li>0x00 = Cancel (See the example of 0x1840 cancel command below)</li><li>0x01 = Start</li></ul></td><td>R</td><td></td></tr><tr><td>/82</td><td>01</td><td><p>Timeout in seconds</p><ul><li>0x00 = No timeout</li><li>0x01 to 0xFF = 1 to 255 seconds</li></ul></td><td>O</td><td>0x00</td></tr><tr><td>/83</td><td>&#x3C;= 254</td><td><p>URL </p><p>URL to use as card data. Required when starting card emulation. Optional and ignored if canceling emulation. Example: https://www.magtek.com/</p></td><td>O/R</td><td></td></tr></tbody></table>

## Request Example

{% code title="Example (Hex)" %}

```
AA 00 81 04 01 01 18 40 84 21 18 40 81 01 01 82 01 00 83 17 68 74 74 70 73 3A 2F 2F 77 77 77
2E 6D 61 67 74 65 6B 2E 63 6F 6D 2F

```

{% endcode %}

## Response Example

{% code title="Example (Hex)" %}

```
AA 00 81 04 82 01 18 40 82 04 01 00 00 00
```

{% endcode %}

## Example of 0x1840 Card Emulation Command

{% code title="Example (Hex)" %}

```
AA 00 81 04 01 01 18 40 84 05 18 40 81 01 00
```

{% endcode %}


# Device Control - Command Group 0x1Fnn

## Device Control

This section of the DynaFamily Programmer's Manual lists available Device Control commands to initiate various functions in the device.

{% hint style="success" %}
Applies to: All Dyna Family products
{% endhint %}

### Information in this group

| **Section**                                                                                                                                                                                                                                            | **Information**                                                                                                                                                        |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [<mark style="color:red;">**Reset Device**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/device-control-command-group-0x1fnn/reset-device-command-0x1f01)                                                             | The host uses this command to reset the device.                                                                                                                        |
| [<mark style="color:red;">**Set Notification Subscriptions**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/device-control-command-group-0x1fnn/set-notification-subscriptions-command-0x1f02)                         | The host uses this command to specify which notifications the device should send on each of its available interfaces.                                                  |
| [<mark style="color:red;">**Extend Session (Session Managements Only)**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/device-control-command-group-0x1fnn/extend-session-session-management-only-command-0x1f03)      | The host can use this command to extend a session for open protocol interfaces, such as the WLAN interface, which require session management to meet PCI requirements. |
| [<mark style="color:red;">**Terminate Bluetooth LE Connection**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/device-control-command-group-0x1fnn/terminate-bluetooth-le-connection-bluetooth-le-only-command-0x1f04) | The host can use this command to terminate a Bluetooth LE connection.                                                                                                  |
| [<mark style="color:red;">**Erase All Bluetooth LE Bonds**</mark>](/api-and-command-reference/scra-dynafamily-programmers-manual/commands/device-control-command-group-0x1fnn/erase-all-bluetooth-le-bonds-bluetooth-le-only-command-0x1f05)           | The host can use this command to erase all Bluetooth® LE bonds.                                                                                                        |

### Need More Help

{% hint style="info" %}
**Need Help?**

For additional support, please contact MagTek Support:

**Technical Support:**

* 📧 **Email:** [support@magtek.com](mailto:support@magtek.com?subject=Support%20Request)
* 📞 **Phone:** 1-562-546-6800 (US)
* 🕐 **Hours:** Monday-Friday, 5:30 AM - 5:00 PM PST

**Online Resources:**

* 🌐 **Support Portal:** developer.magtek.com

**Documentation Feedback:**

Help us improve this documentation! [feedback@magtek.com](mailto:feedback@magtek.com?subject=Feedback)
{% endhint %}


# Reset Device - Command 0x1F01

The host uses this command to reset the device.

{% stepper %}
{% step %}

### Construct the command request

The host constructs the command request for **Command 0x1F01 - Reset Device** in the format below.
{% endstep %}

{% step %}

### Send the command request

The host sends the command request to the device.
{% endstep %}

{% step %}

### Device responds

The device sends a response in the format below to the host.
{% endstep %}

{% step %}

### Device resets

The device starts an automatic reset within 500ms.
{% endstep %}
{% endstepper %}

## Reset Device - Request Data for Command 0x1F01

<table><thead><tr><th>Tag</th><th width="74">Len</th><th width="246">Value / Description</th><th width="76.33331298828125">Typ</th><th width="73.6666259765625">Req</th><th width="98.666748046875">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including <strong>Request Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1F01 = <strong>Reset Device - Command 0x1F01</strong></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>81</td><td>01</td><td><p>Power Off Option</p><ul><li>0x00 = Reset</li><li>0x01 = Power Off</li></ul><p>Power off only works while a device is running on its battery. If a device is powered off while it is powered by USB, the device will immediately turn back on.</p></td><td>B</td><td>O</td><td>0x00</td></tr><tr><td>End of any wrappers, at minimum including <strong>Request Message</strong></td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## Reset Device - Response Data for Command 0x1F01&#x20;

<table><thead><tr><th>Tag</th><th width="74">Len</th><th>Value / Description</th><th width="75">Typ</th><th width="73.6666259765625">Req</th><th width="100.666748046875">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including <strong>Response Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1F01 = <strong>Reset Device - Command 0x1F01</strong> </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>No parameters.</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>End of any wrappers, at minimum including <strong>Response Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## Request Example - Command 0x1F01&#x20;

{% code title="Example (Hex)" %}

```hex
AA 00 81 04 01 12 1F 01 84 02 1F 01
```

{% endcode %}

## Response Example - Command 0x1F01&#x20;

{% code title="Response Example (Hex)" %}

```hex
AA 00 81 04 82 12 1F 01 82 04 00 00 00 00
```

{% endcode %}


# Set Notification Subscriptions - Command 0x1F02

The host uses this command to specify which notifications the device should send on each of its available interfaces. By default, the device sends notifications to the host on all interfaces.

{% stepper %}
{% step %}

### Sequence of events

The sequence of events is as follows:

1. The host constructs the command request in the format below.
2. The host sends the command request to the device.
3. The device sends a response in the format below to the host.
4. The device immediately begins routing notifications per the request.
5. If the device restarts or loses power, the device resets its notification subscriptions to defaults, and the host must call this command again to change them.
   {% endstep %}
   {% endstepper %}

## Set Notification Subscriptions - Request Data for Command 0x1F02

<table><thead><tr><th>Tag</th><th width="72.6666259765625">Len</th><th width="239.6666259765625">Value / Description</th><th width="76.6666259765625">Typ</th><th width="74.66668701171875">Req</th><th width="96.6666259765625">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including <strong>Request Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1F02 = <strong>Set Notification Subscriptions - Command 0x1F02</strong> </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>81</td><td>01</td><td><p>Subscribe<br></p><ul><li>0x00 = Unsubscribe</li><li>0x01 = Subscribe</li></ul></td><td>B</td><td>O</td><td>0x01</td></tr><tr><td>82</td><td>01</td><td><p>Notifications Affected<br></p><ul><li>0x00 = Only subscribe or unsubscribe to notification messages in the Notification Message ID List parameter</li><li>0x01 = Subscribe or unsubscribe to all notifications</li></ul></td><td>B</td><td>O</td><td>0x01</td></tr><tr><td>83</td><td>var</td><td>Notification Message ID List List of two-byte Notification Message IDs (MSB first) from section 7 Notifications to be subscribed / unsubscribed by this command. For example, to subscribe to Notification 0x0105 - Transaction Operation Complete on the interface being used to send this command, the host would include 0x0105 as two bytes in the list. The device ignores any Notification Message IDs in the list that do not exist.</td><td>B</td><td>O</td><td>Null</td></tr><tr><td>A4</td><td>var</td><td><p>Interfaces</p><p>List of interfaces this command should change the subscription settings for. If the host does not specify any interfaces here, the command applies only to the interface the host is using to send the command.</p></td><td>B</td><td>)</td><td>Null</td></tr><tr><td>/81</td><td>00</td><td>Apply changes to the USB interface</td><td></td><td>O</td><td></td></tr><tr><td>/82</td><td>00</td><td>Apply changes to the WLAN interface</td><td></td><td>O</td><td></td></tr><tr><td>/83</td><td>00</td><td>Apply changes to the Bluetooth® LE interface</td><td></td><td>O</td><td></td></tr><tr><td>/84</td><td>00</td><td>Apply changes to the UART interface</td><td></td><td>O</td><td></td></tr><tr><td>End of any wrappers, at minimum including Request Message </td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## Set Notification Subscriptions - Response Data for Command 0x1F02

<table><thead><tr><th>Tag</th><th width="74">Len</th><th>Value / Description</th><th width="77">Typ</th><th width="74.6666259765625">Req</th><th width="98">Default</th></tr></thead><tbody><tr><td>Beginning of any wrappers, at minimum including <strong>Response Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1F02 = <strong>Set Notification Subscriptions - Command 0x1F02</strong></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>No parameters.</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>End of any wrappers, at minimum including <strong>Response Message</strong> </td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

## Request Example - Command 0x1F02

{% code title="Example (Hex)" %}

```
AA00 810401551F02 8402 1F02
```

{% endcode %}

## Response Example - Command 0x1F02

{% code title="Example (Hex)" %}

```
AA00 810482551F02 820400000000 8402 1F02
```

{% endcode %}




---

[Next Page](/llms-full.txt/1)

