DIV350779 Rev 9 Telium Retail Base Application RBA Developers Guide

DIV350779-Rev-9-Telium-Retail-Base-Application-RBA-Developers-Guide

User Manual:

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

DownloadDIV350779-Rev-9-Telium-Retail-Base-Application-RBA-Developers-Guide
Open PDF In BrowserView PDF
DIV350779 Rev 9 Telium
Retail Base Application
(RBA) Developer's Guide
Telium Terminals (iPP320, iPP350,
iSC Touch 250, iSC350, iSC Touch
480, iCMP, iSMP Companion,
iSMP, iUN2xx, and iWL250
Terminals)

Ingenico Inc. - 3025 Windward Plaza, Suite 600 - Alpharetta, GA 30005 Tel:
(678) 456-1200 - Fax: (678) 456-1201 - www.ingenico.com

Telium Retail Base Application (RBA) Developer's Guide
Part Number DIV350779 Rev. 9
Released August, 2015
Copyright © 2015, Ingenico Corp. All rights reserved.
Customer Service Centers:
Ingenico Inc.
3025 Windward Plaza, Suite 600
Alpharetta, GA 30005
Tel: 678.456.1200
Fax: 678.456.1201
www.ingenico-us.com
Ingenico Canada Ltd.
79 Torbarrie Road, Toronto, Ontario
Canada M3L 1G5
Tel: 416.245.6700
Fax: 416.245.6701
www.ingenico-us.com
North American Customer Support
Tel: 888.900.8221
Fax: 905.795.9343
Email: customersfirst.us@ingenico.com
Customer Service Centers:
In the U.S.A.
3025 Windward Plaza, Suite 600
Alpharetta, GA 30005
Canada
6520 Gottardo Court
Mississauga, Ontario, L5T 2A2
No part of this publication may be copied, distributed, stored in a retrieval system, translated into any
human or computer language, transmitted, in any form or by any means, without the prior written consent
of Ingenico. Ingenico and the Ingenico logo are registered trademarks of Ingenico Corp. All other brand
names and trademarks appearing in this guide are the property of their respective holders.
Information in this document is subject to change without notice.
The information contained herein is considered an intellectual property of Ingenico and as such should be
treated as confidential information to be reviewed only by authorized employees covered under the
executed Mutual Non-Disclosure signed between our companies. Ingenico Corp © 2015. All rights
reserved.

Table of Contents
1_Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1_1 Terminals Covered in this Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1_2 About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1_3 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1_4 RBA Integration Kit Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1_4_1

Ingenico Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1_4_2

RBA Application Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

1_4_3

RBA-Related Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

1_5 RBA Content Locations on Terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1_6 Minimum Requirements for RBA Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1_7 Terminal Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1_7_1

Mock-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1_7_2

Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1_8 LCD Display Preservation for Telium Terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1_9 Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2_Terminal Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2_1 EFT Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2_1_1

Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2_1_2

Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2_1_3

Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2_2 Standard Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2_3 On-Demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2_4 Spin the BIN - BIN Lookup Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2_4_1

How to Enable BIN Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2_4_2

Internal BIN Range Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2_4_3

External BIN Range Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2_5 No or Cancel Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2_5_1

Amount Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2_5_2

Cash Back . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2_5_3

PIN Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2_5_4

Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2_5_5

Transaction Cancelled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2_5_6

Cancel after amount received . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2_5_7

Cancel no amount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2_6 Transaction End Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2_6_1

Configuring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2_6_2

Response Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2_7 Telium Terminal Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2_7_1

VID and PID Settings for HID and CDC Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2_7_2

Communication Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2_7_2_1

SSL/TLS for Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2_7_2_2

iCMP and iSMPc Bluetooth Pairing and Unpairing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2_7_2_3

Communications Supported per Terminal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3_Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3_1 Advertising Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3_2 Card Swipe Function Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3_2_1

Standard ISO Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3_2_2

Non-Standard Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3_2_3

Non-Payment Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3_2_4

On-Demand Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3_3 Scrolling (Digital) Receipt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3_3_1

Clearing Line Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3_3_2

Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3_4 Amount Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3_4_1

Configuring Amount Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3_5 Signature Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3_5_1

Configuring Signature Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3_5_1_1

Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3_5_1_2

On-Demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3_5_2

Retrieval Using Get Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3_5_3

Signature Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3_5_4

Disabling Electronic Signature on iSC Series Terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3_5_4_1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3_5_4_2

Configuring for Paper Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3_6 MSR Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3_6_1

Supported Encryption Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3_6_2

Encryption Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3_6_3

Enabling MSR Encryption in RBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3_6_4

EPS (Element Payment Systems) P2PE Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3_6_4_1

EPS P2PE Card Swipe Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

3_6_4_2

EPS P2PE Encryption Processing Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3_6_5

Generic TDES DUKPT Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

3_6_5_1

TDES DUKPT Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

3_6_5_2

Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3_6_6

Magtek Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3_6_6_1

Overview of Magtek Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3_6_6_2

Data to be Encrypted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

3_6_6_3

Configuring Mod-10 and Account Number Check Digit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

3_6_6_4

Configuring for Manual Entry – 23.x Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

3_6_7

Mercury Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

3_6_7_1

Configuration Parameters (in config.dfs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

3_6_7_2

Data to be Encrypted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

3_6_7_3

Encryption Does Not Occur If… . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3_6_7_4

Other Reasons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3_6_7_5

Encryption Data Returned to the POS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3_6_7_6

Initiating an Encrypted Swipe/Tap/Manual Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

3_6_7_7

Configuring for Manual Entry Using the 23.x Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

3_6_7_8

On-Demand Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

3_6_7_9

Card Swipe and Contactless Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

3_6_8

Monetra CardShield Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

3_6_8_1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

3_6_8_2

Data to be Encrypted if Track 3 is Available . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

3_6_8_3

Data to be Encrypted if Track 3 is Unavailable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

3_6_8_4

Manual Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

3_6_8_5

Encryption Does Not Occur If… . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

3_6_8_6

Encryption Data Returned to the POS – Tracks 1 & 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

3_6_8_7

Configuring for Manual Entry using the 23.x Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

3_6_8_8

Initiating an Encrypted Swipe/Tap/Manual Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

3_6_8_9

Monetra CardShield Encryption Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

3_6_9

On-Guard Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

3_6_9_1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

3_6_9_2

On-Guard Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

3_6_9_3

On-Guard Card Data Encryption Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

3_6_9_4

New RBA Messages for On-Guard and KME Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

3_6_9_5

Handling of Existing RBA Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

3_6_9_6

MSR Encryption Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

3_6_9_7

E2EE Card Data Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

3_6_10

RSA-OAEP and TransArmor Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

3_6_10_1

Configuration Parameters (in config.dfs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

3_6_10_2

Encryption Data Returned to the POS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

3_6_10_3

Manual Entry Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

3_6_11

S1 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

3_6_11_1

S1 Encryption Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

3_6_11_2

S1 Encryption Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

3_6_11_3

Configuration Parameters (in config.dfs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

3_6_11_4

S1 and MOD-10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

3_6_11_5

Load Whitelist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

3_6_11_6

Card Swipes During the Standard Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

3_6_11_7

Working with Sensitive Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

3_6_12

Voltage TEP1 and TEP2 Encryptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

3_6_12_1

Overview of Voltage TEP1 and TEP2 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

3_6_12_2

PAN Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

3_6_12_3

Obsolete Voltage Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

3_6_12_4

PAN Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

3_6_12_5

Voltage TEP1 and TEP2 Encryption Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

3_6_13

MSR Encryption Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

3_6_14

MSR Encryption Data Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

3_6_15

Retrieving MSR information using the 29.x (Get Variable) Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

3_6_16

Requesting the PIN Block Using the Masked PAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

3_6_17

Mod-10 Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

3_6_18

Loading Key Serial Number (KSN) Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

3_6_19

Selecting Specific Cards to be Encrypted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

3_6_20

Signing Requirements for .DAT File Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

3_7 Call Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
3_8 Contactless Key Card Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
3_8_1

Introduction to Contactless Key Card Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

3_8_2

RBA Low-Level Contactless Key Card Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

3_8_2_1

Contactless Key Card General Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

3_8_2_2

Setting Contactless Mode (60.x/28.x) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

3_8_2_3

Enabling Contactless and Requesting Card Tap (01.x/23.x) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

3_9 Google Wallet Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
3_9_1

Overview of Google Wallet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

3_9_2

Google Wallet Host Interface Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

3_9_3

General Payment Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

3_9_4

Supported Google Wallet Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

3_10 Softcard SmartTap Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
3_10_1

Overview of Softcard SmartTap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

3_10_2

Configuring the Terminal and Sending Softcard SmartTap Data to the POS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

3_10_3

Supported Contactless Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

3_10_4

Erroneous Card Tap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

3_11 Offline Remote Key Injection (RKI) Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
3_11_1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

3_11_2

Prerequisites/Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

3_11_3

Enabling/Disabling Remote Key Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

3_11_4

Offline RKI Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

3_11_5

Initiating Offline RKI through the TSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

3_11_6

Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

3_11_7

Functional Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

3_12 Dynamic Update of RSA-OAEP Public Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
3_12_1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

3_12_2

Procedure to Dynamically Update RSA OAEP Public Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

3_13 Support for Voice Referral for EMV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
3_13_1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

3_13_2

Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

3_13_3

Transaction Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

4_Host Interface Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
4_1 Communication Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
4_1_1

Link Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

4_1_2

Data Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

4_1_3

General Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

4_2 Communication Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
4_2_1

00.x: Offline Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

4_2_1_1

Overview of the 00.x Offline Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

4_2_1_2

00.x Offline Response Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

4_2_1_3

Message Responses in the Offline State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

4_2_2

0x and 50.x: Authorization Response Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

4_2_3

01.x: Online Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

4_2_4

03.x: Set Session Key Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

4_2_5

04.x: Set Payment Type Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

4_2_6

07.x: Unit Data Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

4_2_7

08.x: Health Stat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

4_2_8

09.x Card Status Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

4_2_9

09.x: Set Allowed Payments Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

4_2_10

10.x: Hard Reset Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

4_2_11

11.x: Status Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

4_2_11_1

Overview of the 11.x Status Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

4_2_11_2

Appending the Form Name to the 11.x Status Response Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

4_2_12

12.x: Account Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

4_2_13

13.x: Amount Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

4_2_14

14.x: Set Transaction Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

4_2_15

15.x: Soft Reset Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

4_2_16

16.x: Contactless Mode Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

4_2_16_1

Overview of the 16.x Contactless Mode Request Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

4_2_16_2

16.x Contactless Mode Request Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

4_2_16_3

Google Wallet Mode Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

4_2_16_4

Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

4_2_16_5

Google Wallet Data Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

4_2_17

17.x: Merchant Data Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

4_2_17_1

Overview of the 17.x Merchant Data Write Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

4_2_17_2

Contactless Key Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

4_2_17_3

Google Wallet Merchant ID/Secret Pair Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

4_2_17_4

Softcard SmartTap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

4_2_17_5

17.x Merchant Data Write Request Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

4_2_17_6

17.x Merchant Data Write Response Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

4_2_17_7

Executing Commands as a Batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

4_2_17_8

17.x Merchant Data Write Message Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

4_2_18

18.x: Non-Payment Card Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

4_2_19

19.x: BIN Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

4_2_20

20.x: Signature Message (On-Demand) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

4_2_20_1

Overview of the 20.x Signature Messages (On-Demand) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

4_2_20_2

20.x Signature Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

4_2_20_3

Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

4_2_20_4

A Note About Keys and Buttons Pressed During the Signature Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

4_2_20_5

Signature Ready Response Message (On-Demand) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

4_2_21

21.x: Numeric Input Request Message (On-Demand) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

4_2_21_1

Use of the 21.x Message to Send Encrypted Clear Entry Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

4_2_22

22.x: Application ID Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

4_2_23

23.x: Card Read Request (On-Demand) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

4_2_23_1

Overview of the 23.x Card Read Request Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

4_2_23_2

23.x Message Flow When Using iConnectEFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

4_2_23_3

New Flag for Coupon Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

4_2_23_4

MSC Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

4_2_23_5

Swiping an Invalid Card or Cancelling Manual Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

4_2_23_6

Execution of the 23.x Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

4_2_23_7

23.x Card Read Request (On-Demand) Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

4_2_23_8

Sample Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

4_2_24

24.x: Form Entry Request (On-Demand) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

4_2_24_1

Setting Prompt Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

4_2_24_2

Setting Button Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

4_2_24_3

Changing Button Visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

4_2_24_4

Setting the Form Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

4_2_24_5

Displaying the Offline Form on iSMPc Terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

4_2_24_6

Using Multiple Buttons with the 24.x Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

4_2_24_7

Displaying Text Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

4_2_24_8

Displaying numerals or symbol characters using the 24.x message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

4_2_25

25.x: Terms and Conditions Request (On-Demand) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

4_2_26

26.x: Run Script Request (On-Demand) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

4_2_27

27.x: Alpha Input Message (On-Demand) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

4_2_27_1
4_2_28

Use of the 27.x Message to Send Encrypted Clear Entry Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

28.x: Set Variable Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

4_2_28_1

Overview of the Set Variable Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

4_2_28_2

Changing Contactless Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

4_2_28_3

Configuring GMT Variables for PayPal Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

4_2_28_4

Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

4_2_28_5

28.x Set Variable Request and Response Message Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

4_2_29

29.x: Get Variable Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

4_2_29_1

Overview of the 29.x: Get Variable Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

4_2_29_2

29.x Get Variable Request and Response Message Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

4_2_30

30.x: Advertising Request Message (On-Demand) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

4_2_31

31.x: PIN Entry Messages (On-Demand) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

4_2_31_1

Overview of the 31.x PIN Entry Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

4_2_31_2

PIN Entry with Credit Selection Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

4_2_31_3

Account Number Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

4_2_32

34.x: Save and Restore State Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

4_2_33

36.x Notification of Command Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

4_2_33_1

Overview of the 36.x Notification of Command Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

4_2_33_2

36.x Notification of Command Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

4_2_33_3

Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

4_2_34

40.x: Survey Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

4_2_34_1

40.0 Survey Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

4_2_34_2

40.0 Survey Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

4_2_34_3

40.0 Survey Request Message Display Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

4_2_34_4

40.x: Survey Question Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

4_2_34_5

40.x: Survey Question Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

4_2_35

41.x Card Read Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

4_2_36

50.x: Authorization Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

4_2_37

51.x: Beep On-Demand Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

4_2_38

52.x: PayPal Preauthorization Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

4_2_39

58.x Terminal Discovery Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

4_2_39_1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

4_2_39_2

Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

4_2_39_3

Terminal Discovery Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

4_2_40

60.x: Configuration Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

4_2_41

61.x: Configuration Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

4_2_42

62.x: File Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

4_2_42_1

Overview of the 62.x File Write Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

4_2_42_2

Aborting the Previous File Download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

4_2_43

63.x: Find File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

4_2_43_1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

4_2_43_2

63.x Find File Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

4_2_44

64.x: Delete File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

4_2_45

70.x: Update Form Element Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

4_2_45_1

Setting Prompt Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

4_2_45_2

Setting Button Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

4_2_45_3

Changing Button Visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

4_2_45_4

Setting the Form Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

4_2_46

82.x On-Guard and KME Session Key Injection Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

4_2_47

83.x On-Guard and KME Enable Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

4_2_48

85.x On-Guard and KME Non-Payment Card Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

4_2_49

86.x On-Guard and KME BIN Lookup (PIN Encouragement) Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

4_2_50

87.x On-Guard and KME Card Read Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

4_2_51

88.x On-Guard and KME Translate Encrypted Card Data Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

4_2_52

89.x On-Guard and KME Register BIN Record Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

4_2_53

90.x: P2PE Data Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

4_2_53_1

Voltage Encryption – Generating a Key On Demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

4_2_53_2

Voltage – Getting Encryption Transmission Block (ETB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

4_2_53_3

RSA OAEP Encryption - Dynamically Updating RSA-OAEP Public Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

4_2_53_4

RSA OAEP Encryption - Deleting Public Keys from the Terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

4_2_53_5

RSA OAEP Encryption - Selecting Public Keys from the Terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310

4_2_54

91.x: Print Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

4_2_54_1

Overview of the 91.x Printer Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

4_2_54_2

91.x Printer Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

4_2_54_3

91.x: Barcode Printing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314

4_2_55

93.x: Terminal Authentication Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316

4_2_56

94.x and 95.x: Barcode Configuration Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

4_2_56_1

Barcode Configuration Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

4_2_56_2

Barcode Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

4_2_56_3

Barcode Message Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

4_2_56_4

Barcode Data Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

4_2_56_5

Barcode Encryption Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

4_2_56_6

Barcode Illumination Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

4_2_56_7

Barcode Image Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

4_2_56_8

Barcode Lighting Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

4_2_56_9

Barcode Power Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336

4_2_56_10

Barcode Reset Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

4_2_56_11

Barcode Scan Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341

4_2_56_12

Barcode Symbology Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

4_2_56_13

Barcode Trigger Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

4_2_57

97.x: Reboot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358

5_Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
5_1 Form Contents and Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
5_1_1

Advertising . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

5_1_2

Approved/Disapproved . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365

5_1_3

Card Swipe Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366

5_1_3_1

Card Swipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

5_1_3_2

Card Swipe On Demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

5_1_3_3

Card Swipe with Language Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372

5_1_3_4

Remove Inserted Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375

5_1_4

Cash Back Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375

5_1_4_1

Cash Back Other . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376

5_1_4_2

Cash Back Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

5_1_4_3

Cash Back Selection without No . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380

5_1_4_4

Cash Back Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382

5_1_5

Contactless Enabled Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383

5_1_5_1

Contactless Card Read Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384

5_1_5_2

Contactless Card Swipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387

5_1_5_3

Contactless Card Swipe with Language Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389

5_1_6

Initialization Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393

5_1_7

Input Entry Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394

5_1_7_1

Alphanumeric Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395

5_1_7_2

Input Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396

5_1_8

Language Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398

5_1_9

Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400

5_1_10

Offline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404

5_1_11

Payment Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

5_1_11_1

Amount Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406

5_1_11_2

Payment Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408

5_1_12

PayPal Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

5_1_12_1

Card Swipe with PayPal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412

5_1_12_2

Card Swipe with PayPal and Language Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413

5_1_12_3

Contactless Card Swipe with PayPal and Language Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416

5_1_12_4

Contactless Card Swipe with PayPal Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418

5_1_12_5

PayPal Data Input (On-Demand form) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419

5_1_12_6

PayPal PIN Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421

5_1_12_7

PayPal Please Wait . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422

5_1_13

PIN Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423

5_1_14

Enter PIN or Press Green for Credit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425

5_1_15

Signature Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427

5_1_15_1

Post-Sign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427

5_1_15_2

Pre-Sign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429

5_1_15_3

Signature (On-Demand) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431

5_1_16

Smart Card (SMC) and EMV Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434

5_1_16_1

Contactless Smart Card (EMV) and Swipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435

5_1_16_2

Contactless Smart Card (EMV) and Swipe with Language Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438

5_1_16_3

Smart Card (EMV) and Swipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441

5_1_16_4

Smart Card (EMV) and Swipe with Language Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445

5_1_17

Survey Swipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448

5_1_18

Terms and Conditions Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449

5_1_18_1

Terms and Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450

5_1_18_2

Terms and Conditions Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452

5_2 Using the Function Keys to Select Menu Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
5_3 Button IDs and Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
5_3_1

iCMP Button IDs and Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456

5_3_2

iPP320 Button IDs and Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458

5_3_3

iPP350 Button IDs and Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460

5_3_4

iSC250 Button IDs and Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463

5_3_5

iSC350 Button IDs and Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470

5_3_6

iSC480 Button IDs and Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477

5_3_7

iSMP and iSMPc Button IDs and Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

5_3_8

Mobile Terminal Battery Level Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486

5_3_9

Reserved Form Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487

5_4 Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
5_4_1

Line Breaks in Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489

5_4_2

Custom Prompts (CUSTPROMPT.xml) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490

5_4_3

Security Prompts (SECURPROMPT.xml) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490

5_4_3_1
5_4_4

Button Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498

Transaction Prompts (PROMPT.xml) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500

5_5 Terms and Conditions (TC1.xml) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
5_6 Form Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
5_6_1

Bluetooth Status Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524

5_6_1_1

Defining the Bluetooth Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524

5_6_1_2

Icons Displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524

5_6_2

RBA Form Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525

5_6_2_1

IP Address and Port Display Variable for TCP-IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527

5_7 Using the iSC480 Terminal Screen to Display Contactless Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
5_7_1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528

5_7_2

Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528

6_Drivers and Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
6_1 Ingenico iConnectEFT Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
6_2 Ingenico iConnectREST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
6_2_1

Overview of iConnectREST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530

6_2_2

Supported Payment Terminals and Connection Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531

6_3 RBA Testing Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532

7_Configuring the Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
7_1 DFS Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
7_1_1

Data Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533

7_1_2

Data Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534

7_1_3

File Name Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534

7_1_4

File Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535

7_2 DAT Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
7_2_1

Advertising Parameters (ads.dat) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535

7_2_1_1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535

7_2_1_2

Automatic Startup of Advertising . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536

7_2_1_3

On-Demand Startup of Advertising . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536

7_2_2

Barcode Parameters (barcode.dat) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540

7_2_3

BIN Lookup (stb.dat) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544

7_2_4

BIN Processing (allBins.dat, bin0.dat - bin20.dat) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545

7_2_4_1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559

7_2_4_2

Transaction Codes Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560

7_2_4_3

Card Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561

7_2_5

Card Configuration (cards.dat) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562

7_2_5_1

Use of the Verify Amount Flag During EMV Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563

7_2_5_2

Converting Binary to Hexadecimal for Card Sources Allowed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564

7_2_5_3

Card Configuration Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565

7_2_6

Cash Back Configuration (cashback.dat) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568

7_2_7

Changes to security.dat or secbin.dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571

7_2_8

Compatibility Flags (compat.dat) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571

7_2_9

Contactless Reader Configuration (cless.dat) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574

7_2_10

EMV Flags (emv.dat) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576

7_2_11

Form Files (forms.dat) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577

7_2_12

MAC Entry (mac.dat) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582

7_2_13

Main Flow (mainFlow.dat) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583

7_2_14

MSR Card Swipe Options (msr.dat) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592

7_2_15

PayPal Configuration (paypal.dat) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593

7_2_16

PIN Entry (pin.dat) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595

7_2_17

Security BIN (secbin.dat) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597

7_2_18

Security Parameters (security.dat) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599

7_2_19

Signature Items (sig.dat) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608

7_2_20

Status Messages (status.dat) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610

7_2_21

Store/Lane Information (store.dat) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612

7_2_22

User Defined Variables (var.dat) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614

7_3 Format Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
7_3_1

General Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615

7_3_2

Specific Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617

7_3_3

Using Multiple Format Specifier Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618

7_3_4

Unknown Format Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618

7_3_5

Examples of Format Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619

7_3_6

Clear-Text Key Press Input Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627

8_EMV Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
8_1 Introduction to EMV Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
8_2 EMV Transaction Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
8_2_1

Card Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632

8_2_2

Language Selection for EMV Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633

8_2_3

Application Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633

8_2_3_1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633

8_2_3_2

Application Selection Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634

8_2_3_3

Canadian Specific Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635

8_2_3_4

Available EMV Application IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635

8_2_3_5

Application Selection for '0019_0003' = '0' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638

8_2_3_6

Application Selection for '0019_0003' = '1' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639

8_2_3_7

Application Selection for '0019_0003' = '2' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640

8_2_3_8

Application Selection for '0019_0003' = '3' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641

8_2_4

Read Application Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641

8_2_5

Data Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642

8_2_6

Cardholder Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642

8_2_6_1

PIN Entry for EMV Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642

8_2_6_2

Signature Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643

8_2_6_3

EMV Reversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643

8_2_6_4

EMV Fallback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643

8_2_7

Terminal Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644

8_2_8

Terminal Action Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644

8_2_9

First Card Action Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644

8_2_10

Online Transaction Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644

8_2_11

Second Card Action Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644

8_2_12

Transaction Completed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644

8_3 EMV Host Interface Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
8_3_1

Overview of EMV Host Interface Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645

8_3_2

EMV '33.00.x' Transaction Initiation Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646

8_3_2_1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646

8_3_2_2

EMV '33.00.x' transaction Initiation Request Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647

8_3_2_3

EMV '33.00.x' Transaction Initiation Response Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649

8_3_3

EMV '33.01.x' Status Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651

8_3_3_1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651

8_3_3_2

EMV '33.01.x' Status Request Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651

8_3_3_3

EMV '33.01.x' Status Response Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654

8_3_4

EMV '33.02.x' Track 2 Equivalent Data Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662

8_3_5

EMV '33.03.x' Authorization Request Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665

8_3_6

EMV '33.04.x' Authorization Response Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668

8_3_6_1

EMV '33.04.x' Authorization Response Error Reply Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670

8_3_6_2

Authorization Response Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673

8_3_7

EMV '33.05.x' Authorization Confirmation Response Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673

8_3_8

EMV '33.07.x' Terminal Capabilities Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676

8_3_8_1

Overview of the Terminal Capabilities Request Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676

8_3_8_2

Overview of the EMV Terminal Capabilities Response Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676

8_3_8_3

EMV '33.07.x' Terminal Capabilities Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677

8_3_8_4

Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682

8_3_8_5

EMV '33.07.x' Terminal Capabilities Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683

8_3_9

EMV '33.08.x' Set Variables Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683

8_3_9_1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683

8_3_9_2

EMV '33.08.x' Set Variables Request Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684

8_3_9_3

EMV '33.08.x' Set Variables Response Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686

8_3_10

EMV '33.09.x' Set Tag Data Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688

8_3_10_1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688

8_3_10_2

EMV '33.09.x' Set Tag Data Request Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688

8_3_10_3

EMV '33.09.x' Set Tag Data Response Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691

8_3_10_4

EMV '33.09.x' Set Tag Data Message Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693

8_3_11

EMV '33.10.x' Get Tag Data Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693

8_3_11_1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693

8_3_11_2

EMV '33.10.x' Get Tag Data Request Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693

8_3_11_3

EMV '33.10.x' Get Tag Data Response Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696

8_3_11_4

'33.10.x' Set EMV Data Message Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698

8_3_12

Transaction Step List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698

8_3_13

EMV Tag Data Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700

8_3_14

EMV and Non-EMV Tags Transmitted in Host Interface Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702

8_4 EMV Transaction Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
8_4_1

EMV Purchase Transaction Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708

8_4_2

EMV Contactless Transaction Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710

8_4_3

EMV Full Refund Transaction Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712

8_4_4

EMV Partial Refund Normal Transaction Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714

8_4_5

EMV Partial Refund On-Demand Transaction Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716

8_4_6

MSD Contactless Transaction Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718

8_4_7

Non-EMV Tag Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719

8_5 EMV On-Demand Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
8_5_1

Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724

8_5_2

Initiate On-Demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724

8_5_3

Initiate EMV Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725

8_6 EMV with P2PE Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
8_6_1

EMV Tags Used with P2PE Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725

8_6_2

Encryption of PAN-Related Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725

8_6_3

EMV Tag Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726

8_6_3_1

EMV Tag Handling During Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726

8_7 EMV Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728
8_7_1

Notes on EMV Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728

8_7_1_1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728

8_7_1_2

Merchant and Acquirer Responsibilities and Parameter Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728

8_7_1_3

Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728

8_7_1_4

Important . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729

8_7_1_5

Data element format conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729

8_7_2

Application ID (AID) Parameters in EMVCONTACT.XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 730

8_7_3

Application ID (AID) Parameters in EMVCLESS.XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732

8_7_4

Certificate Authority Public Keys in EMVCONTACT.XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740

8_7_5

EMV.DAT Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741

8_7_6

ICS Tags in EMVCONTACT.XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743

8_7_7

ICS Tags in EMVCLESS.XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750

8_8 MAC Messages (Canada Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
8_8_1

80.x MAC Calculation Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753

8_8_2

81.x MAC Verification Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756

8_9 Configuring the EMV Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
8_10 EMV Configuration and Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
8_10_1

Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758

8_10_2

Initiate Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758

8_10_3

Process Online PIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759

8_10_4

PIN Block Tag Format in Authorization Request Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759

8_11 EMV Full and Partial Refunds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
8_11_1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759

8_11_2

Important Tags Used in Refund Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760

8_11_3

Cancelling a Refund Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760

8_12 EMV Cashback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
8_12_1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761

8_12_2

Cashback/Total Amount Confirmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762

8_12_3

Sample Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763

8_12_4

Terminal and ECR Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763

9_Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
9_1 Appendix A. Differences Between U32 RBA and Telium RBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
9_1_1

A.1. At A Glance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764

9_1_2

A.2. Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765

9_1_2_1

Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765

9_1_2_2

Terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765

9_1_2_3

POS Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766

9_1_3

A.3. Signing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766

9_1_4

A.4. Transaction Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766

9_1_5

A.5. Host Interface Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767

9_1_6

A.6. Variable Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770

9_1_7

A.7. Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770

9_1_8

A.8. Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770

9_1_9

A.9. RBA Configuration (config.dfs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771

9_1_9_1

General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771

9_1_9_2

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771

9_1_10

A.10. Format Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777

9_2 Appendix B. 3-Byte ASCII Signature Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
9_2_1

B.1. Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778

9_2_2

B.2. Coordinate Data Reconstruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778

9_2_3

B.3. Format for Signature Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779

9_2_4

B.4. Pen-Up Control Character . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780

9_2_5

B.5. Segment Start Control Character . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780

9_2_6

B.6. Coordinate Character Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780

9_2_6_1

Coordinate Data Character 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780

9_2_6_2

Coordinate Data Character 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780

9_2_6_3

Coordinate Data Character 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780

9_2_7

B.7. Unused Control Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780

9_3 Appendix C. RBA Script Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781
9_3_1

What is a Script? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781

9_3_2

Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781

9_3_3

Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781

9_3_4

Tag Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781

9_3_5

Button Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781

9_3_6

Form Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782

9_3_7

Text Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782

9_3_8

Sample Script with Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783

9_4 Appendix D. PayPal Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784
9_4_1

D.1. Minimum Production Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785

9_4_2

D.2. PayPal Validation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785

9_4_3

D.3. Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787

9_4_3_1

PayPal.dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787

9_4_3_2

Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787

9_4_4

D.4. Calculating GMT Offset (Variable 205) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789

9_4_4_1

Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789

9_4_4_2

Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789

9_5 Appendix E. RBA Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789
9_5_1

E.1. Working With RBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789

9_5_1_1

Host Interface Messaging Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789

9_5_1_2

Retrieving EPS Encrypted Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 790

9_5_2

E.2. Customizing RBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791

9_5_2_1

Editing a Prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791

9_5_2_2

Adding a Custom Prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792

9_5_2_3

Editing a Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792

9_5_2_4

Adding a Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792

9_5_2_5

Editing Config.dfs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792

9_5_3

E.3. Packaging a New RBA Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793

9_6 Appendix F. External Display for Telium Terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793
9_7 Appendix G: eWIC Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794
9_7_1

G.1. eWIC Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794

9_7_1_1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794

9_7_1_2

Card Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795

9_7_1_3

Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795

9_7_1_4

Primary Types of WIC Smart Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795

9_7_2

G.2. eWIC WMP Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796

9_7_2_1

WMP Message Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796

9_7_2_2

WMP Request/Response Message Pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796

9_7_2_3

WIC Transaction and RBA Exclusivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797

9_7_2_4

N on-WIC Exemptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797

9_7_2_5

WMP Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798

9_7_2_6

_99 eWIC Reset Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802

9_7_3

G.3. eWIC Transaction Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803

9_7_3_1

Messages in WIC Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803

9_7_3_2

POS-Terminal Server/Client System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803

9_7_3_3

eWIC Sample Message Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805

9_7_3_4

Balance Transaction Flow Breakdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807

9_7_3_5

Debit Transaction Flow Breakdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810

9_7_3_6

Transactions Canceled at PIN Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818

9_7_3_7

Cancelled WIC PIN Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821

9_7_4

WIC Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823

9_8 Appendix H: Creating a .TGZ File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827

10_Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829

This document covers the operation of the Telium Retail Base Application (RBA) is organized into the following sections:
1. Introduction - Document organization, terminals covered in this manual, supported applications, capabilities, operation

requirements, definitions, and terminal profiles.
2. Terminal Process Flow - Communication between the terminal and Point-of-Sale, transaction flow overview, and communications

settings for all types of MSR transactions.
3. Functions - Card swipe functions, digital receipt, transaction amount function, and signature. The following functions are also

covered in this section:
a. MSR Encryption- All current methods of encryption and how they are used in MSR transactions.
b. Google Wallet Implementation- Payment flow and wallet modes for Google Wallet.
c. Softcard SmartTap Implementation- Setup, configuration, and modes for Softcard SmartTap.
d. Contactless Key Card Support- Supported card types, flow, setting mode, enabling and requesting card tap.
e. Offline Remote Key Injection (RKI) Support- Requirements and limitations, toggling and initiating RKI, process, and logs.
f. Dynamic Update of RSA-OAEP Public Keys- Overview and procedure for dynamically updating RSA-OAEP encryption

keys.
g. Support for Voice Referral for EMV- Overview, function, and example transaction.
4. Host Interface Messages- In-depth information on communications protocol, descriptions and breakdowns of all messages

exchanged between the terminal and host during transactions, as well as a list of iConnectEFT Constants.
5. Forms - Screen displays, button images, and cardholder prompts during the transaction process. This section also includes a

description of the forms used to generate the screen images.
6. Drivers and Tools - iConnectEFT Constants, iConnectREST, and RBA Testing Tool.
7. Configuring the Application - Retail Based Application prompts and parameters that may be changed to customize the application

for various Ingenico Telium terminals.
8. EMV Implementation - This section provides detailed information on how Ingenico payment terminals process EMV transactions.
9. Appendices
a. Appendix A. Differences Between U32 RBA and Telium RBA- Support, requirements, flows, names of host interface

messages and variables, forms and prompts, configuration, and format specifiers.
b. Appendix B. 3-Byte ASCII Signature Format- Specifications, Coordinate Data Reconstruction, Format for Signature Data,

Signature Characters and Coordinate Character Data Sets, Unused Control Codes
c. Appendix C. RBA Script Language- Definition, Comments and Tags, Sample Script, and Parameters for Forms, Text, Tags,

and Buttons.
d. Appendix D. PayPal Overview- Requirements, Validation Flow, Configuration, and how to calculate offset from Greenwich

Mean Time (GMT).
e. Appendix E. RBA Best Practices- Best practices for working with RBA, customizing RBA, and packaging a new RBA load.
f. Appendix F. External Display for Telium Terminals- Compatibility, requirements, and instructions for connecting an external

display.
g. Appendix G: eWIC Implementation- Overview of the WIC program, WMP Message usage and breakdowns, transaction

flows, and a list of error codes.
h. Appendix H: Creating a .TGZ File- Proper procedure for generating a .TGZ file for downloading to a terminal.
10. Revision History

19/854 Telium RBA Developer's Guide/ August 18, 2015

1_Introduction
The Retail Base Application is recommended for customers who desire a “plug-and-play” application for their IBM 4680/4690 system, or
any other POS system, that conforms to standard IBMEFT protocol. All additions to the standard IBMEFT protocol are covered in this
manual. However, to take advantage of the iSC250/iSC350/iSC480 signature capture features, some additional code must be added to the
register application (see Retrieval Using Get Variable).
The Telium terminal operate on a direct-connect basis to a point-of-sale (POS) device, or to any RS-232, USB, Ethernet, or tailgate-based
host device.

1_1 Terminals Covered in this Manual
Terminals covered in this manual include the following:
iCMP (also referred to as iCM122)
iSMP (also referred to as iMP350)
iSMPc (also referred to as iMP352)
iPP320
iPP350
iSC250 and iSC Touch 250
iSC350
iSC Touch 480
iUN2xx (includes iUP250 and iUR250 and/or iUC150)
iWL250

The product name is the Terminal ID (this only displays when using the 07.x: Unit Data Request and 08.x: Health Stat
messages.

All references to the iSC250 throughout this document are relevant to the iSC250 and iSC Touch 250 unless otherwise stated.
All references to the iSC480 pertain to the iSC Touch 480.

The iSC Touch 250 requires SDK 9.18.0 or later. The iSC Touch 250 hardware is PCI PTS version 4.x certified.

20/854 Telium RBA Developer's Guide/ August 18, 2015

The following image gallery provides a pictorial overview of the terminals covered in this manual.

Image Gallery of Terminals Covered in this Manual

21/854 Telium RBA Developer's Guide/ August 18, 2015

The application supports:
Credit
Debit
Electronic Benefits Transfer (EBT)
Electronic Signature Capture (iSC250/iSC350/iSC480 only)
Item Scrolling
Customer Graphics Display
Advertising
Personal Messaging
Surveys
Loyalty Programs
Internal/External BIN Range Checking
Contactless Card Reader (optional hardware module)
Cross Selling
Instant Credit
Electronic Couponing
Time and Attendance
Hospitality
Electronic ACH
Frequent Shopper
Transaction Data Encryption

1_2 About This Manual
This manual provides a full overview of the Retail Base Application, including an explanation of all the tools that may be used to change
parameter-driven facets of the application.
This manual also addresses various customer requirements and describes a global approach to using the communication messages
described in Host Interface Messages, as well as the needs of customers with different point of sale (POS) environments. The following
environments can integrate to RBA:
NCR Register / DOS environment
IBM 4680/4690 Register environment
IBM 4694 Register / Windows NT environment
Windows XP, 7, or 8 operating system
Mac OS 10.6 (Snow Leopard) or later operating system
For additional information pertaining to the operation of your Telium terminal, refer to the corresponding user’s guide (DIV350774
iSC350 Operation and Product Support Guide or DIV350784 iPP300 User’s Guide) which explains how to download the software
package which includes the binary data, parameters, and Telium operating system.

22/854 Telium RBA Developer's Guide/ August 18, 2015

1_3 Definitions
Term

Definition

DFS

Data File System

ECR

Electronic Cash Register.

EFT

Electronic Funds Transfer

Financial
Transaction

Refers to processes executed between two hard reset commands: 10.x or equivalent of the hard reset message.

Form File

Refers to an HTML-format file (*.K3Z) used to position and format text, buttons and images used for standard screens on
Ingenico’s Telium terminals.

Host
Interface

A communications interface that connects the terminal to the POS equipment, which connects to the host computer (also
called an in-store system, POS or Point of Sale system, or register).

MSR

Magnetic stripe reader.

OS

Operating system.

Spin the
BIN

IBM-specific terminology for the BIN lookup process (also known as PIN Encouragement).

Terminal

See definition for Telium Terminals.

POS

Point-of-sale system or device. Sometimes referred to as an Electronic Cash Register (ECR).

Prompt File

File referenced by form building utility to load button text and prompts.

RBA

Retail Base Application.

TDA

Telium Download Application.

23/854 Telium RBA Developer's Guide/ August 18, 2015

Term

Definition

Telium
Terminals

For the purposes of this document, refers to the Ingenico:
iCM122
iMP350
iMP352
iPP320
iPP350
iSC250
iSC Touch 250
iSC350
iSC Touch 480
iUN2xx (includes iUP250, iUR250 and iUC150)
iWL250.

1_4 RBA Integration Kit Contents
The integration kit contains:
Ingenico documentation
The RBA financial application
Telium utilities
Bluetooth Pass-through Service
RBA Testing Tool
Telium LLT
Telium Tools
Form Builder
Script Builder
Data Packaging Tool
SAT

1_4_1 Ingenico Documentation
Ingenico’s RBA Integration Kit contains the following types of documentation:
DIV350779 Telium RBA User’s Guide (this document)

24/854 Telium RBA Developer's Guide/ August 18, 2015

User’s guides for supported Telium terminals:
iPP2xx
iPP3xx
iSC250
iSC350
iSC480
iUP250
iWL250
Documentation for Ingenico Telium utilities provided with the kit:
LLT
Bluetooth Pass-Through Service
Form Builder
Script Builder
Data Packaging Tool

1_4_2 RBA Application Package

25/854 Telium RBA Developer's Guide/ August 18, 2015

The RBA Application Package Structure
The RBA Application folder included with the Integration Kit includes the following items:
app folder – contains the RBA application’s binary files.
comm folder – contains data files and TDA.XML files to set terminals to use specific communication types.
config folder – contains the following:
*.DAT files
config.dfs parameter file
ctr, ctr_config, and ctr_trans files
Terminal-specific media folders – contain images and RBA application form (*.K3Z) files.
Terminal-specific multimedia folders – contain audio and video resources.
prompts folder – contains RBA application prompts:
prompt.xml – non-secure application prompts.
custprompt.xml – non-secure user-defined prompts for application customization.
tc1.xml – Terms and Conditions verbiage for use in tc.k3z.
securprompt.xml – secure application prompts.
signed contents folder – contains signed RBA content.
Terminal-specific files for each supported Ingenico terminal:
Package definition *.XML file – also known as the manifest. This file specifies all the information needed to package
*._GZ files that will be used to load RBA content onto the corresponding terminal:
Package name
Files to package
Each file’s path within the original RBA application package folder structure
Each file’s intended location on the terminal (optional)
PackageGZ batch file – generates *._GZ files for loading RBA to the corresponding terminal using the information
specified in that terminal’s manifest file.
PackageLLT batch file – initiates LLT download of the GZ file.
PackageEFT batch file – generates the EFT file with the Packaging Toll using the terminal’s manifest file.
An example of an RBA manifest file (iSC350Package.XML) is shown below:












26/854 Telium RBA Developer's Guide/ August 18, 2015
























































27/854 Telium RBA Developer's Guide/ August 18, 2015



















































28/854 Telium RBA Developer's Guide/ August 18, 2015

1_4_3 RBA-Related Utilities
Ingenico’s RBA Integration Kit contains the following RBA-related Telium utilities:
RBA Testing Tool
Telium LLT
Bluetooth Pass-Through Service
Form Builder
Script Builder
Data Packaging Tool
SAT

1_5 RBA Content Locations on Terminal
When RBA is installed on an Ingenico terminal, each type of application file is moved to a specific path in the terminal’s memory. The
table below shows the path that each RBA application file is installed to:
Files and their Parent Directories
File Name

Location on Terminal Memory

Images

/HOST

SECURPROMPT.XML

/F_SECURITY_APP

PROMPT.XML

/HOST

CUSTPROMPT.XML

/F_SECURITY_APP

CTG graphics

/F_SECURITY_APP/CTG

TC1.XML

/HOST

*.DAT files

/HOST

*.K3Z files

/HOST

BOOT.HTM

/F_SECURITY_APP

Templates

/F_SECURITY_APP

TRACE.XML

/F_SECURITY_APP

29/854 Telium RBA Developer's Guide/ August 18, 2015

1_6 Minimum Requirements for RBA Customization
To modify RBA configuration settings, you need the following:
Text file editor that does not insert hidden characters (for viewing and editing config.dfs and prompts files)
Windows PC equipped with one of the following types of connections:
RS-232
USB_HID (supported for all terminals except the iCM122, iMP350, iMP352 and iWL250)
Network connection to local area network with Internet gateway
Tailgate
Image editing software capable of handling .bmp, .gif, .jpg, or .png formats
Microsoft .NET Framework (required to run the RBA Testing Tool)

1_7 Terminal Profiles
1_7_1 Mock-up
Mock-up terminals are used for lab testing only. The mock-up message flashes on the screen every 30 seconds.

1_7_2 Production
Production terminals are used in the live environment.

1_8 LCD Display Preservation for Telium Terminals
Ingenico Telium terminals utilize backlit LCD displays to convey transaction and advertizing information. As with any LCD display,
preventative actions are recommended in order to minimize the occurrence of image persistence. Image persistence occurs when an image
is displayed for extended periods, leaving a temporary impression of the image on the screen which may be partially visible when the
screen changes to a new image. This can be minimized by taking the following preventative actions:
Do not allow a still image to be displayed for more than four hours.
Use a screensaver with black or medium-gray background when the terminal has been inactive for 10 minutes.
Power down the terminal for a period of time when not in use.

1_9 Signing
All applications, data files, images, videos, and form files must be signed by Ingenico before they can be used in a production terminal,
with the exception of unpackaged files sent to HOST (refer to the 62.x: File Write for more information).

30/854 Telium RBA Developer's Guide/ August 18, 2015

2_Terminal Process Flow
The RBA has a pre-designed flow of standard processes, ready to use for the majority of financial transactions (see Standard Process Flow
for more information). The order of this flow can be customized as follows:
To alter the flow for all financial transactions, use the configuration parameters (see Configuring the Application for more
information).
To alter the data flow for a single transaction only, use the “on-demand” messages. When an on-demand message is received, RBA
stops the execution of the current process and executes the new process. After the new process is finished, the RBA returns to the
interrupted process or goes to the transaction start.
The order of execution is altered when you change certain configuration parameters in the config.dfs file, or when a POS issues an ondemand message. Since each card type (e.g., debit, credit, etc.) requires specific processes, the standard flow can be individually
configured for each card type.

2_1 EFT Overview
This chapter defines the communication protocol between a POS and the Telium terminal. It also discusses the functional requirements
placed on the store controller, user host, or third party switch as a result of this protocol.
There is a payment type known as electronic funds transfer (EFT). EFT provides the customer with an electronic means of paying for
goods or services received. This method requires that the customer has a debit card (a plastic card with an encoded magnetic stripe) issued
by a financial institution and a personal identification number (PIN) associated with the card and accounts.
In a point of sale (POS) environment, the merchant provides an EFT terminal that the customer uses to make payment for his purchases.
This terminal contains:
A magnetic stripe reader (MSR) for reading the information encoded on the debit card
A PIN keypad for entering the personal identification number (in some environments, it is required that the PIN keypad is usable
for numeric entry of other data such as dollar amount of transaction)
A display for showing prompts or other information to the customer during the transaction
In a typical transaction, the cashier totals up the transaction then asks the customer how they want to pay. If the customer uses EFT as
payment, the processing flow is as follows:
1. The cashier activates the EFT terminal.
2. The customer uses the EFT terminal to complete payment.
3. The terminal prompts the user through the process: swipe debit card, select account to be debited, enter PIN number, and authorize

amount due.
4. The RBA then formats an authorization message with the information just received and forwards the message to the POS system.
5. The POS system in turn forwards that message to the proper financial institution for approval or disapproval.
6. The POS system receives the approval or disapproval message from the financial institution and forwards it back to the RBA.
7. If approved, the POS system accepts the amount as payment.

31/854 Telium RBA Developer's Guide/ August 18, 2015

2_1_1 Assumptions
The following is an assumed typical configuration for our industry:

Assumed Points of Communication

2_1_2 Environment
The EFT environment is one of interactions between the customer, the merchant, and a financial institution. The simplest configuration is
a terminal attached to the POS system, with the POS system attached via communications line to a single financial institution. Many of our
merchants are already doing tender approval at their host location (e.g., credit, check authorization). It would therefore be a logical
extension if their POS system used that same physical communication connection to route the EFT authorization request and response to
the user host and have the user host “switch” to the proper financial institution. This also gives merchants the capability to maintain a
certain level of control over the EFT process if these messages pass through their own host.
Since there may be several financial institutions involved with a single merchant, the merchant may choose to use a third party “switch” to
manage EFT processing. These third party switches provide the capability to have only one line from the merchant to the switch. The
switch exchanges the required authorization request and response message with the proper financial institutions on behalf of the merchant.
The communication protocol, message formats and operational procedures for each of these financial institutions and third party services
are currently different. For this reason the following assumptions are made concerning the EFT environment for the POS system:
Base store controller communication support allows the merchant the capability to participate in any of the configurations
discussed above with some amount of user programming.
The controller implements VISA Second Generation message formats.
The controller assumes it is talking to a “switch,” either third party or user host. This implies the controller communicates with
only one message protocol and one message format (VISA II) for EFT.

2_1_3 Dependencies
For the EFT messages to work properly, the dependencies below must be met.
The switch must:
Limit messages to a maximum length of 247 bytes, including the STX, ETX, and LRC control characters (most third-party
switches are capable of this).
Handle the VISA II parameter table loads to the terminal.
The POS must allow the POS operator to enter the account number and card expiration date on the POS keyboard if the terminal cannot
read the card data, and send this data from the POS to the terminal.
The terminal must:
Determine if a PIN is required, allow PIN keying, encrypt the PIN, and build the proper VISA messages for communication.
Provide the capability to build a VISA authorization request message without receiving or showing an amount on the terminal.
Provide the capability to show the amount due received from the POS and allow the customer to validate that amount or to enter
and validate a different amount. Build the VISA authorization request message with the validated amount.

32/854 Telium RBA Developer's Guide/ August 18, 2015

The terminal remains at “Slide Card” until it reads data from a card swipe or receives the account number and card expiration date
as entered from the POS, if the card cannot be read. It then collects the remaining required data at the terminal and builds the
proper VISA authorization request message.
Provide the capability for the POS to reject the amount in the authorization request message and have the terminal validate the new
amount with the customer. The POS must then accept a new authorization request message containing the new amount.

2_2 Standard Process Flow
The RBA standard processes are executed in a specific order. A typical process order, also called a flow or process flow, may be as
follows:
Select language Swipe card Select payment Enter PIN Enter cash back Verify purchase amount Authorization Approve
Transaction End Advertising.
Swipe card Select payment Verify purchase amount Signature Authorization Approve Transaction End Advertising
The following flow chart shows the high-level host process flow from the customer’s perspective for Ingenico’s Retail Base Application:

33/854 Telium RBA Developer's Guide/ August 18, 2015

34/854 Telium RBA Developer's Guide/ August 18, 2015

RBA Standard Process Flow

2_3 On-Demand
On-Demand messages can be used to deviate from the standard transaction flow, and create your own dynamic application. These
messages can be initiated from the offline screen, except 31.x when card data is still required.
20.x: Signature Message (On-Demand)
21.x: Numeric Input Request Message (On-Demand)
23.x: Card Read Request (On-Demand)
24.x: Form Entry Request (On-Demand)
25.x: Terms and Conditions Request (On-Demand)
26.x: Run Script Request (On-Demand)
27.x: Alpha Input Message (On-Demand)
30.x: Advertising Request Message (On-Demand)
31.x: PIN Entry Messages (On-Demand)
On-demand messages cannot be nested. When the above messages are received during the execution of another on-demand message, they
are not executed. RBA sends a response message with a reject status and the execution of the current on-demand message continues.
Exceptions to this behavior are:
The 30.x message
When the Automatic On-Demand Function Cancel parameter in Main Flow (mainFlow.dat) '0007_0028' is set to '1'
When the current on-demand message is 20.x and mainFlow.dat '0009_0006' (Save State on Signature Request) is set to '0'
Offline On-Demand Transaction Recommendations
When performing an offline on-demand transaction, there are a few recommended deviations from standard transaction procedure.
The 00.x: Offline Message should be used for resetting an on-demand card read instead of the typical 15.6 Soft Reset Message.
A '15.8' message can dynamically reset any offline line display.
The 00.x message returns the terminal to the OFFLINE.K3Z offline form. For on-demand transactions, the offline form is recommended
to be modified as either:
A default screen in-between offline and on-demand transactions (potentially including a customer's company logo, messages, etc.)
or
An acceptable interstital screen before issuing the next 24.x or 30.x messages, or resuming any offline ads, if configured to do so.
See also Communication Messages for additional information.

2_4 Spin the BIN - BIN Lookup Process
The RBA has a few ways to automatically establish the payment type based on the cardholder account number. The account number may
be retrieved from the terminal’s local magnetic stripe reader or contactless reader, or it can be received from the POS in a message.
The account number is associated with a card type, such as debit, credit, or gift. For example, an account number which starts with
6011xxxxx may be a Discover card, while a 4000xxxx account may be a Visa card.

35/854 Telium RBA Developer's Guide/ August 18, 2015

The RBA uses the following methods to establish the payment type:
Internal Spin the BIN (STB). The payment is established by the RBA from data included in the RBA local configuration.
External STB. The payment information is received from the POS.
Each method can operate individually or with other methods. Each method has its own set of parameters listed in the config.dfs file.
When payment is selected, the RBA performs a final check to see if the Transaction Code for the selected payment is valid.
If Transaction Code > 0, continue with the transaction.
If Transaction Code = 0, RBA displays the Invalid Card Type prompt, resets the payment, resets the payment, and then goes back
to the card swipe screen.
This method is enabled or disabled by the configuration parameter listed in allBins.dat file, index '0099_0001', Enable BIN range checking
(0 = off, 1 = on).
The default config.dfs file contains seven files, bin0.dat through bin6.dat. Each file contains a description of a specific card type,
such as MasterCard, which applies to that card only. Each binX.dat file contains:
The first few digits of the account.
Minimum and maximum number of digits in the account number.
List of transaction codes used with selected payment. The transaction code is part of the authorization message sent out to the POS.

2_4_1 How to Enable BIN Checking
RBA has the ability to automatically establish a payment type for the customer card. This can be done by using values from the RBA local
configuration (internal Spin the BIN - STB), or by asking the POS to select the payment type (external STB).
If BIN range checking is enabled, the RBA compares the cardholder account with data from all binX.dat files. If there is no match, the
RBA checks if Spin the BIN (STB) is enabled.
If enabled, the application goes to STB.
If it is not enabled, the RBA displays the payment screen with the payment buttons, and prompts the cardholder to select the
payment type.
The BIN range checking configuration options common to all binX.dat files are listed in BIN Processing allBins section in config.dfs,
which are:
'0099_0001', Enable BIN range checking ('0' = off, '1' = on)
'0099_0002', Number of BIN ranges (up to '20')
'0099_0003', BIN length is x digits. It selects how many digits of the cardholder account number are compared with numbers from
bin0.dat to binX.dat files. Only the account's first digits are used for comparison.
See BIN Lookup (stb.dat) for more information on configuring BIN processing settings.

2_4_2 Internal BIN Range Checking
Internal STB means that the payment selection is based on the local RBA configuration data only. This function searches the bin0.dat to
binX.dat files to find the payment. The payment type is included in the string listed at index '010x_0005'.

2_4_3 External BIN Range Checking
When the external STB is allowed to execute, the RBA sends out a request message to the POS and waits for the POS response with the
payment type. The RBA uses the received payment type to continue the transaction or prompt the cardholder to select the payment.

36/854 Telium RBA Developer's Guide/ August 18, 2015

See 19.x: BIN Lookup for more information.

2_5 No or Cancel Process
The following sections describe how the RBA handles a CANCEL key press in various processes. Refer to the following diagram which
illustrates the RBA's standard cancellation process.

37/854 Telium RBA Developer's Guide/ August 18, 2015

RBA’s Standard No or Cancellation Process

38/854 Telium RBA Developer's Guide/ August 18, 2015

2_5_1 Amount Verification
When the NO key is pressed during the verify amount state, the RBA always sends out the 10.x: Hard Reset Message, clears the amount,
and waits for the purchase amount state.
When the CANCEL key is pressed during the verify purchase amount state, the RBA sends out the 10.x message. The RBA goes back to
the transaction start and the transaction is cleared along with the language selection.

2_5_2 Cash Back
The cash back process displays the following screens:
cashb.K3Z: for iSC250/iSC350, screen with Fast Cash Back keys ($20, $40…) and OTHER; for iPP350, screen with Cash Back
YES, NO buttons
NO key press: skips the cash back selection and goes to the next RBA process
CANCEL key press: If '0007_0004' = '0', return to swipe.K3Z, otherwise return to lswipe.K3Z
cashbo.K3Z: Screen to enter specific cash back value.
CANCEL key press: Return to cashb.K3Z
cashbv.K3Z: Cash Back verification screen with YES, NO, CANCEL buttons
CANCEL key press:
If '0002_0012' = '0', return to cashbo.K3Z
If '0002_0012' = '1', return to cashb.K3Z
If '0002_0012' = '2':
If '0007_0004' = '1', return to lswipe.K3Z
Otherwise return to swipe.K3Z
If '0002_0012' = '3', return to pay1.K3Z
NO key press: Return to cashb.K3Z

2_5_3 PIN Entry
When the CANCEL key is pressed during PIN entry, the RBA responds in one of the following ways:
If the payment type was selected automatically or forced by the host in a message ( 04.x: Set Payment Type Request message), the
RBA clears the payment selection, goes back to the payment selection screen, and lets the cardholder make a new payment
selection.
If the payment type was selected by the cardholder pressing a display key, RBA checks if the purchase amount is present in the
terminal.
If the purchase amount is present, the RBA sends out a 10.x message, clears the transaction along with the language
selection, and goes to the transaction start.
If no purchase amount was received, the RBA clears the transaction along with the language selection, and goes to the
transaction start.

39/854 Telium RBA Developer's Guide/ August 18, 2015

2_5_4 Signature
The CANCEL button on the Signature forms for the iSC250, iSC350 and iSC480 terminals is now functional prior to signing (presignature) only. Once signing is initiated (post-signature), the following occurs:
The CANCEL button is removed from the screen.
The CANCEL key on the keypad is processed as a CLEAR.
For the on-demand signature request there is no pre-signature or post-signature state, and the "Cancel" button will always be displayed and
processed as a "CANCEL" action.

2_5_5 Transaction Cancelled
If the CANCEL key is pressed and the transaction conditions are such that the transaction is terminated, the Transaction Cancelled
message may be displayed. The presence of the message is controlled by the configuration switch in the Main Flow section in the config.
dfs file, index '0013_0004' (Show prompt “Transaction Cancelled” 0 = disabled, 1 - 255 = duration in 1/10th of a second).
If the CANCEL key is pressed during the Language Selection, Card Swipe, or Payment Selection process, the RBA will execute the
following processes:
If the purchase amount is present, the RBA sends out a 10.x message, clears the transaction, returns the language selection to the
default value, and goes to the transaction start.
If no purchase amount was received, the RBA clears the transaction, returns the language selection to the default value, and goes to
the transaction start.

2_5_6 Cancel after amount received
Sends 10.x message. Returns to swipe.K3Z or lswipe.K3Z depending on settings.

2_5_7 Cancel no amount
Returns to swipe.K3Z or lswipe.K3Z depending on settings.

2_6 Transaction End Process
The financial transaction ends in following situations:
As a normal part of the RBA flow.
On the POS’s request when one of the following messages is received by the RBA:
10.x - hard reset message is received
15.x - soft reset message is received (some variations only)
01.x - online message is received
50.x or 00.x – authorization response message

40/854 Telium RBA Developer's Guide/ August 18, 2015

When RBA detects a special condition, which may be:
The cardholder pressed the CANCEL key. After that, if the amount is received, the RBA sends out a 10.x message.
Some of the configuration parameters are not present in the terminal, without these, RBA cannot operate normally.
At the end of the signature on-demand execution.
In this process, the RBA takes action according to the received message type, key press, or error condition. Possible actions are:
Clear cardholder data, and start a new transaction.
Start advertising.
Exit the RBA transaction and go to the offline state.
When the financial transaction is cleared, the RBA makes the following changes.
All data collected from cardholder: all account values, payment selection, amounts, language, and signature is deleted.
It increments the transaction counter, which is used by the 50.x authorization message.
It clears timers, buffers, and pointers - used internally to manage the transaction.
It clears the digital receipt based on two options:
10.x message parameter value.
RBA configuration switch, listed in mainFlow.dat file, index '0007_0007' (Clear line item display on reset):
0 = Do not clear.
1 = Clear (display receipt).
At the Transaction End, the cardholder may be informed about the result of the transaction through a text prompt. The text presence is
controlled by the configuration parameter found in the Main
Flow section in config.dfs, Display Approved/Disapproved Message, index '0007_0022': (0 = Do not display, 1 - 65,000 = Duration
of display in 1/10th of a second and only in effect if advertising is on). The prompt displays for five seconds. Next RBA may do one of the
following based on configuration selections:
Start advertisements.
Wait for a transaction reset message, such as the 10.x message.
Automatically reset the transaction and go to the transaction start.
Here are examples of the transaction result texts. They change according to the executed processes:
“Approved” (or equivalent translation) - from file PROMPT.xml, prompt ID 21
“Declined” (or equivalent translation) - from file PROMPT.xml, prompt ID 22
“Invalid PIN. Please Re-enter.” (or equivalent translation) - from the “RBA PIN Prompts” section of the SECURPROMPT.xml
file, prompt ID 15
“Signature Accepted”(or equivalent translation) - from file PROMPT.xml, prompt ID 92
“Input Accepted” (or equivalent translation) - from file PROMPTS.xml, prompt ID 93
“Transaction Cancelled” (or equivalent translation) - from file PROMPT.xml, prompt ID 23.
The display of this prompt is controlled by index '0031_0023' from the Main Flow section in the config.dfs file. It is used when the
CANCEL button is pressed and the RBA resets the transaction.

41/854 Telium RBA Developer's Guide/ August 18, 2015

2_6_1 Configuring
The RBA local configuration provides the ability to control which forms display at the end of the transaction end process:
Once the transaction ends, RBA displays the Host Response for the amount of time specified by the configuration option listed in
mainFlow.dat file, index '0007_0022', Display Approved/Disapproved Message Timer:
0 = Do not display.
1 = Display until a reset is received
2 - 255 = Time in 1/10th of second.
After the Host Response message has timed out, RBA displays advertising based on the configuration option listed in mainFlow.
dat file, index '0007_0023', After Display Approved/Disapproved Message Timeout:
0 = Reset.
1 = Go to advertising
2 = Wait for reset.
It is important to note that there are certain restrictions associated with the advertising display parameter:
Setting '0007_0023' = '1' requires that '0010_0001' be set to either '1' or '3'.
Setting '0007_0023' = '2' requires that '0007_0022' be set to '1'.

2_6_2 Response Messages
RBA response messages use one of the following prompts:
“Accept” (or equivalent translation) - from file PROMPT.xml, prompt ID 120
“Decline” (or equivalent translation) - from file PROMPT.xml, prompt ID 121
“Invalid PIN. Please re-enter” (or equivalent translation) - from the “RBA PIN Prompts” section of the SECURPROMPT.xml file,
prompt ID 15
See Prompts for more information.

2_7 Telium Terminal Information
The VID and PID settings required for USB communications with Ingenico Telium terminals have been compiled into a table which
addresses both CDC and HID modes. In order to establish USB communications with an Ingenico terminal, a POS terminal must be
configured to reference the terminal using the correct VID and PID settings. Refer to the table on the VID and PID Settings for HID and
CDC Communications page for the required settings. Also refer to the Communication Settings page for more information on Telium
terminal communication settings.

2_7_1 VID and PID Settings for HID and CDC Communications
Since Ingenico terminals include a USB interface, they are assigned a USB device classification. Classifications for Ingenico Telium
terminals include:
USB CDC - Communications Device Class
USB HID - Human Interface Device

42/854 Telium RBA Developer's Guide/ August 18, 2015

USB interface products are also identified using a Vendor ID (VID) and Product ID (PID). The following table specifies the CDC and HID
Vendor IDs and Product IDs for Ingenico Telium terminals.
CDC and HID Vendor IDs and Product IDs for Ingenico Telium Terminals
Terminal

String

Screen

Colors

MP4

Touch

Flash

Audio

CDC
VID

CDC
PID

HID
VID

HID
PID

iPP320

Ingenico
iPP320

128x64

Black
/white

No

No

128m

Buzzer

0x0B00

0x0059

0x0B00

0x0071

iPP350

Ingenico
iPP350

320x240

4k

No

No

128m

Buzzer

0x0B00

0x0060

0x0B00

0x0072

iSC250

Ingenico
iSC250

480x272

240k

Yes

Yes

128m

Yes

0x0B00

0x0062

0x0B00

0x0074

iSC350

Ingenico
iSC350

640x480

240k

Yes

Yes

128m

Yes

0x0B00

0x0061

0x0B00

0x0073

iSC480

Ingenico
iSC480

800x480

262k

Yes

Yes

128m

Yes

0x0B00

0x0061

0x0B00

0x0073

iUP250

Ingenico
iUP250

128x64

Black
/white

No

No

128m

Buzzer

0x0B00

0x0057

0x0B00

0x0076

iWL250

Ingenico
iWL250

320x240

240k

No

No

128m

Buzzer

0x0B00

0x0064

NS

NS

2_7_2 Communication Settings
Refer to the Telium Download User's and Developer's Guide for more information on setting up the communication type for your terminal.
Possible communication types include:
RS-232 (19200, 8, N, 1)
RS-232 (115200, 8, N, 1)
USB HID (all terminals except the iUP250 and iWL250)
USB<>SerialConv
MagicBox (iSC250, iSC480, iPP320 and iPP350 only)
Ethernet (DHCP)
Ethernet (Static)
Tailgate
For information on Bluetooth settings, refer to the Bluetooth Settings section of theTelium Download User's and Developer's Guide.
Included in this section is information on the following:
Associating the iWL250 Terminal with Bluetooth Cradle/Base

43/854 Telium RBA Developer's Guide/ August 18, 2015

Bluetooth Pairing for the iWL250 and iSMP Companion
Installing the Bluetooth Pass-Through Service Utility
Also refer to the Configuring Device Communication Settings section of the Telium Download User's and Developer's Guide for
information on the Jungo Driver.

Customers can also request other types of RS-232 settings from their Ingenico account representative if needed.

2_7_2_1 SSL/TLS for Ethernet
SSL (Secure Sockets Layer) handshake and encryption using the more updated, client-authenticated TLS (Transport Layer Security)
handshake, also known as mutual authentication, may be used with Telium RBA.
In the Telium RBA implementation, RBA acts as the SSL server, and the client application acts as the SSL client. Because the
authentication is mutual, both parties (server and client) are required to send its certificate to the opposite side. Therefore, during
installation, both sides should install the root certificate from the other party. During the handshake, both the client and the serve will use
the root certificate to validate the certificate presented by the opposite side.
The list of certificate and key requirements for implementing SSL/TLS follows the Figure "Telium RBA's SSL Connection," shown
below.

Info
Although the iUP250 terminal is illustrated in the Figure, below, SSL applies to any Telium terminal.

Telium RBA's SSL Connection

44/854 Telium RBA Developer's Guide/ August 18, 2015

SSL Implementation Requirements
A set of requirements is outlined in the following table, including certificates, private keys, and a configuration on the PC or tablet hosting
the Bluetooth Pass-Through Service Utility.
SSL Implementation Requirements

45/854 Telium RBA Developer's Guide/ August 18, 2015

Requirement

Environment

Purpose

Description

Customer’s
Root CA
Certificate

Ingenico Terminal

To validate the
certificate
presented by the
client during
handshake.

Usually only one copy of this certificate is used by all terminals.This
certificate should be presented by the customer during the installation and
installed on all terminals requiring SSL. Because it is used for validating
the client POS is the actual POS.

To present to the
client during the
handshake.

This certificate is generated by Ingenico as a Certificate Signing Request
(CSR) and is sent to the customer for signing.

To encrypt the
PreMasterSecret
during the
handshake.

This private key is part of the Server Certificate and should also be stored
in the PKCS12 container.

To validate the
certificate
presented by the
Ingenico terminal.

This is the root CA Certificate used by the customer when signing the
Server Certificate described above.

Client’s
Certificate

To present to the
server during the
handshake.

Each client POS should have a unique copy of this certificate.

Client’s
Private Key

To encrypt the
PreMasterSecret
during the
handshake.

Each client POS should have a unique private key that matches the Client’s
Certificate.

To turn on/off
SSL.

Refer to "Installing the Bluetooth Pass-Through Service Utility" section in
the Telium Download User's and Developer's Guide.

To select the SSL
protocol version.

TLS version 1.1 or 1.2 must be selected. RBA is no longer supporting
SSLv3. Refer to security.dat parameter '0091_0034' for setting the TLS
version.

Server
Certificate

Server
Certificate
Private Key

Customer’s
Root CA
Certificate

Turn on SSL

Set SSL
Protocol
Version
Identifier

Client POS

PC on which the
Bluetooth PassThrough Service
Utility was
installed

This CA certificate should be sent to Ingenico by the customer and
packaged together with the Server Certificate (see below) and Server
Certificate Private Key (see below) into a PKCS12 (PFX) container.

The resulting CRT (Certificate in PEM format) is packaged by Ingenico
into a PKCS12 container.

The POS should have this certificate to validate the Server Certificate
during the handshake.

This setting is checked when a customer has enabled SSL on the terminal
and the correct server.pgz file has been uploaded.

46/854 Telium RBA Developer's Guide/ August 18, 2015

Info
For a review of SSL sequence events that occur during a handshake, see also Wikipedia’s page on Transport Layer Security.

2_7_2_2 iCMP and iSMPc Bluetooth Pairing and Unpairing
iOS Bluetooth Pairing
This pairing mode is to only be used with iOS devices. If the iCMP or iSMPc was previously paired with a “Standard” (non-iOS)
Bluetooth device, the terminal will automatically reboot to allow it to pair to an iOS device.
1. Ensure the terminal is powered on and that the iOS device has Bluetooth connectivity enabled.
2. The terminal should be at the “Bluetooth Pairing Required” screen (shown below). If not, the terminal must be unpaired (see

Bluetooth Unpairing).

3. To begin the pairing process select the “iOS” key (F1) on the iCMP or iSMPc.
a. Some iSMPc terminals are configured to only support one type of Bluetooth pairing. In this case, the iOS and Standard

options that are pictured above will be replaced with a single option that reads “Begin”.

47/854 Telium RBA Developer's Guide/ August 18, 2015

4. The terminal will automatically display all Bluetooth enabled iOS devices in the immediate area:

a. Use the [F2] and [F3] keys to scroll up and down, respectively, through each displayed Bluetooth device.
b. Use the [F1] and [F4] keys to page up and page down, respectively.

48/854 Telium RBA Developer's Guide/ August 18, 2015

5. Highlight the Bluetooth device the user intends to pair with and press the [Green] key:

6. The terminal will display an eight digit randomly generated pairing PIN:

7. The host device will prompt for a pairing PIN. The user should enter the generated PIN into the prompt and select “Pair” on the iOS

device.
8. The iOS device will display the logical name of the iCMP or iSMPc and show the status of the pairing process.
a. Due to the validation and exchange of secure credentials, the iOS device may cycle through “Connected” and “Not

Connected” statuses.

Standard Bluetooth Pairing
This pairing mode is to only be used standard Bluetooth devices.
1. Ensure the iCMP or iSMPc is powered on and that the Standard Bluetooth device has Bluetooth connectivity enabled.

49/854 Telium RBA Developer's Guide/ August 18, 2015

2. The terminal should be at the “Bluetooth Pairing Required” screen (shown again below), if the terminal is not at that screen then the

terminal must be unpaired (see section Bluetooth Unpairing).

3. To begin the pairing process select the “Standard” key (F2) on the iCMP or iSMPc.
a. Some iSMPc’s are configured to only support one type of Bluetooth pairing. If this is the case then the iOS and Standard

options that are pictured to the right will be replaced with a single option that reads “Begin”.
4. The terminal will go into discovery mode and display an eight digit randomly generated pairing PIN with the iCMP or iSMPc’s

unique Bluetooth name:

5. On the standard Bluetooth device, search for the terminal’s logical Bluetooth name that is on the screen of the terminal and select it

to pair.
6. When the standard Bluetooth device prompts for a PIN, enter the PIN that is displayed on the terminal screen.

Bluetooth Unpairing
To unpair the iCMP or iSMPc from the host or tablet simply press the ‘Function’ key four (4) times in under two (2) seconds:

50/854 Telium RBA Developer's Guide/ August 18, 2015

The terminal will beep and then go to the BT Pairing Required screen.

Troubleshooting

Unpairing via scanning a barcode has been depreciated and unpairing via the above section is preferred.

If the Barcode Scanner will not power on for unpairing process:
1. Ensure that the terminal has been forgotten on the host device.
2. Turn the Bluetooth connectivity off on the host device.
3. Reboot the terminal.

51/854 Telium RBA Developer's Guide/ August 18, 2015

4. Once the terminal has finished booting, the barcode scanner will be enabled so that the user can finish the unpairing process.

If the terminal continuously prompts the host device and the user to enter a Bluetooth PIN and the unpairing process has been completed
then the user should follow the steps below.
1. Ensure that the terminal has been forgotten on the host device.
2. Turn the host device Bluetooth connectivity off.
3. Reboot the terminal as illustrated above.
4. Once the terminal has finished booting, turn the host device Bluetooth connectivity back on, ceasing Bluetooth PIN prompting.

2_7_2_3 Communications Supported per Terminal Model
The below table shows the interfaces supported by each device, as they appear in their respective menus:
Supported Communication Types by Device
Device(s)
iPP320, iPP350, iSC250, iSC480

Supported Communication Types
"Serial"
"Ethernet"
"USB-HID"
"USB<>Serial Conv"
"Tailgate"
"MagicBox Serial"

iSC350

"Serial"
"Ethernet"
"USB-HID"
"USB<>Serial Conv"
"Tailgate"

iUP250

"Serial"
"Ethernet"
"USB<>Serial Conv"

iWL250, iMP350, iMP352, iCM122

"USB<>Serial Conv"
"Bluetooth"

From either the "Communication" or "Select Comm. Type" menu, pressing the CLEAR button three times will change the menus to also
include interfaces not supported by the device.

52/854 Telium RBA Developer's Guide/ August 18, 2015

3_Functions

3_1 Advertising Support
RBA supports server-based advertising on Telium terminals. Please contact your Ingenico Representative for additional information.

3_2 Card Swipe Function Details
The RBA can process standard Visa card swipes and non-standard card swipes. Also, the RBA is capable of screening out account
numbers that do not meet a few basic criteria. This capability, called BIN range checking, checks the length of the account number. An
account number with incorrect length is not accepted, and the terminal displays the “Your card is invalid” prompt and returns to the wait
for a new card swipe screen. BIN range checking is performed after the RBA collects the account number and after the payment selection.

3_2_1 Standard ISO Cards
When the cardholder is prompted to swipe a card, the magnetic stripe reader or contactless card reader may be successful in reading the
data or it may have errors.
If the card swipe is error-free, the RBA saves the card information and progresses to the next process in the current flow.
If the card read is unssuccessful:
The terminal displays an error prompt for three seconds, for example, “Card read error. Try again”.
The terminal returns to the initial card swipe screen.
If a consecutive number of bad card swipes reaches the limit specified by parameter '0003_0001' in the Terminal Local
MSR Card Swipe Options (msr.dat) section in the RBA configuration file config.dfs, the prompt changes to “Please
hand card to cashier,” displayed for three seconds.
After that, the RBA checks parameter '0003_0002' in the same section of config.dfs, which tells the duration (in tenths
of a second) that the“Ask for Assistance” prompt should display. If the value is 0, the prompt is not displayed.
Next, RBA initializes the bad card swipe counter to the starting value and goes to the initial card swipe screen. If the new
card swipe is faulty and prompts from the previous bad card swipe have not yet expired, the new card swipe is ignored. This
process filters out card swipes that are too quick, too slow, or too shaky.

3_2_2 Non-Standard Cards
Non-standard cards are acceptable in both the on-demand card swipe request and the RBA flow.
Here is the difference between standard cards and non-standard cards.
Standard cards have the expiration date in the MSR Track 2, and the account number must be followed by the equal sign, which is
followed by the 4-digit expiration date. The format of the date is YYMM, where YY means the 2-digit year and MM means the 2digit month.
Non-standard cards do not have the expiration date in the MSR Track 2, and they do not have an equal sign (=) after the account
number.

53/854 Telium RBA Developer's Guide/ August 18, 2015

The account data may be received from the 12.x: Account Message, MSR card swipe, or contactless reader card tap. The rules for these
sources are as follows:
If the account number is received in the 12.x message, the account is always treated as the payment account. Data from this
message is loaded into buffers used to store track data from the local card swipe. Only Track 2 buffers are used. Track 1 remains
empty.
If the message contains the account number only, with no '=' character or expiration date present (non-standard card), the
Track 2 expiration date is set to '0000'.
If the message contains the ‘=’ character followed by the expiration date (standard card), that date is loaded into the Track 2
buffer.
If the account number is received from the local MSR or contactless reader card swipe, both tracks are checked for an expiration
date. If none is found, the date is set to NONE.
If the expiration date is NONE and the card is a payment type, such as debit or EBT, the RBA displays the payment selection
followed by the “Invalid card” prompt, and goes back to the transaction start.
Swiping a non-standard card can sometimes cause a a card read error or a reboot. With parameter '0003_0018' enabled, the RBA will
append Track 2 data instead of account number for some non-standard MSR cards in both 23.x and 50.x messages. The POS handles entry
of the CVV and expiration date.

3_2_3 Non-Payment Cards
A non-payment card refers to a loyalty card, rewards card, points card, advantage card, or club card type. If the expiration date is NONE
and the card is a non-payment type, the RBA sends out the 18.x: Non-Payment Card Message to the host and returns to the transaction
start. The following figure shows an example non-payment card selected as described in the Cards section of the config.dfs file.

Non-Payment Cards in cards.dat
Note the second parameter circled in the above figure. This is the Card Type parameter which indicates the following:
0 = Payment card.
1 = Non-Payment card.

3_2_4 On-Demand Requirements
The 23.x: Card Read Request On-Demand from the POS starts the Card Swipe process. Prompt text displayed on the screen is from the 23.
x message. During the execution of this process, only a single card swipe is allowed.
If the card swipe is good, the terminal displays the “Card Accepted” prompt for three seconds, sends out 23.x response with the
card data, and returns to the interrupted process.
If the card swipe is bad, the terminal displays the “Card Read Cancelled” prompt for three seconds, sends out response with no data
status, and returns to the interrupted process.
If the 23.x message does not include prompt text, it will not be executed, and an error status response is returned to the host.
If RBA is executing a 23.x message, any new 23.x message will not be executed, and response with error status is returned to the host.
CANCEL button terminates the process.
Additional information about this message is also available in the On-Demand section.

54/854 Telium RBA Developer's Guide/ August 18, 2015

3_3 Scrolling (Digital) Receipt

3_3_1 Clearing Line Items
The digital receipt is also called a scroll item or line item.
The upper part of the terminal screen is used for displaying a digital version of the cardholder paper receipt. Digital Receipt is available on
all screens which have the upper part of the screen reserved for it.
The Digital Receipt can show the last four purchased items. Terminals with a larger screen can display more items. The number of
displayed lines is activated by the size of the scrolling receipt element in the form file.
Text for the digital receipt is received via the 28.x: Set Variable Request message. The receipt text is saved in the terminal’s buffers and
used until the end of the transaction. At the Transaction End, all buffers are cleared.
Clearing line items can be achieved in one of the following ways:
Clear a single line item via the 28.x message with the text part set to spaces (0x20).
Clear all digital receipt lines using only the '15.8' soft reset message from POS.
Clear the whole transaction message.

3_3_2 Compression
The Line Items are displayed on the terminal screen in a dedicated area. The off-the-shelf RBA takes advantage of the whole screen width.
The Scrolling Receipt element size can be tailored to fit the background image size, if specified in the form file. The function compresses
the line item text to the Scrolling Receipt element size.
Text compression works as follows:
If the Line Item text received from the host in a message is greater than 40 characters, it is truncated to 40 characters; otherwise it
is saved in the RBA internal buffer.
When it is time to display the text, it is compressed to fit the scroll window width. The width is selected in the form files.
The form element, Scrolling Receipt, defines the height and width of the scroll window size (SWS), and where the line item text is
displayed. Here are the compression rules:
If the text is longer than SWS and has no '$' char, the text is truncated at the window’s width.
If the text is longer than SWS and has a '$' char, part of the text in front of '$' character is removed and '$' together with following
chars are shifted forward, example:
TestLineLengthBabcdefghijkABCDE$FGHIJKLM" - line before compression
TestLineLengthBabcdef$FGHIJKLM" - line after compression
If the text is shorter than the SWS width, it is displayed as is.
The compression does not provide ‘$’ character alignment.

3_4 Amount Function
Purchase Amount + Cash Back Amount = Total Amount

55/854 Telium RBA Developer's Guide/ August 18, 2015

The purchase amount may also be referred to as the amount or total. The purchase amount may be received in the following messages:
13.x message, (single or multiple amount field)
04.x message, forced payment with amount (single amount field)
28.x message, set amount (single amount field)
When a 13.x message with multiple amount fields is used, the host variable ID_TOTAL is not available until the payment is selected. The
Amount Index can be configured in cards.dat. See Amount Index in Card Configuration (cards.dat).
When the amount value is received in 13.x, 04.x, or 28.x message (all of which use a single amount field), the host variable ID_TOTAL is
immediately updated.
When the cash back value is selected by the cardholder, its value is added to the purchase amount.

3_4_1 Configuring Amount Function
The RBA local configuration provides the ability to verify the total amount. When verification is enabled, the cardholder can be prompted
to verify if the total amount is correct (the total amount includes the purchase amount and cash back amount, if applicable). The selection
of the purchase verification function is controlled by a configuration option listed in cards.dat file, individually per card type, called Verify
Amount (see Card Configuration (cards.dat) for more information). When prompted to verify the purchase amount, the cardholder can
press the YES, NO, or CANCEL button.
If the cardholder presses YES, the RBA flow goes to the next function.
If the cardholder presses NO, the RBA does the following:
sends out a 10.x reset message if the purchase amount is present
checks the configuration option listed in mainFlow.dat file, index '0007_0006' (On Total Amount Incorrect, Return To...),
and goes to that state.
If the cardholder presses CANCEL, the RBA sends out a 10.x reset message, and goes back to the transaction start.
See Amount Verification for more information on the Amount Verification process or 13.x: Amount Message for more
information on amount index setup.

3_5 Signature Retrieval
The signature process is controlled by the RBA configuration switches listed in the Signature section in config.dfs.
Only the stylus attached to the terminal may be used to write the signature on the terminal screen. The signature process starts with the first
touch of the screen with the stylus.
When writing of the signature is finished, it can be accepted when the OK button is pressed, or when the pen is not used for a specified
time. In the latter case, the terminal automatically accepts the signature after a time specified in config.dfs, index '0009_0013'. When
accepted, the terminal displays the text “Signature Accepted” below the signature box.
In order to clear the signature from the screen, the customer can press the CLEAR button, or the cashier can send the '15.4' reset signature
message. The CLEAR button can be used many times.
The screen signature must be translated from analog form to digital. The average signature is translated into 700 bytes of digital data.
When the POS retrieves that data from the terminal, the signature’s digital data is divided into signature blocks. The configuration switch
in sig.dat file, index '0009_0012', controls data length per block. The default value is set to 200 bytes (this is also the maximum
number).
The number of bytes per signature block can be defined in the local configuration file sig.dat, but cannot be changed or read by 28.x or
29.x.

56/854 Telium RBA Developer's Guide/ August 18, 2015

3_5_1 Configuring Signature Retrieval
3_5_1_1 Standard
Signature capture is a standard feature for the iSC250, iSC350, and iSC480 terminals. When using the off-the-shelf RBA, the RBA
functions are programmed to execute in a specific order. The signature function is part of it. When the execution of the signature is
finished, the RBA goes to the next function. The signature position in the RBA data flow has one adjustment in file config.dfs,
'0009_0006' index, called Save State on Signature Capture.
When Save State on Signature Capture = 0, terminate the transaction before prompting for a signature.
When Save State on Signature Capture = 1, save the current state, prompt for a signature, and then return to the saved state.
The signature screen can be aborted by messages 00.x, 01.x, 10.x, '15.0', '15.1', '15.6', and 30.x.

3_5_1_2 On-Demand
The signature may be started by the RBA standard process or by the POS 20.x message. When the signature is accepted, the screen shows
the signature until the start of the digital version of the signature is uploaded to the host, or it is immediately cleared from the screen. That
is controlled by the configuration parameter in sig.dat file, index '0009_0008', Display Signature Until Download Starts (0 = disable, 1 =
enable). The '29.xxxxx7yy' message is used for uploading the signature to the host. The next process after signature is the Transaction End
process.
If the signature is accepted, the RBA can send out to the POS an unsolicited the 20.x message to inform it that the signature data is ready
to be retrieved. Sending out the 20.x message is controlled by the configuration switch in sig.dat file, index '0009_0002'. When this
switch is set to 1, it will send out the 20.x message, 0 = no message.
The signature on-demand starts when the terminal receives the 20.x message from the POS. Before the message is executed, the RBA
checks the following conditions.
If the terminal is not in the signature process, the current process is terminated, and the new signature request is executed. After
signature is finished, RBA goes to the Transaction End.
If the terminal is in the signature state, invoked by the RBA or by a previous on-demand 20.x message, the current signature is
terminated, and the new message is executed.
If the 20.x prompt field is greater than 0, the prompt text is displayed on the signature screen below the signature box.
If the 20.x prompt field equals 0, the RBA config prompt is used instead. When the signature is accepted, the RBA goes to
the Transaction End.
When another on-demand message is received during the execution of 20.x (e.g., 21.x or 23.x), that message is not executed, and a
reject response is sent out, if available. The current process is continued.
When signature on-demand is successfully finished, the RBA displays “Signature accepted” for three seconds and then goes to
Transaction End. After that, based on the RBA configuration selection, it may wait for the host-reset message, go to
advertisements, or start a new transaction.
The signature process can be aborted by messages 00.x, 01.x, 10.x, '15.0', '15.1', '15.5', '15.6', and 30.x.

3_5_2 Retrieval Using Get Variable
The 29.x Get Variable message is the standard method of signature retrieval from the iSC250/iSC350/iSC480. The POS can send the 29.x
request at any time, but signature data is only available after one of the following conditions:
The customer has pressed "OK" on the signature capture page to indicate signature termination.
The terminal times out after the Pen Up time has expired.

57/854 Telium RBA Developer's Guide/ August 18, 2015

For the iSC350, this state is known only when reported by an 11.x Status Response sent from the POS. Once a signature available response
is sent from the iSC250/iSC350/iSC480 terminal to the POS, the POS requests the number of 200-byte blocks the signature data fills. If
this number is non-zero, the POS will begin requesting the signature blocks (one at a time), up to the number of blocks needed to rebuild
the signature.
Signature Request and Response Using the Get Variable Message
Sequence

Message

Begin Authorization Sequence.

50.x Authorization Request.

End Authorization Sequence.

50.x Authorization Response.

Begin Signature Sequence.

11.x Status Request.

Approved.
11.10 Status Response

Terminal displays signature form.
Customer inputs signature and presses OK.
11.x Status Request

End Signature Sequence.

11.11 Status Response (Signature
Available)

Begin Signature Transmittal Sequence.

29.10000712

Get Variable message determines the number of blocks the
signature data covers.
x = the number of signature blocks that contain data, up to 10.
The POS is expected to request x number of signature blocks
in order to recreate the entire signature. There is no value
when no data is available.

27.20000712x

For example, x = '4' if there are four signature blocks, and
those signature blocks are defined as RBA variables 700
through 703. Thus, the last signature block is 70(x-1).
Request first signature block, 700.

58/854 Telium RBA Developer's Guide/ August 18, 2015

29.10000 700

POS

Terminal

Sequence

Message

Return first signature block, 700.

29.20000 700 {data}

Request second signature block, 701.

29.10000 701

Return second signature block, 701.

29.20000 701 {data}

29.x messages continue until the final message in the signature
block...

...

Request last signature block, 70 (x-1) .

29.10000 70(x-1)

Return last signature block, 70 (x-1) .

29.20000 70(x-1) {data}

End Signature Transmittal Sequence.

Reset message

Shutdown Sequence.

Offline

POS

Terminal

Omitted in the diagram above, each message flowing either direction prompts an ACK response from the receiving unit.

3_5_3 Signature Format
The iSC250, iSC350, and iSC480 terminals support the SIG_BIN_2 (3-byte ASCII) Signature Format.
See 3-Byte ASCII Signature Format for more information.

3_5_4 Disabling Electronic Signature on iSC Series Terminals
3_5_4_1 Overview
Some Ingenico merchants prefer a paper signature over the standard electronic signature following transaction approval. A new
configuration has been added which enables electronic signature to be bypassed and a paper signature to be recorded in its place. This
applies to both standard and on-demand flow. Other customers will not be affected by this change and can continue using electronic
signature.

59/854 Telium RBA Developer's Guide/ August 18, 2015

3_5_4_2 Configuring for Paper Signature
To collect a paper signature only, electronic signature must be disabled. Because a signature is still being recorded for the approved
transaction, CVM must be enabled and Signature must be specified. Accordingly, the "No CVM Required" flag must be set to '0' and the
"Signature" flag must be set to '1' in tag T9F33 as illustrated in the below figure. Refer to the EMV '33.07.x' Terminal Capabilities Message
for information on setting the card verification method using the terminal capabilities message.

Setting EMV Tag T9F33 Byte 2 Contents for Signature Required
With CVM enabled, the Signature Required tag D1002 must be set to '0' (no electronic signature required) and included in the EMV '33.03.
x' Authorization Request and EMV '33.05.x' Authorization Confirmation Response messages sent to the POS. With electronic signature
bypassed, the POS should then request cardholder signature on the paper receipt. Anytime signature is specified in the CVM, it is up to the
POS to read the setting of tag D1002 and determine if electronic signature was captured or if a paper signature is required.

3_6 MSR Encryption

3_6_1 Supported Encryption Methods
The following table shows the encryption methods which are supported by the RBA Application:
Encryption Methods' Support Status

60/854 Telium RBA Developer's Guide/ August 18, 2015

Encryption Method

Support Status

'0091_0001' Enable Encryption Value
(“n”)

Magtek MagneSafe™ POS

Will not be supported by Telium (see Note below).

1

On-Guard

2

EPS

3

Voltage TEP1

Voltage TEP2

Voltage TEP3

(Cannot be used with TailGate)

(Cannot be used with TailGate)
Not yet supported.

Monetra CardShield

4

5

6
7

Mercury Payment Systems
(MPS)

Will not be supported by Telium (see Note below).

8

RSA-OAEP

Supported using KP4 key only (see Note below).

9

TransArmor

Supported using KP4 key only (see Note below).

10

TDES DUKPT Generic

11

S1

12

EPS P2PE

Note
Non-KP4 key encryption will no longer be supported by Telium. As such, encryption methods which use only non-KP4 keys
will no longer be supported. Encryption methods which use both KP4 keys and non-KP4 keys will, however, continue to be
supported by Telium provided that only KP4 keys are used.

61/854 Telium RBA Developer's Guide/ August 18, 2015

Encryption or masking of cards with PANs containing less than 9 digits is not supported (minimum 12 for Voltage encryption
types). Merchants should either whitelist these cards or disable non-standard card encryption.

3_6_2 Encryption Requirements
With certain encryption types set, the RBA will encrypt only if certain conditions are met. The table below explains the minimum
requirements for each encryption type supported and used by the RBA:
Encryption Requirements by Encryption Type
Encryption
Method
EPS P2PE

Minimum Requirements

Track 1 or Track 2 must be read successfully.
PAN must include at least 9 characters.

Magtek

Track 1 or Track 2 must be read successfully.

Requirements Document

EPS (Element Payment Systems)
P2PE Encryption

Magtek Encryption

PAN must include at least 9 characters.
Mod-10 Checking must verify PAN.
Mercury Payment
Systems

Track 1 or Track 2 must be read successfully and contain data.

Mercury Encryption

Read track must include sentinels.
Read track must include PAN with correct length.
PAN must include at least 9 characters.
At least one KSN must be defined in parameter '0091_0002'.

Monetra
CardShield

Track 1 or Track 2 must be read successfully.

On-Guard

Track 2 with sentinels for swiped or MSD card.

Monetra CardShield Encryption

PAN must include at least 9 characters.
On-Guard Encryption Configuration

Track 2 Equivalent or PAN for EMV card.
PAN followed by expiration date.
PAN must be at least 9 and at most 37 characters.
RSA-OAEP

Track 1, Track 2, and Track 3 data.
If manually entered, then the input must include the account
number, expiration date and CVV2.
PAN must include at least 9 characters.

62/854 Telium RBA Developer's Guide/ August 18, 2015

RSA-OAEP and TransArmor
Encryption

Encryption
Method

Minimum Requirements

S1

Requirements Document

Track 2 with both account number and expiration date field

S1 Encryption

Minimum 3 bytes of discretionary data.
TDES DUKPT
Generic

Track 1 or Track 2 must be read successfully, or data must be
manually entered.

Generic TDES DUKPT Encryption

PAN must include at least 9 characters.
TransArmor

Raw Track 1 or Track 2 data, or manually entered PAN.
PAN must include at least 9 characters.

Voltage TEP1

PAN must include at least 12 digits.
Track data must include at least one complete PAN.

Voltage TEP2

PAN must include at least 12 digits.
PAN must be successfully read from track data or manually entered
data.

Voltage TEP3

RSA-OAEP and TransArmor
Encryption

Voltage TEP1 and TEP2
Encryptions

Voltage TEP1 and TEP2
Encryptions

Not yet supported by RBA.

3_6_3 Enabling MSR Encryption in RBA
RBA users can enable MSR encryption by adjusting the config.dfs parameters in the below table found in the security.dat file
(see also section Security Parameters (security.dat)):
Parameters for Enabling MSR Encryption
config.dfs
Parameter

Description

Notes

0091_0001

Set value to “n” as noted, above in the table in
Supported Encryption Methods

The former parameter was '0003_0012'.

0091_0002

Set value to key slot index that contains the data
encryption key (if applicable).

Some encryption types do not use this parameter (e.g., Voltage).
Former parameter was '0003_0006'.

Neither of these values can be set using a 60.x: Configuration Write message. To set these, users will have to edit the
security.dat file in config.dfs directly, and obtain signature and a new .PGZ file prior to implementation. See Signing
Requirements for .DAT File Changes for details.

63/854 Telium RBA Developer's Guide/ August 18, 2015

3_6_4 EPS (Element Payment Systems) P2PE Encryption
This section provides information to assist in the configuration and understanding of EPS (Element Payment Systems) encryption. EPS is a
structure-preserving, DUKPT based encryption type.
When using EPS, the Key Sequence Number changes for every encryption. Refer to the following table for configuration parameters.
Parameters used by EPS Encryption
Parameter Name

DFS Data
Index

Default
Value

Description

Enable Encryption

0091_0001

0

Specify this value as 3.

Specify Encryption Key Slot (Key
Index)

0091_0002

4

Valid slot values that may be used for KP4 keys include 0-5.

Configure Leading PAN Digits in the
Clear

0091_0003

This value must match the slot where the key was injected.
6

Configure the number of leading digits to be displayed in the
clear.
Maximum = 6.

Configure Trailing PAN Digits in the
Clear

0091_0004

4

Configure the number of trailing digits to be displayed in the
clear.
Maximum = 4.

Masking the PAN

0091_0012

0

Specify the character to use for masking the PAN.
Use one of the following for EPS encryptions:
'0' = (zero).
'*' = (asterisk).

For examples of EPS card swipes and EPS encryption refer to the following sections.
EPS P2PE Card Swipe Examples
EPS P2PE Encryption Processing Examples

Track 1 is not supported when performing manual entry for EPS encryption. It will remain blank for the manual entry
transaction.

As of RBA release 3.3.0, EPS is PCI3-compliant and uses only KP4 keys.

Encryption or masking of cards with PANs containing less than 9 digits is not supported. Merchants should either whitelist
these cards or disable non-standard card encryption.

64/854 Telium RBA Developer's Guide/ August 18, 2015

Default values for DFS Data Index '0091_0002' (Specify Encryption Key Slot) differ for KP4 versus non-KP4 keys.The
following table shows the default values and valid ranges for KP4 and non-KP4 encryption key slots used for EPS encryption.

Encryption Key Slots for EPS Encryption
KP4 Keys

Non-KP4 Keys

Default Value

4

6

Range

0-5

0-9

3_6_4_1 EPS P2PE Card Swipe Examples
With EPS encryption, the first 6 and the last 4 digits are always in the clear, and the remaining middle digits are encrypted. Remember that
the Key Sequence Number changes for every encryption when using EPS. The following table illustrates swiped card data examples
viewed using a variety of messages when encrypted with EPS.
EPS Encrypted Message Samples

65/854 Telium RBA Developer's Guide/ August 18, 2015

Message

Description of After

Examples of Before (original card number) and After Encryption

19.x (BIN
Lookup)

Only 10 of 13 digits are
displayed.

Before: 4012345678909

The first 6 digits and the
last 4 digits are in the
clear; the 3 middle
digits are encrypted.

After: 401234 000 8909
19.D11000034012340008909[FS]
4B99358C793844C31AC522C764CC5A676
C3DFEE935D522CB613051F2554A9D3B87C09BE4E1A55896E44AB21F4FDA82
8D248F3AE1D1025F3AC935CDB33D1A1AD1:FFFF9876543210E00004[FS]1164
C984EBF0C3FED6A2047073608535C68A1BA050DDB73AAFA03DCC276CAB1
5:FFFF9876543210E00004

23.x (Card Read
Request
Response)

Only 10 of 13 digits are
displayed.
The first 6 digits and the
last 4 digits are in the
clear; the 3 middle
digits are encrypted.

Before: 4012345678909
After: 401234 000 8909
23.04
B99358C793844C31AC522C764CC5A676C3DFEE935D522CB613051F25
54A9D3B87C09BE4E1A55896E44AB21F4FDA828D248F3AE1D1025F3AC935C
DB33D1A1AD1:FFFF9876543210E00004[FS]1164C984EBF0C3FED6A20470736
08535C68A1BA050DDB73AAFA03DCC276CAB15:FFFF9876543210E00004

29.x (Get
Variable
Request/
Response)

All 13 digits are
displayed.
The first 6 digits and the
last 4 digits are in the
clear; the middle 3
digits are encrypted.

Before: 4012345678909
After: 401234 000 8909
Track1:
29.200004064
B99358C793844C31AC522C764CC5A676C3DFEE935D522CB613
051F2554A9D3B87C09BE4E1A55896E44AB21F4FDA828D248F3AE1D1025F3
AC935CDB33D1A1AD1:FFFF9876543210E00004
Track2:
29.200004071164C984EBF0C3FED6A2047073608535C68A1BA050DDB73AA
FA03DCC276CAB15:FFFF9876543210E00004

50.x
(Authorization
Request/
Response)

Only 10 of 13 digits are
displayed.
The first 6 digits and the
last 4 digits are in the
clear; the 3 middle
digits are encrypted.

Before: 4012345678909
After: 401234 000 8909
Track2:
50.12345678901234567890123456789012345678900207003254800002
@D1
164C984EBF0C3FED6A2047073608535C68A1BA050DDB73AAFA03DCC276CA
B15:FFFF9876543210E00004[FS]1@[FS]1025[FS]

66/854 Telium RBA Developer's Guide/ August 18, 2015

3_6_4_2 EPS P2PE Encryption Processing Examples
The following table shows EPS encrypted examples of Track 1, Track 2, and manually entered data.
EPS Encrypted Data Samples
Track

Type

Example

Track 1

Original

B4447340101127648^VISA CARDHOLDER/^1209121000000678000000

Encrypted
Track 1

5D97BDCBC8F9E12F4C99D502FB9B30E7715DBC0C8D64C27BE868554F24F176733C3798B96

KSN

A08B000C000003000023

Encrypted
Track
Format

EncryptedTrack1Data:KSN1

Original

4447340101127648=12091210000067800000

Encrypted
Track 2

CEAFC2FD0BA3E76E0C062DD2DD4196E111A71424C52561E943142AD271FC0D86C45CC365

KSN

A08B000C000003000024

Encrypted
Track
Format

EncryptedTrack2Data:KSN2

Track 2

76A7D68A0F3BFF8256E484AB65A88B4B2C4AB50DFA60B09585B9D57

B8D7E292

Track 3
Used with the 23.x message, Track 3 data will be sent in the clear and is only available when the
'0003_0010' (Append Track 3) parameter is set to a value of ‘1’ (where 1 = Send Track 1, Track 2
and Track 3).

Manually
Entered

Original
Track 1
Data
Encrypted
Track 1
Data

%M4744750029324780^MANUAL ENTRY/^1306000000123000000?

Track 1 is not supported when performing manual entry for EPS encryption. It will remain blank
for the manual entry transaction.

67/854 Telium RBA Developer's Guide/ August 18, 2015

Track

Type
Original
Track 2
Data

Example

4744750029324780=1306=123

The '123' within the Track 2 data in this example represents the CVV number.

Encrypted
Track 2
Data

5EFDACAD0F0B6997EC120D2AE568EDD504A50214F8871E6C43D3A4CFDC30D4BC:FFFF

KSN

FFFF9876543210E00003

Encrypted
Track
Format

EncryptedManuallyEnteredData:KSN

9876543210E00003

Manually entered data will appear as Track 2 data.

3_6_5 Generic TDES DUKPT Encryption
Generic TDES DUKPT Encryption (Triple Data Encryption Algorithm with Derived Unique Key Per Transaction) is an encryption
method for Retail Based Applications. A unique key is used for each transaction. This section assumes the reader is familiar with these
products. It contains information specific to the Generic TDES DUKPT P2PE feature. Generic TDES DUKPT encryption follows DUKPT:
2009 key management defined in X9.24-1 for data keys and uses CBC mode encryption with an Initial Vector of nulls. The current Telium
implementation can be used with MSR, contactless, and manually-entered data. To enable this feature and set its parameters, edit the
SECURITY.DAT section of CONFIG.DFS. The resulting SECURITY.DAT file must be signed and downloaded to the terminal to enable
the encryption.
When using Generic TDES DUKPT Encryption, there are two options for incrementing the Key Serial Number (KSN). It can either be
forced to increment, or it will automatically increment after 10 encryptions. Currently, RBA uses the automatic advance mode. Additional
information can be found in the following subsections:
TDES DUKPT Configuration - Configuration information for Generic TDES DUKPT.
Usage - Data format prior to encryption, data returned to the POS application, and determining the encryption configuration.

3_6_5_1 TDES DUKPT Configuration
Configuring Security Parameters
Configuration information for Generic TDES DUKPT is contained in two files: SECURITY.DAT and SECBIN.DAT. These are the same
files used to configure encryption and security in the Telium RBA application. Refer to Configuring the Application in this manual for
details. The specific security parameters relevant to Generic TDES DUKPT encryption are listed in the below table.
Parameters used by TDES DUKPT Encryption

68/854 Telium RBA Developer's Guide/ August 18, 2015

Parameter Name

DFS Data
Index

Default
Value

Description

Enable Encryption (in
security.dat)

0091_0001

0

Specify this value as 11 for Generic TDES DUKPT.

Specify Encryption Key
Slot (Key Index) (in
security.dat)

0091_0002

4

Generic TDES DUKPT uses this DUKPT key slot for this feature. (Only slots 05 can be used).

Configure Leading PAN
Digits in the Clear (in
security.dat)

0091_0003

6

Generic TDES DUKPT ignores the value of this parameter. Specifies the
number of leading digits to be displayed in the clear (Maximum = 6). The
default value of 6 is hardcoded for Generic TDES DUKPT.

Configure Trailing PAN
Digits in the Clear (in
security.dat)

0091_0004

4

Generic TDES DUKPT ignores the value of this parameter. Specifies the
number of trailing digits to be displayed in the clear (Maximum = 4). The
default value of 4 is hardcoded for Generic TDES DUKPT.

Masking the PAN (in
security.dat)

0091_0012

0

Generic TDES DUKPT ignores the value of this parameter. Specifies the
character to use for masking the PAN. The default value of 0 (zero) is hardcoded
for Generic TDES DUKPT.

Encryption or masking of cards with PANs containing less than 9 digits is not supported. Merchants should either whitelist
these cards or disable non-standard card encryption.

Configuring for Manual Entry
In addition to configuring the security parameters, the "Enter Card" prompt display parameter ('0007_0029') must also be configured for
the proper cardholder prompt. When using TDES encryption and manually entering data, the PAN, expiration date and CVV are all
required. This parameter must therefore be set to '0' or '1' when using this encryption mode.

The only files used by RBA are SECURITY.DAT and SECBIN.DAT. These files must be signed by Ingenico and downloaded
to the terminal. This prevents an attacker from turning off encryption or modifying the settings.

3_6_5_2 Usage
For information on Generic TDES DUKPT encryption data format, communications with the POS, and configuring the encryption, refer to
the following subsections:
Data Format Prior to Encryption - Generic TDES DUKPT encryption cases with examples.
Data Returned to the POS Application - Description of set RBA properties which are set once the card is swiped.
Determining the Encryption Configuration - Methods used by the application to determine how the terminal is configured.

69/854 Telium RBA Developer's Guide/ August 18, 2015

Data Format Prior to Encryption
The input to the encryption process depends on the encryption type. For Generic TDES DUKPT encryption, there are four cases:
Only Track 1 was read successfully. The string to be encrypted consists of the raw Track 1 data with Start and End Sentinels.
Example:
%B4445222299990007^LAST/VISA^14125025432198712345Q?
Only Track 2 was read successfully. The string to be encrypted consists of the raw Track 2 data with Start and End Sentinels.
Example:
;4445222299990007=14125025432198712345?
Data was entered manually. The string to be encrypted consists of concatenated dummy Track 1 and Track 2 data with Start and
End Sentinels. The dummy tracks are constructed from the manually-entered PAN, expiration date and CVV2 which are all
required when using TDES encryption in manual entry mode.
Example:
%M5444009999222205^MANUALLY/ENTERED^12120000001234000000?;5444009999222205=12120000001234000?
In this example, 5444009999222205 is the PAN, 1212 is the expiration date (YYMM), and 1234 is the CVV2. There will
always be six 0’s between the expiration date and the CVV2. There will always be six 0’s after the CVV in Track 1, and
three 0’s after the CVV in Track 2.
Both Tracks 1 and 2 were read successfully. The string to be encrypted consists of the concatenated raw Track 1 and Track 2 with
Start and End Sentinels.
Example:
%B4445222299990007^LAST/VISA^14125025432198712345Q?;4445222299990007=14125025432198712345?

Please refer to Manual Card Data Entry in E2EE Mode for information on programming manual entry of cardholder data when
using point-to-point encryption.

Data Returned to the POS Application
Once a card has been swiped or tapped, or the manual entry process is complete, the following properties are set:
TDES Properties and their Content

70/854 Telium RBA Developer's Guide/ August 18, 2015

Property

Contents when using Generic TDES DUKPT Encryption

Account Number

Masked account number (middle digits are 0)

ExpirationDate

Expiration date (in the clear)

FirstName

First name (in the clear)

MiddleInitial

Middle initial (in the clear)

ServiceCode

Service code (in the clear)

Suffix

Suffix (in the clear)

Surname

Surname (in the clear)

Title

Title (in the clear)

Track1Data

Masked Track 1 data

Track1DiscretionaryData

Masked Track 1 discretionary data

Track2Data

Masked Track 2 data

Track2DiscretionaryData

Masked Track 2 discretionary data

Track3Data

The Track 3 data sent to the POS consists of four items separated by colons (“:”):
The KSN of the TDES DUKPT encryption key - 20 bytes ASCII hex characters.
One digit indicating which data were encrypted: 1 = Track 1, 2 = Track 2, 3 = dummy tracks for
manually-entered data, 4 = Track 1 and Track 2.
The four digit length (decimal) of the encrypted data block. This is the number of bytes of binary
data.
The encrypted data block in ASCII Hex format. Since each byte is represented by two ASCII
characters, the length of this string will be twice the length of the binary data block.
The following is an example of Track 3 Data for generic TDES DUKPT encryption, where Track 2 data
was encrypted:
FFFF4900361491E00004:2:0048:16D8BD06F00671AAA4FBA2381EDD239DE03E618FB33
2AEA7524CBB1ED1DBE4FFDEF26740138D5549E08FB7ECD1649169

If the TransmitSentinels property is true, then Track1Data, Track2Data and Track3Data will each begin with a start
sentinel and end with an end sentinel.

71/854 Telium RBA Developer's Guide/ August 18, 2015

Currently, Track 3 data either in the clear, or masked, are not available to the application.

Determining the Encryption Configuration
The encryption settings are configured on the terminal and cannot be changed by the application. The application can find out how the
terminal is configured by querying certain RBA variables corresponding to the configuration parameters. The general rule is that the
variable DFS_xxxx_yyyy contains the value of the parameter with DFS Data Index xxxx_yyyy. Only the variables needed by the POS
application are provided. Currently, the following variables are supported and are listed in the below table.
Enabling TDES DUKPT Encryption
Variable Name

Variable Description

DFS_0091_0001

A read-only variable containing the encryption type:
0 = No encryption
11 = Generic TDES DUKPT encryption.

3_6_6 Magtek Encryption
3_6_6_1 Overview of Magtek Encryption
Magtek is a format-preserving encryption type. Please refer to the Magtek MagneSafe Technical Reference Manual (Magtek part number
99300001-1) for detailed information about the implementation of Magtek MagneSafe encryption. The following table describes the
configuration parameters relevant to Magtek encryption.
Configuration Parameters (in config.dfs) Used for Magtek Encryption

72/854 Telium RBA Developer's Guide/ August 18, 2015

Parameter Name

DFS Data
Index

Default
Value

Description

Enable Encryption

0091_0001

0

Specify this value as '1'.

Specify Encryption Key Slot (Key
Index)

0091_0002

6

Valid values include 0-9 for most encryption types.
Magtek requires a value other than ‘0’ (zero).
This value must match the slot where the key was
injected.

Configure Leading PAN Digits in the
Clear

0091_0003

6

Magtek does not allow configuration of this parameter.

Configure Trailing PAN Digits in the
Clear

0091_0004

4

Magtek does not allow configuration of this parameter.

Masking the PAN

0091_0012

0

Specify the character to use for masking the PAN.
Magtek uses only ‘0’ (zero).

Encryption or masking of cards with PANs containing less than 9 digits is not supported. Merchants should either whitelist
these cards or disable non-standard card encryption.

3_6_6_2 Data to be Encrypted
At least one present and valid Track is required for encryption to occur.
If there is no Track 1 data, Track 2 data is required, and a simulated copy of Track 1 data will be created and used to formulate the
Magtek message.
Likewise, if there is no Track 2 data, Track 1 data is required, and a simulated copy of Track 2 data will be created and used for the
message.
The following table shows all of the scenarios along with format codes required by Magtek.
Magtek Encryption Scenarios and Format Codes

73/854 Telium RBA Developer's Guide/ August 18, 2015

Tracks Present in Input

Format Code

Tracks 1 & 2 present

E

Only Track 1 = present, Track 2 = blank

I

Only Track 1 = present, Track 2 = error

J

Only Track 2 present, Track 1 = blank

G

Only Track 2 = present, Track 1 = error

H

To learn more about the specific constraints on the content of each track, the specific pieces of data that are ciphered, and the varying
formats for each (which are dependent upon PAN length), please refer to the Magtek MagneSafe Technical Reference Manual (Magtek
part number 99300001-1).

3_6_6_3 Configuring Mod-10 and Account Number Check Digit
Magtek encryption requires Mod-10 checking. Refer to the Mod-10 Checking section for more information. The following table provides
an example Mod-10 check digit using manual entry.
Example Mod-10 Check Digit Using Manual Entry
PAN Length

Track

Example Check Digit

16 Digits

Track 2

;5452300003007180=120410100000000000?

15 Digits

Track 2

;545230000307180=120410100000000000?

This example shows that for cards with 16 digit and 15 digit PANs, the 10th character always holds the Mod-10 check digit correction
character.

Encryption Does Not Occur If…
Any errors result in sending Track 1 and Track 2 data in the clear. Please refer to the Magtek MagneSafe Technical Reference Manual
(Magtek part number 99300001-1) for detailed descriptions.

Encryption Data Returned to the POS – Tracks 1 & 2
The encrypted data will be sent to the POS using all existing messages or the standard RBA flow. For example, the encrypted data will be
sent to the POS using the 23.x message, if conducted through the 23.x message.
Output formats for Tracks 1 and 2 depend on the length of the input PAN. Please refer to the Magtek MagneSafe Technical Reference
Manual (Magtek part number 99300001-1) for detailed information.

74/854 Telium RBA Developer's Guide/ August 18, 2015

Track 3 Data
Magtek takes into account Track 1 and Track 2 only. Because there is no way of knowing what information Track 3 may contain, Track 3
will not be returned when using Magtek encryption.

Initiating an Encrypted Swipe/Tap/Manual Entry
Magtek encryption is used in both the standard RBA flow and with the 23.x message.

Configuring for Manual Entry – Standard RBA Flow
Both the Expiration Date and CVV are required by Magtek.
To support manual entry using the standard RBA flow, the global flag '0007_0029' must be set to ‘1’ (Display button, prompt for the
Expiration Date and the CVV). Refer to the following table which describes this parameter setting and function.
Configuring Prompt for Manual Entry
Value

Description

'0007_0029' configuration

1

Display button, prompt for the Expiration Date and the CVV

REQUIRED

All valid '0007_0029' parameter values are acceptable for Magtek encryption. Values for this parameter are as follows:
0 = Do not display.
1 = Display button and prompt for card number, expiration date, and CVV.
2 = Display button and prompt for card number and expiration date (no CVV).
3 = Display button and prompt for card number and CVV (no expiration date).
4 = Display button and prompt for card number (no expiration date, no CVV).
Note that when the terminal is configured for ‘payment selection before swipe/tap/manual entry’ ('0007_0005' = '1'), the settings (in cards.
dat) for prompting the CVV and Expiration Date for manual entry for the selected card type must be set to ‘1’. This is because the
expiration date and CVV are controlled based on card type rather than the above global flag ('0007_0029'). Refer to the ' 0011_xxxx'
parameters in config.dfs for details on card type settings.

3_6_6_4 Configuring for Manual Entry – 23.x Message
If selected, manual entry will follow the same rules as manual entry from the swipe screen.
To load either of the manual entry forms, specify the CCOD.K3Z form for contactless terminals or the COD.K3Z form for non-contactless
terminals in the 23.x message, in addition to the prompt or prompt index. The button for manual entry is hidden when the Display “Enter
Card” Prompt (configuration parameter '0007_0029') is set to '0'. In order for the manual entry button to be visible, this configuration
parameter must be set to a value of '1' to '4' as described in the following table.
Configuring for Manual Entry

75/854 Telium RBA Developer's Guide/ August 18, 2015

'0007_0029'

"Enter Card" Button

Enter Card Number

Enter Expiration Date

Enter CVV

0

Not Displayed

1

Displayed

Yes

Yes

Yes

2

Displayed

Yes

Yes

No

3

Displayed

Yes

No

Yes

4

Displayed

Yes

No

No

If no manual entry configuration is necessary, load either of the default forms, issue the 23.x message as normal (e.g., no form name
specified, but the prompt or prompt index still needs to be sent).

3_6_7 Mercury Encryption
3_6_7_1 Configuration Parameters (in config.dfs)
Parameter Name

DFS Data
Index

Default
Value

Description

Enable Encryption

0091_0001

0

Specify this value as '8'.

Specify Encryption Key
Slot (Key Index)

0091_0002

4

Valid values include '0' – '6'.
Only slots '0' - '5' can be used.
This value must match the slot where the key was injected.

Configure Leading PAN
Digits in the Clear

0091_0003

6

Mercury does not use this parameter.

Configure Trailing PAN
Digits in the Clear

0091_0004

4

Mercury does not use this parameter.

Masking the PAN

0091_0012

0

Specify the character to use for masking the PAN. Mercury uses either *
(asterisk) or 0 (zero).

For Non-ISO cards, the PAN will not be masked and both Track 1
and Track 2 will be sent in the clear.

76/854 Telium RBA Developer's Guide/ August 18, 2015

Encryption or masking of cards with PANs containing less than 9 digits is not supported. Merchants should either whitelist
these cards or disable non-standard card encryption.

3_6_7_2 Data to be Encrypted
All three tracks should be available for Mercury encryption. Each uses some specific formatting, described below:
Track 1 and Track 2 data will include the start and end sentinels.
Track 3 data will include the start and end sentinels, as well as the LRC check character.
Track 1 and Track 2 will be encrypted independently of one another, i.e., there will be a separate KSN for each track.

The Track 1 and Track 2 KSNs can (but do not necessarily) match.

When both Track 1 and Track 2 are present and valid, the format of the data fed to the ciphering algorithm will be as follows:
Algorithm for Valid Tracks 1 and 2
Track Number

Algorithm

1

%Btrack1? (for ISO cards)

1

%track1? (for non-ISO EBT cards)

2

;track2?

When only Track 1 is present and valid, the format of the data fed to the ciphering algorithm will be as follows:
Algorithm for Valid Track 1
Track Number

Algorithm

1

%Btrack1? (for ISO cards)

1

%track1? (for non-ISO EBT cards)

2

;?

Encryption of non-ISO EBT cards with no Format Code (B) in Track 1 is supported.

When only Track 2 is present and valid, the format of the data fed to the ciphering algorithm will be as follows:
Algorithm for Valid Track 2

77/854 Telium RBA Developer's Guide/ August 18, 2015

Track Number

Algorithm

1

%?

2

;track2?

3_6_7_3 Encryption Does Not Occur If…
At least one present and valid conforming track must be read for encryption to occur. Data will be sent in the clear only if:
Neither Track 1 nor Track 2 has been read successfully
Neither Track 1 nor Track 2 contains data
Neither track conforms (there are missing sentinels, the PAN is too long or too short, etc.)
Any combination of the above for both tracks

3_6_7_4 Other Reasons
If there is a missing key (e.g., '0091_0002' is configured incorrectly), or the ciphering algorithm returns an error, track data will not be
sent. Instead, one of the following will occur:
terminal Responses
Form Displayed on Terminal

Terminal Response

Swiping from the swipe screen...

The terminal will go offline.

Swiping from the card read request screen (23.x message)...

The terminal will issue an encryption error.

3_6_7_5 Encryption Data Returned to the POS
Using the 29.x message: If card data is read from the swipe screen as part of the standard RBA flow, the data will be available to the POS
using the 29.x: Get Variable Request message. The following table suggests variables to use with the 29.x message in this case.
29.x Message Variables
Masked Track Number

Algorithm

1

Use variable 406 with the 29.x message.

2

Use variable 407 with the 29.x message.

3

Use variable 401 with the 29.x message.

The masked Track 1 and Track 2 data will be sent along with the KSNs and Track 3 data. Track 3 will be formatted as follows:
encryptedtrack1:track1KSN:encryptedtrack2:track2KSN:track3

78/854 Telium RBA Developer's Guide/ August 18, 2015

There are colons (:) separating the encrypted tracks and KSNs, and Track 3 data (if present) will be in the clear.

3_6_7_6 Initiating an Encrypted Swipe/Tap/Manual Entry
Mercury encryption is used in both the standard RBA flow, and with the 23.x message.

3_6_7_7 Configuring for Manual Entry Using the 23.x Message
If selected, manual entry will follow the same rules as manual entry from the swipe screen.
To load either of the manual entry forms, specify the CCOD.K3Z form for contactless terminals or the COD.K3Z form for non-contactless
terminals in the 23.x message, in addition to the prompt or prompt index. The button for manual entry is hidden when the Display “Enter
Card” Prompt (configuration parameter '0007_0029') is set to '0'. In order for the manual entry button to be visible, this configuration
parameter must be set to a value of '1' to '4' as described in the following table.
Configuring for Manual Entry
'0007_0029'

"Enter Card" Button

Enter Card Number

Enter Expiration Date

Enter CVV

0

Not Displayed

1

Displayed

Yes

Yes

Yes

2

Displayed

Yes

Yes

No

3

Displayed

Yes

No

Yes

4

Displayed

Yes

No

No

3_6_7_8 On-Demand Transactions
If card data is read from the 23.x card read request screen, the encrypted data will be sent to the POS using the 23.x: Card Read Request
(On-Demand) message. Below is an example of data sent in a 23.x message for an on-demand transaction with Mercury encryption
enabled:

23.0%B476173******0010^CARDHOLDER VISA ^1012201000000000000?[FS]
476173******0010=1012201************?[FS];4761730000000010=1012201000000000000?[FS]
BD303C7853EE862C35B764D51238081BFFB1AF53EB6C6422649F12BB4DC63B99E8EFEE08A1F24B4F71DFC0C6D5939F6E585D16A8
21111010000000000001:
40F758A5B2FE69012DAAA62CB8F2E750512EF077A5D60D7DF084BEEC58DB70908BA1E9FF39BFEF29:
21111010000000000002
The breakdown of the above data sample can be viewed in the table below. Note that there is no Track 3 data sent in this message, as it
would be appended to the end after another colon:
Mercury 23.x Card Read Request Breakdown

79/854 Telium RBA Developer's Guide/ August 18, 2015

Data

Value

Message ID.

23.

Message status.

0

Masked Track 1 Data.

%B4761730000000010^CARDHOLDER VISA ^1012201000000000000?

Field separator.

[FS]

Masked Track 2 Data.

;4761730000000010=1012201000000000000?

Field separator.

[FS]

Encrypted Track 1.

BD303C7853EE862C35B764D51238081BFFB1AF53EB6C6422649F12B
B4DC63B99E8EFEE08A1F24B4F71DFC0C6D5939F6E585D16EA8477
F4097F829EBBB1F19699FFCC5665DA654640

Colon.

:

KSN1.

21111010000000000001

Colon.

:

Encrypted Track 2.

40F758A5B2FE69012DAAA62CB8F2E750512EF077A5D60D7DF084B
EEC58DB70908BA1E9FF39BFEF29

Colon.

:

KSN2.

21111010000000000002

The decrypted track data from the above table is as follows:
Track 1: B4761739001010010^CARDHOLDER VISA ^1012201512349999999
Track 2: 4761739001010010=1012201512349999999

3_6_7_9 Card Swipe and Contactless Transactions
With Mercury encryption enabled, the following data will be sent in a 50.x: Authorization Request message for card swipe and contactless
transactions:
50.12345678901234567890123456789012345678900208020443900001@D;
4761730000000010=1012200000000000000?[FS]1@[FS]1025[FS]
The breakdown of the above data sample can be viewed in the table below:

80/854 Telium RBA Developer's Guide/ August 18, 2015

Example Mercury Encrypted 50.x Message Breakdown
Data

Value

Message ID.

50.

Acquirer BIN.

123456

Merchant Number.

789012345678

Store Number.

9012

Terminal Number.

3456

Merchant Category.

7890

Merchant Country Code.

123

Merchant ZIP Code.

45678

Time Zone Difference.

900

Transaction Code.

20

Terminal Serial Number.

80204439

Index Code.

0

Transaction Number.

0001

Message Status Code.

@

Account Data Source.

D

Masked Track 2 Data.

;4761730000000010=1012000000000000000

Field Separator.

[FS]

PIN Block.

1@

Field Separator.

[FS]

Transaction amount, omitting decimal.
In this case, '1025' equates to 10.25.

1025

81/854 Telium RBA Developer's Guide/ August 18, 2015

Data

Value

Field separator.

[FS]

The decrypted track data from the above 50.x message can be found using the Decrypt Card Data tool with the option 'Data Variant"
unchecked (deselected).

3_6_8 Monetra CardShield Encryption
3_6_8_1 Introduction
Monetra CardShield encryption is built with design principles similar to DUKPT key management and TDES ciphers. Monetra encryption
may be used in both the standard RBA flow, and with the 23.x message.
Configuration Parameters (in config.dfs)
Parameter Name

DFS Data
Index

Default
Value

Description

Enable Encryption

0091_0001

0

Specify this value as '7'.

Specify Encryption Key
Slot (Key Index)

0091_0002

4

Valid values include '0' – '6'.
Only slots '0' - '5' can be used.
This value must match the slot where the key was injected.

Configure Leading PAN
Digits in the Clear

0091_0003

Configure Trailing PAN
Digits in the Clear

0091_0004

Masking the PAN

0091_0012

6

Configure the number of leading digits to be displayed in the clear.
Maximum = '6'.

4

Configure the number of trailing digits to be displayed in the clear.
Maximum = '4'.

0

Specify the character to use for masking the PAN. Monetra uses ONLY the ‘*’
(asterisk).

By always using ‘*’, the POS will have a reliable way to identify
whether the data returned in the 23.x message is encrypted or not.

Encryption or masking of cards with PANs containing less than 9 digits is not supported. Merchants should either whitelist
these cards or disable non-standard card encryption.

82/854 Telium RBA Developer's Guide/ August 18, 2015

3_6_8_2 Data to be Encrypted if Track 3 is Available
If present, the original Track 3 data will be encrypted. The other track data will be handled as specified by the above parameters, and as
explained below.

3_6_8_3 Data to be Encrypted if Track 3 is Unavailable
If Track 3 is unavailable, Track 1 and Track 2 are encrypted together as a single block of data. Dummy card data is not created for empty
track data in the card, and no sentinels will be sent in that case. If a track is blank, then that track will be returned to the POS as blank.
Only track data which is present will be encrypted. Depending on which tracks are present, the format of the data fed to the ciphering
algorithm will be in one of the following formats:
Encrypting per Valid Track Data
Tracks Present and Valid

Algorithm

1&2

%BTRACK1?;TRACK2?

1 only

%BTRACK1?;?

2 only

%B?;TRACK2?

3_6_8_4 Manual Entry
For manual entry, the data input to the ciphering algorithm will be in the form
PAN|EXPDATE|CVV2
If EXPDATE or CVV2 are not entered manually, they will be empty. Regardless, the two vertical bar characters in the data will remain.
The decrypted data may contain trailing null characters as required for padding.

3_6_8_5 Encryption Does Not Occur If…
If neither Track 1 nor Track 2 has been read successfully (e.g., if there is an encryption error, or an invalid card exists), then
encryption does not occur; the data is then sent in the clear.
If one of the tracks is present and valid, then encryption will occur with only the present and valid track.
If Track 3 has been read successfully, then encryption does not occur, and again, the data is sent in the clear. This is because Track
3 is used to send back the encrypted data and the KSN.

3_6_8_6 Encryption Data Returned to the POS – Tracks 1 & 2
The encrypted data will always be sent to the POS using the 23.x message. Sentinels are included in the 23.x message.
The data received can be identified as encrypted when it has these two characteristics:
1. Track 1 or Track 2 contains one or more instances of the masking character ‘*’ (asterisk).
2. Track 3 contains a ‘:’ (colon) which is used to separate the encrypted data from the KSN.

Either both characteristics or neither characteristic will exist at any one time.

83/854 Telium RBA Developer's Guide/ August 18, 2015

Depending on which tracks were encrypted, you will receive one of the following three message formats with the 23.x message:
Encrypted Tracks Returned
Tracks Present and Valid

Format

1&2

23.0%BMASKEDTRACK1?[FS];MASKEDTRACK2?[FS]ENCRYPTEDDATA:KSN

1 only

23.0%BMASKEDTRACK1?[FS];?[FS]ENCRYPTEDDATA:KSN

2 only

23.0%B?[FS];MASKEDTRACK2?[FS]ENCRYPTEDDATA:KSN

3_6_8_7 Configuring for Manual Entry using the 23.x Message
If selected, manual entry will follow the same rules as manual entry from the swipe screen.
To load either of the manual entry forms, specify the CCOD.K3Z form for contactless terminals or the COD.K3Z form for non-contactless
terminals in the 23.x message, in addition to the prompt or prompt index. The button for manual entry is hidden when the Display “Enter
Card” Prompt (configuration parameter '0007_0029') is set to '0'. In order for the manual entry button to be visible, this configuration
parameter must be set to a value of '1' to '4' as described in the following table.
Configuring for Manual Entry
'0007_0029'

"Enter Card" Button

Enter Card Number

Enter Expiration Date

Enter CVV

0

Not Displayed

1

Displayed

Yes

Yes

Yes

2

Displayed

Yes

Yes

No

3

Displayed

Yes

No

Yes

4

Displayed

Yes

No

No

If no manual entry configuration is necessary, load either of the default forms, issue the 23.x message as normal (e.g., no form name
specified, but the prompt or prompt index still needs to be sent).

3_6_8_8 Initiating an Encrypted Swipe/Tap/Manual Entry
Monetra encryption support has been added for card swipes during the standard flow "swipe" screen. Previously, only the 23.x on-demand
card swipes were allowed when using Monetra encryption, while card swipes from the standard flow "swipe" screen were flagged as errors
which caused the terminal to go offline. With card swipes now being supported during the standard flow "swipe" screen, this action is no
longer being processed as an error.

84/854 Telium RBA Developer's Guide/ August 18, 2015

3_6_8_9 Monetra CardShield Encryption Examples
Monetra Data Encryption Examples
Content

PAN

Example Value After Encryption

PAN Only

7195388662093300010

Track 1: 7195388662093300010
Track 2: 7195388662093300010

Track 1 Only

6011086910623514

Track 1: %B 601108*****3514 ^INGENICO/TEST CARD ^0705101************?
Track 2: (BLANK)
Track 3: 212A38115DC56F04850BEB5E91014F401A277713FAB73BE3C66C4893
9BF7289A3CC4154DD23A145D00CD035852CFCFA97EECE48FF9658F8F47F27A
A0CED16B4C:0000000200000B00000161

6 Digit PAN

475767

Track 1: 475767 Track 2: 475767

Track 2 Only

21110000075272

Track 1: (BLANK)Track 2: 21110000075272

Track 2 Only

6001760817150245351

Track 1: (BLANK)Track 2: 6001760817150242351 =3712

Manual Entry Transaction
Variable IDs 399 and 402 (Account Name) return "Manual Entry" for manual entry when Monetra encryption is enabled.
manualAccountName is replaced with 'msg23MsrName' in a 23.x message during an On Demand flow manual entry. Variable 399 then
returns "Manual Entry" in the 29.x message as shown in the table below.
Monetra Manual Entry in On-Demand Flow Example

85/854 Telium RBA Developer's Guide/ August 18, 2015

Step

Notes

Enable TransArmor encryption.
Enable '0007_0029'.

Set to any value '1' through '4'.

Send 23.x message while terminal displays a "Please slide card" form.
Press ENTER CARD button.
Enter PAN+Expiry Date+CVV value as per the '0007_0029' settings.
The terminal displays "card accepted" form and sends a 23.x response.
The POS prompts the terminal for variables with 29.x messages.

During a card swipe or contactless transaction in a normal transaction
flow (not On-Demand), the '29.00000399' request would still return a
card name in the response, e.g., '29.20000399TESTCARD/TEST'.

Sample 29.x Requests and Responses
29.x
Request

29.x Response

29.00000398

29.200003984445220000000007

29.00000399

29.60000399Manual Entry

29.00000400

29.200004000000

3_6_9 On-Guard Encryption
3_6_9_1 Overview
This section provides information about Telium RBA support for On-Guard point-to-point encryption. On-Guard encryption utilizes an
injected DUKPT key. On-Guard encryption and KME encryption methods are handled similarly, and are referred to collectively as the
“E2EE feature” (End-to-End Encryption). On-Guard and KME encryption methods can process card data read by:
Magnetic Stripe Reader (MRS)
Smart Card Reader (SCR) for EMV cards
Manual entry
The purpose of the E2EE solution is to isolate the POS system (Electronic Cash Register or Host device) from processing clear text card
data, and in doing so, reduce the impact of PCI DSS reviews. New commands or modifications to existing commands will be described in
the New RBA Messages for On-Guard and KME Encryption section of this document.
On-Guard encryption and KME encryption can be enabled, disabled, and configured by a signed configuration file loaded into the
SYSTEM drive on the Telium terminal.
The text file containing the configuration information is named "e2ecfg".

86/854 Telium RBA Developer's Guide/ August 18, 2015

The corresponding signed configuration file is "829651xxxx.PGN" where xxxx is the version number.
This configuration file contains the enable mode (KME or On-Guard) as well as the index of the encryption key in the secret area. Once
the RBA reads and parses this file, it will be deleted. The configuration extracted from this file will be saved into the application disk. As
an expected change to the general-release version, the E2EE configuration information will be incorporated into the existing “security.dat”
file described in the Security Parameters (security.dat) section of this document.
An E2EE 'activate' command has been added to simplify the use of this feature. The terminal can be loaded with the required software and
keys. When the POS and network are ready to process the encrypted card data, the POS can send a single command to enable the feature.
It should be noted that once E2EE encryption is enabled by either configuration file or by command, it cannot be disabled. The RBA
application has a mechanism to prevent the reverse operation. The only way to disable E2EE encryption is to erase the terminal and reload
all components.
By default, E2EE encrypts data from all cards. If you require only some cards to be encrypted, you must configure the “e2ebin” file for the
appropriate BIN ranges. This file contains a list of BIN ranges, utilizing low and high ranges of the first 6 digits of the PAN. If there is a
match between the first 6 PAN digits of the card data read and the BIN table, then the card data read is returned in the clear. The “e2ebin”
file must be signed before it can be loaded onto a terminal. As an expected change to the general-release version, the BIN ranges will be
defined in the existing “secbin.dat” file described in the RBA documentation.
Refer to the following sections for more information pertaining to On-Guard encryption:
On-Guard Configuration
On-Guard Card Data Encryption Rules
New RBA Messages for On-Guard and KME Encryption
Handling of Existing RBA Messages
E2EE Card Data Encryption

3_6_9_2 On-Guard Configuration
On-Guard Encryption Configuration
As an expected change to the general-release version, the E2EE configuration information may be incorporated into the existing “security.
dat” file described in the Security Parameters (security.dat) section. Accordingly, the configuration file described in this section may no
longer be used. The E2EE configuration file “e2ecfg” must be signed as (829651xxxx.PGN) before it can be used by the RBA. The
“e2ecfg” file is a text file whose first line contains the following values, separated by commas:
W
X
Y
Z
A
The function of these variables is described in the following table.
On-Guard Encryption Variables

87/854 Telium RBA Developer's Guide/ August 18, 2015

Item

Length

Type

Description

W

1

Alphanumeric

E2EE mode.
1 = KME E2EE mode is enabled.
2 = On-Guard E2EE mode is enabled.
D = E2EE is disabled.

X

1

Alphabetic

Output format type.
A = Type A formatting, will return Track 2 only and support Base 24 framing.
B = Type B formatting used by On-Guard, will return track 2 only (with no framing) and the
KSN for the E2EE DUKPT cryptogram.

Y

1

Alphabetic

Type of key used.
M = Master/Session key (used by KME).
D = DUKPT (used by On-Guard encryption).

Z

1

Numeric

Key slot where the encryption key has been injected. Key Pattern 4 (KP4) must be used.
Must be in the range from 0 to 5.

Commonly,
Slot ‘2’ is used for KME keys.
Slot ‘5’ is used for On-Guard keys.

A

1

Numeric

Optional. Specifies the key number of the optional TDES local storage data encryption key.
Value for key number is from 0 to 9.

This is not used for On-Guard encryption. The format of the LS data block is always that
of the manual entry definition.

aaaaaaaaaaa aaaaaaaaaaa aaaaaaaaaaa aaaaaaaaaaa aaaaaaaaaaa aaaaaaaaaaaa aa

Encryption or masking of cards with PANs containing less than 9 digits is not supported. Merchants should either whitelist
these cards or disable non-standard card encryption.

Because signed files have a minimum size, padding is added after the above information to meet those size requirements. The following
example shows this padding:

88/854 Telium RBA Developer's Guide/ August 18, 2015

1, A, M, 2,
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
The E2EE configuration file can be signed and downloaded, changing the E2EE feature from being disabled to enabled. In this case, the
E2EE feature will be activated and the RBA application will encrypt all data that is required to be encrypted. The feature will remember
being enabled such that downloading a configuration file to disable E2EE will be ignored.
If the E2EE configuration file is loaded into the terminal with the E2EE mode parameter set to ‘enabled’ (‘1’ or ‘2’), then the config.
dfs parameter '0091_0001' (Encrypt track data) will have no effect even if it has been enabled. Its value will be reset to '0'. Note that if the
RBA starts and the E2EE mode has not been configured either by file or by command, then the RBA displays the message "No Config
file" and will not run. (By default, the RBA installation package includes a version of the configuration file that disables E2EE, so this
situation will not typically occur.)
Some terminals require E2EE to be enabled. In these cases, if the E2EE mode is set to Disabled, the RBA will display the message "E2EE
Not Enabled" and will not run.

On-Guard BIN Table Configuration
The BIN table “E2EBIN” provides a means to specify that cards in certain BIN ranges will not be encrypted. This file must be signed and
downloaded to the terminal in order to be recognized by RBA. As an expected change to the general-release version, the BIN range
information will be incorporated into the existing secbin.dat file described in the RBA documentation, and the configuration file
described in this section will no longer be used. The unsigned BIN table is a text file which contains lines in the following format:
Unsigned BIN Table Content

89/854 Telium RBA Developer's Guide/ August 18, 2015

Line

Content

1

Low bin (6 digits)

2

"-"

3

High bin (6 digits)

4

";"

5

Service code

In the service code, an “x” can be used to match any digit. A service code of “mmm” is applicable to BIN checking of Manual Entry card
data only. Consider the following sample BIN table:
Service Codes with x and mmm Examples
Sample

Content

1

000000-999999;110

2

000000-299999;x6x

3

130000-299999;xxx

4

800000-999999;x20

5

130000-299999;mmm

The service codes 120 and 220 are designated for Debit Card only, so they will be excluded from wildcard service codes such as “xxx” or
“x2x”, etc. If a service code of "120" or "220" is explicitly entered in the BIN table, then matching entries will not be encrypted.
The BIN file must be signed and loaded onto the HOST drive in the terminal. The RBA application, at terminal boot up, parses this file
and then deletes it.
When determining the PAN for use with On-Guard encryption, the RBA follows these rules:
For MSR and manual entry, look for an “=” sign or the end of the card data to terminate the PAN, up to a maximum of 37
characters.
For card data from smart cards (contact or contactless), it is assumed that the PAN will be 19 or fewer digits.

3_6_9_3 On-Guard Card Data Encryption Rules
This section describes how data will be formatted prior to E2EE encryption.

Type A Formatting
Type A formatting applies to KME and will be described in a separate document.

90/854 Telium RBA Developer's Guide/ August 18, 2015

Type B Formatting
Type B formatting applies to On-Guard encryption. This section describes how card data will be formatted for On-Guard encryption. A
'Start Sentinel' character and 'End Sentinel' character will be present in all cases. For manual entry, the 'Start Sentinel' character is “M”. For
all other cases, the 'Start Sentinel' character is “;”. The End Sentinel is always “?”. The following applies to type B formatting.
1. For Track 2 data read from a swiped or MSD card, the data to be encrypted will be the Track 2 data converted to ASCII.
2. For chip card data (contact or contactless) with Track 2 Equivalent Data (EMV tag T57 or equivalent) available and converted to

ASCII format, the data to be encrypted will be the ASCII data with a separator (‘=’ , hex 0x3D) inserted after the PAN if not
already present.
3. For manually captured cardholder data, the data to be encrypted will be the PAN followed by the expiration date (YYMM format)

in ASCII. After the data is encrypted, the ASCII character ‘M’ will be added to the beginning of the buffer, and a separator (“=”)
will be added at the location between the PAN and the expiry date.

The application responsible for decrypting this data will have to parse the data into its component encrypted PAN and
Expiry Date before handing off to the Decryption Appliance for decryption.
4. For chip card data (contact or contactless) with Track 2 Equivalent Data (EMV tag T57 or equivalent) not available, the data to be

encrypted will be the PAN. Once the PAN is encrypted, a separator (“=”) will be added after the PAN, followed by the encrypted
Application Expiration date in YYMM format (taken from EMV tag T5F24), followed by the encrypted Service Code (tag T5F30
).

3_6_9_4 New RBA Messages for On-Guard and KME Encryption
The following messages have been added to support On-Guard and KME encryption. Please note that some of these messages are subject
to change in the general-release version.
83.x On-Guard and KME Enable Message
85.x On-Guard and KME Non-Payment Card Message
86.x On-Guard and KME BIN Lookup (PIN Encouragement) Message
87.x On-Guard and KME Card Read Data
Other new message types have been implemented as part of On-Guard and KME encryption support. They will not be described in detail
here because they are not generally necessary for On-Guard use, and they are subject to change in the general-release version. These
include:
82.x On-Guard and KME Session Key Injection Command
88.x On-Guard and KME Translate Encrypted Card Data Command
89.x On-Guard and KME Register BIN Record Command
Additionally, the existing 31.x: PIN Entry Messages (On-Demand) has been modified to accommodate the E2EE encryption feature.

91/854 Telium RBA Developer's Guide/ August 18, 2015

3_6_9_5 Handling of Existing RBA Messages
Message Handling with E2EE Encryption Enabled
With E2EE enabled, a different set of messages will be used in place of existing RBA messages for certain functionality. As an expected
change to the general release, messages will be more consistent between E2EE and non-E2EE configurations. The following table
describes the alternate message process which occurs when E2EE is enabled.
Alternate Process for On-Guard E2EE
Message

When E2EE is Enabled

12.x: Account
Message

This message command is disabled and this message will be ignored.

18.x: Non-Payment
Card Message

The 85.x On-Guard and KME Non-Payment Card Message is sent in place of this message.

19.x: BIN Lookup

The 86.x On-Guard and KME BIN Lookup (PIN Encouragement) Message is sent in place of this message. A
19.x message from the POS will be ignored.

23.x: Card Read
Request (OnDemand)

The 87.x On-Guard and KME Card Read Data should be used in its place. The 23.x card read request message is
disabled and will return an invalid command response with the error code '9' (declined).

31.x PIN Entry Command Message in E2EE Mode
The customer account number is included in the 31.x: PIN Entry Messages (On-Demand). When E2EE encryption is enabled, the clear
text PAN is not available to the POS. It must instead supply the AES encrypted PAN in the Customer's Account Number field,and the key
type field must be set to "m" or "d".
The AES PAN is the result of the encryption of the card's PAN using an internally generated key. Accordingly, the 31.x message cannot be
used separately. The encrypted AES PAN value must be extracted from the encrypted data sent by the terminal. Refer to the 31.x: PIN
Entry Messages (On-Demand) section for a description of the 31.x message with E2EE incorporated.

3_6_9_6 MSR Encryption Example
In the following example, an MSR card is successfully read and card data is encrypted using On-Guard encryption. Refer to the following
image for the card used in this example.

92/854 Telium RBA Developer's Guide/ August 18, 2015

Example MSR Card
The following data will be returned in the 87.x On-Guard and KME Card Read Data:
Exit type = '0' indicating a good card read.
Card Data = ' 48473566921612108121614YOU/A GIFTFOR1
BFFFF98765432292000050114328438595666498708=00823303648413132DE47
E75CB39344F75AA4B82BDFF0AA2264683140DF3D6C473E2C74A7BE9B8B
59D5A11512B5361AB781A382B768E69BE9C02 '
FOR MSR and contactless MSD, the data in this example is formatted as follows:

MSR and Contactless MSD Data Format
With On-Guard encryption enabled, the following data is formatted as described in the below table for Data Sent with On-Guard
Encryption Enabled.
B FFFF98765432292000050114 32 8438595666498708=008233036484131 32 DE47E75CB39344
F75AA4B82BDFF0AA22 64 683140DF3D6C473E2C74A7BE9B8B59D5A11512B5361AB781A
382B768E69BE9C0 2
Data Sent with On-Guard Encryption Enabled

93/854 Telium RBA Developer's Guide/ August 18, 2015

Data

Value

Specifies IngeCrypt data format.

B

DUKPT Key Serial Number (KSN) +
custom field.

FFFF98765432292000050114

Decimal length of IC encrypted card data.

32

IC encrypted card data if reading is valid.

8438595666498708=008233036484131

Decimal length of AES encrypted PAN
field.

32

Decimal length of AES encrypted PAN
field.

DE47E75CB39344F75AA4B82BDFF0AA22

Decimal length of AES/TDES encrypted
card data field.

64

AES/TDES encrypted card data field.

683140DF3D6C473E2C74A7BE9B8B59D5A11512B5361AB781A382B768E69BE9C0

First digit of Track 2 card language
indicator.

2

3_6_9_7 E2EE Card Data Encryption
If E2EE encryption is enabled, the RBA application will encrypt the card data which in turn will be transmitted to the Host for decryption
and processing. The format of the Track 2 field in the 50.x: Authorization Request message will be modified. E2EE encrypted data will
replace the MSR data normally incorporated at offset 62 in the 50.x message. The encrypted card data will vary, depending on the card
entry mode. Refer to the following sections for more information.
MSR and Contactless MSD in E2EE Mode
Manual Card Data Entry in E2EE Mode
EMV Contact and Contactless in E2EE Mode

MSR and Contactless MSD in E2EE Mode
For MSR and contactless MSD, data will be formatted as follows:
MSR and Contactless MSD Format

94/854 Telium RBA Developer's Guide/ August 18, 2015

Data

Length

Type

Description

PAN, first 6 digits

6

ASCII

Clear value of the first 6 digits of the PAN.

PAN, last 4 digits

4

ASCII

Clear value of the last 4 digits of the PAN.

PAN length

2

ASCII

Decimal length of the PAN.

PAN Mod-10 check flag

1

ASCII

0 = PAN failed MOD 10 check.
1 = PAN passed MOD 10 check.

Expiry date (see Note 1)

4

ASCII

Clear value of the Track 2 expiry date (YYMM).

Service code (see Note 1)

3

ASCII

Clear value of the Track 2 service code.

Language code (see Note 1)

1

ASCII

Track 2 card language indicator.

Cardholder name length

2

ASCII

Decimal length of the cardholder name.

Cardholder name

n

ASCII

Clear value of the cardholder name.

Card Data Encrypted flag (see Note 2)

1

ASCII

0 = Clear ASCII data.
1 = Encrypted ASCII data.

Note 1
When Track 1 and Track 2 are requested with E2EE enabled, "Service code", "Language code", and "Expiry date" will be
filled out from Track 2 data only. If only Track 1 data is available, then these fields will contain only '0' values.

Note 2
When Track 1 and Track 2 or only Track 1 are requested with E2EE enabled, and only Track 1 is available, then the Card data
encrypted flag is set but the encrypted field lengths will be zero.

The remaining fields depend on the value of the Card Data Encrypted flag. If set to '0' for clear ASCII data, then the following fields will
be sent:
Remaining Fields with Card Data Encrypted Flag set to 0 for Clear ASCII Data

95/854 Telium RBA Developer's Guide/ August 18, 2015

Data

Length

Type

Description

Track 1 length

2

ASCII

Decimal length of ISO 1 field.

ISO 1 field

n

ASCII

ISO 1 track if reading is valid.

Track 2 length

2

ASCII

Decimal length of ISO 2 field.

ISO 2 field

n

ASCII

ISO 2 track if reading is valid.

Extended Language code

1

ASCII

First digit of Track 2 card language indicator.

If the Card Data Encrypted flag is set to '1', then the following fields will be sent:
Remaining Fields with Card Data Encrypted Flag set to 1
Data

Length

Type

Description

Encrypted Format Type

1

ASCII

IC KSN

24

ASCII

DUKPT Key Serial Number (KSN) + custom field.

IC card data length

2

ASCII

Decimal length of IC encrypted card data.

IC card data field

n

ASCII

IC encrypted card data if reading is valid.

AES PAN length

2

ASCII

Decimal length of AES encrypted PAN field.

AES PAN field

n

ASCII

AES encrypted PAN field if reading is valid.

LS Card data length

2

ASCII

Decimal length of AES/TDES encrypted card data field.

LS Card data field

n

ASCII

AES/TDES encrypted card data field.

Extended Language code

1

ASCII

First digit of Track 2 card language indicator.

B = IngeCrypt (IC) data format.

Manual Card Data Entry in E2EE Mode
For Manual card data entry, the data will be formatted as follows:
Manual Entry Data Format

96/854 Telium RBA Developer's Guide/ August 18, 2015

Data

Length

Type

Description

PAN, first 6 digits

6

ASCII

Clear value of the first 6 digits of the PAN.

PAN, last 4 digits

4

ASCII

Clear value of the last 4 digits of the PAN.

PAN length

2

ASCII

Decimal length of the PAN.

PAN Mod-10 check flag

1

ASCII

0 = PAN failed MOD 10 check.
1 = PAN passed MOD 10 check.

Expiry date

4

ASCII

Clear value of the expiry date (YYMM).

Service code

3

ASCII

'000'

Language code

1

ASCII

D'0'

Card Data Encrypted flag

1

ASCII

0 = Clear ASCII data.
1 = Encrypted data.

The remaining fields depend on the value of the Card Data Encrypted flag. If set to '0' for clear ASCII data, then the following fields will
be sent:
Manual Entry Remaining Fields with Card Data Encrypted Flag set to 0
Data

Length

Type

Description

Card data length

2

ASCII

Decimal length of the data field.

Card data field

n

ASCII

Data field.

Extended language code

1

ASCII

First digit of Track 2 card language indicator.

If the Card Data Encrypted flag is set to '1' then the following fields will be sent:
Manual Entry Remaining Fields with Card Data Encrypted Flag set to 1

97/854 Telium RBA Developer's Guide/ August 18, 2015

Data

Length

Type

Description

Encrypted Format Type

1

ASCII

'B' = IngeCrypt (IC) data format.

IC KSN

24

ASCII

DUKPT Key Serial Number (KSN) + custom field.

IC card data length

2

ASCII

Decimal length of IC encrypted card data.

IC card data field

n

ASCII

IC encrypted card data if reading is valid.

AES PAN length

2

ASCII

Decimal length of AES encrypted PAN field.

AES PAN field

n

ASCII

AES encrypted PAN field if reading is valid.

LS Card data length

2

ASCII

Decimal length of AES/TDES encrypted card data field.

LS Card data field

n

ASCII

AES/TDES encrypted card data.

Extended Language code

1

ASCII

First digit of Track 2 card language indicator.

EMV Contact and Contactless in E2EE Mode
When an EMV transaction is in process (contact or contactless), the EMV '33.03.x' Authorization Request Message will be used in place
of the 50.x Authorization Request message. In this message, the following tags will be substituted with encrypted values:
T5A (PAN)
T57 (Track 2 equivalent data)
Additionally, a new Ingenico-specific tag (TFF1D) will be added.
For the EMV '33.02.x' Track 2 Equivalent Data Message and EMV '33.05.x' Authorization Confirmation Response Message, the Track 2
value will be replaced by the encrypted value. There are currently multiple EMV library commands which return contact and contactless
Track 2 Equivalent Data (tag T57), PAN (tag T5A), and Expiry Date (tag T5F24) in the absence of tag T57. If E2EE encryption is
enabled and the BIN is not present in the validated BIN table, then the Track 2 data will be encrypted using the appropriate E2EE
encryption key. The EMV tag TFF1D for the E2EE Cryptogram will be created using the format outlined in the following table.
Creating Tag TFF1D

98/854 Telium RBA Developer's Guide/ August 18, 2015

Data

Length

Type

Notes

PAN, first 6 digits

6

ASCII

Clear value of the first 6 digits of the PAN.

PAN, last 4 digits

4

ASCII

Clear value of the last 4 digits of the PAN.

PAN length

2

ASCII

Decimal length of the PAN.

PAN Mod-10 check flag

1

ASCII

0 = PAN failed MOD 10 check.
1 = PAN passed MOD 10 check.

Expiry date (see Note 1)

4

ASCII

Clear value of the Track 2 expiry date (YYMM).

Service code (see Note 1)

3

ASCII

Clear value of the Track 2 service code.

Language code (see Note 1)

1

ASCII

Track 2 card language indicator.

Cardholder name length

2

ASCII

Decimal length of the cardholder name.

Cardholder name

n

ASCII

Clear value of the cardholder name.

Card Data Encrypted flag (see Note 2)

1

ASCII

0 = Clear ASCII data.
1 = Encrypted ASCII data.

Note 1
When Track 1 and Track 2 are requested with E2EE enabled, "Service code", "Language code", and "Expiry date" will be
filled out from Track 2 data only. If only Track 1 data is available, then these fields will contain only '0' values.

Note 2
When Track 1 and Track 2 or only Track 1 are requested with E2EE enabled, and only Track 1 is available, then the Card data
encrypted flag is set but the encrypted field lengths will be zero.

The remaining fields depend on the value of the Card Data Encrypted flag. If this flag is to '0' for clear ASCII data, then the following
fields will be sent:
Manual Entry Remaining Fields with Card Data Encrypted Flag set to 0

99/854 Telium RBA Developer's Guide/ August 18, 2015

Data

Length

Type

Notes

Track 1 length

2

ASCII

Decimal length of ISO 1 field.

ISO 1 field

n

ASCII

ISO 1 track if reading is valid.

Track 2 length

2

ASCII

Decimal length of ISO 2 field.

ISO 2 field

n

ASCII

ISO 2 track if reading is valid.

Extended Language code

1

ASCII

First digit of Track 2 card language indicator.

If the Card Data Encrypted flag is set to '1', then the following fields will be sent:Manual Entry Remaining Fields with Card Data
Encrypted Flag set to 1
Data

Length

Type

Notes

Encrypted Format Type

1

ASCII

B = IngeCrypt (IC) data format.

IC KSN

24

ASCII

DUKPT Key Serial Number (KSN) + custom field.

IC card data length

2

ASCII

Decimal length of IC encrypted card data.

IC card data field

n

ASCII

IC encrypted card data if reading is valid.

AES PAN length

2

ASCII

Decimal length of AES encrypted PAN field.

AES PAN field

n

ASCII

AES encrypted PAN field if reading is valid.

LS Card data length

2

ASCII

Decimal length of AES/TDES encrypted card data field.

LS Card data field

n

ASCII

AES/TDES encrypted card data field.

Extended Language code

1

ASCII

First digit of Track 2 card language indicator.

EMV Tags in E2EE Encryption Mode
When E2EE encryption is enabled, the following applies to EMV tags:
Tags affected by On-Guard E2EE

100/854 Telium RBA Developer's Guide/ August 18, 2015

Tag

Tag Name

With E2EE Encryption Enabled

TFF1D

Always included.

T57

Track 2 equivalent data

All zeros.

T5A

PAN

If present:
First 6 digits and last 4 digits will be in the clear.
All other digits will be masked with '0' if the PAN in tag 5A and tag 57 match.

T5F24

Expiry date

Returned in the clear.

T5F30

Service code

Returned in the clear.

T56

All zeros.

The output AES PAN cryptogram is limited to a clear PAN maximum of 30 digits.

3_6_10 RSA-OAEP and TransArmor Encryption
RSA-OAEP encryption is RSA public key encryption with a key length of 2048 bits, and OAEP padding. TransArmor encryption is a
special case of RSA-OAEP encryption, which uses the same encryption algorithm but differs in other details. The following section
applies to both encryption types unless noted otherwise.

See http://en.wikipedia.org/wiki/RSA_(algorithm) and ftp://ftp.rsasecurity.com/pub/rsalabs/rsa_algorithm/rsa-oaep_spec.pdf
for details of the algorithm.

The current Telium implementation can be used with MSR and contactless data. Using the 23.x message to request manually-entered card
data is also supported.
For both encryption types, the public key consists of a 2048-bit modulus and an exponent which is normally ‘010001’. These values need
to be configured in the security.dat section of config.dfs. The resulting security.dat file must be signed and downloaded
to the terminal to enable the encryption.

3_6_10_1 Configuration Parameters (in config.dfs)
The relevant parameters in config.dfs include the following:
Parameters for RSA and TransArmor Encryption
Parameter Name

DFS Data
Index

Default
Value

Description

101/854 Telium RBA Developer's Guide/ August 18, 2015

Parameter Name

DFS Data
Index

Default
Value

Description

Enable Encryption (in
security.dat)

0091_0001

0

Specify this value as '9' for RSA-OAEP, '10' for TransArmor.

Specify Encryption
Key Slot (Key Index)
(in security.dat)

0091_0002

6

RSA-OAEP/TransArmor ignores the value of this parameter. Encryption key
slots are not used.

Configure Leading
PAN Digits in the
Clear (in security.
dat)

0091_0003

6

RSA-OAEP/TransArmor ignores the value of this parameter. Specifies the
number of leading digits to be displayed in the clear (Maximum = 6).

Configure Trailing
PAN Digits in the
Clear (in security.
dat)

0091_0004

Masking the PAN (in
security.dat)

0091_0012

Public Key encoded in
Base64 (in
security.dat)

0091_0013

The default value of 6 is hardcoded for RSA-OAEP/TransArmor.

4

RSA-OAEP/TransArmor ignores the value of this parameter. Specifies the
number of trailing digits to be displayed in the clear (Maximum = 4).
The default value of '4' is hardcoded for RSA-OAEP/TransArmor.

0

RSA-OAEP/TransArmor ignores the value of this parameter.
Specifies the character to use for masking the PAN. The default value of '0'
(zero) is hardcoded for RSA-OAEP/TransArmor.

(392character
string)

Made up of a 2048-bit modulus and an exponent (normally ‘65537’).
See Web page links noted above for more information.
This Public Key should be encoded in ASN.1 Base64 format, which will result
in a 392-character string value for this parameter.

Exponent Value for
RSA-OAEP
/TransArmor (in
security.dat)

0091_0014

Key ID (in
security.dat)

0091_0015

Encryption Target (in
security.dat)

0091_0016

010001

Specify this value as the default value = 010001.

This overrides the exponent value from the public key in parameter
'0091_0013'. This value is in binary format and should generally be
set to the default (where 010001 = 65537), but may need to be
modified – check with your key authority if you are unsure.

12345678901

For TransArmor, the 11-byte Key ID corresponding to the Public Key.
Not needed for RSA-OAEP.

2

For TransArmor, set to 1 or 2 to indicate whether Track 1 or Track 2 data
should be used in the encrypted data block. Currently ignored for RSA-OAEP.
1 = Track 1
2 = Track 2 (Default)

102/854 Telium RBA Developer's Guide/ August 18, 2015

Parameter Name

DFS Data
Index

Default
Value

Description

Terminal ID (in
store.dat)

0004_0013

12345678

For TransArmor, the Terminal ID to be used in the encrypted data block. Must
be 8 digits or fewer. Currently not needed for RSA-OAEP.

Encryption or masking of cards with PANs containing less than 9 digits is not supported. Merchants should either whitelist
these cards or disable non-standard card encryption.

3_6_10_2 Encryption Data Returned to the POS
The encrypted data (2048 bits or 256 bytes) is returned in Track 3 to the POS. The encrypted data is Base64-encoded, resulting in a 344byte string.
For RSA-OAEP, the input to the encryption process consists of the concatenated raw Track 1, Track 2 and Track 3 data. If data is
manually entered, then the input is the account number, expiration date and CVV2.
For TransArmor encryption, the input consists of the Terminal ID (padded to 8 bytes with leading 0’s), followed by either the raw Track 1,
raw Track 2, or manually-entered PAN, depending on the data available for the current transaction. The Track 3 data sent to the POS
consists of three items separated by colons (“:”):
The 344-byte Base64 string of encrypted data.
One digit indicating which data is encrypted:
1 = Track 1.
2 = Track 2.
3 = PAN for manually-entered data.
Key ID from the security.dat file.
Example of Track 3 Data for TransArmor Encryption (where Track 2 data is encrypted with the Key ID of 12345678901):

h7S2Qv71zutAc/6my+V3XaKQv62sQowIhnv2yhogDKylNchR28kv26ZfRrQCqyTkne7nTFjxiES5j0n
FJRax3xhO0EKwlohpDikEi4roStHvF80sY9KwJ+5Ugu0XC+YfubQacSKtZ2ic5ATLwqo0WhNkjgTB
to0yZNhiDRVWok7LGNMx9plqOXlG5nvzONkzLak72hbxjRH452QYN+qC+XcJKgSsQdxziMhNSyg
dUY7HcfQ1KQ0gkkZtwz5Ei+HFrVPKhheAivhJkOwrBa6w6humyvg+2A1VATGIZUkgXwYqRxf0/1R
SSgH29lHUXxmCn/MAa2/Ui34diQUnaolMLg==:2:12345678901

Track 1 and Track 2 in the RBA messages will contain masked Track 1 and Track 2 data.

3_6_10_3 Manual Entry Transactions
Variable IDs 399 and 402 (Account Name) return "Manual Entry" for manual entry when TransArmor encryption is enabled.

103/854 Telium RBA Developer's Guide/ August 18, 2015

manualAccountName is replaced with 'msg23MsrName' in a 23.x message during an On Demand flow manual entry. Variable 399 then
returns "Manual Entry" in the 29.x message as shown in the table below.
TransArmor Manual Entry in On-Demand Flow Example
Step

Notes

Enable TransArmor encryption.
Enable '0007_0029'.

Set to any value '1' through '4'.

Send 23.x message while terminal displays a "Please slide card" form.
Press ENTER CARD button.
Enter PAN+Expiry Date+CVV value as per the '0007_0029' settings.
The terminal displays "card accepted" form and sends a 23.x response.
The POS prompts the terminal for variables with 29.x messages.

With RSA encryption enabled, or during a card swipe or contactless
transaction in a normal transaction flow (not On-Demand), the
'29.00000399' request would still return a card name in the response, e.
g., '29.20000399TESTCARD/TEST'.

Sample 29.x Requests and Responses
29.x
Request

29.x Response

29.00000398

29.200003984445220000000007

29.00000399

29.60000399Manual Entry

29.00000400

29.200004000000

3_6_11 S1 Encryption
3_6_11_1 S1 Encryption Overview
S1 encryption is a format-preserving encryption method implementing Authenticated Encryption Mechanism 5 in [ISO19772].

3_6_11_2 S1 Encryption Process
The following diagram illustrates the S1 P2PE encryption process.

104/854 Telium RBA Developer's Guide/ August 18, 2015

S1 Encryption Flow
This P2PE protocol provides data origin authentication on all encrypted messages transmitted from the terminal to the host. This is
implemented by appending a secure MAC (Message Authentication Code) to encrypted data sent to the host. Once this occurs, the host is
required to validate the secure MAC prior to initiating decryption.
Refer to the above diagram for the S1 Encryption Process. Once the initial card information has been read by the POS, the POS will query
the terminal for sensitive information. The terminal will then transfer two distinct encrypted data blocks to the POS, accompanied by a
sensitive data key block which specifies key attributes used by the host to identify or derive the decryption key. These encrypted data
blocks include PCI stipulations which are read by the POS and are used to determine if certain card information is to be preserved (e.g.,
full track or discretionary data), as sensitive card information is grouped into persistent and volatile data blocks. The terminal compares the
card BIN to a preloaded S1 whitelist to determine whether P2PE is mandated for the card type, and determines what obfuscation is to be
applied to unencrypted card information returned to the POS.

3_6_11_3 Configuration Parameters (in config.dfs)
There are several encryption-related parameters and parameter files in the Telium RBA Developer's Guide which are used to enable or
configure S1 P2PE encryption. Additionally, there are several other encryption-related parameters and parameter files used by other
encryption types that are not used for S1 P2PE. See the below diagram for a description of the relevant parameters for S1 encryption in
config.dfs:
Parameters used by S1 Encryption

105/854 Telium RBA Developer's Guide/ August 18, 2015

Parameter Name

DFS Data
Index

Default
Value

Enable Encryption (in
security.dat)

0091_0001

0

Specify Encryption Key Slot
(Key Index) (in security.
dat)

0091_0002

4

Description

Used to specify the terminal key slot containing the data DUKPT key to use
for S1 P2PE.
Valid values include 0 - 6.
Only slots 0 - 5 can be used.

Configure Leading PAN Digits
in the Clear (in security.
dat)

0091_0003

6

S1 defines its own obfuscation schemes, so it ignores the value of this
parameter.

Configure Trailing PAN Digits
in the Clear (in security.
dat)

0091_0004

4

S1 defines its own obfuscation schemes, so it ignores the value of this
parameter.

Masking the PAN (in
security.dat)

0091_0012

0

S1 defines its own obfuscation schemes, so it ignores the value of this
parameter.

Enable Security BIN Table (
secbin.dat)

0092_0001

0

For S1 encryption, set this value to 0 (zero, the default) to enable use of the
S1 Whitelist (instead of the SecBIN table).

Enable BIN range checking

0099_0001

0

Special note about BIN range checking and MOD-10:
S1 P2PE requires MOD-10 checking.
If '0099_0001' is set to a value of ‘0’ (zero = disables BIN range
checking), then the MOD-10 flag in '0100_0005' (for BIN0.DAT
file) must be set to ‘1’ (one).
If '0099_0001' is set to a value of ‘1’ (one = enables BIN range
checking), then the MOD-10 flag in each BINx.DAT file must also
be set to ‘1’ (one).

Encryption or masking of cards with PANs containing less than 9 digits is not supported. Merchants should either whitelist
these cards or disable non-standard card encryption.

3_6_11_4 S1 and MOD-10
S1 P2PE encryption requires Mod-10 checking. Refer to the Mod-10 Checking section for more information. Also refer to the "Enable
BIN Range Checking" parameter in the table for Card Transaction Codes in the BIN Processing (allBins.dat, bin0.dat - bin20.dat) section
for more information about enabling Mod-10.

106/854 Telium RBA Developer's Guide/ August 18, 2015

3_6_11_5 Load Whitelist
The S1 Whitelist is contained in an .XML file named S1LIST.XML. This file must be used when implementing S1 encryption. This .
XML file also contains all of the S1 P2PE whitelist data, but in a user friendly and modifiable format. The S1List.XML file must be
packaged and then signed by Ingenico before being loaded onto the terminal in the HOST directory. Loading may be performed using the
62.x: File Write message, LLT, or any of the other standard Ingenico terminal loading and updating methods.
Load this .PGZ file to the HOST as you would normally load other signed .PGZ files. From here, the .XML file will be unpacked
automatically to its secure location.

3_6_11_6 Card Swipes During the Standard Flow
Support for S1 encryption has been added for card swipes during the standard flow card swipe screen. Previously, only card swipes using
the 23.x: Card Read Request (On-Demand) message were allowed with S1 encryption selected. Card swipes performed from the standard
flow card swipe screen resulted in errors which prompted the terminal to go offline. With S1 encryption now supported in the standard
flow, this is no longer an issue and this action is no longer being processed as an error.

3_6_11_7 Working with Sensitive Data
After the card is read, a 23.x response message is sent to the POS. Sensitive data is stored and then transmitted in the Track 3 portion of
the 23.x response message. Elements of sensitive data are concatenated together, separated by ‘:’s (colons). If any Track 3 data exists on
the card, this data is obfuscated and then appended to the end of the sensitive data following a ‘:’ (colon).
Track 3 will be formatted as follows:
SensitiveDataKeyBlock:VolatileEncryptedSensitiveDataBlock:PersistedEncryptedSensitiveDataBlock:Obfuscatedtrack3DataFromCard
The sensitive data, as with any binary data sent in an RBA message, must be in hex-ASCII format in accordance with the RBA message
protocol.
If there is an error with the encryption and/or sensitive data, a '23.7' response message is returned to indicate that an encryption error has
occurred. If the card does not contain valid ISO4909 Track 2 data or if there is any other error in the track data that would prevent
encryption, then a '23.9' response message is returned. In both cases, a “card read error” message is displayed for a few seconds on the
terminal.

3_6_12 Voltage TEP1 and TEP2 Encryptions
3_6_12_1 Overview of Voltage TEP1 and TEP2 Encryption
Voltage TEP1 encryption is whole-track encryption, while TEP2 encryption is structure-preserving encryption. Refer to Configuration
Parameters (in config.dfs). There are several encryption-related parameters and parameter files in the Telium RBA which are used to
enable/configure Voltage P2PE. Additionally, there are several other encryption-related parameters and parameter files used by other
encryption types that are not used for Voltage P2PE.

3_6_12_2 PAN Encryption
When Voltage TEP2 encryption is enabled, the PAN must contain a minimum of 12 digits. Up to 6 leading digits as well as the last 4
digits will be preserved and sent in the clear. For PANs containing 14 or more digits, the number of encrypted digits will be the PAN
length less 10. As an example, a PAN containing 15 digits will have 5 digits encrypted. Similarly, a PAN containing 16 digits will have 6
digits encrypted. In all cases, a minimum of 4 digits including the Luhn value will be encrypted. PANs embedded in Track 1 and Track 2
data are processed similarly. The track embedded PAN length will be shorter than the original PAN length, but the leading and trailing
digits will be preserved. The Luhn check will generate the same result as the plaintext version. The additional track data is encrypted using
Base64 alphabet and is stored in the discretionary data field with the ciphertext of the original discretionary data value.

107/854 Telium RBA Developer's Guide/ August 18, 2015

When using Voltage TEP1 encryption, the Base64 character set is used and the Luhn value is disregarded. All digits in the PAN are
encrypted. The PAN length will be a minimum of 12 digits, and can be as long as the original unencrypted PAN. When performing manual
entry, the encrypted PAN included in the 50.x: Authorization Request message will always be the same length as the PAN entered using
the terminal keypad. The following tables summarize Voltage TEP1 and TEP2 encryption of the PAN for a swiped card.
Voltage TEP1 Encryption of PAN for Swiped Card
Message Type

After Voltage TEP2 Encryption

19.x: BIN Lookup

All digits of the PAN are encrypted.
The encrypted PAN length included in the message is longer than the original
PAN length.

23.x: Card Read Request (On-Demand)

All digits of the PAN are encrypted.

29.x: Get Variable Request

All digits of the PAN are encrypted.

50.x: Authorization Request

All digits of the PAN are encrypted.

Voltage TEP2 Encryption of PAN for Swiped Card

108/854 Telium RBA Developer's Guide/ August 18, 2015

Message Type

After Voltage TEP2 Encryption

19.x: BIN Lookup

The encrypted PAN length included in the message is less
than the original
PAN length.

PAN Before and After
Encryption
5444009999222205
544400 806 2205

The first 6 and the last 4 digits of the PAN are sent in the
clear.
The remaining middle digits of the PAN are encrypted.
23.x: Card Read Request (OnDemand)

The encrypted PAN length included in the message is less
than the original
PAN length.

5444009999222205
544400 806 2205

The first 6 and the last 4 digits of the PAN are sent in the
clear.
The remaining middle digits of the PAN are encrypted.
29.x: Get Variable Request

The PAN length is preserved, all digits are included in the
message.

5444009999222205
544400 411407 2205

The first 6 and the last 4 digits of the PAN are sent in the
clear.
The remaining middle digits of the PAN are encrypted.
50.x: Authorization Request

The encrypted PAN length included in the message is less
than the original
PAN length.

5444009999222205
544400 806 2205

The first 6 and the last 4 digits of the PAN are sent in the
clear.
The remaining middle digits of the PAN are encrypted.

Refer to Voltage TEP1 and TEP2 Encryption Examples for examples of TEP1 and TEP2 encryption. Also refer to the following table
which describes the relevant parameters for Voltage Tep1 and TEP2 in the config.dfs file.

Relevant Parameters for Voltage TEP1 and TEP2 in config.dfs
Parameter Name

DFS Data
Index

Default
Value

Description

109/854 Telium RBA Developer's Guide/ August 18, 2015

Parameter Name

DFS Data
Index

Default
Value

Description

Enable Encryption (in
security.dat)

0091_0001

0

Specify this value as:
'4' for Voltage TEP1.
'5' for Voltage TEP2.

Max Number of
Transactions with Same
Key (in security.dat)

0091_0005

0

Maximum number of transactions with the same key.
0 = Don’t change keys based on transaction count.
1 - 65000 = Change key after this many transactions with the same
key.

Periodically Change Keys
(in security.dat)
aaaaaaaaaaaaaaaaaaa

0091_0006

0

Periodically change keys (Requires setting the terminal’s date and time).
All letters must be entered in UPPER CASE.
0 = Disabled.
D = Daily.
SU = Change every Sunday.
MO = Change every Monday.
TU = Change every Tuesday.
WE = Change every Wednesday.
TH = Change every Thursday.
FR = Change every Friday.
SA = Change every Saturday.
01-31 = Change on the XXth day of the month.

Preserve Keys During
Power Failure (in
security.dat)

0091_0007

0

Preserve keys during power failure.
0 = A new key is generated at power up.
1 = Keys are saved when generated and restored at power up.

110/854 Telium RBA Developer's Guide/ August 18, 2015

Parameter Name

DFS Data
Index

Default
Value

Description

Append ETB to 50.x:
Authorization Request (in
security.dat)

0091_0008

0

Append ETB to 50.x Authorization Request Message. An ETB is created
when a new key is created.
0 = Do not append.
1 = Append.
Format is:


Where:
 = start sentinel ";"
 = Track 3 as read from card (could be
empty)
 = record separator 0x1E
 = Voltage encrypted and base64 encoded
(empty for manual entry)
 = Voltage encrypted and base64 encoded (as
described in section 4.3.2 for manual entry)
 = Voltage encrypted primary account number
base64 encoded
 = Voltage ETB base64 encoded (this is optional based on
0091_0008)
 = end sentinel "?"

Identity String (in
security.dat)

0091_0009

id@sample.
com

Identity String, provided by authorizer.
"id@sample.com” is sample data – not for production.

Identity State (in
security.dat)

0091_0010

*

Identity State.
Use format mmddyyyy.
If set to '*' the terminal’s current date will be used. Be sure to set
the date and time via the 28.x: Set Variable Request.

111/854 Telium RBA Developer's Guide/ August 18, 2015

Parameter Name

DFS Data
Index

Parameter Data Encoded in
base64 (in security.
dat)

0091_0011

Default
Value

Description

Sample data – not for production. Actual data must be obtained from your
authorizer.

AkkI5lUTQBRABHW+Q8WeFmGOQOXIe6Av2WvRhsSVLm1BWK
za4u/1JCnS6dPW5L
1pC8xd6H
/7Uc0vAWh8Na07Ge5lsfCW3wbPRDouotjVd7QJoODLqe1C
GQpNJSN/
Wbx5j3E5iYnWuEhSifDqy9M2zZzXWAHdzd6vkRrFkLRyav
YGUsaJa4fzg1y/BE
OYWaURa9I4uUD0exrG4VWrRdQ5GWJGQ3oNQC
/U9Bd6FaOxfnAKttNGiidLN5mN
B6ZxjuBGMY8jM3WxJKvmceyyIW18t4ddUILrTptQ2ZU1Bk
oZjlbJvLuggdGv2l
DZP4CMtznrvC0c5II8QaoRD7+fIpfYZZR+789TqSo3YeI5
BB5rdv9iR/ul0ct/
+DOUJSUERhVjTps2N5sJ5BX4OJy3dnD
/BDiLulQK2VBLtiJ1QNJyPmfZPUBGT5
xGlMrbXw4e5WX87bmc9jAkXjZkgoP5pJxm
/MXuD1vtCcNVCrFnZ/Qi/5SI/PEv
xxYnZkfCfzWGJM
/PgwA1L2T3VFBfTQeTBLBLTV8us5rsGUce
/nyzuDs4ZFRbOe
qVcWEdrnZT
/GWSUC97YA0AFsxT6GkbFR1qv7OAPIzeyw1W6WpciGC4bg
ATdeIx
SD76mm+kPy4DwckTFdVKiDdo4N6rIBUjph1eV5
/StpNXQ4vmwTMhbo2v9b+5Wg
cGboiWcAcc8AiuDzeYxZL2iJUY077U3dYKpTsYLZuWaLFY
iLuwgdBQ+lsZrTYx
PEjx/bp4JHvxMl8tBtU5l3DRj0rk4H7H/syGDtb7z/////
/////////v//////
//////fPmI+YrYeuVmH8NJpSgBYtALj7Vu2ypnWI65c0CP
ZRCWlYxkCtTybOIG
ej5cYKTxLFyP12yWn017VRN+NBnozJlF6nMoOEw+GWdSzo
7kpi+Et8Yyt0LEA+
BPu7vGvUFUmD67v21PL7i+UYjHMN7erBhbGIB+e8ywafDB
EQqaIOFza3libHVl
LnZvbHRhZ2UuY29t

Masking Character

0091_0012

0

Character to use for masking.
For '0091_0012', only '0' and '*' are valid.

112/854 Telium RBA Developer's Guide/ August 18, 2015

Parameter Name

DFS Data
Index

Parameter Data Encoded in
TransArmor Key.

0091_0013

Default
Value

Description

Parameter data encoded in base64 TransArmor key. Sample data:

MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvy
YRQA3cS4wV9yk+6b
FzA7KLDmE+D
/SOP+Q5bNOPG9nUDkAPalRBz12KA5SDxTw2vO1BIeSFUQl
YTpzE
Db/XkfNNm5e6nqf12M4kdHP1F2EXW4WArilUZegAVw
/Y7FvAkA8PQFbfgmBirS
a5GS
/fuAHjemqEf0DxIgq552IDeFw3nB0vccK6ePue5sVB9Sm2
vWpKm/lj2UE4
P6z2ngZr5V31cSAVN08USxHvz+MEnoUBKt6aKvfRUAp4iF
yIpxlp4eylxY8ziz
PekS29lcRMsI9hGug2CoKFhhUJ1gD8G280zIoWCxysNvl4
0k/l8OTtPKrnlhAz
QcIyy/RB0lwb6QIDBlU1

Exponent for TransArmor

0091_0014

010001

Exponent for TransArmor.
This value in binary is equivalent to '65537'.
Do not change this value.

Map to Public Key

0091_0015

12345678901

This is the map to the Public key.
Length should be 11 bytes.

Track 1 or Track 2
Selection for TransArmor
Encrypted Data Block

0091_0016

2

For TransArmor, this value sets the encryption target as Track 1 or Track
2.
1 = Encryption target is Track 1.
2 = Encryption target is Track 2.
Track 2 should be used in the encrypted data block.

Length of Encrypted CVV
in Voltage Encryption

0091_0017

8

For Voltage encryption, this is the length of the encrypted CVV. This is
used for manual entry only.
Valid lengths are 7 - 23.

Terminal Communication
Authentication Selection

0091_0018

0

Terminal communication authentication selection, '93.' Challenge
/Response message authentication.
0 = Disabled - no additional application-layer authentication.
1 = On-connection - authentication required after terminal
connects (e.g., Bluetooth connect signal/event).

113/854 Telium RBA Developer's Guide/ August 18, 2015

Parameter Name

DFS Data
Index

Default
Value

Description

Length of encrypted CVV
returned by Voltage (in
security.dat)

0091_0017

8

This parameter is for use with Voltage P2PE types, only. Defines the
length of the encrypted CVV returned by Voltage encryption (both TEP1
and TEP2). Used only for manual entry. Valid lengths are 7 – 23 digits.
If an invalid length is assigned (e.g., a length of 54), the length will
default back to the default of 8 digits.

Terminal Communication
Authentication

0091_0018

0

Terminal communication authentication selection. See section 93.x:
Terminal Authentication Messages.
0 = Disabled, no additional application-layer authentication.
1 = On-connection, authentication required after the terminal
connects (e.g., Bluetooth connect signal/event).

Encryption or masking of cards with PANs containing less than 9 digits is not supported. Merchants should either whitelist
these cards or disable non-standard card encryption.

3_6_12_3 Obsolete Voltage Parameters
The Voltage parameters outlined in the table, below, have been redefined with new DFS Data Indices and reside in secbin.dat.
Parameter Name

Obsolete DFS Data
Index

Obsolete Default
Value

NEW DFS Data Index

NEW Default
Value

Identity String

0091_0001

id@sample.com

'0091_0009' (in secbin.dat file)

id@sample.com
(no change)

Identity Date

0091_0002

*

'0091_0010' (in secbin.dat
file)

* (no change)

Parameter data encoded in
base64

0091_0003

(n/a)

'0091_0011' (in secbin.dat
file)

(n/a)

3_6_12_4 PAN Encryption
Voltage encryption now handles account messages containing only the PAN. The PAN is always encrypted, regardless of whether or not
expiry date and CVV are also included in the message. Refer to the following Voltage TEP1 Encryption Examples table and Voltage TEP2
Encryption Examples table.

114/854 Telium RBA Developer's Guide/ August 18, 2015

3_6_12_5 Voltage TEP1 and TEP2 Encryption Examples
Voltage Encryption Examples
Depending on the message used to view the encrypted card data, a variety of leading- and ending-digits will be in the clear and/or portions
of the card data will be encrypted when using Voltage TEP1 or TEP2 encryption types.

Remember that to enable the 19.x (BIN Lookup) message for use with either TEP1 or TEP2 encryption types, the following
parameters must be set: '0005_0002' = ‘1’ or ‘2’, and '0005_0004' = ‘1’.

Voltage TEP1 Encryption Examples
The following table illustrates examples of Voltage TEP1 encryption.
Voltage TEP1 Encryption Examples

115/854 Telium RBA Developer's Guide/ August 18, 2015

Content/Parameter

Example Value

Security Parameter Setting

Parameter '0091_0001' in the security.dat configuration file is set to '4' for Voltage
TEP2.

Card in Clear

4077140046854992

PAN Encryption

+++++++Ab/KESest

Track 1 Encrypted Data

qrZ7cYgqSxh/LgKCEId4EqkL4bLOP+CjpFY6qlb/mdibwen0oeVDIZoISWUro+15

Track 2 Encrypted Data

AFdnvAz0VP2kIFHCt/wX+vikfpg

23.x: Card Read Request (On-Demand)

23.0I3yA1C2FsGSrt5UU8tKoaJiqFosOulZQ1yuXO+gbywafLVwhNuPeiLznET9Os
W8zwzfIeSDOV6p[FS]

PAN Only Sent in 12.x Account Message

PAN in clear = 4012345678909
12.4012345678909
50.12345678901234567890123456789012345678900208020453600001@A401234
5678909[FS]1@[FS]12345[FS]

Note that the PAN is sent in the clear when only the PAN is included in the
12.x Account message.

PAN + Expiry Date Sent in 12.x Account
Message

PAN in clear = 4012345678909
12.4012345678909=1212
50.12345678901234567890123456789012345678900208020453600002@ T+++++/
IakLV2q =1212[FS]1@[FS]3523[FS]

PAN + Expiry Date + CVV Sent in 12.x
Account Message

PAN in clear = 4012345678909
12.4012345678909=1212=333
50.12345678901234567890123456789012345678900208020453600003@ A1LSak
AaNvUH2WG9eX+CPAED4Zaf[FS]1@[FS]12345[FS]

The following examples illustrate swiped card PAN encryptions viewed using various messages when encrypted with Voltage TEP1.
Voltage TEP1 Card Swipe PAN Encryption Examples

116/854 Telium RBA Developer's Guide/ August 18, 2015

Message

PAN

Encrypted/Masked PAN

19.x: BIN Lookup

5444009999222205

Encrypted Track 1: wHcwtWNPmagNhPLrAuITygvL0dbplOGHRKhEUj/
SqdO6JSlRh7Cd
6biblSPn
Encrypted Track 2: 8Pun/4ZxdghAfy0rnjVWXhzk4ye
All digits of the PAN are encrypted.
More than 16 digits/characters are displayed.

23.x: Card Read Request
(On-Demand)

341111597242000

29.x: Get Variable Request

341111597242000

++++++/85P8N0ru
All 15 digits of the PAN are encrypted.
++++++/85P8N0ru
All 15 digits of the PAN are encrypted.

50.x: Authorization
Request

341111597242000

50.12345678901234567890123456789012345678900202016846600002@D
/u2vCFy3nvM/zxim FEeA9CZAqYD[FS]1@[FS]1025[FS]
All 15 digits of the PAN are encrypted.

With Voltage TEP1 encryption, the encrypted portion of the data is always unreadable.

Voltage TEP2 Encryption Examples
The following table illustrates examples of Voltage TEP2 encryption. With Voltage TEP2 encryption, the first 6 and the last 4 digits are
always in the clear, and the remaining middle digits are always numerically encrypted.
Voltage TEP2 Encryption Examples

117/854 Telium RBA Developer's Guide/ August 18, 2015

Content/Parameter

Description

Security Parameter Setting

Parameter '0091_0001' in the security.dat configuration file is set to '5' for Voltage TEP2.

Card in Clear

4077140046854992

PAN Encryption

407714 742987 4992
The middle 6 digits are encrypted.

Track 1 Encrypted Data

B4077141064992^YOU/A GIFT FOR^2106521Z8enOVxOyfA4ryC31EpKp5haA0h

Track 2 Encrypted Data

4077141064992=2106521T25N21u/dXMR9dcU

23.x: Card Read Request (On-Demand)

23.0B4077141064992^YOU/A GIFT FOR^2106521Z8enOVxOyfA4ryC31EpKp5haA0h
[FS]4077141064992=2106521T25N21u/dXMR9dcU

PAN Only Sent in 12.x Account
Message

PAN in clear = 4012345678909
12.4012345678909
50.12345678901234567890123456789012345678900207012689400001@A4012345678909
[FS]1@[FS]
18250[FS]

Note that the PAN is sent in the clear when only the PAN is included in the 12.x
Account message.

PAN + Expiry Date Sent in 12.x
Account Message

PAN in clear = 4012345678909
12.4012345678909=1212
50.12345678901234567890123456789012345678900207012689400003@T40123 1639
8909=1212[FS]
1@[FS]18250[FS]

PAN + Expiry Date + CVV Sent in 12.x
Account Message

PAN in clear = 4012345678909
12.4012345678909=1212
50.12345678901234567890123456789012345678900207012689400003@T40123 1639
8909=1212[FS]
1@[FS]18250[FS]

The following examples illustrate swiped card PAN encryptions viewed using various messages when encrypted with Voltage TEP2.
Voltage TEP2 Card Swipe PAN Encryption Examples

118/854 Telium RBA Developer's Guide/ August 18, 2015

Message

PAN

Encrypted/Masked PAN

19.x: BIN Lookup

5444009999222205

544400 806 2205
Only 13 of 16 digits are displayed.
The first 6 and the last 4 digits are in the clear; the 3 middle digits
are encrypted.

23.x: Card Read Request (OnDemand)

5444009999222205

544400 806 2205
Only 13 of 16 digits are displayed.
The first 6 and the last 4 digits are in the clear; the 3 middle digits
are encrypted.

29.x: Get Variable Request

5444009999222205

544400 411407 2205
All 16 digits are displayed.
The first 6 and the last 4 digits are in the clear; the middle 6 digits
are encrypted.

50.x: Authorization Request

5444009999222205

544400 806 2205
Only 13 of 16 digits are displayed.
The first 6 and the last 4 digits are in the clear; the 3 middle digits
are encrypted.

The encrypted portion of the TEP2 data is always numeric.

Manual Entry
Voltage encryption will encrypt in the same format for any manual entry whether parameter '0007_0029' (Display "Enter Card" Prompt) is
set to '1', '2', '3', or '4'. The only changes are what information is appended after the PAN, if any (the '0007_0029' setting determines
whether a customer is prompted for CVV and/or expiration date). The manual entry process is illustrated in the table below, using TEP2
encryption for the examples:
Voltage TEP2 Manual Entry Details

119/854 Telium RBA Developer's Guide/ August 18, 2015

0007_0029 Information
Value
Prompted
'1'

PAN , expiration
date , and CVV .

Input Example

4445222299990007
1512
123

Messages Sent with Data Encrypted

23.0[FS]
4445228903600007=1512=10571712
50.12345678901234567890123456789012345
678900208034438800009@T444522890360000
7=1512=10571712[FS]1@[FS]100[FS]

'2'

PAN and expiration
date .

60110000901023171

23.0[FS]60110000901023171=1512

1512

50.12345678901234567890123456789012345
678900208034438800009@T444522890360000
7=1512[FS]1@[FS]100[FS]

'3'

PAN and CVV .

60110000901023171

23.0[FS]4445228903600007==99236979

369

50.12345678901234567890123456789012345
678900208034438800009@T444522890360000
7==10571712[FS]1@[FS]100[FS]

'4'

PAN only.

60110000901023171

23.0[FS]4445228903600007
50.12345678901234567890123456789012345
678900208034438800009@T444522890360000
7[FS]1@[FS]100[FS]

Variable IDs 399 and 402 (Account Name) return "Manual Entry" for manual entry when Voltage encryption is enabled.
manualAccountName is replaced with 'msg23MsrName' in a 23.x message during an On Demand flow manual entry. Variable 399 then
returns "Manual Entry" in the 29.x message as shown in the table below.
Voltage Manual Entry in On-Demand Flow Example

120/854 Telium RBA Developer's Guide/ August 18, 2015

Step

Notes

Enable TransArmor encryption.
Enable '0007_0029'.

Set to any value '1' through '4'.

Send 23.x message while terminal displays a "Please slide card" form.
Press ENTER CARD button.
Enter PAN+Expiry Date+CVV value as per the '0007_0029' settings.
The terminal displays "card accepted" form and sends a 23.x response.
The POS prompts the terminal for variables with 29.x messages.

During a card swipe or contactless transaction in a normal transaction
flow (not On-Demand), the '29.00000399' request would still return a
card name in the response, e.g., '29.20000399TESTCARD/TEST'.

Sample 29.x Requests and Responses
29.x
Request

29.x Response

29.00000398

29.200003984445220000000007

29.00000400

29.200004000000

29.00000399

29.60000399Manual Entry

3_6_13 MSR Encryption Processing
When MSR encryption is enabled, card data for swiped, manual, and contactless transactions is encrypted immediately after being
captured. In the case of keyed transactions, RBA saves the keyed information as Track 2 data before processing. Track 1, Track 2, and
manually entered data are all encrypted using a TDES DUKPT algorithm.
If BIN range checking is enabled, specific card types can be included/excluded from encryption using the corresponding flag for each BIN
range.
To set up this process, Security BIN (secbin.dat) parameter '0092_0001' should be set to '1' (enabling security bin table checking). Also,
parameters '0092_0002' through '0092_0030' should be modified as needed for inclusion/exclusion of card types and BIN ranges.
The “Spin-the-Bin” process works as usual, except that the account number in the 19.x response will have the proper length, but only the
first few digits will be correct. config.dfs parameter '0005_0008' sets the number of digits.
If MSR encryption is attempted and the operation fails, RBA shuts down and the terminal goes offline.
The following table shows EPS encrypted examples of Track 1, Track 2, and manually entered data:
Encrypting Sample Data with EPS

121/854 Telium RBA Developer's Guide/ August 18, 2015

Track

Type

Example

Track 1

Original

%B4447340101127648^VISACARDHOLDER/^1209121000000678000000?

Encrypted
Track 1

5D97BDCBC8F9E12F4C99D502FB9B30E7715DBC0C8D64C27BE868554F24F176733C37

KSN

A08B000C000003000023

Original

4447340101127648=12091210000067800000?

Encrypted
Track 2

CEAFC2FD0BA3E76E0C062DD2DD4196E111A71424C52561E943142AD271FC0D86C45C

KSN

A08B000C000003000024

Original Track
1 Data

%M4744750029324780^MANUAL ENTRY/^1306000000123000000?

Track 2

Manually
Entered

Encrypted
Track 1 Data

Original Track
2 Data

98B9676A7D68A0F3BFF8256E484AB65A88B4B2C4AB50DFA60B09585B9D57

C365B8D7E292

Track 1 is not supported when performing manual entry for EPS encryption. It will remain
blank for the manual entry transaction.

4744750029324780=1306=123

“123” within the Track 2 data in this example represents the CVV.

Encrypted
Track 2 Data

5EFDACAD0F0B6997EC120D2AE568EDD504A50214F8871E6C43D3A4CFDC30D4BC:

KSN

FFFF9876543210E00003

FFFF9876543210E00003

Contactless track data will be read as Track 2.
By default, the first six digits and the last four digits of card numbers will be listed in the clear when encryption is enabled. To modify
these settings, parameters '0091_0003' (unmasked leading digits) and '0091_0004' (unmasked trailing digits) can be changed.
This does not apply to Magtek or Mercury encryption. Magtek requires that the first six digits and last four digits be listed in the clear.
Mercury uses its own masking convention.

122/854 Telium RBA Developer's Guide/ August 18, 2015

Encryption or masking of cards with PANs containing less than 9 digits is not supported. Merchants should either whitelist
these cards or disable non-standard card encryption.

3_6_14 MSR Encryption Data Variables
After the RBA processes a 23.x: Card Read Request/Response message exchange involving MSR encrypted data, three system variables
are populated with transaction data:
Variable 398 – when the setting of '0091_0012' designates a valid encryption type, the Account Number from the previous 23.x
card read will be returned. Some of the digits will be masked/encrypted based on the '0091_0003' and '0091_0004' settings.
Variable 399 – contains the Account Name in the clear.
Variable 400 – contains the Account Expiration Date in the clear.
Data stored in each of these variables can be retrieved using the 29.x: Get Variable Request.

3_6_15 Retrieving MSR information using the 29.x (Get Variable) Message
The 29.x: Get Variable Request message can be used to retrieve the following pieces of information:
Using the 29.x Message to Retrieve MSR Data
Information Type

Variable

Description

123/854 Telium RBA Developer's Guide/ August 18, 2015

Information Type

Variable

Description

Card Data
Encryption Status for
Card Request
Message

395

Card data encryption status for the 23.x: Card Read Request (On-Demand) message.
0 = Card data not encrypted.
1 = Magtek Encryption
2 = On-Guard Encryption Configuration
3 = EPS (Element Payment Systems) Encryption
4 = Voltage TEP1 Encryption
5 = Voltage TEP2 Encryption
6 = Voltage TEP3 Encryption (not currently supported).
7 = Monetra CardShield Encryption
8 = Mercury Encryption
9 = RSA-OAEP Encryption
10 = TransArmor Encryption
11 = Generic TDES DUKPT Encryption
12 = S1 Encryption

Possible reasons for card data not being encrypted include:
P2P encryption not configured.
Card not found on whitelist.
The card is a nonstandard card which should not be encrypted.

Mod-10 check value

396

Card Read Transaction Flow MOD-10 check value.

MOD-10 check
value

397

Card read on-demand calculated MOD-10 check value (23.x message). Available for use with all
encryption types, but used with S1 only at this time.

Masked PAN (with
first 6 and last 4
digits in the clear)

398

Used to hold the masked PAN for cards read from the "card read request" form.

401

Used to hold the masked PAN for cards read the "swipe" form.

Name

399

Used to hold the name for cards read from the "card read request" form.

402

Used to hold the name for cards read from the "swipe" form.

400

Used to hold the expiration date for cards read from the "card read request" form.

403

Used to hold the expiration date for cards read from the "swipe" form.

Expiration Date

124/854 Telium RBA Developer's Guide/ August 18, 2015

Information Type

Variable

Description

Service Code

413

New service code which is used to determine whether or not the swiped card is an EMV card. This
variable is always available for card type verification whether EPS encryption is enabled or not.
The service code will typically have a value of '101' or '201'. The POS should check this service
code when the card is swiped. If the swiped card is an EMV card then the cardholder will be
prompted to insert the card in the payment terminal chip card reader.

Card Data
Encryption Status for
Standard Flow

414

Card data encryption status for the standard flow.
0 = Card data not encrypted.
1 = Magtek Encryption
2 = On-Guard Encryption Configuration
3 = EPS (Element Payment Systems) Encryption
4 = Voltage TEP1 Encryption
5 = Voltage TEP2 Encryption
6 = Voltage TEP3 Encryption (not currently supported).
7 = Monetra CardShield Encryption
8 = Mercury Encryption
9 = RSA-OAEP Encryption
10 = TransArmor Encryption
11 = Generic TDES DUKPT Encryption
12 = S1 Encryption

Possible reasons for card data not being encrypted include:
P2P encryption not configured, or configured incorrectly.
Card not found on whitelist.
The card is a nonstandard card which should not be encrypted.

Track 1

406

Used to retrieve masked Track 1 data.

Track 2

407

Used to retrieve masked Track 2 data.

Track 3

411

Used to retrieve Track 3 data.

3_6_16 Requesting the PIN Block Using the Masked PAN
A PIN block may be requested using a masked PAN. This is because the terminal stores the account number and keeps a record of the
masked PAN that it sends to the POS.

125/854 Telium RBA Developer's Guide/ August 18, 2015

First, the POS sends the 31.x PIN Request message with the PAN masked.
The terminal will then compare the masked PAN that it sent to the POS to the masked PAN which you are telling it to encrypt the
PIN block with. One of the following will happen:
If the two masked PANs match, the terminal will use the account number to encrypt the PIN block
-orIf the PANs do not match, the terminal will encrypt the PIN block with the masked PAN coming from the POS which will
result in a failed decryption.

3_6_17 Mod-10 Checking
The Mod-10 (Luhn) formula is used to verify the account number (PAN) using a check digit. The check digit verifier is included in the
RBA application to identify PANs that are incorrectly entered (miskeyed), allowing the application to prompt for re-entry of the PAN.
This is very important in the case of network-down situations, wherein the POS logic stands in for the authorization and forwards the
account information upon network return.
The Mod-10 calculation will occur regardless of any configuration parameter settings. Specific Mod-10 BIN settings only determine
whether cards with invalid Mod-10 check digits are accepted or rejected (such as in the case where the last digit of PAN does not match
the Mod-10 calculation). If DFS data index '0099_0001' is set to a value of ‘1’ (to enable BIN range checking), the MOD-10 flag in each
“BINx.DAT” file must be set to a value of ‘1’. Currently, the MOD-10 calculation is the only supported card status validation check.
The following Mod-10 check digit variables are always updated:
Variable number 396 (Card Read Transaction Flow MOD-10 check value).
Variable number 397 (Card Read On-Demand calculated MOD-10 check value, 23.x: Card Read Request (On-Demand)).

Refer to the Card Transaction Codes table in BIN Processing (allBins.dat, bin0.dat - bin20.dat) for information about enabling
Mod-10.

3_6_18 Loading Key Serial Number (KSN) Data
Before MSR Encryption processing can begin, the terminal needs to be loaded with keys (also known as key injection). During the loading
process, an administrator injects key serial number (KSN) data into the terminal. Not all encryption types (such as Voltage) require key
injection.

Terminal KSN data is visible next to KSN indexes 0 and 6 in the terminal’s TSA application. See your terminal’s Operations
Guide for information on accessing terminal applications other than RBA.

3_6_19 Selecting Specific Cards to be Encrypted
By default, MSR encryption encrypts all cards. To specify only certain types of cards to be encrypted, configure the Security BIN (secbin.
dat) file for the appropriate bin ranges. See RSA-OAEP and TransArmor Encryption for additional information specific to those
encryption types.

126/854 Telium RBA Developer's Guide/ August 18, 2015

3_6_20 Signing Requirements for .DAT File Changes
If your organization requires changes to the security.dat and/or secbin.dat files, you must follow the procedure outlined in this
section. Changes to these .DAT files require specific Ingenico signature and approval prior to your implementation.
Security.dat - Security parameters. These parameters must be signed and cannot be changed by messages. See section
Security Parameters (security.dat)for parameter details.
Secbin.dat - Security BIN table. These parameters must be signed and cannot be changed by messages. See also RSA-OAEP
and TransArmor Encryption for additional information specific to RSA-OAEP and TransArmor encryption types. Security BIN
(secbin.dat) for parameter details.
After approval and signature of any changes to your security.dat and/or secbin.dat files, you will receive a new .PGZ file from
Ingenico. You will be unable to implement your changes to the security.dat and secbin.datfiles without a signed .PGZ file from
Ingenico. If you implement your changes prior to receipt of the new .PGZ file, your Telium terminals may appear to run properly,
however, your terminals will actually be running as previously configured, without your changes. See the process diagram on the
following page for approval process information.

All parameters except for those located in the security.dat and secbin.dat files may be changed using the 60.x:
Configuration Write Message.

Contact your Ingenico Account Manager with any questions you may have about the signing process.

127/854 Telium RBA Developer's Guide/ August 18, 2015

MSR Encryption Configuration Process

128/854 Telium RBA Developer's Guide/ August 18, 2015

3_7 Call Scheduling
Call Scheduling will be used to download or upgrade firmware and data files at specific dates and times. Refer to the Call Scheduling
section in the Telium Download User's and Developer's Guide for more information.

3_8 Contactless Key Card Support
3_8_1 Introduction to Contactless Key Card Support
This section describes the implementation of Contactless Key Card support for Telium Retail Base Applications (RBA). Low-level
Contactless Key Card support for Telium RBA is provided by a common Telium application layer called GRAF through newly added
Application Interfaces (APIs). Telium RBA uses these APIs to service Contactless Key Card communications with the Point-Of-Sale
(POS). The GRAF APIs are transparent to the POS which only processes RBA messages.
As of this time, the following card types are supported:
MIFARE Classic 1K
MIFARE Ultralight
MIFARE Mini
MIFARE Classic 4K
Refer to the RBA Low-Level Contactless Key Card Support section for more information on Contactless Key Card Support.

3_8_2 RBA Low-Level Contactless Key Card Support
Telium RBA manages the interface between the POS and the low-level Contactless Key Card support in GRAF, which is transparent to the
POS. Refer to the following sections more more information on the interface and process. Refer to the following sections for more
information on RBA Low-Level Contactless Key Card support.
Contactless Key Card General Flow
Setting Contactless Mode (60.x/28.x)
Enabling Contactless and Requesting Card Tap (01.x/23.x)
16.x: Contactless Mode Request
17.x: Merchant Data Write
17.x Merchant Data Write Message Usage Examples
28.x: Set Variable Request
36.x Notification of Command Execution
The 17.x section includes examples for executing commands as well as executing commands as a batch. The 28.x page provides
information on changing contactless mode.

129/854 Telium RBA Developer's Guide/ August 18, 2015

3_8_2_1 Contactless Key Card General Flow
This section describes the general flow for the Contactless Key Card interface. Contactless mode must first be set to Contactless Key Card
mode. Form there, contactless must be enabled and a card tap must be requested through the 23.x Card Read Request message. Once one
or more cards have been detected, the terminal will send an unsolicited 16.x message to the POS with identifying card information. The
POS will send one or more commands to the terminal. When the POS has completed sending all other commands, it sends a Complete Tap
command through the 17.x: Merchant Data Write message to indicate to the terminal that the tap is complete. Once the tap is complete, the
contactless field must be disabled. The terminal is then ready to initiate another tap sequence or other action such as payment request.
The following table describes the Contactless Key Card General Message Flow. If another tap sequence is started, the first step in the table
may be skipped as the contactless mode will still be set to Contactless Key Card mode.
Contactless Key Card General Message Flow
Sequence

Message

Set the terminal's contactless mode to Contactless Key Card mode.

60.x: Configuration Write
or 28.x: Set Variable
Request

Enable contactless and request a card tap.

23.x: Card Read Request
(On-Demand)

Once one or more cards have been detected, the terminal will send an
unsolicited contactless mode request message to the POS with identifying
card information.

16.x: Contactless Mode
Request

POS

Terminal

The POS acknowledges and sends one or more commands to the terminal.

The POS sends a Complete Tap command last to indicate to the terminal
that the tap is complete.

17.x: Merchant Data Write

The POS sends a command to disable the contactless field.

60.x: Configuration Write
or 28.x: Set Variable
Request

The terminal is now ready to start another tap sequence or other action such
as payment request.

3_8_2_2 Setting Contactless Mode (60.x/28.x)
In order to service Contactless Key Card taps, the terminal must be in Contactless Key Card mode (8). There are two methods for
switching between contactless modes. The method depends on whether the mode change needs to be permanent or short term.
1. For permanently setting the contactless mode, use the 60.x: Configuration Write message to change parameter '0008_0001' (Enable

Contactless Reader) to a value of '8'.
2. For short term setting of the contactless mode (which does not persist following a reboot), use the 28.x: Set Variable Request

message with variable 412 (Contactless Mode).

130/854 Telium RBA Developer's Guide/ August 18, 2015

3_8_2_3 Enabling Contactless and Requesting Card Tap (01.x/23.x)
Once the terminal is in Contactless Key Card mode (8), the contactless must be enabled and a card tap must be requested. There are two
methods to implement this in the RBA:
1. The POS sends a 01.x: Online Message to display the "swipe" screen, which enables contactless and requests the card tap.
2. The POS sends a 23.x: Card Read Request (On-Demand) message to enable contactless and request the card tap. It is recommended

that a 23.x message not be sent from the "swipe" screen in order to avoid accidentally starting a second tap sequence from the
"swipe" once the 23.x message is complete.

3_9 Google Wallet Implementation
3_9_1 Overview of Google Wallet
Google Wallet is a consumer payment application based on Near Field Communication (NFC) which enables customers to store gift card,
Loyalty card and coupon information on mobile phones. Newer Ingenico terminals already include NFC and contactless capability. The
following image shows a mobile phone with Google Wallet installed being used to make a payment on an Ingenico iSC250 terminal.

Mobile Phone Google Wallet Application Used for Payment
Refer to the 17.x: Merchant Data Write message for a description of the MID/secret pair injection process. Also refer to the following
sections for more detail on payment flow and support modes:
General Payment Flow
Supported Google Wallet Modes

131/854 Telium RBA Developer's Guide/ August 18, 2015

3_9_2 Google Wallet Host Interface Messages
Refer to the 16.x: Contactless Mode Request section for information on setting Google Wallet mode and retrieving data.
Refer to the 17.x: Merchant Data Write section for a description of the message formats used for injecting MID/Secret pairs into
Ingenico terminals.

All terminals must be equipped with an Ingenico contactless module in order to enable Google Wallet functionality.

3_9_3 General Payment Flow
The payment method for Google Wallet follows a set priority which is described as follows:
1. If gift card data is present in the Google Wallet data, then the gift card track is used for the payment flow regardless of the presence

of ISO track data.
2. If no gift card track data is present in the Google Wallet data then ISO track data, if present, is used for the payment flow. An

example would be PayPass.
3. If nether gift card track data nor ISO track data are present, then another payment source may be utilized for the payment flow.

3_9_4 Supported Google Wallet Modes
Google Wallet transactions can be processed using any of the following contactless modes:
1. PPSE First - terminal starts in PPSE mode first, then switches to Mifare if needed.
2. Mifare First - terminal starts in Mifare mode first, then switches to PPSE mode if needed.

3_10 Softcard SmartTap Implementation
3_10_1 Overview of Softcard SmartTap
Softcard SmartTap provides customers with a way to use their smartphone to pay and save at participating merchants. Customers can load
their credit cards, Loyalty cards, and special offers by merchants onto their smartphone using this feature. When the smartphone is tapped,
special offer and Loyalty card information is sent to the Ingenico terminal along with the payment information. This information is then
sent by the terminal to the POS and used to adjust the final transaction amount, including applicable discounts. This adjusted amount is
returned to the terminal which then proceeds with the authorization request once confirmed by the customer. Payment information from
the smartphone is used by the POS to authorize the transaction.

3_10_2 Configuring the Terminal and Sending Softcard SmartTap Data to the POS
The POS uses the 17.x: Merchant Data Write Request message to configure the terminal for Softcard SmartTap transactions. A 17.x:
Merchant Data Write Response message indicates if the configuration was successful. When a smartphone is tapped, SmartTap data is sent
using a 16.x Contactless Mode Request message. SmartTap data received from the card or smartphone is sent to the POS in two different
situations:
Sending SmartTap Data to the POS

132/854 Telium RBA Developer's Guide/ August 18, 2015

Situation

Description

"Please
slide card"
state

When the smartphone or card is tapped, any Softcard SmartTap data retrieved will be sent as a 16.x response message
from the terminal to the POS.

23.x Card
Read
Request
message

Then the smartphone or card is tapped, any Softcard SmartTap data retrieved will be sent as a 16.x response message
from the terminal to the POS when the payment information has been successfully read. A 23.x: Card Read Request (OnDemand) message containing track data is sent last.

Refer to the following sections for 16.x and 17.x Softcard SmartTap message format and usage.
17.x: Merchant Data Write
16.x: Contactless Mode Request

3_10_3 Supported Contactless Modes
The following table lists and describes the supported contactless modes for Softcard SmartTap.
Supported Contactless Modes for Softcard SmartTap
Mode

Function

Description

1

PPSE Only

The terminal starts in PPSE payment mode. Softcard SmartTap is not supported in this mode.

5

1st - PPSE

The terminal starts in PPSE payment mode, then switches to Softcard SmartTap mode.

2nd - Softcard SmartTap
6

1st - Softcard SmartTap

The terminal starts in Softcard SmartTap mode, then switches to PPSE payment mode.

2nd - PPSE
7

Softcard SmartTap Only

The terminal starts in Softcard SmartTap mode. PPSE payment mode is not supported.

Selecting or changing contactless modes is implemented using the 28.x: Set Variable Request and 29.x: Get Variable Request messages
with RBA variable 412.

3_10_4 Erroneous Card Tap
If a card is not correctly read while the terminal is in contactless modes 5, 6 or 7, the terminal will issue a beep and display an error
message for a few seconds. After this, depending on the origination of the erroneous read, the terminal will return to one of two screens:
If the erroneous read occurred during the swipe screen, the terminal will return to the swipe screen following the beep and error
message display.

133/854 Telium RBA Developer's Guide/ August 18, 2015

If the erroneous read occurred during the 23.x: Card Read Request (On-Demand) screen, the terminal will return to the screen prior
to this screen following the beep and error message display.

3_11 Offline Remote Key Injection (RKI) Support
3_11_1 Overview
This section describes support of Remote Key Injection (RKI) in the Retail base Application. Offline remote key loading is implemented
using a function based on a TDES symmetry key. Offline remote key injection utilizes Ingenico tools and is maintainable using standard
SDK support. This implementation utilizes WinKeyfac (an existing key management tool) and modified existing terminal application
software. WinKeyfac has been updated and can now read a file containing injected serial numbers. WinKeyfac uses this file to generate a
key bundle file (*.rki) which can be used to update those terminals with specified keys. Each entry in a key bundle contains an injected
serial number and the information required to update a specified key. Once this file has been downloaded to a terminal, the application can
read this file and search for any entries which contain a matching injected serial number and perform the specified update.

3_11_2 Prerequisites/Requirements
Terminals must have injected serial numbers in order for this feature to work. These terminal serial numbers are the customer serial
numbers which have been injected into the terminals.
Each key must be unique to the target terminal. A unique KSN can be generated using a diversification algorithm with the
Customer Serial Number (CSN).
For PCI V3 compliant terminals, Key Pattern 4 (KP4) must be enabled first. Injecting DUKPT Lite keys is not permitted. A request
for injecting these will be declined with a "40" result code.
The following are required by the financial application supporting offline RKI:
Notify the TSA upon power-up using the API to indicate that Offline RKI is being supported.
Must recognize the key file bundle which will have the ".rki" filename extension.
Must scan the key bundle file for the injected customer serial number.
Use the TSA to load each TR-31 key bundle into the appropriate slot as indicated in the key bundle file.
Integrated environment:
Must provide the host with a mechanism to receive acknowledgement of successful Offline RKI.
Standalone application:
Must maintain a log of key bundle headers which were successfully loaded, including the date.

3_11_3 Enabling/Disabling Remote Key Injection
Remote key injection can be enabled or disabled by setting the parameter RKIENABLE in the signed RKI.XML file which is stored in the
application directory. If the RKI.XML file is not present, then remote key injection must be disabled. If this file is present, a call to
VarGetByInt( "RKIENABLE", &RKIEnable ) will return the value of the RKIENABLE parameter. If set to '0' then remote key
injection is disabled. If set to '1' then remote key injection is enabled. The following table summarizes The requirements for enabling the
remote key injection feature.
Requirements for Enabling Remote Key Injection

134/854 Telium RBA Developer's Guide/ August 18, 2015

RKI.XML File

RKIENABLE

Not Present

Remote Key Injection
Disabled

Present

0

Disabled

Present

1

Enabled

3_11_4 Offline RKI Process
The Telium System Application (TSA) supports remote key injection, implemented by a third part software application, which loads keys
encoded in TR-31 2010 Key Block format. This is referred to as Offline Remote Key Injection, or Offline RKI. In order to implement this
process, the Key Block Protection Key (KBPK, also referred to as base key) from which the TR-31 formatted key bundle is generated
must first be loaded into the target terminal. An Application Programing Interface (API) has been added to indicate to the TSA that Offline
RKI is supported. When the TSA initializes following power-up, it checks for the presence of the KBPK. If present, the TSA will diversify
the stored KTK using the SEC_SpecifLoadKey function with the Customer Serial Number in the secret area. Upon completion, the KBPK
is deleted as it will then exist in the Key transfer Key location.
The key bundle file will include the name of the serial number input file, and the extension will be changed to ".rki". The input file name
should not contain spaces. The key bundle format is as follows:

Key Bundle Format
The KBPK can be loaded into a terminal using the following methods:
The KBPK can be directly loaded using the Telium Key Injection Application (KIA) injection command, mode T4.
The injected key automatically replaces the existing key located in the KTK/PIA slot the first time the terminal powers up.
This is implemented by the TSA.
The KBPK can be derived from the existing KTK and injected serial number when an application submits a request to the TSA to
enable Offline RKI or to load a TR-31 formatted key block for the first time.
The derived KBPK will be loaded into the KTK slot and replace the existing KTK.
The KBPK can be encoded in the TR-31 format and requested by the third part software application to load it into the designated
key location.
After the KBPK key has been loaded as a key transfer key, Offline RKI is recognized by the TSA as enabled and is indicated in the
Application Comment field by assigning the key word value "0000000000000DIV". Key Pattern 4 (KP4) will then be enforced by the
TSA. The TSA will first verify that the terminal's secret areas are mapped as KP4 when given a key to load. If the secret areas are not
mapped as KP4 then all secret areas other than 0xXXYY2130 will be deleted and remapped to KP4.
Once the Offline RKI mode is enabled by the TSA, the following apply:
Remote Key Injection can be enabled and disabled with the RKIenable.PGZ file; no keys are lost in the process.
The KTK contains a specialized key which is intended for use by the TSA_LoadKeyFromKeyBlock API as a KBPK. Accordingly,
the TSA_LoadMasterKey function can not be used to load a master key into the terminal. An error code will be returned following
any attempt to do so.

135/854 Telium RBA Developer's Guide/ August 18, 2015

An external application can inject the following keys by calling the TSA API TSA_LoadKeyFromKeyBlock:
CDMK (Application Download Authorization Key, also referred to as Code MAC Key). This key replaces any existing
CDMK key.
CEFMK (Clear Text Entry Authorization Key, also referred to as the Clear Text Entry Prompt MAC Key). This key
replaces any existing CEFMK key. All MAC data generated from the previous CEFMK key is deleted.
PEFMK (Secure Text Authorization Key, also referred to as the Secure text Entry Prompt MAC Key). This key replaces
any existing PEFMK key. All MAC data generated from the previous PEFMK key is deleted.
Master Key. This key replaces the existing Master Key. Its corresponding Session Key is deleted.
Session Key. This key replaces the existing Session Key.
DUKPT IK. The initial key is reloaded.
Upon successful KBPK injection, the following conditions will be enforced:
If the key pattern is mode 4 prior to KBPK injection then the key is injected and the terminal remains in KP4 mode.
If the key pattern is not KP4 prior to KBPK injection then the following actions are taken before injecting the key:
All existing keys in secret areas with the exception of ID 0xXXYY2130 are erased.
The key pattern is changed to KP4.

3_11_5 Initiating Offline RKI through the TSA
An Application Programing Interface (API) has been added to indicate to the TSA that offline RKI is being supported. From the TSA
menu, select option "6 - Prepare for RKI" as shown in the following illustration. When this option is selected, the TSA will delete the
system file RKI.DIA if it exists. The terminal will display "WILL AUTO RESTART" and initiate a restart.

Initiating Offline RKI
Once the process has been completed, the TSA will remove the RKI indicator from the secret area.

3_11_6 Log Files
The log file is a text file that includes a line for each injection attempt. The log file is readable by users and can also be parsed by an
application. Each line in the log file will contain the following information:
Time stamp for when the installation was attempted.
Status code. This code provides the result of the injection attempt. It does provide an indication of the key that is currently loaded.
Human readable message explaining the status code.
Second and third fields from the original record (e.g., IPPKOPIN).

136/854 Telium RBA Developer's Guide/ August 18, 2015

For DUKPT keys, include the current KSN (20 digits). For other keys, include the KCV (6 digits).

3_11_7 Functional Limitations
The maximum .rki file length is 1000 lines.
Each terminal uses a unique key to transport key bundles. Accordingly, a key set cannot be shared with other terminals.

3_12 Dynamic Update of RSA-OAEP Public Keys
3_12_1 Overview
Dynamic updating of RSA-OAEP Public Keys enables on demand updating of keys without sending the terminal to Ingenico for key
injection. To support this feature, the following encryption support message subtypes were added to the 90.x: P2PE Data Message:
'90.5' RSA-OAEP Public Key Request/Response message.
'90.6' Delete RSA-OAEP Public Key Request/Response message.
'90.7' Select RSA-OAEP Public Key Request/Response message.
Additionally, two new security parameters were added to the Security Parameters (security.dat) configuration file:
'0091_0032' - Public Key for Signature Verification.
'0091_0033' - Public Key for Data Encryption.
The '90.5' request message sent from the POS to the terminal includes a key name, key file data, and signature data. Security parameter
'0091_0032' (Public Key for Signature Verification) must be set prior to sending the request message. When this message is received, the
terminal uses the signature and signature verification public key to verify the new encryption public key. Once the signature is verified, the
encryption public key is stored in the terminal and a '90.5' response message is returned to the POS with a result code (e.g., success,
invalid request). Upon validation, the encryption public key data is stored in a file in the /F_SECURITY_APP/RSAKEYS directory with
the file name provided in the Key Name field of the request message. A ".PEM" extension will be appended to the file. If the signature is
not validated then the encryption public key data will be discarded.
The '90.6' request message is used by the POS to delete an encryption public key from the terminal while the '90.7' request message is used
to select an encryption public key. Once a key has been selected, it is stored in the '0091_0033' parameter location (Public Key for Data
Encryption) so that it can be reloaded upon rebooting the terminal. For more information on encryption support messages refer to the 90.x:
P2PE Data Message section in this manual
To rotate the public key, the following steps are taken:
1. Generate a new public/private key pair.
2. Sign the new public key with the existing initial private key.
3. Send the signed data to the terminal via the 90.x message. The response to this message will indicate if the update was successful.

This feature is only supported in v12.2.1 and v12.2.2 of RBA.

3_12_2 Procedure to Dynamically Update RSA OAEP Public Keys
1. The customer generates a Signing Public and Private key pair.

137/854 Telium RBA Developer's Guide/ August 18, 2015

2. The customer shares the Signing Public key with Ingenico.
3. Ingenico returns a SECURITY.PGZ file which is a signed file containing the customer's Signing Public key.
4. The customer downloads the SECURITY.PGZ file to the terminal so that the Signing Public key is applied.
5. The terminal is rebooted following successful download of the SECURITY.PGZ file.
6. The customer generates an Encrypting Public and Private key pair.
7. The customer signs the Encrypting Public key with the Signing Private key.
8. The customer sends an RBA message to the terminal containing the Signed Encrypting Public key.
9. The terminal receives the Signed Encrypting Public key from the POS and validates the signature using the Signing Public key

included in the SECURITY.PGZ file.
10. Once the signature of the Signed Encrypting Public key is validated by the terminal, it is then stored and can be selected for

encrypting cardholder data.
a. If the signature is invalid then an error message will be returned to the POS.
b. If the new Signed Encrypting Public key is downloaded but not signature-validated, then the RBA will respond with an

error message and the new key will not be stored and cannot be used for encrypting cardholder data.
c. A reboot is not required for this process.

3_13 Support for Voice Referral for EMV
3_13_1 Overview
Voice referral, also referred to as voice authorization, is a situation where voice authorization by phone is required in order to complete the
EMV transaction. The merchant is given a phone number to call for transaction approval. A "declined" message will be sent but the
terminal will instead display "Voice authorization required" and prompt for card removal. The operator is then given the card to perform
the voice referral and complete the transaction. If the transaction is approved, an authorization code will be provided over the phone. This
code will be included in the receipt and provided in the settlement.

3_13_2 Functional Description
When the POS sends an EMV '33.04.x' Authorization Response Message with a tag T8A value of '01' (referral requested by issuer) or '02'
(referral result), the RBA will display "Voice authorization required" and prompt the cardholder to remove the card. EMV tag D1011
(Transaction Result) has been added to support this feature. The use of this tag will be similar to that of tag T8A; '00' for approval and '05'
for decline. Tag D1011 is optional; when not included in the Authorization Response message, the original processing will be used.
A new prompt has been added to the PROMPT.XML file in three languages:
 (English)
 (Spanish)
 (French)
When this prompt is displayed, it will be followed by a second prompt instructing the cardholder to remove their card. The transaction will
be completed once the operator calls the provided phone number and receives the voice authorization. There are three important steps in
this process:
1. When the terminal receives a voice authorization request from the card issuer, it must terminate the EMV transaction by asking the

card for an AAC.

138/854 Telium RBA Developer's Guide/ August 18, 2015

2. Once the voice authorization is processed, acquirers must retain the authorization approval code and ARQC produced by the card.
3. The authorization approval code must be included in the clearing message.

3_13_3 Transaction Example
The following transaction example is based on a tag T8A value of '02' indicating that voice authorization is required. Refer to the
following table or a list of the transaction steps.
Voice Authorization Required Transaction Example
Sequence

Message

The POS sends an offline message to the terminal.

00.x: Offline Message

The terminal acknowledges with an offline message and displays the
Offline/Lane Closed form.

00.x: Offline Message

The POS sends a configuration write message to enable EMV transactions.

'60.19[GS]1[GS]1'

The terminal acknowledges the configuration write and enables EMV.

'60.2'

The POS sends an online message to the terminal.

01.x: Online Message

The terminal acknowledges the online message.

01.x: Online Message

The terminal prompts the cardholder to swipe or insert their card.
The cardholder inserts their EMV card.
The terminal sends card status message to POS indicating that EMV card
has been inserted.
The terminal briefly displays "Please wait ... Do not remove card"
message.
The terminal prompts the cardholder to select the language (optional,
depending on card's application).
The cardholder selects the language.
The terminal displays the application (e.g., VISA Debit, MasterCard
Credit).

139/854 Telium RBA Developer's Guide/ August 18, 2015

'09.020201I'

ECR

Terminal

Sequence

Message

The POS sends an amount message to terminal.

'13.2000'

The terminal returns a Track 2 Equivalent Data message.

EMV '33.02.x' Track 2
Equivalent Data Message

The POS sends Set Payment Type message.

'04.0B2000'

The terminal acknowledges the Set Payment Type message.

'04.0B000'

The POS sends a final amount message.

'13.2500'

The terminal displays the Amount Verification screen and prompts the
cardholder to proceed or cancel.
The cardholder confirms the purchase amount and is prompted to enter
their PIN.
The terminal sends the Authorization Request message to the POS.

'33.03.0000[FS] .... '

The POS returns an Authorization Response message. Tag 8A has a value
of ' 02 ' indicating that voice authorization is required.

'33.04.0000[FS]T8A: 02 :
a01[FS]'

The terminal sends an Authorization Confirmation Response message.

'33.05.0000[FS] ....'

The terminal displays
"Voice authorization required"
" Please remove card "
The terminal beeps every 3 seconds until card is removed.
The cardholder removes their card and hands it to the operator for voice
authorization.
The terminal sends the updated Card Status message to POS indicating that
the card has been removed.
The terminal displays the card swipe/insert prompt.

140/854 Telium RBA Developer's Guide/ August 18, 2015

'09.020201R'

ECR

Terminal

Sequence

Message

The POS sends a hard reset message to the terminal.

'10.'

141/854 Telium RBA Developer's Guide/ August 18, 2015

ECR

Terminal

4_Host Interface Messages

4_1 Communication Protocol Overview
The terminal connects to the POS using one of the supported communication methods. Communications are asynchronous seven-bit
ASCII. The communication between the POS and the terminal consists of:
Link-level responses that are used to control the communications and to ensure the messages are exchanged correctly
Messages that are used to exchange the required information Each of these is discussed in the following sections.
As stated in the previous section, there are two types of communication messages that flow between the POS and the terminal: link level
responses and data messages. This section defines the format of each type.

4_1_1 Link Level
The link level responses are the ASCII-defined control characters, ACK and NAK. A link-level response is sent in response to all
messages received.
ACK is a positive acknowledgement that indicates to the station sending a message that the message was received correctly.
NAK is a negative acknowledgement that indicates to the station sending a message that the message was received but it was
incorrect. The sending station then resends the previous message.
The only other response that a station sending a message expects is a timeout while waiting for the ACK or NAK. If a message is sent and
no response is received by the sending station within three seconds, this is called a timeout and the sending station resends the previous
message.
Link Level Responses are one-character messages as defined below:
Link Level Response 1 byte, where:
Link Level Response is the following one-character ASCII code:
ACK is hexadecimal 06
NAK is hexadecimal 15

4_1_2 Data Message Format
The POS and terminal to exchange information via data messages. Each data message corresponds to the function requested and
performed. The messages consist of the required data, enclosed in ASCII-defined control characters that indicate the start and end of the
message. The sending station receives a link-level response (ACK or NAK) or a timeout response to all messages sent. The RBA can be
configured such that the ACK response is delayed until a message is processed via parameter '0013_0011' in the Compatibility Flags
(compat.dat) section of config.dfs.
The POS can send a message to the terminal at any time. On many systems, the terminal can send a message to the POS only at specific
times when the POS is expecting to receive a message. Other systems allow the terminal to send a message at any time.
Systems that limit terminal messages usually expect to receive a message at the following times:
In response to an Online Request message

142/854 Telium RBA Developer's Guide/ August 18, 2015

In response to a Status Request message
Between the sending of an Amount message and receiving an Authorization Request message
The RBA general message flow contains the following message exchange sequences:
Startup sequence: The messages between and including the Online Request and Online Response are the startup sequence. This
sequence normally occurs only when the POS sales application is started and the POS is opened for sales transactions.
Transaction sequence: The messages between and including the Amount message and the RESET message are the possible
sequence of messages for each transaction. Some subset of the messages would be used for any EFT transaction.
Shutdown sequence: The Offline message is the shutdown sequence and is sent by the POS when the sales application is stopped
and the POS closed.
This section defines the messages that flow between the POS and the terminal. Some of these messages flow to and from the switch and
are defined by the VISA Second Generation specification. For consistency, all messages have been defined to fit within the VISA message
format.
All messages are checked by the LRC and a positive acknowledgement (ACK) response is sent to all good messages or a negative
acknowledgement (NAK) to all bad messages. The maximum allowable message length is 247 bytes.
The basic format of these messages is as follows:
RBA Message Format
Message Fragment

Fragment Size

STX control character

1 byte

Message Identifier

3 bytes

....
Message data, consisting of multiple fields

n bytes (0 to 241)

....
ETX control character

1 byte

LRC check character

1 byte

Where:
STX is the ASCII-defined control character, hex 02
Message Identifier is three ASCII characters (two digits followed by a decimal) that identify the type message, as defined below:
00.x = Offline Message
01.x = Online Request/Response
03.x = Set Session Key Message
04.x = Set Payment Type Request/Response
07.x = Unit Data Request/Response
08.x = Health Status Request/Response

143/854 Telium RBA Developer's Guide/ August 18, 2015

09.x = Set Allowed Payments
09.x = Card Status Message
10.x = Reset Message
11.x = Status Request/Response
12.x = Account Message
13.x = Amount Message
14.x = Set Transaction Type Message
15.x = Soft Reset Message
16.x = Contactless Mode Request
17.x = Inject MID/Secret Pairs
18.x = Informational Card Message
19.x = BIN Lookup Message
20.x = Signature Request Message
21.x = Numeric Input Request/Response
22.x = Application ID Request/Response
23.x = Card Read Request/Response
24.x = Form Input Request
25.x = Terms and Conditions Request
26.x = Run Script
27.x = Alpha Input Request/Response
28.x = Set Variable Request/Response
29.x = Get Variable Request/Response
30.x = Advertising Request Message
31.x = PIN Request Message
34.x = Save and Restore State Message
36.x = Notification of Command Execution
40.x = Survey Message
41.x = Card Read Message
50.x = Authorization Request/Response
60.x = Configuration Write
61.x = Configuration Read
62.x = File Write
63.x = Find File
64.x = Delete File
70.x = Update Form Element Message
80.x = MAC Calculation Message Format

144/854 Telium RBA Developer's Guide/ August 18, 2015

81.x = MAC Verification Message Format
82.x = On-Guard and KME Session Key Injection Command
83.x = On-Guard and KME Enable Message
85.x On-Guard and KME Non-Payment Card Message
86.x On-Guard and KME BIN Lookup (PIN Encouragement) Message
87.x On-Guard and KME Card Read Data
88.x On-Guard and KME Translate Encrypted Card Data Command
89.x = On-Guard and KME Register BIN Record Command
90.x = MSR Encryption Support Message
91.x = Printer Message
93.x = Terminal Authentication Messages
94.x = Barcode Configuration Messages
95.x = Barcode Configuration Messages
97.x = Reboot
Message Data is the variable data defined for each message
ETX is the ASCII-defined control character, hex 03
LRC check character is a character generated for each message, using the data in the message, and is verified by the receiving
station to ensure that the message was received correctly. The LRC is generated by exclusive-OR’ing all characters in the message
except the STX but including the ETX (see following example). This calculation is done by both the sending and receiving station.
The sending station appends the LRC character to the message it is sending following the ETX character. The receiving station
validates that the LRC is received at the end of the message is the same LRC that it calculated for the message it received.
The following is an example of two messages shown in both ASCII and hex, followed by the LRC calculation:
10.x Hard Reset Message with no Data
ASCII

[STX]10.[ETX][LRC]

Hex

02 31 30 2E 03 2C

LRC calculation

31 01 2F 2C

12.x Amount Message with a Balance Due of $123.89
ASCII

[STX]13.12389[ETX][LRC]

Hex

02 31 33 2E 31 32 33 38 39 03 1E

LRC calculation

31 02 2C 1D 2F 1C 24 1D 1E

4_1_3 General Message Flow
The following diagram shows the general message flows between a POS and the terminal.

145/854 Telium RBA Developer's Guide/ August 18, 2015

General Message Flow
Sequence

Message

Begin Startup Sequence
End Startup Sequence

Online Request

Online Response

Begin Transaction Sequence

Set Variable Request (receipt)

End Transaction Sequence
* Transaction Type (Sale, Void, Return, etc.)

* Account Message

Amount Message

* Status Request

* Status Response

Authorization Request

Authorization Response

* Get Variable Request

* Get Variable Response

Reset

Shutdown Sequence

Offline

146/854 Telium RBA Developer's Guide/ August 18, 2015

POS

Terminal

Info
An asterisk (*) indicates an optional message. All of these messages will be ACKed, but that is not shown here for simplicity.

The diagram, above, contains the following message exchange sequences:
Startup sequence: The messages between and including the Online Request and Online Response are the startup sequence. This
sequence normally occurs only when the POS sales application is started and the POS is opened for sales transactions.
Transaction sequence: The messages between and including the Amount message and the Reset message are the possible sequence
of messages for each transaction. Some subset of the messages would be used for any EFT transaction.
Shutdown sequence: The Offline message is the shutdown sequence and is sent by the POS when the sales application is stopped
and the POS closed.

4_2 Communication Messages
This section describes RBA’s communication messages, as well as how they are used, when they are executed, and their corresponding
configuration settings in config.dfs.
Although most RBA messages are executed as part of a predetermined sequence, certain messages can also be executed by the host ondemand, which means that they interrupt the normal operation of the application in order to perform the new function requested by the
message. The following on-demand messages are available in the RBA:
20.x: Signature Message (On-Demand)
21.x: Numeric Input Request Message (On-Demand)
23.x: Card Read Request (On-Demand)
24.x: Form Entry Request (On-Demand)
25.x: Terms and Conditions Request (On-Demand)
26.x: Run Script Request (On-Demand)
27.x: Alpha Input Message (On-Demand)
30.x: Advertising Request Message (On-Demand)
31.x: PIN Entry Messages (On-Demand)
34.x: Save and Restore State Messages
51.x: Beep On-Demand Message
For the exact behavior when an on-demand message is received, see the message’s corresponding section. Here are some general rules for
on-demand functions:
On-demand messages are not nested.
On-demand messages cannot execute while another on-demand function is executing. This behavior can be modified by the
onDemandCancel flag in mainFlow.dat.
A transaction will resume where it was interrupted when an on-demand function completes.
If an on-demand message cannot be executed, a response with a reject status is returned.

147/854 Telium RBA Developer's Guide/ August 18, 2015

Please note that to adhere to enhanced security standards, dynamic text is not supported in this release of RBA. The POS will
use prompt indices to display plain text messages.

4_2_1 00.x: Offline Message
4_2_1_1 Overview of the 00.x Offline Message
The 00.x Offline message flows in both directions.
The POS sends the 00.x Offline Request message to force the terminal into an offline state. The message format will always be
'00.0000' when sent by the POS.
The terminal sends the 00.x Offline Response message to the POS to indicate that it has detected a problem and has entered the
offline state. In an offline state, the terminal cannot collect any customer data.

4_2_1_2 00.x Offline Response Message
The 00.x Offline Response message contains a four-character status field which indicates the reason for being offline. Refer to the
following '00.x' Offline Response Message Format table for a description of these. Also refer to the following examples.
The '2000' code may be encountered when an attempt has been made to perform a task offline which cannot be accomplished in an
offline state, such as attempting to reset when offline. Resetting can only be accomplished when in online state.
The '4000' code may be encountered when a parameter file such as a .dat file is missing.
The '9000' code may be encountered when a key is bad or missing, or for instance, when an attempt is made to generate a Voltage
key, but there is an error when generating that key.
In an offline state, the terminal clears all data and remains offline until receiving the 01.x: Online Message. Upon receiving the 01.x
message, the terminal attempts to go Online. If successful, it then sends an Online Response indicating it has entered the online state. If
unsuccessful, an Offline Response message will be returned to the POS indicating the reason for being offline.
The terminal comes up in an offline state following a power on or a PLD (power line disturbance). The RBA will also send an Offline
Response message when it encounters an error condition (such as an encryption error) during normal operation; this reply is not solicited
by an Offline Request message from the POS. The terminal enters an offline state if it detects an unrecoverable error within itself, if it
detects invalid message protocol from the POS, or if it receives an Offline Request message from the POS.
When the RBA receives the Offline Request message, it will only send an Offline Response message if it is already in an offline state.
Refer to the following tables which describe the '00.x' Offline Request message format and '00.x' Offline Response message format.
'00.x' Offline Request Message Format

148/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M00_OFFLINE
Identifier – ASCII – “00.”

4

4

Decimal

iConnectEFT Constant = P00_REQ_REASON_CODE
Always '0000' for the Offline Request message.

8

1

Constant

ASCII control character – ETX

9

1

Binary

LRC check character.

'00.x' Offline Response Message Format
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M00_OFFLINE
Identifier – ASCII – “00.”

4

4

Decimal

iConnectEFT Constant = P00_RES_REASON_CODE
Offline reason code.
0000 = No errors present.
2000 = Request not valid.
4000 = Missing parameter file.
9000 = MSR encryption error.

8

1

Constant

ASCII control character – ETX

9

1

Binary

LRC check character.

Legacy versions of the RBA Test Application may not display the 00.x response from the terminal when sending a 00.x
message to RBA.

While there is a response format designated for the 00.x message, the POS polls the terminal for its online/offline status using
the 11.x: Status Message.

149/854 Telium RBA Developer's Guide/ August 18, 2015

4_2_1_3 Message Responses in the Offline State
The below table illustrates the messages that are functional when prompting a terminal in offline mode:
Message Availability while Offline
Messages Allowed

Example Response

11.x Status

00.x: Offline Message

00.0000

11.00LaneClosed
[FS]

01.x: Online Message

01.00000000

11.01SlideCard[FS]

07.x: Unit Data
Request

07.INGNAR[FS]iSC350[FS]6115A1000000021[FS]9999[FS]
9999[FS]0000[FS]0308[FS]1111[FS]0271[FS]0000[FS]0000

11.00LaneClosed
[FS

08.x: Health Stat

08.0047[FS]03[FS]02[FS]27[FS]0012[FS]3438[FS]iSC350[FS]
6115A1000000021[FS]1111[FS]0271[FS]0308[FS]0270[FS]
0000[FS]0000[FS]63896[FS]22066[FS]2010-06-29[FS]0[FS]
OK[FS]Retail Base[FS]INGNAR[FS]0000

11.00LaneClosed
[FS

11.x: Status Message

11.00LaneClosed[FS]

11.00LaneClosed
[FS

20.x: Signature
Nothing is received in the RBA Testing Tool (until you send a Status Request 11.x,
Message (On-Demand) then you get 11.10PleaseSign[FS]).

11.00LaneClosed
[FS] then 11.12

21.x: Numeric Input
Request Message (OnDemand)

Nothing is received in the RBA Testing Tool (until you send a Status Request 11.x,
then you get 11.10PleaseSign[FS]).

11.00LaneClosed
[FS] then 11.12

22.x: Application ID
Request

Nothing is received in the RBA Testing Tool (until you send a Status Request 11.x,
then you get 11.10PleaseSign[FS]).

11.00LaneClosed
[FS]

23.x: Card Read
Request (On-Demand)

Nothing is received in the RBA Testing Tool (until you send a Status Request 11.x,
then you get 11.10PleaseSign[FS]).

11.00LaneClosed
[FS] then 11.12

24.x: Form Entry
Request (On-Demand)

Nothing is received in the RBA Testing Tool (until you send a Status Request 11.x,
then you get 11.10PleaseSign[FS]).

11.00LaneClosed
[FS] then 11.12

25.x: Terms and
Conditions Request
(On-Demand)

Nothing is received in the RBA Testing Tool (until you send a Status Request 11.x,
then you get 11.10PleaseSign[FS]).

11.00LaneClosed
[FS] then 11.12

26.x: Run Script
Request (On-Demand)

26.3

11.00LaneClosed
[FS] then 11.12

150/854 Telium RBA Developer's Guide/ August 18, 2015

Messages Allowed

Example Response

11.x Status

27.x: Alpha Input
The alpha keyboard appears on the PIN pad before the 11.x request is run. Nothing is
Message (On-Demand) received in the RBA Testing Tool (until you send a Status Request 11.x, then you get
11.12Input[FS]).

11.00LaneClosed
[FS] then 11.12

28.x: Set Variable
Request

For variable 202 the response would be 28.30000202.

11.00LaneClosed
[FS]

29.x: Get Variable
Request

The response to a 29.00000251 message would be 29.20000251Retail base.

11.00LaneClosed
[FS]

30.x: Advertising
Request Message (OnDemand)

Nothing is received in the RBA Testing Tool (until you send a Status Request 11.x,
then you get 11.10PleaseSign[FS]).

11.00LaneClosed
[FS] then 11.15
Advertising[FS]

31.x: PIN Entry
Messages (OnDemand)

The alpha keyboard appears on the PIN pad before the 11.x request is run. Nothing is
received in the RBA Testing Tool (until you send a Status Request 11.x, then you get
11.12Input[FS]).

11.00LaneClosed
[FS] then 11.12Input
[FS]

The response to a '63./HOST/BIN3.DAT' message would be '63/0187'.

11.00LaneClosed
[FS]

60.x: Configuration
Write
61.x: Configuration
Read
62.x: File Write
63.x: Find File

64.x: Delete File
70.x: Update Form
Element Message
87.x On-Guard and
KME Card Read Data
90.x: P2PE Data
Message
97.x: Reboot

These messages are disallowed in an offline state:
03.x: Set Session Key Message

151/854 Telium RBA Developer's Guide/ August 18, 2015

04.x: Set Payment Type Request
09.x Card Status Message
10.x: Hard Reset Message
12.x: Account Message
13.x: Amount Message
14.x: Set Transaction Type
15.x: Soft Reset Message
16.x: Contactless Mode Request
17.x: Merchant Data Write
18.x: Non-Payment Card Message
19.x: BIN Lookup
33.x EMV messages
34.x: Save and Restore State Messages
40.x: Survey Messages
41.x Card Read Message
50.x: Authorization Request
51.x: Beep On-Demand Message
52.x: PayPal Preauthorization Message
58.x Terminal Discovery Message
82.x On-Guard and KME Session Key Injection Command
83.x On-Guard and KME Enable Message
85.x On-Guard and KME Non-Payment Card Message
86.x On-Guard and KME BIN Lookup (PIN Encouragement) Message
88.x On-Guard and KME Translate Encrypted Card Data Command
89.x On-Guard and KME Register BIN Record Command
91.x: Print Message
93.x: Terminal Authentication Messages
94.x and 95.x: Barcode Configuration Messages

4_2_2 0x and 50.x: Authorization Response Message Format
Both the Authorization Response message format and the Alternate Authorization Response message format are defined by the VISA
Second Generation specification. Either message is acceptable.
This message contains the transaction approve code and text, which the RBA shows on the display during execution of the Transaction
End process. This message is also called the approve message. The 0.x message is in the old format, while 50.x is in the new format. Both
formats are supported by the RBA.
0.x Authorization Response Message Format (Received by RBA from POS)

152/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

1

Constant

iConnectEFT Constant = M00_AUTHORIZATION
Message Identifier – ASCII – “0”

2

8

Decimal

iConnectEFT Constant = RES_PIN_PAD_SERIAL_NUM
Terminal Serial Number.

10

1

Constant

Index Code (always "0").

11

4

Decimal

iConnectEFT Constant = RES_POS_TXN_NUM
POS Transaction Number (from Authorization Request).

15

2

Alphanum

iConnectEFT Constant = P50_RES_RESPONSE_CODE
Response Code:
A? = Approved.
NP = Re-enter PIN.
E? = Declined.
N? = Declined.

All other codes are invalid and are treated as declined. The “?” above may be any
character.

17

6

Alphanum

iConnectEFT Constant = P50_RES_APPROVAL_CODE
Approval Code.

23

6

Decimal

iConnectEFT Constant = P50_RES_TODAYS_DATE_YYMMDD
Today’s Date (YYMMDD).

29

Variable

Alphanum

iConnectEFT Constant = P50_RES_PROMPT_INDEX_NUM
Prompt index number.

M

1

Constant

ASCII control character – FS

M+1

1

Constant

ASCII control character – ETX

M+2

1

Binary

LRC check character.

153/854 Telium RBA Developer's Guide/ August 18, 2015

50.x Alternate Authorization Response Format
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M50_AUTHORIZATION
Message Identifier – ASCII – “50.”

4

8

Decimal

iConnectEFT Constant = P50_RES_PINPAD_SER_NUM
Terminal Serial Number.

12

1

Constant

Index Code (always "0").

13

4

Decimal

iConnectEFT Constant = P50_RES_POS_TXN_NUM
POS Transaction Number (from Authorization Request)

17

2

Alphanum

iConnectEFT Constant = P50_RES_RESPONSE_CODE
Response Code:
A? = Approved.
NP = Re-enter PIN.
E? = Declined.
N? = Declined.
All other codes are invalid and are treated as declined

19

6

Alphanum

iConnectEFT Constant = P50_RES_APPROVAL_CODE
Approval Code.

25

6

Decimal

iConnectEFT Constant = P50_RES_TODAYS_DATE_YYMMDD
Today’s Date (YYMMDD)

31

Variable

Alphanum

iConnectEFT Constant = P50_RES_PROMPT_INDEX_NUM
Alpha display message (from POS) or prompt index number (from RBA).
(Up to 32 characters.)

M

1

Constant

ASCII control character – FS

M+1

1

Constant

ASCII control character – ETX

M+2

1

Binary

LRC check character.

154/854 Telium RBA Developer's Guide/ August 18, 2015

4_2_3 01.x: Online Message
The 01.x Online message flows in both directions as a request/response pair. An 01.x request message is sent by the POS when the
terminal is being “Opened” to validate that it has the correct program load and parameter load levels and is ready to process transactions. If
these conditions are met, the terminal responds with an Online response message to the POS and is then ready to collect customer data. If
the terminal has detected an unrecoverable error and cannot process transactions, or the 01.x request parameter load level is zero and the
terminal does not contain a parameter load, then the terminal responds with the proper Offline message and remains in the offline state.
When the terminal is ready, it responds with an Online response identifying the current program load and parameter load versions. Upon
sending the Online response, the terminal enters the Slide Card state. At this point, the terminal is ready to accept card data, account
selection, and PIN data.

Info
The 01.x message allows the merchant or financial institution to control the changing of the terminal program or parameters.
Software versions can be controlled by maintaining a file on the store controller that contains the program load and parameter
load version for each terminal.

The 01.x message data consists of two fields: program load version and parameter load version, which indicate the level of program and
parameter load that is currently contained in that terminal. The terminal validates that it contains the current levels before accepting the 01.
x request. If either level is incorrect, it requests a load of the pieces that are incorrect (see Scenarios, below). The incorrect level in the 01.x
request that is forcing the load is assigned to be the level of the new load. Zero (0000) in either field of the 01.x request is a special case
indicating to the terminal to use the level it currently contains of that piece. If the terminal does not contain any level for that piece, it
returns an Offline message; otherwise, the Online response contains the current level value for that piece.

Info
Sending the 01.x message with a value other than the current EFT level (0000) will trigger a download via TDA. When this
occurs, you may observe in the RBA Testing Tool execution of “VarSetByInt() code in procesOnlineReqRespMsg()”. When
this occurs, RBA exits and can no longer respond to further 00.x or 01.x messages.

Format Defined
Syntax

Sample

01.XXXXYYYY

01.02081234

Version Fields
Field

Value

Sample

XXXX

Program Load version

0208

YYYY

Parameter Load version

1234

Scenarios

155/854 Telium RBA Developer's Guide/ August 18, 2015

Terminal
contains

01.x Message
contains

Comparison results in…

01.02071235

01.02081234

A version change for both the Program Load and Parameter Load, resulting in '01.02081234'
being loaded to the terminal.

01.02071234

01.02081234

A version change for the Program Load, resulting in '01.02081234' being loaded to the terminal.

01.02071234

01.00000000

Proceeds online and conducts no version changes. The terminal continues with '01.02071234'.

01.x Online Request Message/Response Message Format
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M01_ONLINE_MSG
Message Identifier – ASCII – “01.”

4

4

Decimal

iConnectEFT Constant = P01_REQ_APPID for Request or
P01_RES_APPID for Response
Application ID (“0000” is the response)

8

4

Decimal

iConnectEFT Constant = P01_REQ_PARAMID for Request or
P01_RES_PARAMID for Response
Parameter ID (“0000” is the response).

12

1

Constant

ASCII control character – ETX

13

1

Binary

LRC check character.

Info
The default value is '0001'.

4_2_4 03.x: Set Session Key Message
The 03.x Session Key message is used to send a new session encryption key to the terminal. It is designed to flow in both directions as a
request/response pair, with a 03.x request flowing from the POS to the terminal and the 03.x response from the terminal to the POS. The
03.x request message data consists of the new session key used for data encryption. The 03.x response message contains a 3-character
status code indicating the result of the key injection process. The only allowable message response to the 03.x request is a 03.x response.

156/854 Telium RBA Developer's Guide/ August 18, 2015

Although this message can be sent at any time, it is recommended to send it before a new transaction has been started on the terminal. The
new session key is then stored in flash memory where it remains stored even in the event of a power loss.
03.x Session Key Request Message Format
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M03_SET_SESSION_KEY
Message Identifier – ASCII – “03.”

4

Variable

Alphanum

iConnectEFT Constant = P03_REQ_SESSION_KEY
Session Key (must be between 16 and 32 characters)

M

1

Constant

ASCII control character – ETX

M+1

1

Binary

LRC check character.

03.x Session Key Response Message Format
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M03_SET_SESSION_KEY
Message Identifier – ASCII – “03.”

4

16

Decimal

iConnectEFT Constant = P03_RES_SESSION_KEY_STATUS
Decimal Status Flag:
0 = Successful.
1 = Failed.

20

1

Constant

ASCII control character – ETX

21

1

Binary

LRC check character.

4_2_5 04.x: Set Payment Type Request
The 04.x Set Payment Type Request message flows from the POS to the terminal. This message is used to indicate the payment method if
selected by the cashier for the customer. The Force Type parameter in the request message determines whether to always force the
payment method or to only force the payment method when it has not been selected by the cardholder. Payment methods are defined in the
cards.dat configuration file. A field for the transaction amount is included in this message.

157/854 Telium RBA Developer's Guide/ August 18, 2015

The terminal responds to the POS with a 04.x response message indicating if the Force Type was successful, if it failed, or if the customer
changed the payment method. As with the request message, a field for the transaction amount is included in this message.
04.x Set Payment Type Request Message Format
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX.

1

3

Constant

iConnectEFT Constant = M04_SET_PAYMENT_TYPE.
Message Identifier – ASCII – "04."

4

1

Decimal

iConnectEFT Constant = P04_REQ_FORCE_PAYMENT_TYPE.
Force Type:
This setting determines whether the terminal should force a specific type of payment.
Allowable values are:
0 = Unconditional – always force payment type, even if the cardholder selects an alternate
payment type.
1 = Conditional – force payment type unless the cardholder selects a payment type.

5

1

Decimal

iConnectEFT Constant = P04_REQ_PAYMENT_TYPE.
Payment Type (as defined in cards.dat):
A = Debit.
B = Credit.
C = EBT Cash.
D = EBT Food Stamps.
E = Store Charge.
F = Loyalty.
G = PayPal.

These are only the default settings in cards.dat. Payment type can be configured such that
any value A – P refers to a payment type of choice.

158/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

6

Variable

Decimal

iConnectEFT Constant = P04_REQ_AMOUNT.
Transaction Amount.
3 to 9 characters.

If the transaction amount is zero, or if the transaction amount is less than 3 digits, then
preceding zeros will be added to the amount. If the amount exceeds 9 digits, the digits in
excess of 9 will be silently ignored. As examples:
0 amount = '000' sent.
8 amount = '008' sent.
78 amount = '078' sent.
If the transaction amount is blank, a 13.x: Amount Message is required for the amount.

M

1

Constant

ASCII control character – ETX.

M+1

1

Binary

LRC check character.

04.x Set Payment Type Response Message Format
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX.

1

3

Constant

iConnectEFT Constant = M04_SET_PAYMENT_TYPE.
Message Identifier – ASCII – "04."

4

1

Decimal

iConnectEFT Constant = P04_RES_FORCE_PAYMENT_TYPE.
Force Type:
0 = Successful.
1 = Failed.
2 = Changed customer selection.

159/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

5

1

Decimal

iConnectEFT Constant = P04_RES_PAYMENT_TYPE.
Payment Type (as defined in cards.dat):
A = Debit.
B = Credit.
C = EBT Cash.
D = ET Food Stamps.
E = Store Charge.
F = Loyalty.
G = PayPal.

These are only the default settings in cards.dat. Payment type can be configured such that
any value A – P refers to a payment type of choice.

6

Variable

Decimal

iConnectEFT Constant = P04_RES_AMOUNT.
Transaction Amount.
3 to 9 characters.

If the transaction amount is zero, or if the transaction amount is less than 3 digits, then
preceding zeros will be added to the amount. If the amount exceeds 9 digits, the digits in
excess of 9 will be silently ignored. As examples:
'0' amount – '000' sent.
'8' amount – '008' sent.
'78' amount – '078' sent.
If the transaction amount is blank, a 13.x: Amount Message is required for the amount.

M

1

Constant

ASCII control character – ETX.

M+1

1

Binary

LRC check character.

4_2_6 07.x: Unit Data Request
The Unit Data Request Message flows from the POS to the terminal. It is used to request the hardware and software configuration on the
terminal.
07.x Unit Data Request Format

160/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M07_UNIT_DATA
Message Identifier – ASCII – “07.”

4

1

Constant

ASCII control character – ETX

5

1

Binary

LRC check character.

07.x Unit Data Response Format
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M07_UNIT_DATA
Message Identifier – ASCII – “07.”

4

6

Alphanum

iConnectEFT Constant = P07_RES_MANUFACTURE
Manufacture ID – “INGNAR”

10

1

Constant

ASCII control character – FS

11

6

Alphanum

iConnectEFT Constant = P07_RES_DEVICE
Terminal ID – “iPP320,” “iPP350,” “iSC250,” "iSC350,” "iSC480," or “iMP350”

17

1

Constant

ASCII control character – FS

18

Variable

Alphanum

iConnectEFT Constant = P07_RES_UNIT_SERIAL_NUMBER
Unit Serial Number.

During Alert Irruption condition, "ALERT" is sent in place of the manufacture serial
number. Otherwise, it will send the serial number as normal.

M

1

Constant

ASCII control character – FS

161/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

M+1

Variable

Decimal

iConnectEFT Constant = P07_RES_RAM_SIZE
RAM size in KB.

N

1

Constant

ASCII control character – FS

N+1

Variable

Decimal

iConnectEFT Constant = P07_RES_FLASH_SIZE
Flash memory size in KB.

O

1

Constant

ASCII control character – FS

O+1

4

Decimal

iConnectEFT Constant = P07_RES_DIGITIZER_VERSION
Digitizer Version .

O+5

1

Constant

ASCII control character – FS

O+6

4

Decimal

iConnectEFT Constant = P07_RES_SECURITY_MODULE_VERSION
Security Module Version.

O+
10

1

Constant

ASCII control character – FS

O+
11

Variable

Decimal

iConnectEFT Constant = P07_RES_OS_VERSION

P

1

Constant

ASCII control character – FS

P+1

4

Decimal

iConnectEFT Constant = P07_RES_APPLICATION_VERSION

OS Version.

Application Version, data format is XXYY.
P+5

1

Constant

ASCII control character – FS

P+6

4

Decimal

iConnectEFT Constant = P07_RES_EFTL_VERSION
EFTL Version.

P+
10

1

Constant

ASCII control character – FS

P+
11

4

Decimal

iConnectEFT Constant = P07_RES_EFTP_VERSION
EFTP Version.

162/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

P+
15

1

Constant

ASCII control character – FS

P+
16

Variable

Alphanum

iConnectEFT Constant = P07_RES_MOB_DEV_BATTERY_LEVEL
Mobile Terminal Battery Level.
0-100% for a mobile terminal.
N/A for a non-mobile terminal.

Q

1

Constant

ASCII control character – FS

Q+1

Variable

Alphanum

iConnectEFT Constant = P07_RES_MOB_DEV_BATTERY_CHRG_STAT
Mobile Terminal Battery Charging State.
CHG = charging state.
DCHG = discharging state.
N/A = not available.

R

1

Constant

ASCII control character – FS

R+1

Variable

Alphanum

iConnectEFT Constant = P07_RES_MANUFACTURING_SERIAL_NUMBER
Manufacturing Serial Number

S

1

Constant

ASCII control character – FS

S+1

4

Alphanum

iConnectEFT Constant = P07_RES_EMV_DC_KERNEL_TYPE
Kernel type.

S+5

1

Constant

ASCII control character – FS

S+6

4

Alphanum

iConnectEFT Constant = P07_RES_EMV_ENGINE_KERNEL_TYPE
Engine kernel type.

S+
10

1

Constant

ASCII control character – FS

S+
11

4

Alphanum

iConnectEFT Constant = P07_RES_CLESS_DISCOVER_KERNEL_TYPE

S+
15

1

Contactless Discover kernel type.
Constant

ASCII control character – FS

163/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

S+
16

4

Alphanum

iConnectEFT Constant = P07_RES_CLESS_EXPRESSPAY_V3_KERNEL_TYPE

S+
20

1

Constant

ASCII control character – FS

S+
21

4

Alphanum

iConnectEFT Constant = P07_RES_CLESS_EXPRESSPAY_V2_KERNEL_TYPE

S+
25

1

Constant

ASCII control character – FS

S+
26

4

Alphanum

iConnectEFT Constant = P07_RES_CLESS_PAYPASS_V3_KERNEL_TYPE

S+
30

1

Constant

ASCII control character – FS

S+
31

4

Alphanum

iConnectEFT Constant = P07_RES_CLESS_PAYPASS_V3_APP_TYPE

S+
35

1

Constant

ASCII control character – FS

S+
36

4

Alphanum

iConnectEFT Constant = P07_RES_CLESS_VISA_PAYWAVE_KERNEL_TYPE

S+
40

1

Constant

ASCII control character – FS

S+
41

4

Alphanum

iConnectEFT Constant = P07_RES_CLESS_INTERAC_KERNEL_TYPE

S+
45

1

Constant

ASCII control character – FS

S+
46

Variable

Alphanum

iConnectEFT Constant = P07_RES_CLESS_INTERFACE_IS_SUPPORTED

Contactless ExpressPay v3 Kernel type.

Contactless ExpressPay v2 Kernel type.

Contactless PayPass v3 kernel type.

Contactless PayPass v3 application type.

Contactless VISA PayWave kernel type.

Contactless Interac kernel type.

"YES" = Contactless interface supported for transactions.
"NONE" = Contactless interface not supported for transactions.

T

1

Constant

ASCII control character – ETX

164/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

T+1

1

Binary

LRC check character.

RBA’s default configuration returns the full size of RAM and Flash memory in kilobytes. If compatibility with previous
versions (e.g., older than version 3.0.0), which limited the RAM and Flash memory fields to four digits (max 9999 kilobytes) is
desired, set '0013_0016' (Field Size for RAM and Flash Memory Size) to the value '0'. See also Compatibility Flags (compat.
dat).

4_2_7 08.x: Health Stat
The Health Stat Message flows from the POS to the terminal. It is used to request health and usage statistics from the terminal, as well as
identification information for the terminal. Refer to the below table for a description of the 08.x request message format.
08.x Health Stat Request Message Format
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M08_HEALTH_STAT
Message Identifier – ASCII – “08.”

4

1

Decimal

iConnectEFT Constant = P08_REQ_REQUEST_TYPE
Request Type:
0 = Retrieve Health Stats.
1 = Reset then Retrieve Health Stats.
2 = Battery Life Health Stats.

5

1

Constant

ASCII control character – ETX

6

1

Binary

LRC check character.

Info
IBMEFT downloading is not supported in this release. The following table will display the values of EFTL version and EFTP
version as “0000”.

165/854 Telium RBA Developer's Guide/ August 18, 2015

Info
Health Stat Response offsets 4 (Number of MSR swipes), offsets 9, 12 and 15 (Number of bad Track 1, 2, 3, reads), and offset
18 (Number of signature totals) reset to 0 (zero) after having sent an '08.1' reset message. All other 08.x responses remain intact
for the life of the terminal.

There are two possible response messages when the Health Stat Request message is received. The response messages are generated based
on the request type:
Request type = 0 – return Health Stats (see Health Stat Response Message Format in first table below).
Request type = 1 – reset and then retrieve Health Stats (refer Health Stat Response Message Format in first table below).
Request type = 2 – return Battery Life Health Stats (refer Health Stat Battery Life Response Message Format in second table
below).
08.x Health Stat Response Message Format (returned in response to 08.0 "Retrieve Health Stats" message)
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M08_HEALTH_STAT
Message Identifier – ASCII – “08.”

4

4

Decimal

iConnectEFT Constant = P08_RES_COUNT_MSR_SWIPES
Number of MSR Swipes.

8

1

Constant

ASCII control character – FS (0x1c)

9

2

Decimal

iConnectEFT Constant = P08_RES_COUNT_BAD_TRACK1_READS
Number of bad Track 1 reads.

11

1

Constant

ASCII control character – FS (0x1c)

12

2

Decimal

iConnectEFT Constant = P08_RES_COUNT_BAD_TRACK2_READS
Number of bad Track 2 reads.

14

1

Constant

ASCII control character – FS (0x1c)

15

2

Decimal

iConnectEFT Constant = P08_RES_COUNT_BAD_TRACK3_READS
Number of bad Track 3 reads.

17

1

Constant

ASCII control character – FS (0x1c)

166/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

18

4

Decimal

iConnectEFT Constant = P08_RES_COUNT_SIGNATURES
Number of signature totals.

22

1

Constant

ASCII control character – FS (0x1c)

23

4

Decimal

iConnectEFT Constant = P08_RES_COUNT_REBOOT
Number of reboots.

27

1

Constant

ASCII control character – FS (0x1c)

28

Variable

Alphanum

iConnectEFT Constant = P08_RES_DEVICE_NAME
Terminal Name.

M

1

Constant

ASCII control character – FS (0x1c)

M+1

Variable

Alphanum

iConnectEFT Constant = P08_RES_SERIAL_NUMBER
Unit serial number.

During Alert Irruption condition, "ALERT" is sent in place of the manufacture serial
number. Otherwise, it will send the serial number as normal.

N

1

Constant

ASCII control character – FS (0x1c)

N+1

Variable

Decimal

iConnectEFT Constant = P08_RES_OS_VERSION
OS version.

O

1

Constant

ASCII control character – FS (0x1c)

O+1

Variable

Decimal

iConnectEFT Constant = P08_RES_APP_VERSION
Application Version, format is MMNN (where MM = Major version, NN = Minor version).

P

1

Constant

ASCII control character – FS (0x1c)

P+1

Variable

Decimal

iConnectEFT Constant = P08_RES_SECURITY_LIB_VERSION
Security library version.

Q

1

Constant

ASCII control character – FS (0x1c)

167/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

Q+1

4

Decimal

iConnectEFT Constant = P08_RES_ TDA_VERSION
TDA version.

Q+5

1

Constant

ASCII control character – FS (0x1c)

Q+6

4

Decimal

iConnectEFT Constant = P08_RES_EFTL_VERSION
EFTL version

Q+
10

1

Constant

ASCII control character – FS (0x1c)

Q+
11

4

Decimal

iConnectEFT Constant = P08_RES_EFTP_VERSION

Q+
15

1

Constant

ASCII control character – FS (0x1c)

Q+
16

Variable

Decimal

iConnectEFT Constant = P08_RES_RAM_SIZE

R

1

Constant

ASCII control character – FS (0x1c)

R+1

Variable

Alphanum

iConnectEFT Constant = P08_RES_ FLASH_SIZE

EFTP version .

RAM size in KB.

Flash memory size in KB.
S

1

Constant

ASCII control character – FS (0x1c)

S+1

Variable

Alphanum

iConnectEFT Constant = P08_RES_MANUFACTURE_DATE
Manufacture Date.

T

1

Constant

ASCII control character – FS (0x1c)

T+1

1

Decimal

iConnectEFT Constant = P08_RES_CPEM_TYPE
CPEM type.
0 = none.
1 = Internal.

T+2

1

Constant

ASCII control character – FS (0x1c)

168/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

T+3

Variable

Alphanum

iConnectEFT Constant = P08_RES_PEN_STATUS
Pen Status (see Note).
OK
FAIL
UNKNOWN
UNSUPPORTED DEVICE

Note
Currently this is not supported in Telium terminals and the field will return
"UNSUPPORTED_DEVICE.

U

1

Constant

ASCII control character – FS (0x1c)

U+1

Variable

Alphanum

iConnectEFT Constant = P08_RES_APP_NAME
Application Name.

W

1

Constant

ASCII control character – FS (0x1c)

W+1

6

Alphanum

iConnectEFT Constant = P08_RES_MANUFACTURE_ID
Manufacture ID – “INGNAR”

W+7

1

Constant

ASCII control character – FS (0x1c)

W+8

Variable

Constant

iConnectEFT Constant = P08_RES_DIGITIZER_VERSION
Digitizer Version.

X

1

Constant

ASCII control character – FS (0x1c)

X+1

Variable

Decimal

iConnectEFT Constant = P08_RES_MANUFACTURING_SERIAL_NUMBER
Manufacturing Serial Number.

Y

1

Constant

ASCII control character – ETX

Y+1

1

Binary

LRC check character.

Health Stat Battery Life Response Message Format (returned in response to 08.2 "Battery Life Health Stats" message)
Offset

Length

Type

Description

169/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

Message Identifier – ASCII – “08.”

4

4

Decimal

Number of times MSR was enabled.

8

1

Constant

ASCII control character – FS (0x1c)

9

4

Decimal

Total time MSR was enabled.

13

1

Constant

ASCII control character – FS (0x1c)

14

4

Decimal

Average MSR enable time.

18

1

Constant

ASCII control character – FS (0x1c)

19

4

Decimal

Number of times contactless was enabled.

23

1

Constant

ASCII control character – FS (0x1c)

24

4

Decimal

Total time contactless was enabled.

28

1

Constant

ASCII control character – FS (0x1c)

29

4

Decimal

Average contactless enable time.

33

1

Constant

ASCII control character – FS (0x1c)

34

4

Decimal

Number of times smart card was enabled.

38

1

Constant

ASCII control character – FS (0x1c)

39

4

Decimal

Total smart card enabled time.

43

1

Constant

ASCII control character – FS (0x1c)

44

4

Decimal

Average smart card enable time.

48

1

Constant

ASCII control character – FS (0x1c)

49

4

Decimal

Number of times barcode scanner was enabled.

170/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

53

1

Constant

ASCII control character – FS (0x1c)

54

4

Decimal

Total barcode scanner enable time.

58

1

Constant

ASCII control character – FS (0x1c)

59

4

Decimal

Average barcode scanner enable time.

63

1

Constant

ASCII control character – FS (0x1c)

64

4

Decimal

Number of times Bluetooth was searching.

68

1

Constant

ASCII control character – FS (0x1c)

69

4

Decimal

Total Bluetooth search time.

73

1

Constant

ASCII control character – FS (0x1c)

74

4

Decimal

Average Bluetooth search time.

78

1

Constant

ASCII control character – FS (0x1c)

79

4

Decimal

Number of times Bluetooth was connected.

83

1

Constant

ASCII control character – FS (0x1c)

84

4

Decimal

Total time Bluetooth was connected.

88

1

Constant

ASCII control character – FS (0x1c)

89

4

Decimal

Average Bluetooth connection time.

93

1

Constant

ASCII control character – FS (0x1c)

94

4

Decimal

Number of times display backlight was enabled.

98

1

Constant

ASCII control character – FS (0x1c)

99

4

Decimal

Total time display backlight was enabled.

103

1

Constant

ASCII control character – FS (0x1c)

171/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

104

4

Decimal

Average backlight enable time.

108

1

Constant

ASCII control character – ETX

109

1

Binary

LRC check character

Although all terminals will respond to the '08.2' message, only the battery powered terminals will return meaningful results. All
other terminals will return zero for each field.

4_2_8 09.x Card Status Message
The 09.x Card Status message flows from the terminal to the POS. This message provides information about the card such as the card type,
message version, transaction type and card status. It is primarily used for smart cards to provide card insertion status (e.g., inserted,
removed).
Anytime a WIC, EMV, or other type of smart card is inserted in the terminal to initiate a transaction, the terminal sends the appropriate
message indicating that the card has been inserted. The card reader must be enabled, or the message will not be sent. This mitigates battery
consumption while not in use. Additionally, the 09.x message will be sent if a 23.x message is sent to the terminal.
In the event a damaged or invalid card is inserted, the terminal will send a '09.990200P' message to inform the POS that his has occurred.
An invalid card type may include other smart cards if disabled (e.g., disabled EMV card; '0019_0001' = '0'). Refer to the following table
which provides example 09.x Card Status messages.
Example 09.x Card Status Messages
Card Type

Action

09.x Card Status Message

EMV

Card inserted.

09.020201I

Card removed.

09.020201R

Card inserted.

09.010201I

Card removed.

09.010201R

Generic Smart Card

Card inserted.

09.000201I

Damaged or Invalid Card

Card inserted.

09.990200P

WIC

In order to avoid interrupting the EMV/WIC transaction flow, 09.x status messages conveying card insertion status (e.g., card inserted,
card removed) are only sent before the transaction is started. The value of parameter '0007_0047' in Main Flow (mainFlow.dat) determines
when and whether the 09.x message is sent.
Refer to the following table which describes the 09.x Card Status message format.

172/854 Telium RBA Developer's Guide/ August 18, 2015

09.x Card Status Message Format
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M09_SET_ALLOWED_PAYMENT
Message Identifier – ASCII – '09.'

4

2

Numeric

iConnectEFT Constant = P09_RES_CARD_TYPE
Card type:
00 = Generic smart card (SMC).
01 = WIC smart card.
02 = EMV smart card.
99 = Damaged or invalid card.

The 09.x Card Status message only returns status for smart cards.

6

2

Numeric

Message version/variant = P09_RES_MSG_VERSION
0 = Original message version only for WIC smart cards.
1 = Current message version for WIC and EMV smart cards.
02 = Message version upgraded to two digits.

Future variants may be implemented for all card types.

8

2

Numeric

Transaction type = P09_RES_TRANSACTION_TYPE
00 = Unknown (typically for invalid cards).
01 = Purchase.

Future transaction types maybe implemented (e.g., refund, debit).

173/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

10

1

Alphanumeric

Card status = P09_RES_CARD_STATUS
I = SMC inserted.
R = SMC removed.
P = Unknown problem.

Future status options may be added, especially for other card types.

11

1

Constant

ASCII control character – ETX

12

1

Binary

LRC check character

4_2_9 09.x: Set Allowed Payments Message
The 09.x Set Allowed Payment Message flows from the POS to the terminal. It is used to enable or disable the various payments
configured in the terminal. The terminal supports up to sixteen payment types, which are defined in the config.dfs file. A payment
type is represented by a flag. The array of flags may include a subset of the flags. If the message only includes five flags, the first five
payment types are set. The other eleven are not changed.
09.x Set Allowed Payments Message Format
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M09_SET_ALLOWED_PAYMENT
Message Identifier – ASCII – “09.”

4

16

Decimal

iConnectEFT Constant = P09_REQ_ENABLE_PAYMENT_ARRAY
Enable Payment Array
Array of 16 characters, one for each payment type.
0 = Disabled
1 = Enabled
Example: If the payment type field is set to '1011000000000000', payment types 1, 3 and 4 are enabled.
All others are disabled.

20

1

Constant

ASCII control character – ETX

21

1

Binary

LRC check character

174/854 Telium RBA Developer's Guide/ August 18, 2015

4_2_10 10.x: Hard Reset Message
The 10.x Hard Reset message is architected to flow in either direction. It can be sent by the POS to reset the terminal, or by the terminal to
notify the POS that the customer has forced a reset by pressing the CANCEL key on the terminal.
The 10.x message, when sent by the POS to the terminal, forces the terminal to the beginning of the transaction. Its purpose is to clear out
the previous transaction or any activity at the terminal since the previous transaction. The POS sends a 10.x message at the end of every
transaction.
The 10.x message, when sent by the terminal to the POS, notifies the POS that the customer has pressed the CANCEL key, causing a reset.
The terminal clears out any previous actions and returns to the ready state. The customer may choose another form of payment or redo the
payment from the start. The terminal sends the 10.x message to the POS only if it has received an Amount message from the POS and not
yet responded with the Authorization Request message. If those two conditions are not met, the 10.x message is not sent to the POS. Upon
receiving a 10.x message, the POS sends a current Amount message to the terminal to allow the new transaction to complete.
The RBA decides when to clear the scrolling receipt based on information from two sources.
Source #1 - the 10.x message parameter value
Source #2 - the RBA local configuration parameter, listed in mainFlow.dat file, index '0007_0007', Clear line item display on
reset (0 = don't clear, 1 = clear).
The RBA clears the scrolling receipt from the terminal screen in the following conditions:
If the 10.x message received from the POS does not specify if the line display should be cleared or not, the display is cleared based
on the RBA local configuration selection.
If the 10.x message received from the POS includes the parameter, then the parameter included in the message is used to select the
clearing method, which is:
0 – Do not clear the receipt.
1 – Clear the receipt.
If the RBA receives a message other than the 10.x, which also resets the transaction, such as the 01.x Online Message, or 30.x: Advertising
Request Message, the receipt is cleared based on the configuration selection.
10.x Hard Reset Message Format (from POS)

175/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M10_HARD_RESET
Message Identifier – ASCII – “10.”

4

0 or 1

Decimal

iConnectEFT Constant = P10_REQ_CLEAR_LINE_DISPLAY
Clear Line Display (optional)
0 = Do not clear line display
1 = Clear line display
If invalid value or if left out of message, the setting in mainFlow.dat ('0007_0007') will be used.
This field is never sent to the POS.

M

1

Constant

ASCII control character – ETX

M+1

1

Binary

LRC check character

If the 10.x message is sent out by the RBA, the customer has either cancelled the transaction or declined the total. In either case, a new
amount message must be sent to the terminal.
If the customer pushes the [Cancel] on the terminal, the following 10.x message is sent:
10.x Hard Reset Message Format (from Terminal)
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M10_HARD_RESET
Message Identifier – ASCII – “10.”

4

1

Decimal

iConnectEFT Constant = P10_RES_DESTINATION
Destination (optional - only sent if '0013_0009' is set to '1').
0 = Cancel transaction
1 = Decline total

5

1

Constant

ASCII control character – ETX

6

1

Binary

LRC check character

176/854 Telium RBA Developer's Guide/ August 18, 2015

4_2_11 11.x: Status Message
4_2_11_1 Overview of the 11.x Status Message
The 11.x Status message has been architected to flow in both directions as a request/response pair. It is defined to allow the POS system to
keep track of the state of the terminal. The POS sends the 11.x request to the terminal to request status. The customer input returns a 11.x
response, indicating its current status.
The 11.x request from the POS contains no Message Data. The 11.x response contains a two-character state code followed by a variable
field that represents the terminal’s current display message.
The POS can send the 11.x request message at any time. The 11.x response message is only sent in response to a 11.x request. The
allowable message response to the 11.x request is a 11.x response or a 00.x Offline message. A 00.x message is returned if the terminal is
in offline state; otherwise, an 11.x response message is returned. A new "Idle" status has been added to the 11.x Status response message.
When the terminal is in idle mode, this message will be returned with a '99' status value and default "Idle" text in the Text field.

4_2_11_2 Appending the Form Name to the 11.x Status Response Message
An alternate form of the 11.x Status request message has been added so that the form name can be appended to the status response
message, without the ".K3Z" extension (e.g., CSWIPE, CLSWIPE). The new '11.01' Status Request is used to retrieve this additional
information. Refer to the following example:
1. POS sends a '11.01' message to the terminal.
2. Terminal returns a '11.01Slide Card[FS]CLSWIPE' message, indicating that it is displaying the text "Slide Card" on the

"CLSWIPE" card swipe form. Because the current text display length is variable, a [FS] field separator character is inserted.
The following tables describe the 11.x Status Request message and 11.x Status Response message formats.
11.x Status Request Message Format
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M11_STATUS
Message Identifier – ASCII – “11.”

4

2

Decimal

iConnectEFT Constant = P11_REQ_GET_CURRENT_FORM_NAME
01 = Request Form Name.

The Request Form Name field is optional.

6

1

Constant

ASCII control character – ETX

7

1

Binary

LRC check character.

177/854 Telium RBA Developer's Guide/ August 18, 2015

11.x Status Response Message Format
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M11_STATUS
Message Identifier – ASCII – “11.”

4

2

Decimal

iConnectEFT Constant = P11_RES_STATUS_INDICATOR
State Indicator:
00 = Offline.
01 = Slide/Insert/Tap Card.
02 = Transaction Type.
03 = Enter PIN.
04 = Amount.
05 = Processing.
06 = Approved/Declined.
10 = Please Sign.
11 = Signature Accepted.
12 = Card / Input Capture.
13 = Card / Input Data Available.
14 = Select Language.
15 = Advertising, Offline Advertising.
16 = Menu.
17 = Textbox.
18 = EMV.
19 = WIC.
20 = Smart card.
99 = Idle.

State indicator 14 (Select Language) will be returned only if the mainflow.dat parameter
'0007_0004' is set to '0' (zero). See also, section Main Flow (mainFlow.dat).

6

Variable

Alphanum

iConnectEFT Constant = P11_RES_CURRENT_DISPLAY_TEXT
Text indicating current display on terminal 0 to 32 ASCII characters on first message line.

178/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

M

1

Constant

ASCII control character – FS (0x1C)

This field separator is optional. It is only present when responding to a '11.01' Status
Request, which specifies that the form name is to be appended to the status response
message.

M+1

Variable

Alphanum

iConnectEFT Constant = P11_RES_CURRENT_FORM_NAME
Current form name.

This field is optional. It is only present when responding to a '11.01' Status Request, which
specifies that the form name is to be appended to the status response message.

N

1

Constant

ASCII control character – ETX

N+1

1

Binary

LRC check character.

4_2_12 12.x: Account Message
The POS sends the 12.x Account Message to the terminal to enable the terminal to complete an EFT tender when it cannot read the
required information from the card. This process is referred to throughout this document as a manual entry.
Data in the 12.x message is of variable length. The account number is separated from the expiration date by the equals sign (= ). The
account data may be keyed in by the cashier or read in the POS MSR reader.
The POS can send the 12.x message to the terminal when both these conditions are true:
The POS operator has keyed in an account number and expiration date.
The POS is expecting EFT tender.
The POS operator or customer must recognize that the terminal is not accepting the card data (display continues to show 'Slide Card'). The
operator then keys in the account number and expiration date from the card at the POS keyboard, which then sends the 12.x message to the
terminal. The terminal accepts the Account Message data as though it had been read from the card, and proceeds with the account selection
and PIN entry. The data in the 12.x message format is included in the 50.x: Authorization Request message constructed by the terminal.
When sending discretionary data using the 12.x message, only numeric data should be sent. Non-numeric data will not be accepted. An
invalid example and valid example are given below:
Example 1: Invalid Format
4012345678909= 0905000399818VISA/INGENICO
In this example, the discretionary data will be interpreted as invalid.
Example 2: Valid Format
4012345678909= 0905000399818

179/854 Telium RBA Developer's Guide/ August 18, 2015

This format will be accepted by the terminal and the transaction will continue in the normal flow. Refer to the following table which
describes the 12.x message format.
12.x Account Request Message Format
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX.

1

3

Constant

iConnectEFT Constant = M12_ACCOUNT.
Message Identifier – ASCII – '12.'

4

Variable

Alphanum

iConnectEFT Constant = P12_REQ_ACCOUNT_NUMBER.
Account Number (13 to 24 characters).

M

1

Constant

iConnectEFT Constant = P12_REQ_CVV_SEPARATOR
ASCII Character – '= '

M+1

4

Decimal

iConnectEFT Constant = P12_REQ_EXPDATE.
Expiration date in YYMM format.

M+5

Variable

Numeric

iConnectEFT Constant = P12_REQ_DISCRETIONARY_DATA.
Discretionary data (optional).

N

1

Constant

Field Separator – [FS].

N+1

Variable

Alphanum

iConnectEFT Constant = P12_REQ_CVV_NUMBER.
CVV number.

O

1

Constant

ASCII control character – ETX.

O+1

1

Binary

LRC check character.

The 12.x Message follows the same format as a card’s Track 2 data. As such, it should only contain numeric data and field
separators.

A 12.x response message will be sent to POS to indicate if the 12.x request message was successful. See response message format below.

The response can be enabled or disabled by setting compat.dat configuration parameter '0013_0021'.

12.x Account Message Response

180/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX.

1

3

Constant

iConnectEFT Constant = M12_ACCOUNT
Message Identifier – ASCII – '12.'

4

1

Decimal

iConnectEFT Constant = P12_RES_STATUS
Response status:
'0' = Successful.
'1' = Failed, due to one of the following:
incorrectly formatted data
value of '0091_0030' = '1' when encryption is enabled
a card has already been swiped

5

1

Constant

ASCII control character – ETX.

6

1

Binary

LRC check character.

4_2_13 13.x: Amount Message
The 13.x Amount Message flows from the POS to the terminal. It is used to provide the terminal with the current Balance Due amount,
and to request an Authorization Request message from the terminal.
The Amount message has variable length. It may have a minimum of 1 and a maximum of 16 amount fields, separated by the FS (Field
Separator) character. Each individual amount field length is from 3 to 9 digits, ASCII string, representing the amount in cents, without the
decimal point (e.g., $10.85 is represented as '1085'). For following example, the following message includes a Current Transaction
Balance Due of $12.34.
13.123456787699
A 13.x message with a single amount field is acceptable for compatibility with the existing POS systems. When received, the Amount
Index value from the Cards section of config.dfs is ignored, and the amount value is unconditionally accepted.
When a 13.x message with multiple fields is received, only one of the fields is used. The Amount Index value from the Cards section of
config.dfs (see Card Configuration Table) selects the correct amount field to use with the authorization message.
If the Amount Index value is '0', or if it points a field that does not exist, the RBA goes to offline mode.
If the Amount Index points to a valid value, the amount that the index points to is used in the 50.x: Authorization Request message.
Index 1 points to the first amount field in the 13.x message (e.g., '1234' in the example above), index 2 to second field ('5678' in the
example above), and so on. The Amount Index applies to 13.x message with multiple fields only.
When the purchase amount value is received in a message other than a 13.x message, such as a 04.x: Set Payment Type Request or 28.x:
Set Variable Request, it is handled the same as the 13.x message with a single amount field.
When the purchase amount is received in a 13.x message with multiple fields, the host variable “Amount Due” value is not available until
the payment is selected.
The purchase amount may be received in the following messages:

181/854 Telium RBA Developer's Guide/ August 18, 2015

13.x, amount
04.x: Set Payment Type Request, forced payment with amount (single amount field)
28.x: Set Variable Request, set amount (single amount field)
13.x Amount Message Format
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M13_AMOUNT
Message Identifier – ASCII – “13.”

4

Variable

Decimal

iConnectEFT Constant = P13_REQ_AMOUNT
Current Transaction Balance Due (3 to 9 characters).
ASCII string representing the BAL DUE in cents (e.g., $123.89 BAL DUE is represented by 12389).

M

1

Constant

Field separator (optional for alternate amount).

M+1

Variable

Decimal

iConnectEFT Constant = P13_REQ_AMOUNT
Next Balance Due (3 to 9 characters).
ASCII string representing the BAL DUE in cents (e.g., $123.89 BAL DUE is represented by 12389)
(optional for alternate amount).

P

1

Constant

ASCII control character – ETX

P+1

1

Binary

LRC check character.

4_2_14 14.x: Set Transaction Type
The 14.x Set Transaction Type message flows from the POS to the terminal. It is only required if the transaction is not a sale. The
application flow changes based on the transaction type. For example, cash back is disabled for non-sale transactions.
14.x Set Transaction Type Format

182/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M14_SET_TXN_TYPE
Message Identifier – ASCII – “14.”

4

2

Decimal

iConnectEFT Constant = P14_REQ_TXN_TYPE
Set the transaction type:
01 = Sale.
02 = Void.
03 = Return.
04 = Void Return.

6

1

Constant

ASCII control character – ETX

7

1

Binary

LRC check character.

4_2_15 15.x: Soft Reset Message
The 15.x Soft Reset Message flows from the POS to the terminal. It is used to cancel or clear a specific function of the transaction.
15.x Soft Reset Message Format

183/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M15_SOFT_RESET
Message Identifier – ASCII – “15.”

4

1

Decimal

iConnectEFT Constant = P15_REQ_RESET_TYPE
Reset type:
0 = Hard (same as 10.x message).
1 = Cancel Signature (iSC250/iSC350/iSC480 only).
2 = Cancel PIN.
3 = Reset Amount.
4 = Reset Signature (iSC250/iSC350/iSC480 only).
5 = Continue Action.
6 = Stop Action, cancel process started by on-demand message.
7 = Reset PIN.
8 = Clear Line Item Display.

5

1

Constant

ASCII control character – ETX

6

1

Binary

LRC check character.

184/854 Telium RBA Developer's Guide/ August 18, 2015

4_2_16 16.x: Contactless Mode Request
4_2_16_1 Overview of the 16.x Contactless Mode Request Message
The 16.x Contactless Mode Request message is used by the terminal to send unsolicited notification to the POS that one or more cards
have been detected in the contactless field. As part of this notification, the UID, card index number and card type are sent. A response
from the POS is not required. This message is used to support Contactless Key Card, Google Wallet, and Softcard SmartTap features. A
message subtype included in the 16.x request message determines the message usage (e.g., Contactless Key Card, Google Wallet, Softcard
SmartTap). There are two message format deltas from the standard 16.x request message format which support Contactless Key Card.
These deltas which support Google Wallet and Softcard SmartTap are described in the tables provided for the 16.x message format.

4_2_16_2 16.x Contactless Mode Request Message Format
The following tables describes the 16.x Contactless Mode Request message content for Contactless Key Card, Google Wallet, and
Softcard SmartTap.
16.5: Contactless Mode Request Format for Contactless Key Card
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

Message Identifier – ASCII – "16."

4

1

Alphanum

Message subtype = '5' indicating Contactless key Card mode.
1 = Google Wallet.
4 = Softcard SmartTap
5 = Contactless Key Card mode.
All other values are reserved.

5

1

Alphanum

Message status.
0 = Success.
1 = Failure.
2 = Unsupported message type.
5 = Data overflow. The data to be returned exceeds the communication buffer depth.

6

1

Alphanum

Flag indicating whether or not additional data is available.
0 = No additional data is available.
1 = Additional data is available.
For Contactless Key Card, this flag will always be "0".

7

1

Alphanum

Card index number.
The first card detected will always have a value of "0".

185/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

8

1

Alphanum

Card type.
0 = Unsupported or unknown card type.
1 = MIFARE Classic 1K.
2 = MIFARE Ultralight.
3 = MIFARE Mini.
4 = MIFARE Classic 4K.

9

Variable

Hex-ASCII

UID of the card.
MIFARE Classic 1K (format is 4-byte NUID, 8 hex-ASCII digits).
MIFARE Ultralight (format is 7-byte NUID, 14 hex-ASCII digits).
MIFARE Mini (format is TBD).
MIFARE Classic 4K (format is TBD).

M

Constant

ASCII control character – ETX

M+1

Binary

LRC check character

If multiple cards are detected, an ASCII file separator character (0x1C) will follow the UID of the previous card, which is then
followed by the card index number, card type and UID of the next card. Up to 9 cards can be detected in a single tap.

186/854 Telium RBA Developer's Guide/ August 18, 2015

16.1: Contactless Mode Request Format for Google Wallet
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

Message Identifier – ASCII – “16.”

4

1

Alphanum

Message subtype = '1' indicating Google Wallet.
1 = Google Wallet mode.
4 = Softcard SmartTap
5 = Contactless Key Card mode.
All other values are reserved.

5

1

Alphanum

Message status.
0 = Success.
1 = Failure.
2 = Unsupported message type.
5 = Data overflow. The data to be returned exceeds the communication buffer depth.

6

1

Alphanum

Flag indicating whether or not additional data is available.
0 = No additional Google Wallet data is available.
1 or greater = Additional Google Wallet data is available.

7

Variable

Alphanum

ASCII representation of Google Wallet hex data.

M

1

Constant

ASCII control character – ETX

M+1

1

Binary

LRC check character

187/854 Telium RBA Developer's Guide/ August 18, 2015

16.4: Contactless Mode Request Format for Softcard SmartTap
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

Message Identifier – ASCII – “16.”

4

1

Alphanum

Message subtype = '4' indicating Softcard SmartTap.
1 = Google Wallet mode.
4 = Softcard SmartTap
5 = Contactless Key Card mode.
All other values are reserved.

5

1

Alphanum

Message status.
0 = Success.
1 = Failure.
2 = Unsupported message type.
5 = Data overflow. The data to be returned exceeds the communication buffer depth.

6

1

Alphanum

Flag indicating whether or not additional data is available.
0 = No additional Softcard SmartTap data is available.
1 or greater = Additional Softcard SmartTap data is available.

7

Variable

Alphanum

ASCII representation of Softcard SmartTap hex data.

M

1

Constant

ASCII control character – ETX

M+1

1

Binary

LRC check character

4_2_16_3 Google Wallet Mode Message
A Google Wallet Mode message flows from the POS to the terminal. it is used to set the Google Wallet mode for reading track data during
Google Wallet transactions. The following table describes this message format.
16.x Google Wallet Message Format

188/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Format

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

Message Identifier – ASCII – "16."

4

1

Decimal

Google Wallet mode.
2 = PPSE first.
3 = MIFARE first.

5

1

Constant

ASCII control character – ETX

6

1

Binary

LRC check character

4_2_16_4 Usage Examples
The following examples illustrate 16.x message usage for sending the UID to the POS.
Example 1: MIFARE Classic 1K (with 4-byte NUID), NUID value = {0x4B, 0xE9, 0x1B, 0x4C}
Sequence

Message Content

1

16.500014BE91B4C

POS

Terminal

Example 2: MIFARE Ultralight (with 7-byte NUID), NUID value = {0x04, 0x21, 0xDD, 0x09, 0x36, 0x02, 0x80}
Sequence

Message Direction

Message Content

1

Terminal to POS

16.500020421DD09360280

POS

Terminal

4_2_16_5 Google Wallet Data Message
Once a mobile phone with the installed Google Wallet application enters the contactless field and connects with the terminal, the terminal
will read the information (e.g., gift card, Loyalty card). A 16.x data message is sent to the POS which will include status and data
availability. If the read operation was successful, the message will indicate successful data retrieval and available data. The following
example message illustrates a successful read operation.
Example 1:
'16.101'
If the read indicates an unsupported type or data length exceeding the communication buffer length, this information will be provided in
the 16.x data message. Refer to the following example messages.
Example 2:
Read indicates an unsupported type.

189/854 Telium RBA Developer's Guide/ August 18, 2015

'16.120'
Example 3:
Read indicates that the data length exceeds the communication buffer length.
'16.151'

Telium RBA messaging is ASCII-based. Accordingly, any binary data must be sent as hex-ASCII.

For details about this message, including a list of supported contactless modes, please refer to one of the following Ingenico
documents: DIV350980 Rev A Isis SmartTap Implementation Guide; DIV350955 Rev A Google Wallet Implementation
Guide.

To read and/or change the contactless mode, use variable 412 (Contactless Mode) with the 29.x Get Variable Request and 28.x
Set Variable Request messages.

4_2_17 17.x: Merchant Data Write
4_2_17_1 Overview of the 17.x Merchant Data Write Message
The 17.x Merchant Data Write Message is used to support the following RBA features:
Contactless Key Card
Google Wallet
Softcard SmartTap
The 17.x Merchant Data write message is used by the POS to send Contactless Key Card commands to the terminal and return command
execution status. This message can also be used to inject Merchant ID/Secret Pairs for Google Wallet or to configure the terminal for
Softcard SmartTap. A message subtype included in the 17.x request message determines the message usage (e.g., Contactless Key Card,
Google Wallet, Softcard SmartTap). There are two message format deltas from the standard 17.x request and 17.x response formats used
to support Contactless Key Card. These deltas which support Google Wallet and Softcard SmartTap are described in the tables provided
for the 17.x Merchant Data Write Request Message Format and 17.x Merchant Data Write Response Message Format.
Refer to 17.x Merchant Data Write Message Usage Examples for usage examples with the 17.x Merchant Data Write Message.

4_2_17_2 Contactless Key Card
The POS sends Contactless Key Card commands to the terminal using the 17.x Merchant Data write Request message. This message
includes the command type (e.g., Authenticate sector with Key A (MIFARE Classic 1K only)). Also included in this message is the index
number of the card where the command is to be executed, the command ID, and a flag which determines if the terminal should send a 36.x
Notification of Command Execution message once the command has been executed. The 17.x Merchant Data Response message returns
the command status (e.g., successful, failed), confirms the command type and availability of data, and provides the actual data which was
requested (e.g., Authenticator Sector data).

190/854 Telium RBA Developer's Guide/ August 18, 2015

4_2_17_3 Google Wallet Merchant ID/Secret Pair Injection
When the 17.x Merchant Data Write Request message is received with a message subtype of '1,' the '17.1' message follows a format
specific to Google Wallet. The POS uses the Merchant ID/Secret Pair Injection Request message to inject the terminal with Merchant ID
/secret pairs used to process Google Wallet transactions. A Merchant ID/Secret Pair Injection Request message must be sent each time the
terminal is turned on or rebooted in order for the terminal to support Google Wallet transactions.
All Merchant ID/secret pairs to be injected must be included in the same 17.x message using field separator [FS] characters. Once a '17.1'
Merchant ID/Secret Pair Injection Request message is received, all previously injected Merchant ID/secret pairs are replaced with those
included in the new message. A '17.1' Merchant ID/Secret Pair Injection Response message is sent from the terminal to the POS indicating
injection status (e.g., successful, failed). A '17.1' Merchant ID/Secret Pair Injection Request message received with no Merchant ID/secret
pairs will prompt the terminal to clear all injected Merchant ID/secret pairs.

4_2_17_4 Softcard SmartTap
The POS uses the 17.x: Merchant Data Write Request message to configure the terminal to support the Softcard SmartTap feature. When
this message is received with a message subtype of '4', the RBA will configure the terminal based on the configuration data included in the
request message. When configuration is completed, the terminal sends a 17.x Merchant Data Response message to the POS indicating
success status.

4_2_17_5 17.x Merchant Data Write Request Message Format
Refer to the following tables which describes the 17.x Merchant Data Write Request message format for Contactless Key Card, Google
Wallet, and Softcard SmartTap, respectively.
17.5 Merchant Data Write Request Message Format for Contactless Key Card
Offset

Length

Type

Description

0

1

Constant

ASCII control character - STX

1

3

Constant

Message Identifier – ASCII – “17.”

4

1

Alphanum

Message subtype.
1 = Google Wallet.
4 = SoftCard SmartTap.
5 = Contactless Key Card mode.
All other values are reserved.

191/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

5

1

Alpha

Command type.
A = Authenticate sector with Key A (MIFARE Classic 1K only).
B = Authenticate sector with Key B (MIFARE Classic 1K only).
R = Read
For MIFARE Classic 1K, read 16-byte block from authenticated sector.
For MIFARE Ultralight, read 4 consecutive 4-byte pages.
W = Write.
For MIFARE Classic 1K, write 16-byte block to authenticate sector.
For MIFARE Ultralight, write 4-byte pages.
I = Increment (future use).
D = Decrement (future use).
M = Move (future use).
C = Complete Tap.

Not all sectors and blocks are available for user data when using Classic MIFARE cards.
Care must be given to not write to reserved blocks that could cause the card to be
unusable. Block 0 of sector 0 is reserved by the card manufacturer. For every sector, block
3 is reserved for the access restrictions for each of the key types (A and B). User data can
generally be written to sector 0, blocks 1 and 2, and for Sectors 1 - X, blocks 0, 1, and 2
totaling 752 bytes for the 1K Classic card and 3,440 bytes for the 4K Classic card.

6

2

Hex
ASCII

Flag which indicates whether a 36.x notification message should be sent to the POS once this
command has been executed.
0 = No 36.x notification message is to be sent.
>0 = Send 36.x notification message.

8

1

Alphanum

Index number of the card where the command is to be executed. This index number must match the
index number sent with the card UID in the 16.x card detection message.

9

1

Alphanum

Command ID that is used in conjunction with the 36.x notification message.
If not sending a 36.x notification message for this command, then the value of the ID is
ignored and can assume any 1-byte (2 hex-ASCII digits) value.
If sending a 36.x notification message for this command, the value of the ID should be
selected such that the individual command can be correctly identified by the POS when sent in
the 36.x message.

10

Variable

HexASCII

Command data.

192/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description
Authenticate sector (A or B). For MIFARE Classic 1K only.
Sequence

Format

Description

1

1 byte (2 hex-ASCII digits)

Sector index.

2

6 bytes (12 hex-ASCII digits)

Key value.

Read.
For MIFARE Classic 1K:
Sequence

Format

Description

1

1 byte (2 hex-ASCII digits)

Sector index.

2

1 byte (2 hex-ASCII digits)

Block index.

For MIFARE Ultralight:
Sequence

Format

Description

1

1 byte (2 hexASCII digits)

Page address of the first of four consecutive 4byte pages to be read.

Write.
For MIFARE Classic 1K:
Sequence

Format

Description

1

1 byte (2 hex-ASCII digits)

Sector index.

2

1 byte (2 hex-ASCII digits)

Block index.

3

16 bytes (32 hex-ASCII digits)

Block of data to be written.

For MIFARE Ultralight:
Sequence

Format

Description

1

1 byte (2 hex-ASCII digits)

Page address.

2

4 bytes (8 hex-ASCII digits)

Block of data to be written.

193/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

Complete Tap (omits this field).

M

1

Constant

ASCII control character – ETX

M+1

1

Binary

LRC check character

If multiple commands are sent in a batch, an ASCII file separator character (0x1C) will follow the command data of the previous
command which is then followed by the command type, notification flag, card index number, command ID and command data of the next
card.

194/854 Telium RBA Developer's Guide/ August 18, 2015

17.1 Merchant Data Write Request Message Format for Google Wallet
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

Message Identifier – ASCII – “17.”

4

1

Decimal

Message subtype.
1 = Google Wallet.
4 = SoftCard SmartTap.
5 = Contactless Key Card mode.
All other values are reserved.

5

4

Constant

Merchant ID.
'0000' is required for Google Wallet features to function correctly.
'FFFE' prompts the terminal to create logs for Google Wallet transactions.

9

48

Alphanum

Secret (24 bytes in length)

57

1

Constant

ASCII control character - FS

58

4

Alphanum

First merchant ID

62

48

Alphanum

Secret (24 bytes in length)

110

1

Constant

ASCII control character - FS

This field separator character is only required if an additional MID/secret pair is expected
to follow.

N

1

Constant

ASCII control character – ETX

N+1

1

Binary

LRC check character

195/854 Telium RBA Developer's Guide/ August 18, 2015

17.4 Merchant Data Write Request Message Format for Softcard SmartTap
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

Message Identifier – ASCII – “17.”

4

1

Decimal

Message subtype.
1 = Google Wallet.
4 = SoftCard SmartTap.
5 = Contactless Key Card mode.
All other values are reserved.

5

Variable

Alphanum

Hex representation of the configuration data required to call "Get SmartTap."

M

1

Constant

ASCII control character - ETX

M+1

1

Binary

LRC check character.

196/854 Telium RBA Developer's Guide/ August 18, 2015

4_2_17_6 17.x Merchant Data Write Response Message Format
Refer to the following tables which describes the 17.x Merchant Data Write Request message format for Contactless Key Card, Google
Wallet, and Softcard SmartTap, respectively.
17.5 Merchant Data Write Response Message Format for Contactless Key Card
Offset

Length

Type

Description

0

1

Constant

ASCII control character - STX

1

3

Constant

Message Identifier – ASCII – “17.”

4

1

Alphanum

Message subtype.
1 = Google Wallet.
4 = SoftCard SmartTap.
5 = Contactless Key Card mode.
All other values are reserved.

5

1

Alphanum

Command status.
0 = Command was successful.
1 = Command failed.
2 = Command not executed, unsupported command type.
4 = Command not executed, invalid command format.
All other values are reserved.

6

1

Alphanum

Flag indicating whether or not additional data is available.
0 = No additional data is available.
1 = Additional data is available.
For Contactless Key Card, this flag will always be "0".

197/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

7

1

Alpha

Command type.
A = Authenticate sector with Key A (MIFARE Classic 1K only).
B = Authenticate sector with Key B (MIFARE Classic 1K only).
R = Read
For MIFARE Classic 1K, read 16-byte block from authenticated sector.
For MIFARE Ultralight, read 4 consecutive 4-byte pages.
W = Write.
For MIFARE Classic 1K, write 16-byte block to authenticate sector.
For MIFARE Ultralight, write 4-byte pages.
I = Increment.
For MIFARE Classic 1K, increment a source 16-byte block from an authenticated
sector and store the new value in a destination 16-byte value block in the same
authenticated sector.
For MIFARE Ultralight, increment a source 4-byte page and store the new value in a
destination 4-byte page.
D = Decrement.
For MIFARE Classic 1K, decrement a source 16-byte block from an authenticated
sector and store the new value in a destination 16-byte value block in the same
authenticated sector.
For MIFARE Ultralight, decrement a source 4-byte page and store the new value in a
destination 4-byte page.
M = Move.
For MIFARE Classic 1K, move the value in a source 16-byte value block from an
authenticated sector into a destination 16-byte value block in the same authenticated
sector.
For MIFARE Ultralight, move the value in a source 4-byte page into a destination 4byte page.
C = Complete Tap.

8

1

Alphanum

Flag which indicates whether a 36.x notification message should be sent to the POS once this
command has been executed.
0 = No 36.x notification message is to be sent.
>0 = Send 36.x notification message.

198/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

9

2

Hex
ASCII

Command ID that is used in conjunction with the 36.x notification message.
If not sending a 36.x notification message for this command, then the value of the ID is
ignored and can assume any 1-byte (2 hex-ASCII digits) value.
If sending a 36.x notification message for this command, the value of the ID should be
selected such that the individual command can be correctly identified by the POS when sent in
the 36.x message.

11

Variable

HexASCII

Command data.
Authenticate sector (A or B). For MIFARE Classic 1K only.
Sequence

Format

Description

1

1 byte (2 hex-ASCII digits)

Sector index.

2

6 bytes (12 hex-ASCII digits)

Key value.

Read.
For MIFARE Classic 1K:
Sequence

Format

Description

1

1 byte (2 hex-ASCII digits)

Sector index.

2

1 byte (2 hex-ASCII digits)

Block index.

For MIFARE Ultralight:
Sequence

Format

Description

1

1 byte (2 hexASCII digits)

Page address of the first of four consecutive 4byte pages to be read.

199/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

Write.
For MIFARE Classic 1K:
Sequence

Format

Description

1

1 byte (2 hex-ASCII digits)

Sector index.

2

1 byte (2 hex-ASCII digits)

Block index.

3

16 bytes (32 hex-ASCII digits)

Block of data to be written.

For MIFARE Ultralight:
Sequence

Format

Description

1

1 byte (2 hex-ASCII digits)

Page address.

2

4 bytes (8 hex-ASCII digits)

Block of data to be written.

Complete Tap (omits this field).
M
M+1

1

Constant

ASCII control character – ETX

Binary

LRC check character

200/854 Telium RBA Developer's Guide/ August 18, 2015

17.1 Merchant Data Write Response Message Format for Google Wallet
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

Message Identifier – ASCII – “17.”

4

1

Decimal

Message subtype.
1 = Google Wallet.
4 = SoftCard SmartTap.
5 = Contactless Key Card mode.
All other values are reserved.

5

4

Constant

Status:
0 = Successful injection.
1 = Failed injection.
2 = Unsupported type.
4 = Invalid format.
5 = Data to be returned exceeds the communication buffer.

N

1

Constant

ASCII control character – ETX

N+1

1

Binary

LRC check character

201/854 Telium RBA Developer's Guide/ August 18, 2015

17.4 Merchant Data Write Response Message Format for Softcard SmartTap
Offset

Length

Format

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

Message Identifier – ASCII – “17.”

4

1

Decimal

Message subtype.
1 = Google Wallet.
4 = SoftCard SmartTap.
5 = Contactless Key Card mode.
All other values are reserved.

5

4

Constant

Status:
0 = Successful injection.
1 = Failed injection.
2 = Unsupported type.
4 = Invalid format.
5 = Data to be returned exceeds the communication buffer.

N

1

Constant

ASCII control character - ETX

N+1

1

Binary

LRC check character

4_2_17_7 Executing Commands as a Batch
All batched commands are executed in the order in which they appear in the 17.x message.
Only one 17.x response message is sent for the entire batch message. A successful response will indicate that all commands were
correctly executed. A negative response will indicate that there was a problem with one of the commands in the batch message.
For each successful command executed within the batch, the response data for that command will be contained in the 17.x response
message. If all commands are executed successfully, then all response data will be included in the 17.x response message.

All previously written merchant data can be cleared by sending the 17.x message without including any new merchant data in
the message.

Telium RBA messaging is ASCII-based. Accordingly, any binary data must be sent as hex-ASCII.

202/854 Telium RBA Developer's Guide/ August 18, 2015

For details about this message, please refer to one of the following Ingenico documents: DIV350980 Rev A Isis SmartTap
Implementation Guide; DIV350955 Rev A Google Wallet Implementation Guide.

4_2_17_8 17.x Merchant Data Write Message Usage Examples
Usage Examples
Example 1: Authenticating Card Sector via the 17.x Message
MIFARE Classic 1K, Sector 2 with Key A and Key Value of {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF}
Sequence

Message Content

1

17.5A000002FFFFFFFFFFFF

2

17.500A000002FFFFFFFFFFFF

POS

Terminal

Example 2: Reading from a Card via the 17.x Message
MIFARE Classic 1K
Sector 2, block 1 containing data {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E,
0x0F}
Sequence

Message Content

POS

1

17.5R00000203

2

17.500R00000203000102030405060708090A0B0C0D0E0F

Terminal

MIFARE Ultralight
Pages 4,5,6,7 containing data {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E,
0x0F}
Sequence

Message Content

1

17.5R000004

2

17.5000004000102030405060708090A0B0C0D0E0F

203/854 Telium RBA Developer's Guide/ August 18, 2015

POS

Terminal

Example 3: Writing to a Card via the 17.x Message
MIFARE Classic 1K
Sector 12, block 1 containing data {0x0F, 0X0E, 0X0D, 0X0C, 0X0B, 0X0A, 0X09, 0X08, 0X07, 0X06, 0X05, 0X04, 0X03,
0X02, 0X01, 0X00}
Sequence

Message Content

POS

1

17.5W00000B010F0E0D0C0B0A09080706050403020100

2

17.500W00000B010F0E0D0C0B0A09080706050403020100

Terminal

MIFARE Ultralight
Pages 4 containing data {0x03, 0x02, 0x01, 0x00}
Sequence

Message Content

POS

1

17.5W00000403020100

2

17.500W00000403020100

Terminal

Example 4: Completing Card Tap via the 17.x Message
Sequence

Message Content

1

17.5C0000

2

17.500C0000

POS

Terminal

Example Batch Messages
MIFARE Classic 1K
Commands in Batch message:
1. Authenticate card sector 2 with key A and key value of {0xFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF}.
2. Read sector 2, block 1 containing data {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D,

0x0E, 0x0F}.
3. Write sector 2, block 1 with data {0x0F, 0X0E, 0X0D, 0X0C, 0X0B, 0X0A, 0X09, 0X08, 0X07, 0X06, 0X05, 0X04, 0X03, 0X02,

0X01, 0X00}.
4. Read sector 2, block 1 now containing data {0x0F, 0X0E, 0X0D, 0X0C, 0X0B, 0X0A, 0X09, 0X08, 0X07, 0X06, 0X05, 0X04,

0X03, 0X02, 0X01, 0X00}.

204/854 Telium RBA Developer's Guide/ August 18, 2015

5. Complete the card tap.

The following table shows the messages exchanged between the POS and the terminal for the above described batch message.
MIFARE Classic 1K Example Batch Message Exchange
Sequence

Message Content

1

17.5A000002FFFFFFFFFFFF[FS]R00000201[FS]W000002010F0E0D0C0B0A0908
0706050403020100[FS]R00000201[FS]C0000

POS

Terminal

"[FS]" is the non-printable ASCII file separator character with a value of 0x1C.
This field separator is commonly used in RBA messaging to separate variable
length fields.

2

17.500A000002FFFFFFFFFFFF[FS]R00000201000102030405060708090A0B0C0D 0E0F
[FS]W000002010F0E0D0C0B0A09080706050403020100[FS]R000002010F0
E0D0C0B0A09080706050403020100[FS]C0000

MIFARE Ultralight
Commands in Batch message:
1. Read pages 4,5,6,7 containing data {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E,

0x0F}.
2. Write page 4 with data {0x03, 0x02, 0x01, 0x00}.
3. Read pages 4,5,6,7 now containing data {0x03, 0x02, 0x01, 0x00, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D,

0x0E, 0x0F}.
4. Complete the card tap.

The following table shows the messages exchanged between the POS and the terminal for the above described batch message.
MIFARE Ultralight Example Batch Message Exchange
Sequence

Message Content

1

17.R000004[FS]W00000403020100[FS]R000004[FS]C0000

2

17.500R000004000102030405060708090A0B0C0D0E0F[FS]W00000403020100[FS]
R000004030201000405060708090A0B0C0D0E0F[FS]C0000

205/854 Telium RBA Developer's Guide/ August 18, 2015

POS

Terminal

4_2_18 18.x: Non-Payment Card Message
The 18.x Non-Payment Card message flows from the terminal to the POS. When the cardholder swipes a card and selects a payment
method, that method is checked against the local configuration in the cards.dat file. If the “Card Type” option for the selected payment
is '1' (indicating a non-payment type card), the terminal sends out the 18.x Non-Payment card message.
18.x Non-Payment Card Message Format
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M18_INFO_CARD
Message Identifier – ASCII – “18.”

4

Variable

Decimal

iConnectEFT Constant = P18_RES_TRACK1
Track 1 data.

M

1

Constant

ASCII control character – FS

M+1

Variable

Decimal

iConnectEFT Constant = P18_RES_TRACK2
Track 2 data.

N

1

Constant

ASCII control character – ETX

N+1

1

Binary

LRC check character.

4_2_19 19.x: BIN Lookup
The 19.x BIN Lookup message is sent to the POS to allow for external BIN range lookup for purposes of pre-selecting the payment type
for the customer. It will automatically be disabled if the unit is set to "Select Payment Type" first.
If a customer swipes a payment card, this message is sent to the POS. If the POS responds within the set timeout range, the application will
either:
automatically select the payment type for the customer,
Or:
if "UNKNOWN" was returned, allow the customer to proceed and select the payment type.
For automatic payment selection to occur, the following must occur:
the response message must be received within the preset timeout
the response counter must match the request counter
the account number of the response message must match the account number from the request
If there is any mismatch, the response is ignored and the terminal continues waiting using the original timeout value.

206/854 Telium RBA Developer's Guide/ August 18, 2015

When the payment type is automatically chosen for the customer, the Select Payment screen is bypassed and the payment is processed as
if the customer had pressed the payment key. To any of the screens that the transaction may advance (either via 19.x or the Select Tender
Type prompt), there is a CANCEL button, which will take the transaction back to the Select Payment screen without clearing the swiped
card data from the application. This allows the customer to change the payment type to any other payment type, at which point the
application proceeds as a normal Slide Card first transaction without Spin the BIN.
On the Select Payment screen, the customer has the option of canceling the previous card swipe, which clears the old MSR data and
returns to the Slide Card screen to restart the application for the process to be repeated.
If the POS fails to respond within the set timeout range, the application proceeds to allow the customer to manually select the payment
type and ignore any further payment type messages.
An account data origin option of "A" has been added to enable the application to distinguish between manual entry and an account
message.
19.x PIN Encouragement Request Message Format (Received from RBA)
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M19_BIN_LOOKUP
Message Identifier – ASCII – “19.”

4

1

Alphanum

iConnectEFT Constant = P19_REQ_ACCOUNT_DATA_ORIGIN
Indicates from where account data was derived:
P = Phone Number (used with PayPal).
H = Electronic Track 1.
D = Electronic Track 2 (default track to use).
B = Electronic Tracks (both 1 & 2).
h = Contactless Track 1.
d = Contactless Track 2.
b = Contactless Tracks (both 1 & 2).
X = Manual Track 1.
T = Manual Track 2.
A = Account Message (12.x: Account Message).

The Contactless indicators can be configured in the config.dfs file where
'0008_0006' handles ‘h’ and '0008_0007' handles ‘d’.

207/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

5

1

Alphanum

iConnectEFT Constant = P19_REQ_TRACK1_DATA_STATUS
Track 1 good read indicator.
0 = Bad read.
1 = Good read.

If account number is from 12.x account message, set to ‘0’.

6

1

Alphanum

iConnectEFT Constant = P19_REQ_TRACK2_DATA_STATUS
Track 2 good read indicator.
0 = Bad read.
1 = Good read.

If account number is from 12.x account message, set to ‘1’.

7

1

Alphanum

iConnectEFT Constant = P19_REQ_RESERVED
Reserved (use ‘0’).

8

4

Alphanum

iConnectEFT Constant = P19_REQ_COUNTER
Request Counter.

12

Variable

Alphanum

iConnectEFT Constant = P19_REQ_ACCOUNT_NUMBER
Account number from source, Offset 4.

M

1

Constant

ASCII control character – FS (optional)

M+1

Variable

Alphanum

iConnectEFT Constant = P19_REQ_TRACK1_DATA
Track 1 data (optional).

N

1

Constant

ASCII control character – FS (optional)

N+1

Variable

Alphanum

iConnectEFT Constant = P19_REQ_TRACK2_DATA
Track 2 data (optional).

O

1

Constant

ASCII control character – FS (optional)

208/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

O+1

1

Alphanum

iConnectEFT Constant = P19_REQ_SERVICE_CODE
Service code (optional).

If parameter '0005_0010' (Append Service Code) is set to '1' then the RBA will append a
field separator character and the service code to the 19.x request message.

O+2

1

Constant

ASCII control character – ETX

O+3

1

Binary

LRC check character.

Sample Requests:
Card Source

Sample Request

STB - Debit

19. A 0007341111597242000

Contactless

19. d 11000114005578000000150

MSR / Card Swipe

19. D 11000106011000990911111

Manual Entry

19. T 00000069999999800009901

19.x PIN Encouragement Response Message Format

209/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M19_BIN_LOOKUP
Message Identifier – ASCII – “19.”

4

1

Alphanum

iConnectEFT Constant = P19_PAYMENT_TYPE_SELECTED
Payment type selected:
- = Prompt user to insert card.
0 = Invalid card.
9 = Unknown card.
A = Card type 1: default is debit.
B = Card type 2: default is credit.
C = Card type 3: default is EBT cash.
D = Card type 4: default is EBT food stamp.
E = Card type 5: default is store credit.
...
O = Card type 15.
P = Card type 16.

Undefined responses are treated as "Unknown."

5

4

Alphanum

iConnectEFT Constant = P19_RES_COUNTER
Response counter (copied from request message).

9

Variable

Alphanum

iConnectEFT Constant = P19_RES_ACCOUNT_NUMBER
Account number (copied from request message).

M

1

Constant

ASCII control character – ETX

M+1

1

Binary

LRC check character.

210/854 Telium RBA Developer's Guide/ August 18, 2015

4_2_20 20.x: Signature Message (On-Demand)
4_2_20_1 Overview of the 20.x Signature Messages (On-Demand)
Signature capture is initiated by the POS using the 20.x: Signature Request Message (On-Demand) message . When this message is
received, the terminal will display the requested form and prompt. The cardholder may then begin signing. The 20.x: Signature Response
Message (On-Demand) notifies the POS when a keypad key or screen button is pressed during the signature process.
The response message provides a status and may be used to indicate an invalid prompt or state save error (when the '0009_0006' Save
State on Signature Capture Request parameter is set to '1'). A status value of '2' in the response message indicates that a button was pressed
(e.g., , , ). When this occurs, a 2-byte Data Input field will follow indicating which button was pressed. A status value
of '0' followed by a 1-byte Data Input field of '2' indicates that the signature was accepted.
If the signature notification message is enabled (parameter '0009_0002' = '1'), then the terminal will use the Signature Ready Response
Message (On-Demand) to notify the POS that the signature has been completed and is ready for downloading. Otherwise, the POS must
poll to determine when the signature is available.
The 20.x Signature Request Message may be used at the following times:
If the payment type requires a signature but the payment is not configured to automatically prompt for a signature, the POS may
send the 20.x Signature Request Message.
The cashier compares the signature with the signature on the card, and would like the customer to resign.
To collect a signature for something other than the payment transaction.
When any of the following messages are received during the execution of the on-demand signature capture, the message will not be
executed. A response message including reject status will be returned while the signature process continues.
21.x: Numeric Input Request Message (On-Demand)
23.x: Card Read Request (On-Demand)
24.x: Form Entry Request (On-Demand)
25.x: Terms and Conditions Request (On-Demand)

The 20.x Signature Request message should only be used after the 50.x: Authorization Request message is received or before
the transaction has begun. If this message is called during a transaction, the transaction will be aborted.

4_2_20_2 20.x Signature Message Format
The following tables describes the 20.x Signature Request and 20.x Signature Response message formats. Refer to the Signature Ready
Response Message (On-Demand) section for a description of the 20.x Signature Ready Response message.
20.x Signature Request Message Format

211/854 Telium RBA Developer's Guide/ August 18, 2015

Offset Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M20_SIGNATURE
Message Identifier – ASCII – “20.”

4

Variable

Alphanum

iConnectEFT Constant = P20_REQ_PROMPT_INDEX
Prompt index number (if 1st character is numeric) or prompt (if 1st character is not numeric). Up to
230 characters.

Using a prompt greater than 230 bytes in this field will return a '20.6' (invalid prompt)
response.

M

1

Constant

ASCII control character - FS

M+
1

Variable

Alphanum

iConnectEFT Constant = P20_REQ_FORM_NAME
Form name.

Using a form name greater than 230 bytes in this field will return a '20.6' (invalid prompt)
response.

N

1

Constant

ASCII control character – ETX

N+1

1

Binary

LRC check character.

20.x Signature Response Message Format

212/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M20_SIGNATURE
Message Identifier – ASCII – “20.”

4

1

Decimal

iConnectEFT Constant = P20_RES_STATUS
Status:
0 =  key pressed.
1 =  key pressed.
2 = Button pressed. Refer to Data input field for key pressed.
6 – Invalid prompt.
9 – State save error (only returned during errors when '0009_0006' = 1).

5

1 or 2

Decimal

iConnectEFT Constant = P20_RES_KEY
Data input field (if Status = '2'), 2 bytes.
08 =  key (Backspace).
89 =  key.
78 =  key.
-orOptional signature status field (if Status = '0'), 1 byte.
2 = Signature accepted

M

1

Constant

ASCII control character – ETX

M+1

1

Binary

LRC check character.

4_2_20_3 Usage Examples
20.x Signature Request Message
Example 1 : The POS sends a 20.x Signature Request message to the terminal requesting the SIGN.K3Z signature form with prompt index
165 ("Please sign and tap ENTER with pen"). The format for this message will be
' 20.165[FS]SIGN.K3Z '
The terminal displays the signature form with the specified prompt, and the cardholder can then proceed with signing. When signing is
completed, the cardholder presses the "ENTER" key on the terminal. The terminal then responds to the POS with a 20.x Signature
Response message indicating which key or screen button was pressed. In this example, the format of the response message will be
' 20.0 '
indicating that the  key was pressed.

213/854 Telium RBA Developer's Guide/ August 18, 2015

Example 2: The POS sends a 20.x Signature Request message to the terminal requesting the SIGN.K3Z signature form with prompt
index 165 ("Please sign and tap ENTER with pen"). The format for this message will be
' 20.165[FS]SIGN.K3Z '
20.x Signature Response Message
Example 3:
The cardholder begins signing, but presses the "Clear" button on the display. In this example, the format of the 20.x Signature Response
message will be
' 20.208 '
indicating that a screen button was pressed. The second field in the message ('08') indicates that it was the "Clear" button which was
pressed.
Example 4:
An invalid prompt was included in the 20.x Signature Request message. The terminal returns the following 20.x Signature Response
message:
' 20.6 '
A signature accepted message would have the following format:
' 20.02 '
20.x Signature Ready Response Message
Example 6:
The 20.x Signature Ready Response message has been enabled. The signature is completed and the terminal sends the following
notification message to the POS:
' 20. '

4_2_20_4 A Note About Keys and Buttons Pressed During the Signature Process
The "Cancel" and "Clear" keys function as follows during the signature capture process:
The keypad "Cancel" key is by default disabled during on-demand and normal credit transaction flows.
The keypad "Clear" key will clear the Signature form in preparation for the new signature.
Prior to signature capture, the Signature form should be refreshed. Once the signature capture has been captured, the terminal will display
the approval status as follows:
For on-demand, the terminal will display "Signature Approved".
For normal credit flow, the terminal will display "Approved".

4_2_20_5 Signature Ready Response Message (On-Demand)
The 20.x Signature Ready Response message flows from the terminal to the POS. It signals the POS that a signature is ready to be
downloaded. This message is also optionally sent to the POS when a signature is completed. This message is only sent to the POS if the
sig.dat configuration parameter '0009_0002' is set to '1' specifying that the terminal must send a notification message once the signature
capture is complete.
The following table describes the 20.x Signature Ready message format.
20.x Signature Ready Response Message Format

214/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M20_SIGNATURE
Message Identifier – ASCII – “20.”

M

1

Constant

ASCII control character – ETX

M+1

1

Binary

LRC check character.

4_2_21 21.x: Numeric Input Request Message (On-Demand)
The 21.x Numeric Input Request Message flows from the POS to the terminal. When it is received, the terminal pauses the payment
transaction and prompts the customer for numeric entry (for example, driver’s license). When the customer has entered the data or
cancelled entry, the Input Response Message is sent to the POS. The payment transaction then resumes where it was paused.
If the customer is in the middle of entering a PIN when the input request is received, the PIN entry will stop, and the customer will be
prompted for the input. When the input is complete, PIN entry will restart. Any portion of the PIN that was entered before the interruption
will be lost. A '15.6' Stop Action soft reset will cancel the input request and continue the payment transaction.
The Input Request message is always ACKed. Rules for the message are:
If the prompt index is not valid, then an input response message with Exit Type = 9 is sent to the POS and the request is ignored.
If the prompt length is 0 (zero), that message is not executed and the '21.9' reject response is sent out.
When the 21.x message is received during the execution of another on-demand function (20.x, 21.x, 23.x, 24.x, 27.x, or 31.x), the
new 21.x on-demand message does not execute, a reject response status is returned, and the current on-demand Enter Generic
Number process continues to operate.
When the  button is tapped, a response 21.x message with cancel state is sent out, the display shows the “Input
Cancelled” prompt for three seconds, the current process terminates, and the RBA returns to the process before initial 21.x was
received.
The on-demand messages are not nested.
Execution of 21.x is terminated in one of the following ways:
By a message - 00.x, 01.x, 10.x, '15.0', '15.6', 20.x, 30.x.
By tapping the CANCEL button. When this happens, the “Input Cancelled” prompt displays, and a '21.1' response ('1' indicating
the cancel state) is sent out. The function terminates and returns to the interrupted state.

4_2_21_1 Use of the 21.x Message to Send Encrypted Clear Entry Data
With some customers prompting the cardholder for sensitive information such as their social security number, a new method for
encrypting this clear entry data and sending it to the POS has been established. This information can now be encrypted using the same
encryption key used for the 94.x and 95.x: Barcode Configuration Messages and sent to the POS via the 21.x Numeric Input Request
Message. In order to facilitate this, configuration parameters '0091_0019' through '0091_0022' have been reallocated to support generic
message encryption. Refer to Security Parameters (security.dat) for more detail on the use of these parameters. These parameters now
support encryption of barcode data as well as encryption of clear entry data such as the cardholder's sensitive information. The encryption
key used in both cases is the base64 barcode key. The following new configurations have been added to enable encryption for specific
messages:

215/854 Telium RBA Developer's Guide/ August 18, 2015

'0091_0026' - Used to enable encryption of clear entry data via 21.x and 27.x messages.
'0091_0027' - Used to enable encryption of barcode data via the 95.x barcode data message.
Exit types "8" and "E" have been added to the 21.x Numeric Input Response message as described in the below table titled "Numeric
Input Response (On-Demand) Message Format."
21.x Numeric Input Request (On-Demand) Message Format
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M21_NUMERIC_INPUT_ON_DEMAND
Message Identifier – ASCII – “21.”

4

1

Alphanum

iConnectEFT Constant = P21_REQ_DISPLAY_CHARACTER
Display character:
0 = Display digits entered
Any other character is displayed in place of the entered digit.

5

2

Alphanum

iConnectEFT Constant = P21_REQ_MIN_INPUT_LENGTH
Minimum input length: 0 – Maximum input length.

7

2

Alphanum

iConnectEFT Constant = P21_REQ_MAX_INPUT_LENGTH
Maximum input length: 1 – 40.

9

Variable

M

1

M+1

Variable

Alphanum

Prompt index number.
ASCII control character – FS (This field is optional.)

Alphanum

iConnectEFT Constant = P21_REQ_FORMAT_SPECIFIER
Format specifier ID number. See Format Specifiers for more information. (This field is optional.)

N

1

Constant

ASCII control character – FS (This field is optional.)

N+1

Variable

Alphanum

iConnectEFT Constant = P21_REQ_FORM_SPECIFIC_INDEX_NUMBER
Form specific index number from 1-30 or text that is the form’s name.

O

1

Constant

ASCII control character – ETX

O+1

1

Binary

LRC check character.

21.x Numeric Input Response (On-Demand) Message Format

216/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M21_NUMERIC_INPUT_ON_DEMAND
Message Identifier – ASCII – “21.”

4

1

Alphanum

iConnectEFT Constant = P21_RES_EXIT_TYPE
Exit Type:
0 = Enter pressed.
1 = Cancelled.
2 = Button pressed.
4 = Invalid form.
5 = Invalid format.
6 = Invalid prompt.
8 = Returned input data encoded using base64 barcode key.
9 = Declined/Rejected.
E = Error occurred during preparation of response message; no return data included.

5

Variable

Decimal

iConnectEFT Constant = P21_RES_INPUT_DATA
Data input.

M

1

Constant

ASCII control character – ETX

M+1

1

Binary

LRC check character.

Info
Examples of ‘Invalid formats’ (5 = Invalid format, in Response table, above) are non-numeric or negative min/max values.

4_2_22 22.x: Application ID Request
The 22.x Application Message flows from the POS to the terminal. It queries the terminal for the ID of the application installed in the
terminal.
22.x Application ID Request Message Format

217/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M22_APPLICATION_ID_REQUEST
Message Identifier – ASCII – “22.”

M

1

Constant

ASCII control character – ETX

M+1

1

Binary

LRC check character.

22.x Application ID Response Message Format
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M22_APPLICATION_ID_REQUEST
Message Identifier – ASCII – “22.”

4

Variable

Alphanum

iConnectEFT Constant = P22_RES_APPLICATION_NAME
Application Name.

M

1

Constant

ASCII control character – FS

M+1

Variable

Alphanum

iConnectEFT Constant = P22_RES_APPLICATION_VERSION
Application Version.

N

1

Constant

ASCII control character – ETX

N+1

1

Binary

LRC check character.

4_2_23 23.x: Card Read Request (On-Demand)
4_2_23_1 Overview of the 23.x Card Read Request Message
The 23.x Card Read Request message flows from the POS to the terminal. The 23.x message stops the execution of the current process,
displays the Card Swipe process screen, and waits for a card swipe on the terminal magnetic stripe reader (MSR). When the MSR track
data is available, it sends out a 23.x response with entered data, and returns to the process it interrupted.
The 23.x request is always ACKed. Rules for the message are:
When the 23.x message is received during the execution of 20.x, 21.x, 23.x or 31.x, the 23.x message is not executed and the '23.9'
reject response message is returned. The current function is continued.

218/854 Telium RBA Developer's Guide/ August 18, 2015

The On-Demand messages are not nested. Refer to 34.x: Save and Restore State Messages regarding the ability to send multiple OnDemand messages.
The execution of 23.x message during the processing of 20.x: Signature Message (On-Demand) is dependent upon the value for DFS Data
Index '0009_0006' (Save state when signature request received) as follows:
If '0009_0006' = 0, RBA processes the 23.x message and comes back to process the signature request.
If '0009_0006' = 1, RBA returns '23.9' (declined).
After a card swipe is executed, the following can happen:
When the MSR card read is correct, the “Card Accepted” prompt is displayed for three seconds, and the terminal sends out a 23.x
response with status of '0' and attached track data. The RBA returns to the interrupted process.
When the MSR card read is not correct, the “Card Read Cancel” prompt is displayed for three seconds, the terminal sends out a 23.
x response, and RBA returns to the interrupted process.
After a contactless card touch/tap is executed, the following can happen:
When the MSR card read is correct, the “Card Accepted” prompt is displayed for three seconds, and the terminal sends out a 23.x
response with status of '0' and attached track data. The RBA returns to the interrupted process.
When the MSR card read is not correct, the “Card Read Cancel” prompt is displayed for three seconds, the terminal sends out a 23.
x response, and the RBA returns to the interrupted process.

4_2_23_2 23.x Message Flow When Using iConnectEFT
The 23.x message has different flows depending on the '0013_0014' configuration parameter setting. This setting controls whether to
include or exclude the source field in the 23.x Card Read Response message. The message flow is changed based upon this configuration
parameter setting. If set to exclude the source field from the 23.x response message, the iConnectEFT sends a 61.x: Configuration Read
message following every 23.x message if the configuration setting of '0013_0014' is disabled.

4_2_23_3 New Flag for Coupon Support
A new flag has been added to the 23.x request message to indicate that couponing data (if enabled) should be returned in the 23.x response
message, and not in the 16.x Contactless Mode Request message. An optional 1-byte 'Options' field has been added to the 23.x message to
facilitate this feature. All optional fields before the 'Options' field must be present in order to use this field. When set to a value of '1' this
indicates that the RBA will send a 16.x response message with a status of '6' if payment data is available and a pending a 23.x response
message. Refer to the following examples.
Example 1:
In this example, the Options field is set to '1' indicating that the RBA will send a 16.x response with status '6' if payment data is available
and pending 23.x response.
[STX]23.PROMPT[FS]FORM[FS]1[FS]MSC[ETX][LRC]
Example 2:
In this example, the following message uses the prompt "Swipe, Tap or Insert Card” with form FORM1.K3Z having readers MSR, Cless
and SCR enabled, and having a 16.x response with payment notification.
[STX]23.Swipe, Tap or Insert Card[FS]FORM1.K3Z[FS]1[FS]MCS[ETX][LRC]
Example 3:
This example uses the prompt “Swipe, Tap or Insert Card” with the default form selection, having all readers enabled by default and
forcing the 16.x response with payment notification.
[STX]23.Swipe, Tap or Insert Card[FS][FS]1[ETX][LRC]

219/854 Telium RBA Developer's Guide/ August 18, 2015

Example 4:
This example uses the prompt “Swipe, Tap or Insert Card” with the default form selection, having MSR and Cless readers enabled,
without the 16.x response notification.
[STX]23.Swipe, Tap or Insert Card[FS][FS][FS]MC[ETX][LRC]

4_2_23_4 MSC Field
The MSC field is used to indicate which readers to enable (MSR, contactless and SCR). If contactless mode was not enabled previously,
"card swipe on demand w/o Cless" will be set as the default form. The contactless reader will not be enabled if the appropriate contactless
mode has not been enabled, regardless of the MSC field content. Refer to the following examples of MSC field use in the 23.x message.
1. Use prompt "Swipe, Tap or Insert Card" with FORM1.K3Z, enabling MSR, contactless and SCR:

[STX]23.Swipe, Tap or Insert Card[FS]FORM1.K3Z[FS][FS]MCS[ETX][LRC]
2. Use prompt "Swipe or Tap Card" with default form, enabling MSR and contactless:

[STX]23.Swipe or Tap Card[FS][FS]MC[ETX][LRC]

4_2_23_5 Swiping an Invalid Card or Cancelling Manual Entry
When swiping an invalid card, a "Bad Read" exit type is returned in the 23.x response message. The "Source of Card Read" field will be
blank, and a "?" character will be inserted in the field designated for Track 1 data. The message format for an invalid card swipe will then
be
' 23.x?[FS] '
When selecting manual entry and then cancelling, a "Cancelled" exit type is returned in the 23.x response message. The "Source of Card
Read" field will be blank, and a "?" character will be inserted in the field designated for Track 1 data. The message format for cancelled
manual card entry will then be
' 23.2?[FS] '
In both cases, the "Source of Card Read" field is blank and a "?" character is inserted Track 1 data field. The "?" character defines the card
source as unknown or invalid.

4_2_23_6 Execution of the 23.x Message
The execution of the 23.x message is terminated in one of the following ways:
By the following messages
00.x: Offline Message
01.x: Online Message
10.x: Hard Reset Message
15.0 Soft Reset Message (same as 10.x Hard Reset Message)
15.6 Soft Reset Message
20.x: Signature Message (On-Demand)
30.x: Advertising Request Message (On-Demand)
Or by tapping the CANCEL button. When this occurs, the “Card Read Cancelled” prompt is displayed, and a '23.2' cancel response
message is sent out. The function terminates and returns to the interrupted process.

220/854 Telium RBA Developer's Guide/ August 18, 2015

Info
Encryption and BIN range checks on a card account number will be performed based on the settings from the configuration
file.

4_2_23_7 23.x Card Read Request (On-Demand) Message Format
The following tables describe the format for the 23.x Card Read Request and 23.x Card Read Response messages.
23.x Card Read Request Message Format

221/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M23_CARD_READ_REQUEST_ON_DEMAND
Message Identifier – ASCII – “23.”

4

Variable

Alphanum

iConnectEFT Constant = P23_REQ_PROMPT_INDEX
Prompt index number. Can be literal text up to 230 characters, an index number from Prompt.xml, or
nothing when used with an optional form_file_name.

M

1

Constant

ASCII control character – FS (This field is optional.) Only used with M + 1.

M+1

Variable

Alphanum

iConnectEFT Constant = P23_REQ_FORM_NAME
Form File Name or Number (this field is optional). Only used with M.
Maximum length = 13 characters.

N

1

Constant

ASCII control character – FS (This field is optional.)

N+1

1

Alphanum

iConnectEFT Constant = P23_REQ_OPTIONS
1 = RBA will send 16.x response with status '6' if payment data is available and pending a 23.
x response.

N+2

1

Constant

ASCII control character – FS (This field is optional.)

N+3

Variable

Alphanum

iConnectEFT Constant = P23_REQ_ENABLE_DEVICES
Enable Devices field (this field is optional). Letters in the field indicate which readers to enable:
M = Enable MSR.
C = Enable contactless.
S = Enable SCR.
The order of the letters does not matter, only whether or not they are included in the string.

To avoid ambiguity, the Form field must be present (even with empty value) in order for
the MSC field to be sent.

O

1

Constant

ASCII control character – ETX

O+1

1

Binary

LRC check character

222/854 Telium RBA Developer's Guide/ August 18, 2015

23.x Card Read Response Message Format (if '0013_0014' = 1)
Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M23_CARD_READ_REQUEST_ON_DEMAND
Message Identifier – ASCII – “23.”

4

1

Alphanum

iConnectEFT Constant = P23_RES_EXIT_TYPE
Exit Type:
0 = Good Read
1 = Bad Read
2 = Cancelled
3 = Button Pressed
6 = Invalid Prompt
7 = Encryption Failed
9 = Declined

5

1

Alpha

iConnectEFT Constant = P23_RES_CARD_SOURCE
Source of card read:
C = Contactless Reader.
H = Manual entry.
M = MSR.
S = One of the following:
SLE5542 memory card
EMV card
WIC card

Only included in Response if '0013_0014' parameter = 1.

6

Variable

Decimal

iConnectEFT Constant = P23_RES_TRACK1
Track 1 data. (If the above field is 3 = Button Pressed, then it will be the single byte ID of the key.)

M

1

Constant

ASCII control character – FS

M+1

Variable

Decimal

iConnectEFT Constant = P23_RES_TRACK2
Track 2 data

223/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

N

1

Constant

ASCII control character – FS (only if Track 3 data is present)

N+1

Variable

Alphanum

iConnectEFT Constant = P23_RES_TRACK3
Track 3 data

O

1

Constant

ASCII control character – ETX

O+1

1

Binary

LRC check character

4_2_23_8 Sample Responses
The following table provides sample responses for contactless, manual entry and MSR/card swipe card read sources.
Card Read Examples
Card Source

Sample Response

'0013_0014' not set to
‘1’

23.0B4005578000000150^CARDHOLDER/VISA^101210155555012340000000000556100571740000[FS]

Contactless

23.0 C B4005578000000150^CARDHOLDER/VISA^101210155555012340000000000556100460770000
[FS]

4005578000000150= 10121015555557100741

4005578000000150= 10121015555546000771
Manual Entry
'0013_0014' = '0'

23.0 H 5444009999222205^MANUAL ENTRY/^1412000000123000000[FS]5444009999222205=
1412000000123000

'0007_0029' = '1'
MSR / Card Swipe

23.0 M B5444009999222205^TESTVOID/TEST^141210100000000000000071700[FS]
5444009999222205= 14121010000071700

4_2_24 24.x: Form Entry Request (On-Demand)
The 24.x Form Entry Request message flows from the POS to the terminal. When the message is received and accepted, the RBA starts the
Form Entry process of displaying the form requested by the command. When the process is complete, or there is an error, the response
message is sent to the POS.
In the Form Entry Request format, the four offsets M through O work together to allow you to override a text field on a form. If the form
has multiple text fields or buttons, you can repeat the set of fields for each text element or button that needs to change, as long as it has a
different B or T number (T1, T2, T3, etc.), and as long as the total message is less than 247 bytes. The B and T blocks can be sent in any
order.

224/854 Telium RBA Developer's Guide/ August 18, 2015

4_2_24_1 Setting Prompt Text
The syntax for setting prompt text is as follows:
Tid,text
where
id = the label ID from the K3Z form.
text = the new prompt text.
Example: Set the prompt for label id "PROMPTLINE1" to "A new label":
TPROMPTLINE1,A new label

4_2_24_2 Setting Button Text
The syntax for setting button text is as follows:
Bid,text
where
id = the button ID from the K3Z form.
text = the new button text.
Example: Set the button text for id "btn1" to "text":
Bbtn1,text

4_2_24_3 Changing Button Visibility
The syntax for changing a button visibility is as follows:
Bid,visibility
where
id = the button ID from the K3Z form.
visibility = "S" for show or "H" for hide.
Example: Hide button with id "btn1":
Bbtn1,H

If "S" or "H" are needed for the button text, then the following syntax should be used in order to avoid confusion:
To show a button:
Bid, S
To hide a button:
Bid, H
Note the extra space following "Bid".

225/854 Telium RBA Developer's Guide/ August 18, 2015

4_2_24_4 Setting the Form Timeout
The syntax for setting the form timeout is as follows:
t,timeout
where "timeout" is the form timeout in seconds.

4_2_24_5 Displaying the Offline Form on iSMPc Terminals
It is important to note that due to Bluetooth pairing on iSMPc terminals, the prior form (e.g., "Approved") will be displayed following the
request to display the offline form. In order to correctly display the offline form, the '24.' message must specify T1 formatting and include
the offline.K3Z message. The required message to display the "This Lane Closed" prompt on iSMPc terminals is as follows:
[STX]24.offline.K3Z[FS]T1,This Lane Closed[ETX][LRC]
24.x Form Entry Request Message Format

226/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant = M24_FORM_ENTRY_REQUEST_ON_DEMAND
Message Identifier – ASCII – “24.”

4

Variable

Alphanum

iConnectEFT Constant = P24_REQ_FORM_NUMBER
Form Number or Form Name.

M

1

Constant

ASCII control character – FS

M+1

1

Constant

iConnectEFT Constant = P24_REQ_TYPE_OF_ELEMENT
ASCII character – ‘T’

M+2

Variable

Alphanum

iConnectEFT Constant = P24_REQ_TEXT_ELEMENTID
Text Element ID.

N

1

Constant

ASCII character - ’,’

N+1

Variable

Alphanum

iConnectEFT Constant = P24_REQ_PROMPT_IDX
Prompt index number.

O

1

Constant

ASCII control character – FS

O+1

1

Decimal

ASCII character – B.

O+2

1

Decimal

iConnectEFT Constant = P24_REQ_BUTTONID
Button ID.

O+3

1

Decimal

iConnectEFT Constant = P24_REQ_BUTTON_STATE
Button State:
0 = Up.
1 = Down.

O+4

1

Constant

ASCII control character – ETX

O+5

1

Binary

LRC check character.

24.x Form Entry Response Format

227/854 Telium RBA Developer's Guide/ August 18, 2015

Offset

Length

Type

Description

0

1

Constant

ASCII control character – STX

1

3

Constant

iConnectEFT Constant =M24_FORM_ENTRY_REQUEST_ON_DEMAND
Message Identifier – ASCII – “24.”

4

1

Decimal

iConnectEFT Constant = P24_RES_EXIT_TYPE
Exit Type:
0 = Successful.
1 = Invalid form.
6 = Invalid prompt.
8 = Timeout occurred.
9 = Declined.

5

1

Decimal

iConnectEFT Constant = P24_RES_KEYID
ID of key pressed to exit the form.

6

1

Decimal

iConnectEFT Constant = P24_RES_BUTTONID
Button ID. This is always paired with the Button State. This is repeated for every check box and radio
button.

7

1

Decimal

Button State:

Check Boxes:

0 = Up.

0 = Not Checked.

1=
Down.

1 = Checked.

Radio Buttons:
x, where x is a value of 1 to y,
where y is the number of buttons in the group.

iConnectEFT Constant = P24_RES_BUTTON_STATE
Always in a pair with the Button ID. Repeated for every check box and radio button.
See also, section "Using multiple buttons with the 24.x message."
M

1

Constant

ASCII control character – ETX

M+1

1

Binary

LRC check character

The 24.x Form Entry Request message is an on-demand message. Accordingly, this messages interrupts the normal operation of the RBA
in order to execute a new function requested by the host. The rules for the on-demand functions are:
On-demand messages cannot be nested.
A received 24.x request is validated prior to execution.
When a 24.x request has been successfully executed, a 24.x response message is returned with a status of '0' indicating successful
execution.

228/854 Telium RBA Developer's Guide/ August 18, 2015

A 24.x request is not executed when either of the following situations occur:
The form file index is invalid, or the form file is not present in the terminal's DFS memory. A 24.x response message is
returned with a status of '1' indicating that the form was invalid.
Another on-demand request is already running. In this event, a 24.x response message is returned with a status of '9'
indicating that the request has been declined.
The execution of a 24.x request can be terminated using the following types of reset messages:
Reset whole transaction and return to card swipe process. This can be implemented using any of the following messages:
10.x Hard Reset Message
'15.0' Soft Reset Message
01.x Online Message
00.x Offline Message
30.x Advertising Request Message (On-Demand)
20.x Signature Message (On-Demand)
A '15.6' Soft Reset Message terminates the current process.

4_2_24_6 Using Multiple Buttons with the 24.x Message
When using multiple buttons on a form (such as a group of radio buttons), the 24.x message returns a single digit group number followed
by a single digit button ID for the selected radio button at the time the form was closed. There can be up to four groups (1 – 4) on a single
form.
Example:
A form exists with four groups of four radio buttons (group 1 with four radio buttons, group 2 with four radio buttons, etc.). If radio button
4 is selected from group 1, and radio button 2 is selected from group 3, the 24 response may look like this:
24.0[CR]14213241
So, digit-by-digit, the above response reads like this: message 24 returns for group 1/button 4, for group 2/button 1, for group 3/button 2,
and for group 4/button 1. The default selection for each group is ‘1’ (button 1).

Important to note, here, is that the button ID is paired with its value.

The letters [CR] represent non printable characters in the ASCII set.

Note that the RBA application does not support the simultaneous use of both radio buttons and check boxes on a single form,
nor does it support the simultaneous use of radio buttons or check boxes with a signature box on a single form.

4_2_24_7 Displaying Text Data
The maximum radio button and check box length has been increased from 30 characters to 100 characters. If the text exceeds 100
characters, then only the first 100 characters will be displayed.

229/854 Telium RBA Developer's Guide/ August 18, 2015

4_2_24_8 Displaying numerals or symbol characters using the 24.x message
There may be a need to display a numeral or a symbol, such as a dollar sign ($), as the first character on a terminal line. The text in a
command string that follows a comma (following a ‘T’ number) displays this using the following rules:
Parser Action by Character Type
If the first character
is… following the
comma that follows a
‘T’ number

Then the parser does this…

… a numeral

The parser assumes the numeral to be a prompt index number into the prompt file, so the corresponding
prompt will be displayed.

… not a numeral

The parser checks to see if the first character is the Ctrl/Q character (aka DC1, aka ox11 ASCII value). If this
non-printable control character is found, then the parser will display whatever text follows. This feature is in
place to allow for the printing of text that starts with a number, but it will print any text that follows, not just
numbers.

… not a numeral NOR
a Ctrl/Q (e.g., ‘DC1’)
character

The parser simply displays all of the text after the comma.

Example:
A form exists with variables (in dollar amounts) for Sales Total, Tax and Total. The three dollar amounts on the form are 5.50, 8.50 and
9.50. This set of data is returned as the following string to the terminal, instructing the terminal what to display:
24.total.k3z[FS]T8,[DC1]5.50[FS]T9,[DC1]8.50[FS]T10,[DC1]9.50
The letters [FS] represent a non-printable character known as Field Separator.
The letters [DC1] represent the Ctrl/Q character.
Icon

Note about the ‘T’ number: This number should be matched to a ‘PROMPTLINEx’ number in the K3Z file where ‘x’ is the ‘T’
number. The object’s ‘id’ and ‘text’ fields should use ‘PROMPTLINEx’ in the same manner as one of the standard RBA K3Z
forms using prompts.

The following code from a K3Z file illustrates this point: