1 of 27

Guides

Guides are task-first, how-to side documentation. API & 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

Reference Section

Information Available

Information on the different ways products connect to hosts.

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

Applies to: DynaFlex II PED, DynaFlex Pro/SCR (Gen I)

About Wireless LAN (WLAN) Connections

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.

For information about SDKs and sample code that can wrap the protocol and speed up development, see SDKs and Tools.

How to Connect to a Device Using the Wireless LAN (WLAN) Connection

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 , 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:

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.

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

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

Choose the command to invoke from .

Construct the command request message using the Request table in the command documentation. For a deeper explanation of the contents of request tables, see

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:

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

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.

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

Applies to: DynaFlex II PED, DynaFlex II Go, DynaFlex Pro/SCR (Geni I)

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

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

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

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

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

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

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.

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.

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.

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

Message Counter

PDU Counter

PCB

Message Length

Message Portion

Message Counter

PDU Counter

Message Portion

Message Counter

PDU Counter

Message Portion

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.

Implement error detection that as a minimum detects and discards incomplete messages.

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 SDKs & 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.

Need Help?

For additional support, please contact MagTek Support:

Technical Support:

📧 Email:

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

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.

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.

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.

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.

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 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?

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.

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?

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.

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:

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:

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

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

Repeat until reaching the first block.

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.

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.

For and , 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.

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

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

Repeat until reaching the first block.

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:

TR-31 Key Block (data object) — 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.
— 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.

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.

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 API & Command Reference.

Applies to: DynaFamily readers with a contactless (NFC) interface — DynaFlex II PED, Go, SCR, and DynaProx.

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)
- Pass-through for NTag and MIFARE Ultralight tags.
MIFARE Classic / MINI / Plus SL1 (Type 2)
- Pass-through for an activated MIFARE Classic, MINI, or Plus SL1 tag.
MIFARE DESFire (Type 4)
- Pass-through for MIFARE DESFire tags.
MIFARE Plus (Type 2)
- Pass-through for MIFARE Plus tags.

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

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 . Entering and leaving pass-through mode is handled by, and requests the reader to poll for a card.

Beyond reading tags, the reader can emulate a card so it can be read by another NFC device — the basis for MagTek's . Card emulation is initiated with the command, using the Card Emulation data object.

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

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.

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^SM 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.

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.

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

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.

Introduction

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

The following documents are essential:

D998200383 DynaFlex Family Programmer’s Manual ( COMMANDS )

A Windows 10 host with available USB port

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

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

Figure - Connecting DynaFlex to a USB Host

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.

The Output log shows the status of the connection.

To disconnect the device, press Disconnect button.

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

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.

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.

At the Add a device window, select Bluetooth.

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

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

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

Update Firmware

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

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

Check the status displayed in the software.

Send The Command Set

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

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.

Enter the following sequence of commands into the Raw Command text box

Set Protection Key Command

Response

Set Your Long Term Key Command

Response

Retrieve your key version Command

Response

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

Response

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

Response

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 CJvcmlnaW5zIjpbImh0dHA6Ly9sb2NhbGhvc3Q6ODA4MCJdLCJpc3MiOiJnb29nbGUtcGF5LWZvci1 wYXNzZXMtZ3RlY2hAcGF5LXBhc3Nlcy1zbWFydC10YXAtc2FtcGxlLmlhbS5nc2VydmljZWFjY29 1bnQuY29tIiwiaWF0IjoxNTI5OTU2MDcwLCJ0eXAiOiJzYXZldG9hbmRyb2lkcGF5IiwicGF5bG9hZC I6eyJsb3lhbHR5T2JqZWN0cyI6W3siY2xhc3NJZCI6IjMyNjUzMjAxMTE2NDE5NTYxODMuMDYxO V9nb29nbGVEZW1vVGVzdCIsInN0YXRlIjoiYWN0aXZlIiwiaWQiOiIzMjY1MzIwMTExNjQxOTU2 MTgzLjA2MTlfZ29vZ2xlRGVtb1Rlc3Qtb2JqMDEifV19fQ.MjUBdBtGyQwcE3xI-q6tVNBiApZppLMp0Op0XvB-c31Ri-JttJCzGXZvURNvKFDGXTNQQDqVBgQziuBMR_ZL0_lp7q8B5nwfSR32I0Kr220n3CezAsikaM5rKV f83UXT9fvqagnRn0QVVuS7fyLLc9nBDxRhRnkqEz2dQPgrNZ1u2AEJBPSoM6sLTeHssOWUMp7dg W6REJg7NUcczXJgLSOpAmD08G14q1qfS5T4Jb4knwPeIMnggNMjHcSBmz0z6W4DGD5Ld16nKOt y4TvoDh4EevEJF7U7UQcOwIpozIXRVKs8rlqEXMObGsrk4hPM-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.

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.

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.

Press the Start EMV Transaction button to start the transaction.

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