Update based on 99200078-8.01: Update usage tables for
0x1A, 0xA1, 0xA2; apply consistent captions to tables and
figures; add kernel IDs; clarify HID Usages; add 0x1F, 0x2E
usages in report descriptor and elsewhere; add BLE properties;
misc. clarifications and accuracy fixes; add Report 0x06
bitmap option, Report 0x1F, Report 0x2E
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® is a registered trademark of MagTek, Inc.
MagnePrint® is a registered trademark of MagTek, Inc.
Magensa™ is a trademark of MagTek, Inc.
MagneSafe™ is a trademark of MagTek, Inc.
DynaPro™ and DynaPro Mini™ are trademarks of MagTek, Inc.
Bluetooth® is a registered trademark of Bluetooth SIG.
iPhone®, iPod®, iPad®, and Mac® are registered trademarks of Apple Inc., registered in the U.S. and
other countries. App StoreSM 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® and Windows® are registered trademarks of Microsoft Corporation.
All other system names and product names are the property of their respective owners.
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 any 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.
FCC WARNING STATEMENT
This equipment has been tested and was found to comply with the limits for a Class B digital device
pursuant to Part 15 of FCC Rules. These limits are designed to provide reasonable protection against
harmful interference when the equipment is operated in a residential environment. This equipment
generates, uses, and can radiate radio frequency energy and, if not installed and used in accordance with
the instruction manual, may cause harmful interference with radio communications. However, there is no
guarantee that interference will not occur in a particular installation.
FCC COMPLIANCE STATEMENT
This device complies with Part 15 of the FCC Rules. Operation of this device is subject to the following
two conditions: (1) this device may not cause harmful interference, and (2) this device must accept any
interference received, including interference that may cause undesired operation.
CANADIAN DOC STATEMENT
This digital apparatus does not exceed the Class B limits for radio noise from digital apparatus set out in
the Radio Interference Regulations of the Canadian Department of Communications.
Le présent appareil numérique n’émet pas de bruits radioélectriques dépassant les limites applicables aux
appareils numériques de la classe B prescrites dans le Réglement sur le brouillage radioélectrique édicté
par le ministère des Communications du Canada.
This Class B digital apparatus complies with Canadian ICES-003.
Cet appareil numérique de la classe B est conformé à la norme NMB-003 du Canada.
CE STANDARDS
Testing for compliance with CE requirements was performed by an independent laboratory. The unit
under test was found compliant with standards established for Class B devices.
UL/CSA
This product is recognized per Underwriter Laboratories and Canadian Underwriter Laboratories 1950.
ROHS STATEMENT
When ordered as RoHS compliant, this product meets the Electrical and Electronic Equipment (EEE)
Reduction of Hazardous Substances (RoHS) European Directive 2002/95/EC. The marking is clearly
recognizable, either as written words like “Pb-free,”“lead-free,” or as another clear symbol ().
This document describes the master command set available through byte-by-byte direct communication
with DynaPro Mini PIN encryption devices (referred to in this document as “the device”).
1.2 Nomenclature
The general terms “device” and “host” are used in different, often incompatible ways in a multitude of
specifications and contexts. For example “host” may have different meanings in the context of USB
communication than it does in the context of networked financial transaction processing. In this
document, “device” and “host” are used strictly as follows:
Device refers to the Pin Encryption Device (PED) that receives and responds to the command set
specified in this document.
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 PED. When “host”
must be used differently, it is qualified as something specific, such as “USB host.”
Because the BLE communication layer uses a very specific meaning for the term “Application,” (see
section 2.3 How to Use BLE Connections) this document favors the term software for software on the
host that provides an interface for the operator, such as a cashier. The combination of device(s), host(s),
software, firmware, configuration settings, physical mounting and environment, user experience, and
documentation is referred to as the solution.
Similarly, the word “user” is used in different ways in different contexts. In command names in this
document, user generally refers to the cardholder.
1.3 About Connection Types
DynaPro Mini uses a common communication protocol across a variety of physical connection layers,
which can include universal serial bus (USB), Apple 30-pin dock connector, and Bluetooth Low Energy
(BLE). The set of available connection layers depends on the device. Details for communicating with
devices via each physical connection type are provided in section 2 Connection Types.
1.4 About Device Features
The information in this document applies to multiple devices. When developing solutions that use a
specific device or set of devices, integrators must be aware of each device’s communication interfaces,
features, and configuration options, which affect the availability and behavior of some commands. Table
1-1 provides a list of device features that may impact command availability and behavior.
MagTek provides convenient Application Programming Interface (API) libraries for some connection
types and development frameworks. These APIs wrap the details of the connection in an interface that
conceptually parallels the device’s internal operation, freeing developers from dealing with the details of
the connection, and allowing them to focus on software business logic. In cases where API libraries are
available, developers also have the option to revert to direct communication with the device using
libraries available in the chosen development framework. This document provides information and
support for the latter method. Information about using MagTek APIs is available in separate
documentation, including 99875394 DynaPro/IPAD Programmer’s Reference (.NET).
2 Connection Types
Table 1-1 above includes a list of connection types available for each device. The following subsections
provide details developers will need to communicate with the devices using each connection type.
2.1 How to Use USB Connections
The devices conform to the USB specification revision 2.0, and are compatible with revision 1.1. They
also conform to the Human Interface Device (HID) class specification version 1.1, and communicate as
vendor-defined HID devices. This document assumes the reader is familiar with USB HID class
specifications, which are available at www.usb.org.
Developers can easily create custom software using any framework that can make API calls to the
standard Windows USB HID driver, such as Visual Basic or Visual C++. MagTek has developed
demonstration software that communicates with the device via this method, and developers can use it to
test the device and to provide a starting point for developing other software. For more information, see
the MagTek web site, or contact your reseller or MagTek Support Services.
These devices are full speed high-powered USB devices that, when connected, draw power from the USB
bus. They identify themselves with vendor ID 0x0801 and product ID 0x3009. The devices will enter
and wake up from Suspend mode when directed to do so by the USB host. They do not support remote
wakeup.
This device has programmable configuration properties stored in non-volatile memory. The properties
are configured via the USB port and can be configured at the factory, by the key loader, or by the end
user. More details can be found in section 3 Command Set in this document, and in a separate document
which provides details about key loading.
2.1.1 About HID Usages
2.1.1.1 About Reports
HID devices send and receive data using reports. Each report can contain several sections, called
usages, each of which has its own unique four-byte identifier. The two most significant bytes of a usage
are called the usage page, and the least two significant bytes are called the usage ID. Vendor-defined
usages must have a usage page in the range 0xFF00 – 0xFFFF, and it is common practice for related
usage IDs to share the same usage page. For these reasons, all usages for these devices use vendordefined usage page 0xFF20.
HID reports used by the host can be divided into three types:
Feature Reports (documented in section 3.4 General Feature Reports). Feature reports can be
further divided into Get types and Set types. The host exclusively uses this type of report to send
commands to the device and to receive synchronous responses from the device.
Input Reports (documented in section 3.5 General Input Reports) are used by the device to send
asynchronous responses or notifications to the host when a related feature report completes, or
automatically when the device’s state changes. This is common when a command depends on
cardholder action (for example, Report 0x03 – Request Swipe Card or Report 0x04 – Request PIN Entry) or otherwise takes more time to run.
Output Reports. Output reports are part of the HID standard, but are not used by these devices.
The host uses HID Set Feature Reports to send commands to the device, and HID Get Feature Reports to
retrieve data or responses from the device when synchronous response is appropriate. The general
sequence for using feature reports to send a command and receive a response is as follows:
1) Send the feature report (command), which could be either a Get or Set type.
2) Read Report 0x01 – Response ACK for acknowledgement, which includes the command number
being acknowledged and a one-byte status indicating whether the device accepted the command.
3) For some commands, the host would then call a Get feature report to read the device’s response.
4) For some commands, the host would instead expect the device to send an asynchronous response via
an HID Input Report using a USB Interrupt IN transaction when the command finishes executing.
2.1.1.2 About the Report Descriptor
The list of the device’s available reports and their structure is sent to the host in a report descriptor,
usually just after the device is connected to the USB port. Generally the details of the report descriptor
are abstracted by the developer’s HID API; however, should it become necessary to examine a report
descriptor byte-by-byte, a full inventory of the report descriptor for these devices is provided in Table 2-1, which also indicates whether each report is a Get type or Set type or both. The reports themselves
are fully documented in the sections that follow.
When DynaPro Mini is connected to an iOS host via the Apple 30-pin dock connector, custom apps use
iPod Accessory Protocol (iAP1) to communicate with DynaPro Mini using the EASession class. The
custom software wraps commands in simple Get/Set wrappers, also called a UART packet header. The
device firmware expects to receive and send data using the same formats produced by the iAP
iPodDataTransfer and AccessoryDataTransfer commands, respectively. Documentation for
these formats is available from Apple, specifically in MFi Accessory Firmware Specification R44 (see
http://developer.apple.com/programs/mfi/). Sample code is available in the form of Apple’s EADemo
app; see https://developer.apple.com/library/IOS/samplecode/EADemo/Introduction/Intro.html.
Because the command set is common to all connection types, it is also helpful to read section 2.1.1 About HID Usages to become familiar with the types of available commands.
The devices only use TXD and RXD; hardware handshaking is not available. The serial settings are
57600 bps, No parity, 8 data bits, and 1 stop bit. Code upgrade commands are not available through
this connection. To communicate with a device using the UART connection, the host should begin all
commands and responses with the following UART packet header:
Command/Response as defined in section 3 Command Set.
IMPORTANT: Generally, iOS commands must be transmitted in MSB (big endian) order.
By convention, this document gives commands in LSB (little endian) order.
2.3 How to Use BLE Connections
This section provides information about developing software for a BLE-capable host that needs to
interface with the device using Bluetooth Low Energy (BLE). In this arrangement, the device will act as
a BLE server/peripheral, and the host will act as a client/central. The custom software wraps commands
in simple Get/Set wrappers, and should use whatever BLE library is appropriate for the chosen software
development framework. For example, iOS custom apps use Apple’s CoreBluetooth Framework, for
which sample code is available in the form of Apple’s Temperature Sensor app; see
https://developer.apple.com/library/IOS/samplecode/TemperatureSensor/Introduction/Intro.html.
Because the command set is common to all connection types, it is also helpful to read section 2.1.1 About HID Usages to become familiar with the types of available commands.
In its default configuration, the BLE module can be toggled between Advertising and not Advertising (for
example, for airline travel) as follows:
If the device is Advertising, press and hold the power button for 7 seconds or longer to reset the BLE
module and turn Advertising off. The device will also reset to this state if the battery completely
discharges.
If the device is not Advertising, press and release the power button, or connect the device to USB
power.
Some of the details described in this section may be abstracted by the libraries in the chosen development
framework. For general information about BLE and the associated terms, see the Bluetooth specifications
found at https://www.bluetooth.org/Technical/Specifications/adopted.htm.
The general steps for a host to communicate with the device via BLE are as follows. Refer to Table 2-3
for details about each BLE Characteristic (in this case, “Application” refers to the device):
1) If the device has been recently reset or has had its battery replaced, re-enable BLE Advertising by
pressing and releasing the power button or connecting the device to USB power.
2) Scan for nearby BLE peripherals advertising the desired GATT service UUID.
3) If multiple devices of the desired type are available, examine each device’s name property. A
specific device’s default name is a constant, equal to the product name plus a dash and the least
significant 4 digits of its Bluetooth address.
4) Establish a BLE connection with the device. If the device is not already powered on, it will start
powering on when the host establishes a connection. The power-on sequence takes about 10 seconds.
Any application data the host sends before the power-on sequence is complete will be lost.
5) Pair with the device using passkey 000000. In many cases this step is user-driven.
6) Configure the device to notify the host when the Application Data To Host Length
characteristic changes. The host should then use this notification as a trigger to read the
Application Data To Host characteristic and process incoming data from the device. The
specific method to enable notifications for a characteristic is different in different BLE development
libraries. For example, iOS code would be similar to [servicePeripheral setNotifyValue:YES forCharacteristic:characteristic].
20:02:B6:0C:41:E3:43:F8:8F:89:82:AD:F8:E6:08:05
Application Data From Host
65 bytes
21:02:B6:0C:41:E3:43:F8:8F:89:82:AD:F8:E6:08:05
Application Data To Host Length
1 byte
22:02:B6:0C:41:E3:43:F8:8F:89:82:AD:F8:E6:08:05
Application Data To Host
128 bytes
23:02:B6:0C:41:E3:43:F8:8F:89:82:AD:F8:E6:08:05
Bit 7 6 5 4 3 2 1 0
Byte 0
0x00 = Get
0x01 = Set
Byte 1
… Byte n
Request data as defined below and in section 3 Command Set.
7) Send commands to the device by writing to the Application Data From Host Length
characteristic, then to the Application Data From Host characteristic; receive notifications
that the device has changed the Application Data To Host Length characteristic, and read
the corresponding incoming data from the Application Data To Host characteristic.
8) The device will stay powered on until the host terminates the BLE connection, or until a user powers
off the device using the power switch. Powering off causes the device to terminate the BLE
connection. To conserve power, always power off the device when it is not in use.
Table 2-3 - BLE Characteristics and UUIDs
To communicate with a device using the BLE connection, hosts should begin all commands and
responses with the following header:
The command / response for a Get report are formatted as follows:
Request from Host
Byte 0 0 (Get)
Byte 1 Report ID
Response from Device
Byte 0 Report ID
Byte 1 - n Report
Maximum report size is 63 bytes.
The command / response for a Set report are formatted as follows:
Request from Host
Byte 0 1 (Set)
Byte 1 Report ID
Byte 2 – n Report
Maximum report size is 63 bytes.
This section describes the full device command set. Because the command set is common to all
connection types, it is helpful to first read and understand section 2.1.1 About HID Usages to become
familiar with the types of available commands.
3.1 About Big Block Data Mode
The device’s big block data mode supports feature reports (commands sent from the host to the device)
and input reports (events sent from the device to the host) that require special treatment of data involved.
Special treatment can include large data sizes, encryption / decryption, encoding / decoding, and so on.
Using big block data mode for feature reports involves using Report 0x10 – Send Big Block Data to Device to load the big block data buffer with the relevant data, then invoking the command.
Using big block data mode for input reports involves sending the desired command, then receiving an
event notification Report 0x29 – Send Big Block Data to Host and unpacking the data.
This document includes specific information for using big block data mode in the usage information for
each report that uses it.
3.2 About SRED / Non-SRED Firmware
Devices can be loaded with one of two types of firmware, depending on how the integrator wants the
device to transmit card data to the host:
The SRED version of the firmware enables Secure Reading and Exchange of Data. In this mode, the
device will not allow complete unmasking of card data, such as the PAN.
In some cases, the solution may require further options for unmasking and encrypting card data
before the device transmits it to the host. In those cases, the device can be loaded with the NonSRED version of the firmware.
All commands and responses in this chapter that are tagged “MAC” require the host to calculate and
append the device unique serial number and a MAC signature to the message per ANSI X9.19 -1996 – Financial Institution Retail Message Authentication.
Data for “MAC” commands is staged using big block data buffers. For information about using big block
mode, section 3.1 About Big Block Data Mode. After the host sends the big block data to the device, it can then send the “MAC” tagged command.
The key used will be depend on the message; it will be the MAC variant of either the MSR or AMK key.
For CA Public Key configuration, the host should use the AMK MAC variant (because no encryption is
involved). For big block batch data and smart card ARQC requests, the host should use the MSR MAC
variant. These commands require the encrypted block to begin with a two-byte header in big-endian form
(MSB first) that contains the expected length of the message after decryption, excluding data padding and
CBC-MAC.
The following sections provide details about the required tag structures for each of these requests.
3.3.1 CA Public Key Data and Terminal and Payment Brand Data (TLV format)
AAAA /* 2-byte MSB message length excluding padding and CBC-MAC */
F9<len> /* container for MAC structure and generic data */ DFDF55(MAC Encryption Type)<len><val>
DFDF25(IFD Serial Number)<len><val>
FA<len>/* container for generic data */
<Buffer if any to make blocks as multiple of 8 bytes>
<CBC-MAC (4 bytes, use MAC variant of AMK)>
3.3.2 ARQC Requests (Smart Cards)
3.3.2.1 Non-SRED ARQC request
Begin with a two-byte header in big-endian form (MSB first) that contains the expected length of the
message after decryption (included as <len> in the sample below), excluding data padding and CBCMAC. Use container F9 for the MAC structure, container FA for passing the non-encrypted ARQC
message, and use the MAC variant of the MSR DUKPT key.
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>
FA<len>/* container for generic data */
70<len> /*container for ARQC */
F4<len>/* container tag for encrypted MSR data, if
present */
DFDF36 <EncT1status><len><val>
DFDF37 <EncT1data><len><val>
DFDF38 <EncT2status><len><val>
DFDF39 <EncT2data><len><val>
DFDF3A <EncT3status><len><val>
DFDF3B <EncT3data><len><val>
DFDF3C <Encrypted Magneprint Data><len><val>
DFDF3D <Magneprint Status><len><val>
DFDF43 <Magneprint Status Data><len><val>
DFDF50(MSR KSN Data)<len><val> /*sent in the
clear*/
DFDF51(MSR EncryptionType)<len><val>
F5<len>/* container tag for encrypted PIN data
(normally debit card)*/
99(Encrypted PIN DATA)<len><val>
DFDF41(PIN KSN Data)<len><val>
DFDF42(PIN EncryptionType)<len><val>
(Buffer if any to be a multiple of 8 bytes)
CBC-MAC (4 bytes, use MAC variant of MSR DUKPT key)
3.3.2.2 SRED ARQC Request
Begin with a two-byte header in big-endian form (MSB first) that contains the expected length of the
message after decryption, excluding data padding and CBC-MAC. Use container F9 for the MAC
structure, use container F8 within container FA for passing the encrypted ARQC message, and use the
MAC variant of the MSR DUKPT key.
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>
FA<len>/* container for generic data */
70<len> /*container for ARQC */
F8<len> /*container tag for encryption */
DFDF59(Encrypted Data
Primitive)<len><Encrypted Data val (Decrypt data to read tags)>
DFDF56(Encrypted Transaction Data
KSN)<len><val>
DFDF57(Encrypted Transaction Data
Encryption Type)<val>
DFDF58(# of bytes of padding in
DFDF59)<len><val>
(Buffer if any to be a multiple of 8 bytes)
CBC-MAC (4 bytes, use MAC variant of MSR DUKPT key)
The Value inside tag DFDF59 is encrypted and contains the following after decryption:
FC<len>/* container for encrypted generic data */
F4<len>/* container tag for encrypted MSR
data */
DFDF36 <EncT1status><len><val>
DFDF37 <EncT1data><len><val>
DFDF38 <EncT2status><len><val>
DFDF39 <EncT2data><len><val>
DFDF3A <EncT3status><len><val>
DFDF3B <EncT3data><len><val>
DFDF3C <Encrypted Magneprint
Data><len><val>
Response from host (key used must be the same as KSN in ARQC request). Use container F9 for the
MAC structure, use F8 within FA for passing the encrypted ARQC message, use MAC variant of MSR
DUKPT key. This example assumes an acquirer host response of 70 04 8A 02 30 30:
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>
FA<len> /* Container for generic data */
70 04 8A 02 30 30
(ARQC padding, if any, to be a multiple of 8 bytes)
CBC-MAC (4 bytes, use MAC variant of MSR DUKPT key that was used in
ARQC request, from message length up to and including ARQC padding, if
any)
3.3.3 Batch Data
3.3.3.1 Non-SRED Batch Data
Begin with a two-byte header in big-endian form (MSB first) that contains the expected length of the
message after decryption, excluding data padding and CBC-MAC. Use container F9 for the MAC
structure, FA for passing non-encrypted batch data message, use MAC variant of MSR DUKPT key.
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>
FA<len>/* container for generic data */
F0<len> /* Transaction Results */
F1<len> /* container for Status Data */
… /* Status Data tags */
F2<len>/* container for Batch Data */
… /* Batch Data tags */
F3<len>/* container for Reversal Data, if any */
… /* Reversal Data tags */
F7<len>/* container for Merchant Data */
… /* < Merchant Data tags */
(Buffer if any to be a multiple of 8 bytes)
CBC-MAC (4 bytes, use MAC variant of MSR DUKPT key)
3.3.3.2 SRED Batch Data
Begin with a two-byte header in big-endian form (MSB first) that contains the expected length of the
message after decryption, excluding data padding and CBC-MAC. Use container F9 for the MAC
structure, use F8 within FA for passing encrypted batch data message, use MAC variant of MSR DUKPT
key.
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>
FA<len>/* container for generic data */
F0<len> /* Transaction Results */
F1<len> /* container for Status Data */
… /* Status Data tags */F8<len> /* container tag for encryption */
DFDF59(Encrypted Data Primative)<len><Encrypted
Data val (Decrypt data to read tags)>
DFDF56(Encrypted Transaction Data KSN)<len><val>
DFDF57(Encrypted Transaction Data Encryption
Type)<val>
DFDF58(# of bytes of padding in DFDF59)<len><val>
F7<len>/* container for Merchant Data */
… /* < Merhcant Data tags */
(Buffer if any to be a multiple of 8 bytes)
CBC-MAC (4 bytes, use MAC variant of MSR DUKPT key)
The Value inside tag DFDF59 is encrypted and contains the following after decryption:
FC<len>/* container for encrypted generic data */
F2<len>/* container for Batch Data */
… /* Batch Data tags */F3<len>/* container for Reversal Data, if any */
… /* Reversal Data tags */
Notes:
1 - ARQC request encrypted message: 70<len> F8 <len><encrypted data>
2 - Batch data includes batch and merchant data and for declined transactions, reversal data as well.
This command causes the device to send the host a response status (“ACKSTS”, see Appendix C Status
and Message Table), and the Report ID of the command the host has just executed. The host should get
this report immediately after it sends any command to the device to determine whether or not the device
accepted the command as sent.
Table 3-1 - Usage Table for Report 0x01
3.4.2 Report 0x02 – End Session
This command clears all existing session data including PIN, PAN, and amount. The device returns to
the idle state and sets the display to the specified Welcome screen. Use of message IDs 1-4 require that
the associated bitmaps have been previously loaded during configuration; otherwise, use 0 for
displayMsg and the device will display its default “Welcome” screen (shown below).
Wait time in seconds, (1 – 255; 0 = infinite wait time)
Byte 2
Card Message ID to display:
0 = Swipe Card / Idle alternating
1 = Swipe Card
2 = Please Swipe Card
3 = Please Swipe Card Again
4 = Chip Error, Use Mag Stripe
Byte 3
Tones:
0 = No sound
1 = One beep
2 = Two beeps
3.4.3 Report 0x03 – Request Swipe Card
This command causes the device to prompt the user to swipe a card by displaying one of four
predetermined messages (see Card Message ID in Table 3-3). Example request screens look like this:
Figure 3-2 - DynaPro Mini Initial Swipe Prompt
The device will report an error in ACKSTS of Report 0x01 – Response ACK in the following cases:
System Error (0x80)
Bad parameter (0x82)
PAN already exists in the device (0x84)
System is not available (0x8A)
When this command completes (card swiped OK, user cancelled, or timeout), the device will send Report
0x22 – Card Status Report to the host. If the Card and Operation Status are both OK, the host should then send Report 0x0A – Request MSR Data to get the card data.