My E3 Device Integrator's Guide

E3%20Device%20Integrator's%20guide

User Manual:

Open the PDF directly: View PDF .
Page Count: 21

Download
Open PDF In Browser	View PDF

Heartland End-to-End
Encryption

Integrator's Guide
V 2.0
AUGUST 12, 2014

E3 User's Guide, V 2.0—August 12, 2014

Table of Contents

Table of Contents
Table of Contents
1 Overview
1.1 Introduction
1.2 The E3® Solution
1.3 Target Audience
2 Encryption Data
2.1 Encrypted Track and PAN Data
2.2 Encrypted Card Security Code
2.3 Encryption Transmission Block
3 Z01 Section
4 NTS Section
5 POS 8583
6 Heartland Exchange
6.1 Unique Transaction ID (UID)
6.2 Merchant ID Number (MID)
6.3 Account Data Source
6.4 Customer Data
6.5 Retrieval Reference Number (RRN)
6.6 Transaction Identifier
6.7 Authorization Example
6.8 Void/Incremental Example
6.9 Settlements
6.9.1 Header Record Fields
6.9.2 Detail Record Fields
6.9.3 Settlement Notes
7 E3 Hardware Devices
7.1 E3 MSR Wedge (HPS-E3-M1)
7.1.1 E3 MSR Wedge Device Interface
7.1.2 E3 MSR Wedge Example Output
7.2 E3 PIN Pad (HPS-E3-P1)
7.2.1 E3 PIN Pad Device Interface
7.2.1.1 E3 PIN Pad Requests
7.2.1.2 E3 PIN Pad Responses
7.3 Ingenico iPP300 and iSC Touch Series PIN Pads
7.4 Equinox L4000 and L5000 Series PIN Pads

ii
1
1
1
1
2
2
3
3
4
6
8
9
9
9
9
9
10
10
10
12
12
12
12
13
14
14
15
15
15
17
18
18
18
19

E3 User's Guide, V 2.0—August 12, 2014

1 Overview

1 Overview
1.1 Introduction
Heartland Secure™ is a comprehensive credit/debit card data security solution that combines three
powerful technologies working in tandem to provide merchants with the highest level of protection
available against card-present data fraud.
Offered to Heartland customers for no additional processing fees as part of Heartland's
comprehensive solutions, Heartland Secure combines:
l
l

EMV electronic chip card technology to prove that a consumer's card is genuine.
Heartland's E3® end-to-end encryption technology, which immediately encrypts card data as it
is acquired so that no one else can read it.
Tokenization technology, which replaces card data with "tokens" that can be used for returns
and repeat purchases, but are unusable by outsiders because they have no value.

This guide focuses on Heartland's E3 end-to-end encryption solution and contains integration
information for POS systems. It serves as a companion to Heartland's host network specifications
and the E3 device programmer's manuals. These documents should be referred to for more detailed
information.
®

1.2 The E3 Solution
E3, an end-to-end encryption product by Heartland Payment Systems, is designed to protect credit
and debit card data from the moment of card swipe and through the Heartland network — not just at
certain points of the transaction flow.
E3 is based on Voltage Security's SecureData Payments product which provides a complete
payment transaction protection framework, built on two breakthrough technologies encompassing
encryption and key management: Voltage Format-Preserving Encryption (FPE) and Voltage
Identity-Based Encryption (IBE).
With Voltage Format-Preserving Encryption (FPE), credit card numbers and other sensitive data
are protected without the need to change the data format or structure. In addition, data properties
are maintained, such as a checksum, and portions of the data can remain in the clear.
With Voltage Identity-Based Encryption (IBE), the complexity of key management through
traditional Public Key Infrastructure (PKI) systems and symmetric key systems is eliminated.
Because encryption keys are securely generated on demand and not stored, POS devices are not
subject to key injection and key rotation.

1.3 Target Audience
This document's target audience includes POS software developers who use Heartland’s POS
technologies and are certified in payment processing with Heartland.

2 Encryption Data

E3 User's Guide, V 2.0—August 12, 2014

2 Encryption Data
2.1 Encrypted Track and PAN Data
Depending on the configuration of your E3-capable card acceptance device, the E3 encrypted Track
and PAN data will be formatted using one of two Track Encryption Protocol (TEP) algorithms, TEP1
or TEP2. TEP1 is whole track encryption, while TEP2 is structure preserving encryption. For
example, the following data was produced by an E3-capable device using Heartland's VISA test
card:
Table 2.1: PAN Encryption
PAN Encryption
Cleartext

4012002000060016

TEP2

4012002650330016

TEP1

+++++++BWmfv/HUA

Table 2.2: Track 1 Encryption
Track 1 Encryption
Cleartext

%B4012002000060016^VI TEST CREDIT^251210118039000000000396?

TEP2

B4012007060016^VI TEST CREDIT^2512101XlwD91O5qOg+7Ftv+nLu

TEP1

3FLr83Ed5tiHN3r2CpT3kIndkhtiHRt3mtKQsozJ2rFQM8GE0ha2X7K6t

Table 2.3: Track 2 Encryption
Track 2 Encryption
Cleartext

;4012002000060016=25121011803939600000?

TEP2

4012007060016=2512101e3vdC5QhAEZa7UAN

TEP1

AsbjXkDWaRqLV0o5U33jffZqiPg

For TEP2, the following is guaranteed:
l
l
l

The leading six digits of the original PAN are maintained in the clear.
The trailing four digits of the original PAN are maintained in the clear.
The middle digits are used for the ciphertext value, which is guaranteed to consist solely of
digits.
The Luhn check value is preserved so that a PAN with a valid (0) result, creates ciphertext that
also checks as valid.

For TEP1, the device will provide a separate masked or obfuscated representation of the track data
for processing that requires the first six or last four digits of the PAN, cardholder name, expiration
date, Luhn check results, etc.

2 Encryption Data

E3 User's Guide, V 2.0—August 12, 2014

2.2 Encrypted Card Security Code
The Card Security Code (CSC) printed on the back of the card, referred to as CAV2, CVC2, CVV2,
or CID depending on the card brand, can be optionally encrypted. The value to be encrypted is
constructed as follows:
Length [1 digit] Random Filler [x digits] CSC [3 or 4 digits]

Step

Example Data

1. Obtain the CSC value (either 3 or 4 digits)

572

2. Generate a random 3-digit number

413

3. Construct the value to be encrypted

3413572

4. Encrypt the value

9037662

Note: The total length of the encrypted CSC will always be seven digits. Typically, the device will
randomly generate two or three digits of filler to ensure the CSC is seven digits.

2.3 Encryption Transmission Block
The Encryption Transmission Block (ETB), sometimes referred to as a Key Transmission Block
(KTB), contains the IBE encrypted version of the device's randomly generated FPE key that was
used to encrypt the card data. The ETB must be sent in the authorization requests so that the host
can decrypt the card data.
Heartland's ETB must be Base64 encoded, and for TEP1 and TEP2 it must be 276 bytes.
For example:
/wECAQEEAoFGAgEH3gcOTDT6jRZwb3NAc2VjdXJlZXhjaGFuZ2UubmV0tmpl5zBEIeye
aDRWB0IlbnWdMjK32V4QIJRoRIpu1Fm9w8fdoJt1gLt2jkkliD+0kvFOrhspWh4dsDYv
SHGgdgetU3pfAx+iBS38Wq2KvTOOlueGvXcGe0y4G/DFVgT7zBHm1YS7cseYLEtADtoS
nhBUjasCciO5ul9GhesvQo8Ah7NM8geDZdKN0QZZiLH8cmYhgHp8kamxSciDJHARUO9t
Fb+h

3 Z01 Section

E3 User's Guide, V 2.0—August 12, 2014

3 Z01 Section
This section addresses specific requirements for E3 terminals processing on the Z01 network
platform. All card types may be sent via E3 encryption. All transactions using E3 processing append
additional data items at the end of the record, which signals to the host that the transaction is E3
encrypted.
These transactions require the following:
l

l
l

Portions of the E3 data must always appear at the end of a transaction. The POS terminal will
append a 0x1D at the end of the transaction followed by the E3 data. Refer to Table 2.1 Data
Fields.
Note: The encrypted CVV and ETB are attached to the E3 Data Block, while the encrypted
track data and/or encrypted PAN are placed in their normal position in the
authorization message.
POS must send spaces in AVS RESULT AND CID RESULT. The encrypted values are in
the E3 Data Block.
An account number must not be less than 13 characters and the encrypted account number
data will not exceed 19 characters.
Encrypted Track 1 data will not include the field separator 0x1C.
Encrypted Track 2 data will not exceed 37 bytes.

Response codes specific to E3 transactions are:
l
l

URC = EG, SRC = 8 (Failure for E3 terminals only – encryption error)
URC = EH, SRC = 8 (Failure for E3 terminals only – too many queued / no connection)

Note: E3 transactions are not supported for TDC batch uploads.

Table 2.1 Data Fields shows the data items that must be appended to the end of an E3 transaction.
Table 3.1: Z01 Data Fields
Name

Length

Value

FIELD SEPARATOR

0x1D

RECORD ID

RECORD TYPE

001

KEY BLOCK DATA TYPE

ENCRYPTED FIELD MATRIX

Comment
Indicator for E3 transaction (Hex: Constant ASCII)
Must be appended at end of E3 transaction.

v = Voltage
Values:
l
l

03 = Customer Data
04 = Customer Data, Card Security Code

3 Z01 Section

E3 User's Guide, V 2.0—August 12, 2014

TEP TYPE

Values:
l
l

1 = TEP 1
2 = TEP 2

RESERVED

Blank-fill

CARD SECURITY CODE

Encrypted CVV data. Unencrypted bytes defined as:
l
l

1 = Length of actual CVV data
2-7 = CVV data, right-justified, random-fill, numeric
only

RESERVED

Blank-fill

ETB LLL

Length of ETB Block.

ETB BLOCK

Varies

ETB should not exceed 276 bytes.

4 NTS Section

E3 User's Guide, V 2.0—August 12, 2014

4 NTS Section
This section addresses specific requirements for E3 terminals processing on the NTS network
platform. All card types may be sent via E3 encryption. All transactions using E3 processing append
additional data items at the end of the record, which signals to the host that the transaction is E3
encrypted. These transactions require the following:
l

l
l

Portions of the E3 data must always appear at the end of a transaction. The POS terminal will
append a 0x1D at the end of the transaction followed by the E3 data. Refer to Table 3.1: NTS
Data Fields.
Note: The encrypted CVV and ETB are attached to the E3 Data Block, while the encrypted
track data and/or encrypted PAN are placed in their normal position in the
authorization message.
POS must send spaces in the CVN field. This encrypted CVN value will be in the E3 Data
Block.
An account number must not be less than 13 characters and the encrypted account number
data will not exceed 19 characters.
Encrypted Track 1 data will not exceed 79 bytes.
Encrypted Track 2 data will not exceed 40 bytes.

Response codes specific to E3 transactions are:
l
l

52 (Failure for E3 terminals only – encryption error)
53 (Failure for E3 terminals only – too many queued / no connection)

Table 3.1 NTS Data Fields shows the data items that must be appended to the end of an E3
transaction.
Table 4.1: NTS Data Fields
Name

Length

Value

FIELD SEPARATOR

0x1D

RECORD ID

RECORD TYPE

001

KEY BLOCK DATA TYPE

ENCRYPTED FIELD MATRIX

Comment
Indicator for E3 transaction (Hex: Constant ASCII) Must
be appended at end of E3 transaction.

v = Voltage
Values:
l
l

TEP TYPE

03 = Customer Data
04 = Customer Data, Card Security Code

Values:
l
l

RESERVED

1 = TEP 1
2 = TEP 2

Blank-fill

4 NTS Section

E3 User's Guide, V 2.0—August 12, 2014

CARD SECURITY CODE

Encrypted CVV data. Unencrypted bytes defined as:
l
l

RESERVED
ETB LLL
EBT BLOCK

45
3
Varies

1 = Length of actual CVV data
2 – 7 = CVV data, right-justified, random-fill, numeric
only

Blank-fill
Length of ETB Block.
ETB should not exceed 276 bytes.

5 POS 8583

E3 User's Guide, V 2.0—August 12, 2014

5 POS 8583
This section addresses specific requirements for E3 terminals using the POS 8583 message
specification. All card types may be sent using E3 encryption. All transactions utilizing E3 processing
will include E3 data in DE 127: Forwarding Data.
These transactions require the following:
l

l
l

E3 data must always appear in DE 127: Forwarding Data (using an Entry Tag value of
“E3E”.)
Note: The encrypted CVV and ETB are attached to the E3 Data Block, while the encrypted
track data and/or encrypted PAN are placed in their normal position in the
authorization message.
An account number must be more than 13 characters, the encrypted account number data
cannot exceed 19 characters.
Encrypted Track 1 data will not exceed 79 bytes.
Encrypted Track 2 data will not exceed 40 bytes.

Response codes specific to E3 transactions are:
l
l

DE 39 = 952 (Failure for E3 terminals only – encryption error)
DE 39 = 953 (Failure for E3 terminals only – too many queued / no connection)
Table 5.1: POS 8583 Data Fields
Field Name

Field Length

Comment

RECORD ID

"E3"

RECORD TYPE

"001"

KEY BLOCK DATA
TYPE

"v" Voltage

ENCRYPTED FIELD
MATRIX

Values:
l
l

TEP TYPE

03 CustomerData
04 CustomerData,Card Security Code

Values:
l
l

1 = TEP 1
2 = TEP 2

RESERVED

Blank-fill

CARD SECURITY
CODE

Encrypted CVV data. Unencrypted bytes defined as:
l
l

1 = Length of actual CVV data
2-7 = CVV data, right-justified, random-fill, numeric only

RESERVED

Blank-fill

ETB LLL

Length of ETB Block

ETB BLOCK

Varies

ETB cannot exceed 276 bytes.

E3 User's Guide, V 2.0—August 12, 2014

6 Heartland Exchange

6 Heartland Exchange
This section addresses specific requirements for E3 terminals using the Heartland Exchange
message specification. All card types may be sent using E3 encryption.

6.1 Unique Transaction ID (UID)
Heartland's Unique Transaction ID (UID) is a software solution that eliminates the need for a POS
application to store the account number or track data for subsequent processing such as Voids,
Incrementals, and Batch Settlement. The UID is returned by the Heartland Exchange Host in the
Authorization response messages. This application is not available on other Heartland host
platforms.

Voids / Incrementals:
The Account Data Source field will be 'Z' or 'z' to indicate that the UID is being used instead of
track or Primary Account Number (PAN) data. The Customer Data field will contain the UID
which is the Retrieval Reference Number (RRN) from the Authorization.

Batch Settlement:
The Primary Account Number field in the Batch Settlement Detail Record will be filled with all
spaces to indicate that the UID is being used instead of PAN data. The Transaction Identifier field
in the Batch Settlement Detail Record is the Transaction Identifier from the Authorization and it
contains the UID.

6.2 Merchant ID Number (MID)
Merchant ID Number is a 12 character field that contains a unique number assigned by Heartland. If
your E3 implementation encrypts the MID, then the E3 sub-encryption indicator in the Key Block
data field must indicate the MID is encrypted (01 or 02 as appropriate).

6.3 Account Data Source
The Account Data Source field is used to indicate the source and format of the data contained in the
Customer Data field. Refer to the Exchange Host Specification for a complete list of Account Data
Source codes.

6.4 Customer Data
The Customer Data field contains the Key Block data and either the Cardholder Account data or the
Unique Transaction ID. The Cardholder Account data may be either the encrypted Track 1,
encrypted Track 2, or encrypted primary account number. The unique transaction ID is never
encrypted. Refer to the Exchange Host Specification for the Customer Data format.

6 Heartland Exchange

E3 User's Guide, V 2.0—August 12, 2014

6.5 Retrieval Reference Number (RRN)
The Retrieval Reference Number field contains a value that uniquely identifies a transaction. The
Retrieval Reference Number is sent in an authorization response. The POS then uses the RRN in
voids and incrementals to identify the original transaction.

6.6 Transaction Identifier
The Transaction Identifier field contains the UID. The Transaction Identifier is sent in an
authorization response.

6.7 Authorization Example
The following examples shows highlighted fields that are used in the POS message to Heartland
messaging:
l
l
l
l

Encrypted Track 1 data
Encrypted Track 2 data
Encrypted PAN (Primary Account Number)
KTB (Key Transmission Block)
Table 6.1: Authorization Examples
Request

For Encrypted Card Swipes:
The following request fields require specific handling:
l

MID (Merchant ID Number) This field will be the unencrypted,
cleartext MID.
Account Data Source – This field will indicate that either
encrypted Track 1 or Track 2 data is being sent:
n
n

Response

The following response
fields require specific
handling:
l

“h” = Encrypted Track 1
“d” = Encrypted Track 2

Customer Data – This field will be , where is “v” (Voltage encryption)+ “03” + KTB.
For example:

RRN (Retrieval
Reference Number)–
This field will be used as
the UID (Unique
Transaction ID) for
subsequent messages
such as voids.
Transaction Identifier –
This field will be used as
the UID in the batch
settlement detail record.

v03/wECAQECAoFGAgEH2ggJTHLeIBZwb3NAc2
VjdXJlZXhjaGFuZ2UubmV0aFLxu2XTNLs6jIk3Bakt
bFZrdJ26dX85BjkkngQnmk+3tOhXRVILvASHnfmao0y
l5z7KNBx6Na7ekL+hryGQ3oPOcOVkEzei83Clsc
9QSfQJWB9ysAynGc6btccnrfjwyJn70KJ1cqQrw

E3 User's Guide, V 2.0—August 12, 2014

6 Heartland Exchange

623ASSWm57Hov2fMtWmPpYpQRr54oAoXZY
jUajd0sRXCn5XeD5BhpE/Wzd4Ayn+342BGUL
0N7hWKmV2uvVFzWkBTNzcX7vcrWTi4
jV9AtG2bLYJkCOi+OA2aY2OiRmw/0ZSQcH
For Encrypted Manual Entry:
The following request fields require specific handling:
This field will be the unencrypted, cleartext MID.
Account Data Source – This field will indicate that an encrypted
PAN is being sent:

l
l

n
n

“x” = Encrypted, manually keyed PAN, Track 1 capable
“t” = Encrypted, manually keyed PAN, Track 2 capable

Customer Data – This field will be , where is “v” (Voltage
encryption) + “03” + KTB. For example:
v03/wECAQECAoFGAgEH2ggJTHLeIBZwb3NAc
2VjdXJlZXhjaGFuZ 2UubmV0aFLxu2XTNLs6jIk3Ba
ktbFZrdJ26dX85BjkkngQnm
k+3 tOhXRVILvASHnfmao0yl5z7
KNBx6Na7ekL+hryGQ3oPOcOVkE
zei83Clsc9QSf QJWB9ysAynGc6btccnfrfjwyJn70KJ1
cqQrw623ASSWm57Hov2fMtWmPpYpQRr
54oAoXZYjUajd0sRXCOn5XeD5BhpE/Wzd4Ayn+3
42BGUL0N7hWKm+++++++X8zr5YaCZ1012

Notes:
l

Refer to section Authorization Chapter in the Heartland Exchange specification for all other
fields.
UIDs are used to retrieve a transaction’s account data for Voids, Incrementals, and Batch
Settlement. This eliminates the need to store or send encrypted or unencrypted track, PAN, or
KTB data once authorization has occurred.
For refunds/returns, Purchase Return (Transaction Code CR) must be utilized so that the
returned UID can be used for settlement.
For voice authorizations, Online Forced Purchase (Transaction Code 5S) must be utilized so
that the returned UID can be used for settlement.

E3 User's Guide, V 2.0—August 12, 2014

6 Heartland Exchange

6.8 Void/Incremental Example
A Void is required to cancel a previously authorized transaction. Online Auth Void (Transaction
Code 59), PIN Debit: Purchase Void (Transaction Code A3), or PIN Debit: Purchase Return Void
(Transaction Code A4) should be used depending on the type of the original authorization.
An Incremental Authorization is required in certain industries such as Hotel/Lodging when the final
amount due is more than 15% higher than the originally authorized amount.
For Voids/Incremental Requests, the fields below require specific handling:
l
l

Merchant ID Number – This field will be the unencrypted, cleartext MID.
Account Data Source – This field will indicate that the UID is being sent instead of track or
PAN data:
n

“z” = Original authorization request contained encrypted track or PAN data.

Customer Data – This field will be , where
is just "v03" - the KTB is not required in this case since no encrypted data is being sent, and
is the RRN from the original authorization response.
Note: Refer to the Heartland Exchange specification for all other fields.

For Void/Incremental Responses, no specific fields in the Exchange Host response require specific
handling.

6.9 Settlements
Batch transactions consist of a number of record types and require both request and responses.

6.9.1 Header Record Fields
Header Record Requirements:
l
l

Merchant ID Number – This field will be the unencrypted, cleartext MID.
Key Block – This field will be just “v03” – the KTB is not required in this case since no encrypted
data is being sent.

6.9.2 Detail Record Fields
Detail Record Requirements:
l

Account Data Source – This field will be the same value as was used in the original
authorization request.
Primary Account Number – This field will be filled with 22 spaces to indicate that the UID will
be used.
Transaction Identifier – This field will be the Transaction Identifier from the original
authorization response (it contains the UID).

E3 User's Guide, V 2.0—August 12, 2014

6 Heartland Exchange

6.9.3 Settlement Notes
UIDs must be used for settlement, all other record fields in both the request and responses follow
those defined in the Exchange Host Specifications.
Note: The only alternative supported on Exchange for settling E3 encrypted transactions is to send
the encrypted PANs in the detail records, but that option requires that all transactions in the
batch share the same KTB.

7 E3 Hardware Devices

E3 User's Guide, V 2.0—August 12, 2014

7 E3 Hardware Devices
The following section describes hardware devices that use E3 encryption technology which
integrates with Heartland Hosts:
l
l
l
l
l

E3 MSR Wedge (HPS-E3-M1)
E3 PIN Pad (HPS-E3-P1)
Ingenico iPP300 Series Retail PIN Pads
Ingenico iSC Touch Series Signature Capture PIN Pads
Equinox L4000 and L5000 Series Signature Capture PIN Pads

Note: These E3-capable devices must be pre-configured to use either TEP1 or TEP2 encryption,
and pre-configured to be used in either the certification or production environments. Please
work with Heartland to ensure that the your devices have been configured appropriately
prior to certification testing or production deployment.

7.1 E3 MSR Wedge (HPS-E3-M1)
l
l

Hardware-encrypts card data upon swipe
Incorporates a Tamper-Resistant Security Module (TRSM) to physically protect data and
encryption keys
Available with USB and RS232 connectors

Figure 7.1: E3 MSR Wedge

7 E3 Hardware Devices

E3 User's Guide, V 2.0—August 12, 2014

7.1.1 E3 MSR Wedge Device Interface
Table 7.1: E3 MSR Wedge operation modes:
Mode

Description

USB HID-KB

The POS system receives data from the E3 MSR Wedge as if sent from a
standard USB keyboard. In this mode, you can see the output by opening a text
editor such as Notepad and swiping a card. The output is in Format 2 per the
programmer’s manual.

USB HID-MSR

The POS system receives data from the E3 MSR Wedge via its native USB HID
interface in Format 1. For this mode, an ActiveX control is available for web
applications running on Internet Explorer and provides commands for obtaining
the desired output components. Also, a command-line application is available
that acquires and reformats the output as Format 2.

USB Virtual-COM or RS232

The POS system receives data from the E3 MSR Wedge via its native serial
COM port interface, which outputs in Format 2.
A virtual COM port driver is available for Windows. The RS232 wedge has a
standard 9-PIN serial connector.

7.1.2 E3 MSR Wedge Example Output
See the following Format 2 example output from the E3 MSR Wedge:

7.2 E3 PIN Pad (HPS-E3-P1)
The E3 PIN Pad is compatible with standard PIN entry/encryption operations, but is also capable of
functioning with MSR, Europay, MasterCard, and VISA (EMV) smart cards.
l
l
l

Built-in MSR encrypts at the swipe and TRSM protects the data and keys
Hardware-encrypt manually-entered card numbers
Available with USB and RS232 connectors

7 E3 Hardware Devices

E3 User's Guide, V 2.0—August 12, 2014

Figure 7.2: E3 PIN Pad
Table 7.2: E3 PIN Pad Codes
POS System
E1.3111219098025[LRC]

E2.030[LRC]

Direction

E3 PIN Pad

→

“SWIPE CARD OR ENTER ACCOUNT #” is displayed
on LCD.

←

→
←

7 E3 Hardware Devices

E3 User's Guide, V 2.0—August 12, 2014

←

If card is swiped...
E3.11%B401200000000001
6^VI TEST CREDIT^25120000000
0000000000000?|V2uvVFzWkBT
NzcX7vcrWTi4jV9AtG2bLYJkCO
i+OA2aY2OiRmw/0ZSQcH|++++
+++X8zr5YaCZ11;4012000
000000016= 251 20000000000
000000?|7QjTe2v1Qy1L84Q+n6
zudfNOXf|+++++++X8zr5YaCZ
00||/wECAQ
ECAoFGAgEH2ggJTHLeIBZwb3N
Ac2VjdXJlZXhjaGFuZ2
UubmV0aFLxu2XTNLs6jIk3Baktb
FZrdJ26dX85Bjkkng Qnmk+3tOhX
RVILvASHnfmao0yl5z7KNBx6Na
7ekL+hry GQ3oPOcOVkEzei8
3Clsc9QSfQJWB9ysAynGc6btccn
fr fjwyJn70KJ1cqQrw623ASSWm
57Hov2fMtWmPpYpQRr54
oAoXZYjUajd0sRXCOn5XeD5Bhp
E/Wzd4Ayn+3 42BGUL0N7hWKm
[LRC]
or
If card number is manually entered...
E4.114012000000000016
+++++++X8zr5YCZ/wECA
QECAoFGAgEH2g
gJTHLeIBZwb3NA2VjdXJlZXhj
aGFuZ2UubmV0aFLxu2XTNLs6
jIk3Baktb FZrdJ26dX85Bjkkng
Qnmk+3tOhXRVILvASHnfma
o0yl5 z7KNBx6Na7ekL+hryGQ3
oPOcOVkEzei83Clsc9QSfQJW
B9ysAynGc6btccnfrfjwyJn70KJ
1cqQrw623ASSWm57H ov2fM
tWmPYpQRr54oAoXZYjUajd0
sRXCOn5XeD5BhpE /Wzd4Ayn
+342BGUL0N7hWKm[LRC]

→

7.2.1 E3 PIN Pad Device Interface
The POS system transmits and receives data to/from the E3 PIN Pad via its native serial COM port
interface. For the USB PIN pad, a virtual COM port driver is available for Windows. The RS232 PIN
pad has a standard 9-PIN serial connector.
All messages are framed using standard VISA protocols:
l
l

Message[LRC]
Message[LRC]

E3 User's Guide, V 2.0—August 12, 2014

7 E3 Hardware Devices

7.2.1.1 E3 PIN Pad Requests
The following messages are sent to the PIN pad to request E3 encrypted card data via card swipe
and/or manual entry:
l

E1.[entry_flag][disp_flag][mask_flag] [min len][max len]
[prompt1][prompt2] [prossing_prompt][LRC]
E2.[timeout][LRC]

7.2.1.2 E3 PIN Pad Responses
The following messages are returned from the PIN pad with E3 encrypted card data via card swipe
or manual entry:
l

Card Swipe:
E3.[trk1][trk2][trk3][ktb][LRC]

Manual Entry:
E4.[result][luhn][obf][enc][ktb][LRC]

7.3 Ingenico iPP300 and iSC Touch Series PIN Pads
You must sign up for an account at the Ingenico Developer Portal and mention that you are working
with Heartland. Retail Base Application (RBA) Integration Kits, Software Development Kits (SDKs),
and integration documentation for these devices can be downloaded from their portal.
The E3 encryption settings are contained in a digitally signed SECURITY.PGZ files. Work with
Heartland to ensure that the appropriate file is loaded to your devices prior to certification testing or
production deployment.

E3 User's Guide, V 2.0—August 12, 2014

7 E3 Hardware Devices

7.4 Equinox L4000 and L5000 Series PIN Pads
You must sign up for an account at the Equinox Developer Portal and mention that you are working
with Heartland. Software Development Kits (SDKs) and integration documentation for these
devices can be downloaded from their portal.
The E3 encryption settings are contained in XML files which must be specified for all forms (screens)
from which card data is obtained, and the forms must be digitally signed. Equinox can provide a
development key to sign the forms for use on a development device, but for production devices the
forms will either need to be signed by Heartland, Equinox, or another entity that has the appropriate
signing tools. Work with Heartland to ensure that the appropriate forms have been signed and
loaded to your devices prior to certification testing or production deployment.

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.4
Linearized                      : Yes
Author                          : brice.jaggi
Create Date                     : 2014:09:23 15:42:15-05:00
Modify Date                     : 2014:09:23 15:42:39-05:00
Subject                         : 
Language                        : en-us
XMP Toolkit                     : Adobe XMP Core 5.2-c001 63.139439, 2010/09/27-13:37:26
Format                          : application/pdf
Creator                         : brice.jaggi
Description                     : 
Title                           : My Document
Metadata Date                   : 2014:09:23 15:42:39-05:00
Keywords                        : 
Producer                        : MadCap Flare V10
Document ID                     : uuid:2b333db3-fbca-4fd2-a630-3572d7295d7d
Instance ID                     : uuid:430e4cb1-6f70-4f69-827c-3f44c0a815da
Page Mode                       : UseOutlines
Page Count                      : 21

EXIF Metadata provided by EXIF.tools

My E3 Device Integrator's Guide

E3%20Device%20Integrator's%20guide

Navigation menu

Versions of this User Manual:

Views

Navigation