llaves pinpad verifone emv_sc5000

VeriFone Part Number 22595, Revision A

sbofpefbia

pb`rofqv

ôèfqb`qrob

ljkf=PPuu

jriqfJ m̂mif`^qflk

^mmif^k`bp

sbof`bkqob

^mmif^k`b=j^k^dbjbkq

prfqb

ljkf=PTuu

e^kaJlsboJ`lrkqbo

jriqfJ^mmif`^qflk

^mmif^k`bp

p`=RMMM

fkqbdo^qba

moldo^jj^_ib

mfkmâ

SC 5000

EMV Application Architecture andInterface Guide

All rights reserved. No part of the contents of this document may be reproduced or transmitted in any form without the writtenpermission of VeriFone, Inc.

The information contained in this document is subject to change without notice. Although VeriFone has attempted to ensure theaccuracy of the contents of this document, this document may include errors or omissions. The examples and sample programs arefor illustration only and may not be suited for your purpose. You should verify the applicability of any example or sample programbefore placing the software into productive use. This document, including without limitation the examples and software programs, issupplied “As-Is.”

VeriFone, Inc.2455 Augustine Drive

Santa Clara CA 95054-3002

www.verifone.com


SC 5000 EMV Application Architecture and Interface Guide© 2002 VeriFone, Inc.

VeriFone, the VeriFone logo, Omni, VeriCentre, Verix, and ZonTalk are registered trademarks of VeriFone. Other brand names ortrademarks associated with VeriFone’s products and services are trademarks of VeriFone, Inc.

All other brand names and trademarks appearing in this manual are the property of their respective holders.

Comments? Please e-mail all comments in this document to [email protected]

mailto: [email protected]?Subject=Verix_Programmer�s_Manual&[email protected]

http://www.VeriFone.com

CONTENTS

CHAPTER 1General Interface

andCommunications

Protocol

Assumptions and Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Receiving a NAK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Unsolicited Packets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

CHAPTER 2Communication

Packets andCommands

Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7General Communication Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Packet 11: PIN Pad Connection Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Packet 12: Select Prompt Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Packet 13: Application Version and Modify Serial Port . . . . . . . . . . . . . . . . . 10

Encrypted PIN Communication Packets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Packet 02: Transfer Master Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Packet 04: Check Master Key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Packet 08: Select a Master Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Packet Z62: Accept and Encrypt PIN, Display Custom Messages . . . . . . . . 17Packet 71: Transfer PIN Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Packet 72: Cancel Session Request. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Custom Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Custom Communication Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Packet Z2: Display a String. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Packet Z8: Set/ Reset Idle Prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

CHAPTER 3Magnetic Card

ReaderSpecifications

Packet Q4: Activate/Deactivate the Card Reader . . . . . . . . . . . . . . . . . . . . . . . 25Packet 81: Card Image Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

CHAPTER 4ICC Reader

SpecificationsPacket I02: Wait for ICC Removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Packet I05: ICC Presence Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

CHAPTER 5EMV Services Transaction Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Primary EMV Communication Packets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Step-by-Step EMV Communication Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Packet Response Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Card Status Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Packet C00: Wait For Card and Select Application . . . . . . . . . . . . . . . . . . . 39Packet C01: Add Amount, Process AFL, and Authenticate . . . . . . . . . . . . . 41Packet C02: Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Packet C03: Get Card Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Packet C04: Transaction Complete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Packet C05: Add Amount and Process AFL . . . . . . . . . . . . . . . . . . . . . . . . . 49Packet C06: Card Data Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Packet C07: Get Card Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

EMV APPLICATION ARCHITECTURE AND INTERFACE GUIDE 3

4

Packet C08: Card Holder Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Packet C09: Processing Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Packet C10: Terminal Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Packet C11: Authenticate Issuer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Packet C12: Process Issuer Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Packet C13: Europay-Specific Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Packet C14: Get CAPK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Packet C15: Set Default DDOL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Packet C16: Set Default TDOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Packet C17: Set TACs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Packet C18: Set ROS Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Packet C19: Add TLV to Collxn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Packet C20: Get TLV from Collxn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Packet C21: Update TLV in Collxn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Packet C22: Check Fallback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Packet C23: Clean Transaction Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Packet C24: Get Card Second Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . 74Packet C25: Write to Script File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Packet C99: Unsolicited Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Packet C3X: Super Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Example Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Parameters and Response Fields Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 80

CHAPT ER 6EMV Configuration

TablesEST.DAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83MVT.DAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83How the Tables are Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Field Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Certificate Serial Number Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

CHAPT ER 7Database Services Database Communication Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Database Concepts and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Packet Response Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Packet D00: Create Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Packet D01: Table Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Packet D02: Seek Record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Packet D03: Read Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Packet D04: Add New Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Packet D05: Update Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Packet D06: Delete Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Packet D07: Delete Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Packet D08: Get Field from Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Packet D09: Put Field into Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

CHAPT ER 8Application

Switching PacketsPacket P00: Remote Application Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Packet P01: “Who are You?” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

CHAPT ER 9Application

Switching Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

EMV APPLICATION ARCHITECTURE AND INTERFACE GUIDE

CHAPTER 1

General Interface and Communications Protocol

The SC 5000 Generic Application Interface is designed to provide functionality and services needed to implement specific application (such as, EMV, PINPad101/201 emulation), as well as other regional applications by providing the following features:

• EMV services: Required for a complete EMV financial transaction (application selection, data authentication, restriction processing, risk management, cardholder verification, and so on)

• Traditional PINPadP101/201 credit and debit services: Required for a magnetic-stripe card-based financial transaction (PIN entry, PIN encryption, mag stripe reading, and so on)

• ICC read/write services: Required for non-EMV ICC-based transactions (for example, loyalty applications)

• Database services

• Application selection and RS-232 set up services

• Adding user-defined commands for specific country or customer application requirements

The SC 5000 communicates with a master device through an RS-232 connection. The master device can request any of the above services using a defined set of commands the PIN pad interprets. A master device can be a VeriFone terminal, ECR (electronic cash register), or other device that can communicate over the RS-232 port using the defined message protocol and command set.

Assumptionsand

Dependencies

Polling Since the SC 5000 RS-232 port can be controlled by several applications and each time an application assumes the control it must initialize the port, some data sent by the master device may be lost. To avoid this the master device can send an ENQ character (0x05) to be answered with an ACK character (0x06) by the PIN pad. This procedure indicates if the PIN pad is ready to acknowledge to a master device request. If no ACK is received from the SC 5000 within the time-out period (default = 15 seconds; see Timeout), the master device must continue to poll before sending the packet. The master device must repeat the polling process by sending an ENQ packet until an ACK is received within the time-out period.

SC 5000 EMV APPLICATION ARCHITECTURE AND INTERFACE GUIDE 5

GENERAL INTERFACE AND COMMUNICATIONS PROTOCOL

Assumptions and Dependencies

6

Receiving a NAK If during a communication session, either the master device or the PIN pad receives a NAK, it retransmits the previous message and increments a NAK counter for the communication session. If more than three NAKs occur while attempting to transmit the same packet, the sending device (that is, the device that transmitted the three NAKs) sends an EOT and terminates the communication session.

Timeout During a communication session, the PIN pad or master device times out the expected communication is not received within the specified time-out period This can be configured using packet 13 (see section Packet 13: Application Version and Modify Serial Port). The default time-out value is 15 seconds. In this situation, the SC 5000 sends an EOT to terminate the communication session.

UnsolicitedPackets

In some circumstances the SC 5000 may send a specific report to the master device. In this case, an ENQ character is sent from the SC 5000. If this ENQ is answered with an ACK, the SC 5000 sends the unsolicited packet.

SC 5000 EMV APPLICATION ARCHITECTURE AND INTERFACE GUIDE

CHAPTER 2

Communication Packets and Commands

Packet Format There are two options for packet format:

• <STX><packet data><ETX>{LRC}

• <SI><packet data><SO>{LRC}

where,

The SC 5000 EMV application accepts any of these formats for all packets described in the rest of this document.

The description for each packet, nevertheless, is compatible with PINPad 101 and PINPad 1000. It is recommended that the master device developer comply with this definitions, as there is no guarantee that other platforms have the same flexibility provided by the SC 5000.

GeneralCommunication

Packets

The following packets initiated tests or functions between a master device and a PIN pad. These packets are suitable for any key management scheme.

• Communication test

• Select prompt language

• Application version

• Modify serial port

Table 1 lists packets used in both MS and DUKPT sessions.

• STX = 0x02 • SO = 0x0E

• ETX = 0x03 • LRC = longitudinal redundancy check = XOR of all bytes in the packet, excluding the first byte (STX or SI)

• SI = 0x0F

Table 1 Common Packets

Packet Description

11 PIN pad connection test

12 Select prompt language

13 Application version and modify serial port


COMMUNICATION PACKETS AND COMMANDS

General Communication Packets

8

Packet 11: PIN PadConnection Test

This packet is used by the master device to test the connection with the PIN pad. On a good connection, the master device receives an ACK from the PIN pad within one second. Otherwise, the master device must assume that the PIN pad is not properly connected.

Packet 11 Length

• MAX: 5 characters

• MIN: 5 characters

Packet 11 Example

<SI>11<SO>{LRC}

NOTE

This packet is ignored during any PIN or data entry session.

Table 2 Packet 11 Format

Data Element Characteristic Comments

<SI> 1H Shift In, Value: 0Fh

Packet type 2AN Value: 11

<SO> 1H Shift Out, Value: 0Eh

{LRC} 1H Error Check

Table 3 Packet 11 Communication Protocol

Master DeviceTransmitDirection

PIN Pad

<SI>11<SO>{LRC}

• ACK if LRC okay

• NAK if LRC incorrect

• EOT after 3 NAKs

SC 5000 EMV APPLICATION ARCHITECTURE AND INTERFACE GUIDE



Packet 12: SelectPrompt Language

The master device uses packet 12 to select the prompt language for the PIN pad. Up to four different languages are supported. Languages can be selected from one of the following single digit codes:

• The language ID must be in the range 1–4.

• If the ID is out of this range, the PIN pad selects English (ID=1), the default language, as the new prompt language.

• After the new prompt language is selected, the PIN pad displays the new language for 3 seconds, then falls back to the idle prompt in the selected language.

For example, for Latin American countries the supported languages are English, Spanish, French, and Portuguese.

Packet 12 is responsible for setting the preferred language of the master device. Other situations where the language can be changed are:

• If the preferred language for the EMV card is different than set.

• If the user selects another language during a type operation (for example, Z62).

Packet 12 Length



Packet 12 Example

<SI>122<SO>{LRC}

NOTE

This option is not yet defined.





[c] 1N Language codes: 1 to 4






1

Packet 13:Application

Version andModify Serial Port

The master device uses packet 13 to obtain the SC 5000 application version identifier and select the baud rate and data communication parameters. After the new baud rate and other parameters are selected, the PIN pad flashes the new configuration for 3 seconds and then returns to the idle prompt.



PIN Pad

<SI>12[c]<SO>{LRC}

• ACK if LRC okay



Prompt language is selected.





[b] 1N Baud rate codes:

[c] 1N If [b] = 1–7 the data configuration is as follows:

<FS> 1AN If an FS (0x1C) character is here the display of new configuration is disabled (optional).



• 0 = Return application version

• 1 = 1200 bps • 2 = 2400 bps

• 3 = 4800 bps • 4 = 9600 bps

• 5 = 19200 bps • 6 = 38400 bps

• 7 = 115200 bps

• 8 and 9 are accepted for backwards compatibility

• 1 = 7 bits, even parity

• 2 =2 = 7 bits, odd parity

• 3 = 8 bits, no parity

• 4 = 8 bits, even parity

• 5 = 8 bits, odd parity

0 SC 5000 EMV APPLICATION ARCHITECTURE AND INTERFACE GUIDE



Packet 13 Length



Packet 13 Example

<SI>130<SO>{LRC} (get app version)

<SI>1311<SO>{LRC} (1200 baud, 7 bits, Even parity)

<SI>1343<SO>{LRC} (9600 baud, 8 bits, No parity)

Packet 13 Length



Packet 13 Example

<SI>001121<SP>100100100<SO>{LRC}

Table 7 Response Packet Format




[application version string] 32AN String containing the app version





PIN Pad

<SI>13[b][c]<SO>{LRC}

• ACK if LRC okay



<SI>13[application version string]<SO>{LRC)

only if [b] = 0

• ACK if LRC okay



Baud rate and data configuration are selected accordingly. If [b] ≠ 0.



Encrypted PIN Communication Packets

1

Encrypted PINCommunication

Packets

The following packets initiate test or functions for Master Key Sessions (MS) and are only suitable for key management when the SC 5000 is configured for Master Session or MS + DUKPT. The SC 5000 rejects these packets sending an <EOT> if the PIN pad is configured for DUKPT.

Table 9 Encrypted PIN Packets

Packet Description

02 Transfer Master Key to the PIN pad

04 Check Master Key

08 Select one of the master keys

Z62 Accept and encrypt PIN; display custom messages

71 Transfer PIN Block

??? Cancel Session Request




Packet 02:Transfer Master

Key

The master device uses this packet to send a master key to the PIN pad.

Packet 02 Length



Packet 02 Example

<SI>0200123456789ABCDEF<SO>{LRC}

This example packet requests that the PIN pad load the master key “0123456789ABCDEF” into location “0.”

NOTE To avoid overwriting existing master keys, it is required that Packet 04: Check Master Key is sent to check for valid master keys already present in a designated address prior to sending packet 02.





[n] 1N Master key address:

• 0–9

[hhh...hh] 16H Master key in ASCII





PIN Pad

<SI>02[n][hhhhhhhhhhhhhhhh]<SO>{LRC}

• ACK if LRC okay



<SI>02[n][hhhhhhhhhhhhhhhh]<SO>{LRC}

• ACK if LRC and key echo okay



• EOT if LRC correct but key echo incorrect

PIN pad saves new master key only on receipt of ACK.

EOT terminates entire session.

EOT




1

Packet 04: CheckMaster Key

The master device sends packet 04 to check if the PIN pad has a master key stored at a designated master key address.

Packet 04 Length



Packet 04 Examples

Request sample packet to check if the master key at address 5 is loaded:

<SI>045<SO>{LRC}

Response Packet Length



Response sample packet if no master key at address 5:

<SI>040<SO>{LRC}

NOTE To avoid overwriting existing master keys, it is required that packet 04 is sent to check for valid master keys already present in a designated address prior to sending packet 02.





[a] 1N Master key address:

• 0–9







[r] 1AN Response Code:

0 = No MK at address [a]

F = MK present at address [a]






Packet 08: Select aMaster Key

The master device sends packet 08 to the PIN pad to select one of ten possible master keys (0–9).

The master key address must be in the range 0–9. If the master key address is out of range, the selected MK is not changed. If the master key address is valid, the SMK is set to the new master key location, regardless if the new location contains a master key.



PIN Pad

<SI>04[a] <SO>{LRC}

• ACK if LRC okay



PIN pad checks requested address ([a]).

<SI>04[r]<SO>{LRC}

• ACK if LRC okay



EOT

NOTE To request PIN entry, the master device should always send packet 08 before sending the following packets

• 70

• Z60

• Z62

NOTETo ensure the presence of a valid master key, send Packet 04: Check Master Key before sending packet 08.





[a] 1N Master key address: 0 – 9

[check presence flag] 1A Optional: ‘C’






1

Packet 08 Length



Packet 08 Example

Sample packet to select master key 7:

<SI>087<SO>{LRC}




Response Packet Example

Response Sample Packet if no master key at address 5:

<SI>080<SO>{LRC}





[r] 1AN Response Code:

0 = No MK at address [a]

F = MK present at address [a]



NOTE

The response packet is only available if [check presence flag] is set to ‘C’.



PIN Pad

<SI>08[a] <SO>{LRC}

• ACK if LRC okay



PIN pad makes specified master key ([a]) currently active.

<SI>08[r]<SO>{LRC}




Packet Z62:Accept and

Encrypt PIN,Display Custom

Messages

Packet Z62 initiates the PIN pad to accept a PIN from a customer, build a PIN block, encrypt it (using single DES Master Session key), and return it to the master device.

This packet also allows the master device to specify the length of the PIN and if a null PIN entry is allowed. It displays up to two messages, alternating with each other before PIN entry, and a message after PIN entry.

The [message1] and [message2] fields can contain printable ASCII characters only. Control characters (00-1Fh) are ignored by the PIN pad. If the [message] fields are empty, they are also ignored by the PIN pad.

On receipt of packet 72, the PIN pad sends EOT to terminate the session and displays CANCEL REQUESTED for 2 seconds (if turned on, otherwise returns to idle prompt). All other packets received during a 70 session are ignored (no response).

When the CLEAR ( ) key on the PIN pad, the PIN pad stops the operation and sends EOT to master device to terminate the session, even if a PIN entry was started. If THE CANCEL REQUESTED prompt is enabled (through packet 72), the PIN pad displays the text for 2 seconds, then returns to the idle prompt. If the CANCEL REQUESTED is disabled, the idle prompt displays.

To correct any entry from the keypad, use the BACKSPACE () key.

• ACK if LRC okay



EOT

Table 17 Packet 08 Communication Protocol (continued)


PIN Pad

NOTEDuring a Z62 session, only the receipt of packet 72 from the master device or pressing the CLEAR key ( ) on the PIN pad can cancel the session.

Table 18 Packet Z62 Format


<STX> 1H Start of Text, Value: 02h

Packet type 3AN Value: Z62

Packet Type Del. 1A Value: (.), 2Eh

[aaa...aa] 8-19N Card Account Number

Field Separator 1H Value: 1Ch




1

Packet Z62 Length



Packet Z62 Example 1

<STX>Z62.4000000000006<FS>0123456789ABCDEF0412YMESSAGE 1 <FS>MESSAGE 2<FS>PROCESSING MSG<ETX>{LRC}

On receipt of packet Z62, the PIN pad alternately displays the text for [message 1] and [message 2] until a PIN or null PIN is entered. A null PIN is

generated by pressing the Enter key ( ). Only a PIN with a length range of 4 to 12 digits is accepted. Each PIN digit is echoed with an asterisk (*). As soon as the PIN entry is complete, a third message, PROCESSING MSG, displays.

Packet Z62 Example 2

<STX>Z62.4000000000006<FS>0123456789ABCDEF0608NMESSAGE 1<FS><FS> PROCESSING MSG<ETX>{LRC}

[www...ww] 16H The working key is encrypted

under the PIN pad master key.

If zero filled, PIN pad active

master key is used as the

working key.

[||] 2N Minimum PIN length: 01 – 16

[hh] 2N Maximum PIN length: 01 – 16

[n] 1A Null PIN status

• Y = Null PIN OK

• N = No null PIN

[bbb...bb] 0-16AN Message 1 (Message 1 and 2 will be displayed until the user presses a key)


[ccc...cc] 0-16AN Message 2


[ddd...dd] 0-16AN Processing message to display after PIN entry


<ETX> 1H End of Text, Value: 03h


Table 18 Packet Z62 Format (continued)





On receipt of packet Z62, the PIN pad displays the text for [message 1] and [message 2] until a PIN is entered. No null PIN entry is allowed. Only a PIN with a length range of 6 to 8 digits is accepted. Each PIN digit is echoed with an asterisk (*). As soon as the PIN entry is complete, a third message, PROCESSING MSG, displays.

Packet 71:Transfer PIN Block

In response to the request for a PIN (packets 70, Z60, and Z62), the PIN pad encrypts the formatted clear-text PIN block and sends the cipher text PIN block to the master device (refer to VISA PIN Processing Specification, US Version 1.0).

Packet 71 Length



Packet 71 Examples

<STX>71.000010123456789123456<ETX>{LRC}

<STX>71.00001<ETX>{LRC} <-- NULL entry





Packet delimiter 1A Value: (.), 2Eh

Function Key Indicator 1N Value is 0, Function key feature not implemented

PIN Length 2N Range: 00, 04 – 12

PIN Block Format 2N Value: 01

Format of PIN block prior to encryption.

PIN Block 16AN 64-bit encrypted PIN block represented as 16 hex digits. Length is 0 if null PIN entered.





PIN Pad

<STX>Z62.[aaaaaaaaaaaaaaaaaaa]<FS>[wwwwwwwwwwwwwwww][ll][hh][n]

[bbbbbbbbbbbbbbbb]<FS>[cccccccccccccc]<FS>[ddddddddddddddd]<ETX>{LRC}

• ACK if LRC okay






2

Packet 72:Cancel Session

Request

Packet 72 is the only packet which can be used to cancel or abort the session after initiating PIN entry mode (packets 70, Z60, and Z62).

After the PIN pad receives packet 72, EOT will be sent back to terminate the session. If packet 72 is received and the PIN pad is not in the PIN/data entry mode, ACK will be sent back as in normal condition. All other packets will be ignored (no response) when received during pin/data entry session.

Packet 72 returns the PIN-Pad's display to the default idle prompt (set by Z8).

Packet 72 Length



Packet 72 Examples

<STX>72<ETX>{LRC}

Cycles through these messages:

[bbbbbbbbbbbbbbbb]

[cccccccccccccccc]

User enters PIN; ‘*’ display

<STX>71.[f][pp]01[pppppppppppppppp]<ETX>{LRC}

• ACK if LRC okay



Display

[dddddddddddddddd]

repeatedly

Table 20 Packet 71 Communication Protocol (continued)


PIN Pad









PIN Pad

<STX>72<ETX>{LRC}

• ACK if LRC okay





Custom Specifications

CustomSpecifications

The master device must be able to send to the PIN pad special prompts and data entry requirements for customizing the PIN pad. Under control of the master device, the PIN pad can:

• display a single message,

• display rotating messages (in approximately 3 second intervals), and

• request a single keystroke entry from the customer.

CustomCommunication

Packets

The following custom packets were designed according to specific application requirements:

Table 23 Custom Communication Packets

Packet Description

Z2 Display a string

Z8 Set/reset idle prompt




2

Packet Z2: Displaya String

This packet presents messages to the PIN pad display (up to 32 bytes). These messages can only consist of ASCII printable characters. Control characters (00-1Fh) are ignored.

Packet Z2 Length



Packet Z2 Examples

<STX>Z2THX<ETX>{LRC}

Directs the PIN pad to add the message “THX” to the end of the currently displayed message.

<STX>Z2<SUB>PLZ SLIDE CARD<ETX>{LRC}

Directs the PIN pad to clear the current display, then display the message “PLZ SLIDE CARD.”





<SUB> 1H 1Ah, Optional (clear display)

[sss...ss] 0-32AN Message: ASCII string



Table 25 Packet Z2 Communication Protocol


PIN Pad

<STX>Z2<SUB>[sssssssssssssss]<ETX>{LRC}

• ACK if LRC okay



Clear display. Displays

[ssssssssssssss]




Packet Z8:Set/ Reset Idle

Prompt

Packet Z8 sets the idle prompt in the PIN pad. Sending a null string resets the idle prompt to the default setting.

Packet Z8 Length



Packet Z8 Examples

Reset the idle prompt:

<STX>Z8<ETX>{LRC}

Set the idle prompt to ‘NEW PROMPT:’

<STX>Z8NEW PROMPT<ETX>{LRC}





[ppp...pp] 0-32AN Message: ASCII string



Table 27 Packet Z8 Communication Protocol


PIN Pad

<STX>Z8[pppppppppppppppp]<ETX>{LRC}

• ACK if LRC okay



Idle prompt changed to:

[pppppppppppppppp]




2

CHAPTER 3

Magnetic Card Reader Specifications

The SC 5000 magnetic (mag) card reader allows customers to slide mag stripe cards to enter account information without ever releasing their card.

Packet Q4:Activate/

Deactivate theCard Reader

On power up, the PIN pad mag card reader defaults to the disabled state. The master device can use packet Q4 to toggle the PIN pad card reader between its enabled/disabled state. Packet Q4 tells the PIN pad to allow or not allow data entry from its cardreader.

Packet Q4 Length



Packet Q4 Examples

Activates the PIN pad mag card reader:

<STX>Q40<ETX>{LRC}

Deactivates the PIN pad card reader:

<STX>Q41<ETX>{LRC}

Table 28 Magnetic Card Reader Communication Packets

Packet Description

Q4 Activate/deactivate the card reader

81 Card image response

NOTE

This message does not affect the PIN pad display.

Table 29 Packet Q4 Format



Packet type 2AN Value: Q4

Card reader status 1A Range:

• 0 = Activate

• 1 = Deactivate




MAGNETIC CARD READER SPECIFICATIONS

2

Packet 81: CardImage Response

Packet 81 sends the card information obtained from the PIN pad card reader to the master device. The track data order in Table 31 was adopted for compatibility with existing applications.

Packet 81 Length



PAcket 81 Example

<STX>81.0123456789012345678901234567890123456789<FS><FS><FS><ETX>{LRC}

Table 30 Packet Q4 Communication Protocol


PIN Pad

<STX>Q4[f]<ETX>{LRC}

• ACK if LRC okay



Activate/deactivate card reader.





Message type delimiter 1A Value: (.),2Eh

[track2 data] 0-40N Card image information (track 2) or ‘*’ (0x2A), meaning that an ICC card was inserted.


[track1 data] 0-79AN Card image information (track 1)


[track3 data] 0-107N Card image information (track 3)





PIN Pad

Card swipe



To optimize the communication between the master device and the PIN pad, packet 81 has the capability to signal that an ICC card was inserted to the primary ICC reader. In this case the response is:

<STX>81.*<ETX>{LRC}

<STX>81.[track 2]<FS>[track 1]<FS> [track 3]<FS> <ETX>{LRC}

• ACK if LRC okay





PIN Pad



2

CHAPTER 4

ICC Reader Specifications

The SC 5000 ICC reader allows customers to insert smart cards and perform read/write and security functions associated with the card

Packet I02: Waitfor ICC Removal

Packet 102 makes the SC 5000 wait for removal of the customer ICC from the reader. Packet 102 is only valid for the primary ICC reader. This request can be cancelled at any time with packet 72.

Packet 102 Length



Packet 102 Example Packet

<STX>I02<ETX>{LRC}

Table 33 ICC Reader Communication Packets

Packet Description

I02 Wait for ICC Removal

I05 ICC Presence Check




Packet type 3AN Value: I02







[status] 1N Operation status:

• 0 = Success

• 1 = Invalid parameter




ICC READER SPECIFICATIONS

3




Packet 102 Example

<STX>I020

Packet I05: ICCPresence Check

Packet 105 forces the SC 5000 to check for the physical presence of an ICC in one of its readers.

Packet 105 Length



Packet 105 Example

<STX>I051<ETX>{LRC}



PIN Pad

<STX>I02<ETX>{LRC}

• ACK if LRC okay



Wait for ICC removal.

<STX>I02[status]<ETX>{LRC}

• ACK if LRC okay







[reader] 1N Reader number: 0-4

0 = primary








Packet 105 Example

<STX>I051<ETX>{LRC}


Data Element

Characteristic Comments



[result] 1N Result:

• 0 = no card inserted

• 1 = ICC inserted





PIN Pad

<STX>I05[reader]<ETX>{LRC}

• ACK if LRC okay



Waits for insertion of ICC.

<STX>I05[result]<ETX>{LRC}

• ACK if LRC okay


• (EOT after 3 NAKs)



3

CHAPTER 5

EMV Services

Figure 1 outlines a typical EMV transaction.

Figure 1 ICC and Magnetic Card Swipe Transaction Flow Chart

ICC INSERTED

SELECTAPPLICATION

READ APPLICATIONDATA FROM ICC

DATAAUTHENTICATION

FALLBACKPROCEDURE

STOP

MS CARD SWIPE

CARD RANGING

AMOUNT ENTRY

PROCESSINGRESTRICTIONS

EMV TERMINAL RISKMANAGEMENT

CARDHOLDERVERIFICATION

TERMINCAL ACTIONANALYSIS

ONLINE?

TERMINAL-TO-HOSTPROTOCOL

ISSUER AUTHENTICATION,SCRIPT PROCESSING, AND

SECOND CRYPTOGRAM

TRANSACTION COMPLETED

MS TERMINAL RISKMANAGEMENT

ONLINE?

FAILED

FAILED

GOOD MS

Y

N

Y

N


EMV SERVICES

Primary EMV Communication Packets

3

Transaction Tasks The transaction tasks listed in Figure 1 are summarized as follows:

1 Transaction initialization (not shown in Figure 1).

2 Chip card inserted or magnetic card swiped.

3 Application is selected.

4 Read application data from card.

5 Data authenticated.

6 Fallback procedures enacted.

7 Card ranging.

8 Total transaction amount entered.

9 Processing restrictions checked.

10 EMV or MS terminal risk management assessed.

11 Cardholder verified.

12 Terminal action analysis completed.

13 Card generated first cryptogram.

14 Terminal-to-host protocol verified.

15 Issuer authenticated.

16 Script processed.

17 Card generated second cryptogram.

18 Transaction completed.

Primary EMVCommunication

Packets

The messages listed in this section are the main commands required to facilitate the transactions described above.

The objective of these commands is to minimize the communication steps between the master device and the PIN pad, so each message performs as many steps of the whole transaction as possible:

Table 40 EMV Communication Packets

Packet Description

C00 Wait For Card and Select Application

C01 Add Amount, Process AFL, and Authenticate

C02 Risk Management

C03 Get Card Certificate

C04 Transaction Complete

C22 Check Fall Back

C23 Clean Transaction Data

C25 Write to Script File


EMV SERVICES

Step-by-Step EMV Communication Packets

In the following table, the transaction tasks are associated with the appropriate communication packet.

Step-by-StepEMV

CommunicationPackets

In addition to the primary commands listed in Primary EMV Communication Packets, the packets listed in Table 41 enable host-specific or customized services. Most of these are a part or individual steps of the commands listed in Primary EMV Communication Packets.

• Transaction initialization (not shown in Figure 1)

Wait for card and select application (C00).

• Chip card inserted or magnetic card swiped

Wait for card and select application (C00).

• Select application Wait for card and select application (C00).

• Amount entry Terminal application, plus add amount, process AFL and authenticate (C01).

• Read application data from card Add amount, process AFL, and authenticate (C01).

• Data authentication Add amount, process AFL, and authenticate (C01).

• Mag card swipe (MS) Magnetic Card messages (Q4, 81)

• Fallback procedures Check fallback (C22).

• Card ranging Terminal application.

• Processing restrictions Risk management (C02).

• EMV terminal risk management Risk management (C02).

• Cardholder verification Risk management (C02).

• Terminal action analysis Get card certificate (C03).

• Card generates first cryptogram Get card certificate (C03).

• MS terminal risk management Terminal application.

• Terminal-to-host protocol Terminal application.

• Issuer authentication Transaction complete (C04).

• Script processing Transaction complete (C04/C25).

• Second cryptogram Transaction complete (C04).

• Transaction completed Transaction complete (C04).

Table 41 Host-Specific or User-defined Communication Packets

Packet Description

C05 Add Amount and Process AFL

C06 Card Data Authentication

C07 Get Card Config

C08 Card Hold Verification

C09 Processing Restrictions

C10 Terminal Risk Management

C11 Authenticate Issuer

C12 Process Issuer Script


EMV SERVICES

Packet Response Codes

3

The following table associates tasks with the appropriate communication packet.

PacketResponse

Codes

All CXX response packets contain a 2-digit response code (after the CXX identification) that reflects the result of the operation related to the packet. Table 42 lists these codes.

C13 MasterCard Europe (Europay) specific tests

C14 Get CAPK

C15 Set default DDOL

C16 Set default TDOL

C17 Set TACs

C18 Set ROS parameter

C19 Add TLV to Collxn

C20 Get TLV from Collxn

C21 Update TLV in Collxn

C23 Clean transaction data

C24 Get card second certificate

• Transaction initialization (not shown in Figure 1)

Wait for card and select application (C00)

• ICC inserted Wait for card and select application (C00)

• Select application Wait for card and select application (C00)

• Amount entry Terminal application, plus add amount and process AFL (C05)

• Read application data from card Add amount and process AFL (C05)

• Data authentication Card data authentication (C06)

• MS card swiped Magnetic card messages (Q4, 81)

• Fallback procedures Check fallback (C22)

• Card ranging Terminal application

• Processing restrictions Process restrictions (C09)

• EMV terminal risk management Terminal risk management (C10)

• Cardholder verification Cardholder verification (C08)

• Terminal action analysis Terminal application

• Card generates first cryptogram Get card certificate (C03)

• MS terminal risk management Terminal application

• Terminal-to-host protocol Terminal application

• Issuer authentication Authenticate issuer (C11)

• Script processing Process issuer scripts (C12/C25)

• Second cryptogram Get card second certificate (C24)

• Transaction completed

Table 41 Host-Specific or User-defined Communication Packets

Packet Description


EMV SERVICES


Table 42 Packet Response Codes

ResponseCode

Description Comments

00 Operation successful

01 Invalid command code Packet ID (CXX) not recognized.

02 Invalid data format One or more parameters are invalid.

03 Response has more packets The resultant packet has more than 512 bytes. The remaining contents will be immediately sent in an additional packet.

04 Previous step missing Some mandatory step for the required task was not performed.

05 INVALID_CONFIG

06 TIMEOUT

07 TIMER_ERROR

08 CANCELLED

09 COMM_FAILURE

10 CHIP_RDR_FAILURE

20 USE_CHIP_READER

21 USE_MAG_STRIPE

22 CHIP_ERROR

23 CARD_REMOVED

24 CARD_BLOCKED

25 CARD_NOT_SUPPORTED

26 INVALID_APP

27 DO_ABSENT

28 DO_REPEAT

29 INVALID_PIN

30 PIN_LAST_CHANCE

31 PIN_RETRYLIMIT

32 TLVCOLLECTION_FULL

33 TLVFORMAT

34 INVALID_PDOL

35 INVALID_CDOL

36 INVALID_TDOL

37 INVALID_DDOL

38 INVALID_SDOL

39 AID_LIST_FULL

40 PSE_NOT_FOUND

41 ICC_DATA_MISSING

42 CANDIDATELIST_EMPTY


EMV SERVICES


3

43 APDU_FORMAT

44 HASH_FAILED

45 BAD_TRACK2

46 CERTIFICATE_EXPIRED

47 DIFF_AVN_ERR

48 SERVICE_NOT_ALLOWED

49 APP_NOTYET_EFFECTIVE

50 APP_EXPIRED

51 LOWER_LMT_EXCEED

52 UPPER_LMT_EXCEED

53 CVM_FAILED

54 UNRECOGNIZED_CVM

55 BAD_DATA_FORMAT

56 BAD_HASHALGO

57 BAD_IPKALGO

58 INVALID_LENGTH

59 TAG_NOTFOUND

60 INVALID_OFFSET

61 BAD_COMMAND

62 TAG_ALREADY_PRESENT

63 READ_RECORD_FAILED

64 EXPLICIT_SELEC_REQD

65 COND_NOT_SATISFIED

66 CSN_FAILURE

67 BAD_SLOT

68 BAD_LEN

69 NO_MEM

70 CAPK_ERROR

71 PIN_CONFIG_ERR

72 EST_TAB_ERR

73 MVT_TAB_ERR

74 SCRIPT_ERROR

75 LOG_ERROR

76 COMBINED_DDA_AC_GEN_REQD

77 COMBINED_DDA_AC_GEN_FAILED

78 CARD_INSERTED

97 UNRECOG_RETURN

98 UNEXPECTED_RETURN

99 FAIL

Table 42 Packet Response Codes (continued)

ResponseCode

Description Comments


EMV SERVICES

Card Status Detection

Some return codes are not expected to be received under normal conditions (for example, 97 and 98). It is possible that these packets may be sent in any unpredictable situation. In this case, a negative number can follow the response code. Report negative-number response codes when requiring support from the VeriFone Helpdesk.

Card StatusDetection

ICC insertion and removal events are signaled by the SC 5000 EMV application to the master device. To allow this, unsolicited packets must be enabled through EMVG_DNF.DAT.

It is also possible to display “CARD INSERTED” or “CARD REMOVED,” according to the event, if configured in the MVT.DAT table.

If these features are enabled, C00 begins card status detection. If the card is inserted before issuing C00, the event is not detected.

After the card is removed or C23 is issued, card status detection is turned off.

Unsolicited packets do not substitute any CXX response, so receipt of C99 and then a CXX answer is normal (see Packet C99: Unsolicited Packet).

Packet C00: WaitFor Card and

Select Application

This command takes the internal data base configuration data from the SC 5000, which is not specific to any particular card, and puts it in the data object collection (DOC). It also obtains the date and time and puts them in the DOC. This command must be called at the start of every transaction.

This command also checks for ICC presence and establishes communication with an EMV card. The C00 command:

• Switches the card on, attempts to read the ATR, and decides whether to use the T=0 or T=1 protocol. It sets the appropriate parameters required for terminal-to-card communication, and tests the ATR for conformance with the EMV ’96, 3.1.1, Card Spec., Part I, 4.

• Looks for a PSE file on the card. If found, it makes the selection according to implicit selection rules. Otherwise, it uses explicit selection (EMV ’96, ICC Spec., Part III). C00 uses the list of supported applications present in the SC 5000 internal data base.

• Performs application selection.

Table 43 Packet C00 Format



Packet type 3AN Value: C00

[timeout] 3N Time to wait for card insertion in seconds

Terminal Record 2N Terminal DB record number to be used.

Date 6N Current date in “YYMMDD” format.

Time 6N Current time in “HHMMSS” format


EMV SERVICES


4

Packet C00 Length



Packet C00 Example

<STX>C0000301020325120000<ETX>{LRC}


• MAX: depends on the tag length



<STX>C0000[Data]<ETX>{LRC}







[response] 2N According to Table 42

[AID len] 3N Tag 4F length (= n)

[AID] nH (2nAN) Tag 4F (ASCII representation of hex)

[Pref Name len] 3N Tag 9F12 length (= n)

[Pref Name] nH (2nAN) Tag 9F12 (ASCII representation of hex)

[App Label len] 3N Tag 50 length (= n)

[App Label] nH (2nAN) Tag 50 (ASCII representation of hex)



Table 43 Packet C00 Format (continued)


Table 45 Packet C00 Communication Protocol


PIN Pad

<STX>C00[timeout][term rec][date][time]<ETX>{LRC}

• ACK if LRC okay



SC 5000 performs card treatments.


EMV SERVICES


Packet C01: AddAmount, Process

AFL, andAuthenticate

The C01 command:

• Adds the transaction amounts authorized and cash back TLV data objects to the DOC.

• Tries to initialize the application selected at C00. In case of failure, C01 allows the user to select another application (if available). In this case, the three C00 return fields are replaced by three new fields at C01 response. If the initialized application is the one selected at C00, the first three C01 fields return empty.

• Performs get processing options and obtains the AFL and other data objects, which are placed in the DOC. If the selected application is Easy Entry (as defined in VIS 1.3), the Easy Entry condition value returns.

• Takes the AFL from the DOC and uses it to locate files associated with the selected card application. C01 reads all appropriate records from these files, extracts the data, and places it in the DOC. C01 then counts the mandatory data objects and ensures that a data object does not occur more than once.

• Builds up the concatenated static data required for static data authentication (SDA), as appropriate. (See EMV ’96, Application Spec., 7.2.)

• Takes the relevant cryptographic data from the DOC and uses it to perform either SDA or dynamic data authentication (DDA), as required (according to EMV ’96, ICC spec., Part IV, 1. & 2). And takes the relevant CA public key from the appropriate config file described in the Appendix.

• Checks the issuer public key certificate serial number against a list of revoked serial numbers maintained in the internal data base. It adjusts the values of the TVR and TSI in the DOC as appropriate. If the card does not support SDA or DDA, C01 returns SUCCESS and does nothing.

<STX>C00[response][data]<ETX>{LRC}

• ACK if LRC okay



Table 45 Packet C00 Communication Protocol (continued)


PIN Pad





[transaction type] 1N 0 = credit

1 = debit

[amount] 12N Transaction amount (maximum 12 digits)


EMV SERVICES


4

Packet C01 Length



Packet C01 Example

<STX>C011000000001000000000000000<ETX>{LRC}

[cash back amount] 12N Transaction cash back amount

(maximum 12 digits)

[currency code] 4N Optional.

Substitutes Tag 5F2A at the collection.








[AID len] 3N Tag 4F length (= n)

[AID] nH (2nAN) Tag 4F (ASCII representation of hex).

This field returns empty if the initialized application is the same as selected in C00.

[Pref Name len] 3N Tag 9F12 length (= n)

[Pref Name] nH (2nAN) Tag 9F12 (ASCII representation of hex).


[App Label len] 3N Tag 50 length (= n)

[App Label] nH (2nAN) Tag 50 (ASCII representation of hex).


[Serv Code len] 3N Tag 5F30 length (= n)

[Serv Code] nH (2nAN) Tag 5F30 (ASCII representation of hex)

[CHolder Name len] 3N Tag 5F20 length (= n)

[CHolder Name] nH (2nAN) Tag 5F20 (ASCII representation of hex)

[Track 2 Eq len] 3N Tag 57 length (= n)

[Track 2 Eq] nH (2nAN) Tag 57 (ASCII representation of hex)

[PAN len] 3N Tag 5A length (= n)




EMV SERVICES






<STX>C0100[Data]<ETX>{LRC}

[PAN] nH (2nAN) Tag 5A (ASCII representation of hex)

[Exp Date len] 3N Tag 5F24 length (= n)

[Exp Date] nH (2nAN) Tag 5F24 (ASCII representation of hex)

[PAN Seq len] 3N Tag 5F34 length (= n)

[PAN Seq] nH (2nAN) Tag 5F34 (ASCII representation of hex)

[authentication status] 1N • 0 = success

• 1 = CAPK not found

• 2 = CAPK check sum failure

• 3 = CAPK check sum absent

• 4 = SDA failed

• 5 = DDA failed



Table 47 Response Packet Format (continued)




PIN Pad

<STX>C01[tran type][amount][cash back amount]<ETX>{LRC}

• ACK if LRC okay




<STX>C01[response][data]<ETX>{LRC}

• ACK if LRC okay




EMV SERVICES


4

Packet C02: RiskManagement

Based on the card ranging performed by the terminal application (so that the application knows the issuer and the acquirer), packet C02 collects all configuration data required to perform a particular transaction (in addition data already collected when C00 is sent). It does this by looking through the SC 5000 internal card scheme, general EMV data, and issuer and acquirer tables.

Packet C02:

• Takes the relevant data from the DOC (which must include the transaction amount) and uses it to perform both the processing restrictions and the terminal risk management procedures (according to EMV ’96, Application Spec., 7.4. & 7.6). Adjusts the values of the TVR and TSI in the DOC as appropriate. If the card does not support terminal risk management, this part of the function is not performed and the ‘TRM Performed’ bit is not set in the TSI. Packet C02 must be called after amount is entered.

• Takes the relevant data from the DOC (mainly the CVM list) and performs cardholder verification (according to EMV ’96, Application Spec., 7.5. & 7.6). Adjusts the values of the TVR and TSI in the DOC as appropriate. If the card does not support cardholder verification, the ‘Cardholder Verification Performed’ bit is not set in the TSI.

Packet C02 Length



Packet C02 Example

<STX>C0200010001<ETX>{LRC}





[issuer number] 4N Issuer index to the internal tables

• 0 indicates no reference

[acquirer number] 4N Acquirer index to the internal tables

• 0 indicates no reference









EMV SERVICES






<STX>C020010050000000000002E800<ETX>{LRC}

Packet C03: GetCard Certificate

Packet C03:

• Performs terminal action analysis (see EMV ’96, Application Spec., 7.7) to decide what kind of certificate to request. It takes CDOL1 from the DOC, together with the TDOL, where necessary.

• Can take the default TDOL from the configuration data. Packet C03 uses these data objects to assemble the data string required to perform the generate application cryptogram procedure (according to EMV ’96, ICC Spec., Part II, 2.4.5 and EMV ’96, Application Spec., 8.

[signature flag] 1N • 0 = signature not required

• 1 = signature required

• 2 = online PIN required

[TVR len] 3N Tag 95 length (= n)

[TVR] nH (2nAN) Tag 95 (ASCII representation of hex)

[TSI len] 3N Tag 9B length (= n)

[TSI] nH (2nAN) Tag 9B (ASCII representation of hex)







PIN Pad

<STX>C02[issuer number][acquirer number]<ETX>{LRC}

• ACK if LRC okay




<STX>C02[response][signature flag][TVR][TSI]<ETX>{LRC}

• ACK if LRC okay




EMV SERVICES


4

• Adjusts the values of the TVR and TSI in the DOC, as appropriate. It puts the card-generated 8-byte cryptogram (tag 9F26) in the DOC, along with the cryptogram information data (CID, tag 9F27), the issuer application data (tag 9F10), and the application transaction counter (ATC, tag 9F36). The application must inspect the CID to decide how to proceed with the transaction (see EMV ’96, ICC Spec., Part II, 2.4.5.4 & EMV ’96, Terminal Spec., Part I, 2.2.7).

Packet C03 Length



Packet C03 Example

<STX>C031<ETX>{LRC}





[terminal decision] 1N Enables the application to force the transaction online or force a decline. May be because merchant is suspicious or because application must force a particular transaction online (for example, 1 in N checking). Possible values:

• 0 = no decision

• 1 = FORCED_ONLINE

• 2 = FORCED_DECLINE








[CID len] 3N Tag 9F27 length (= n)

[CID] nH (2nAN) Tag 9F27 (ASCII representation of hex)

[Auth Resp len] 3N Tag 8A length (= n)

[Auth Resp] nAN Tag 8A




EMV SERVICES






<STX>C0300001800025901<ETX>{LRC}

Packet C04:Transaction

Complete

Packet C04 takes the data returned by the host after a transaction has gone online and uses the data to perform all necessary steps to complete the transaction (as far as the card is concerned). This always involves performing the second generate AC and can also involve issuer authentication and issuer script processing (EMV ’96, Application Spec., 7.9 & 7.10), depending on the data returned by the host and which processes are supported by the card. It adjusts the values of the TVR and TSI in the DOP, as appropriate. The application must inspect the CID to decide how to complete the transaction.

It is assumed that all scripts returned by the host will have been written (in binary format) to the files SCRIPT71.DAT (for the type 71 scripts) and SCRIPT72.DAT (for the type 72 scripts). In each file the scripts are simply written sequentially with no separators.



PIN Pad

<STX>C03[terminal decision]<ETX>{LRC}

• ACK if LRC okay




<STX>C03[response][CID]<ETX>{LRC}

• ACK if LRC okay








EMV SERVICES


4

Packet C04 Length



Packet C04 Example

<STX>C042<ETX>{LRC}


• MAx: 115 characters



<STX>C0400001400211223344551122334455<ETX>{LRC}

[host decision] 1N Possible values:

• 0 = HOST_AUTHORISED

• 1 = HOST_DECLINED

• 2 = FAILED_TO_CONNECT

• 3 = REFERRAL_AUTHORIS

• 4 = REFERRAL_DECLINE












[scripts processed] 2N Number of scripts processed

[script 1 results] 5H (10AN) Results obtained on script 1 processing (ASCII representation of hex)

... ... ...

[script n results] 5H (10AN) Results obtained on script n processing (ASCII representation of hex)



Table 55 Packet C04 Format (continued)



EMV SERVICES


Packet C05: AddAmount and

Process AFL

Packet C05:

• Adds the transaction amounts, authorized and cash back TLV data objects, to the DOC.

• Takes the AFL from the DOC and uses it to locate the files associated with the selected card application.

• Reads all appropriate records from these files, extracts the data, and puts the data in the DOC. Packet C01 then counts the mandatory data objects and ensures that a data object does not occur more than once.

• Builds up the concatenated static data required for SDA, where appropriate (see EMV ’96, Application Spec., 7.2).

Packet C05 Length





PIN Pad

<STX>C04[host decision]<ETX>{LRC}

• ACK if LRC okay



SC 5000 performs card treatments

<STX>C04[response][scripts processed][script 1 results]...[script n results]<ETX>{LRC}

• ACK if LRC okay







[transaction type] 1N • 0 = credit

• 1 = debit

[amount] 12N Transaction amount (maximum 12 digits)

[cash back amount] 12N Transaction cash back amount

(maximum 12 digits)




EMV SERVICES


5

Packet C05 Example

<STX>C051000000001234000000000000<ETX>{LRC}





<STX>C0500<ETX>{LRC}

Packet C06: CardData

Authentication

Packet C06:

• Takes the relevant cryptographic data from the DOC and uses it to perform either SDA or DDA, as required (according to EMV ’96, ICC Spec., Part IV, 1. & 2).

• Takes the relevant CA public key from the appropriate config. file described in the Appendix.

• Checks the issuer public key certificate serial number against the list of revoked serial numbers maintained in the internal data base.

• Adjusts the values of the TVR and TSI in the DOC, as appropriate.


Data Element

Characteristic Comments








PIN Pad

<STX> C05[tran type][amount][cash back amount]<ETX>{LRC}

• ACK if LRC okay




<STX>C05RR<ETX>{LRC}

• ACK if LRC okay




EMV SERVICES


If the card does not support SDA or DDA this function returns SUCCESS and does nothing.

Packet C06 Length



Packet C06 Example

<STX>C06<ETX>{LRC}

















[authentication status] 1N • 0 = success

• 1 = CAPK not found

• 2 = CAPK check sum failure

• 3 = CAPK check sum absent

• 4 = SDA failed

• 5 = DDA failed




EMV SERVICES


5

Packet C07: GetCard Config

Packet C07 collects all configuration data required to perform a particular transaction (in addition to that already collected when C00 is sent) based on the card ranging performed by the terminal application (so that the application knows the issuer and the acquirer). It does this by looking through the SC 5000 internal card scheme, general EMV data, issuer and acquirer tables.

Packet C07 Length



Packet C07 Example

<STX>C0700010001<ETX>{LRC}



PIN Pad

<STX>C06<ETX>{LRC}

• ACK if LRC okay





• ACK if LRC okay







[issuer number] 4N Issuer index to the internal tables

[acquirer number] 4N Acquirer index to the internal tables











EMV SERVICES







Packet C08: CardHolder Verification

Packet C08:

• Takes the relevant data from the DOC (mainly the CVM list) and performs cardholder verification (according to EMV ’96, Application Spec., 7.5. & 7.6).

• Adjusts the values of the TVR and TSI in the DOC, as appropriate.

If the card does not support cardholder verification, packet C08 returns SUCCESS and does nothing, the ‘Cardholder Verification Performed’ bit is not set in the TSI.

If online PIN verification is required, the online PIN entry function is called. If online PIN is not supported, the pointer to this function should be set to NULL.

Packet C08 Length





PIN Pad

<STX>C07[issuer number][acquirer number]<ETX>{LRC}

• ACK if LRC okay





• ACK if LRC okay










EMV SERVICES


5

Packet C08 Example

<STX>C08<ETX>{LRC}






Packet C09:Processing

Restrictions

Packet C09:

• Takes relevant data from the DOC and uses it to perform processing restrictions (according to EMV ’96, Application Spec., 7.4).

• Adjusts the value of the TVR in the DOC, as appropriate.






[signature flag] 1N • 0 = signature not required

• 1 = signature required

• 2 = online PIN required





PIN Pad

<STX>C08<ETX>{LRC}

• ACK if LRC okay




<STX>C08RR[signature flag]<ETX>{LRC}

• ACK if LRC okay




EMV SERVICES


Packet C09 Length



Packet C09 Example

<STX>C09<ETX>{LRC}





















PIN Pad

<STX>C09<ETX>{LRC}

• ACK if LRC okay





• ACK if LRC okay




EMV SERVICES


5

Packet C10:Terminal RiskManagement

Packet C10:

• Takes relevant data from the DOC and uses it to perform terminal risk management (according to EMV ’96, Application Spec., 7.6).

• Adjusts the values of the TVR and the TSI in the DOC, as appropriate.

• Must be called after amount is entered.

Packet C10 Length



Packet C10 Example

<STX>C10<ETX>{LRC}





















PIN Pad

<STX>C10<ETX>{LRC}

• ACK if LRC okay




EMV SERVICES


Packet C11:Authenticate

Issuer

Packet C11:

• Takes the issuer authentication data the application received from the host after going online and performs issuer authentication (as described in EMV ’96, Application Spec. 7.9).

• Adjusts the values of the TVR and the TSI in the DOC, as appropriate.

If issuer authentication is not supported, the function returns SUCCESS and does nothing.

It is assumed that the issuer authentication data (tag 91) is in the DOC.

Packet C11 Length



Packet C11 Example

<STX>C11<ETX>{LRC}



• ACK if LRC okay





PIN Pad















EMV SERVICES


5

Packet C11 Length



Packet C11 Example


Packet C12:Process Issuer

Script

Packet C12 takes an issuer script received from the host and sends it to the card (as described in EMV ’96, Application Spec. 7.10).

Packet C12 Length



Packet C12 Example




PIN Pad

<STX>C11<ETX>{LRC}

• ACK if LRC okay





• ACK if LRC okay



NOTE It is the responsibility of the application developer to ensure that the script is sent to the card at the correct point in the transaction (before or after the second generate AC) and that the TVR and TSI are adjusted as appropriate.





[Script Type] 2N 71 or 72




EMV SERVICES






<STX>C12000211223344551122334455<ETX>{LRC}<ETX>{LRC}

Packet C13:Europay-Specific

Tests

MasterCard Europe (previously known as Europay) mandates requirements for EMV cards in addition to those of the EMV specification. A card whose AID value indicates that it is issued by MasterCard Europe or MasterCard is normally subject to these requirements that is, it is rejected if it does not meet MasterCard Europe’s requirements, even if it meets all EMV requirements.

Packet C13:


Data Elements Characteristic Comments




[scripts processed] 2N Number of scripts processed

[script 1 results] 5H (10AN) Results obtained on script 1 processing (ASCII representation of hex)

... ... ...

[script n results] 5H (10AN) Results obtained on script n processing (ASCII representation of hex)





PIN Pad

<STX>C12[script type]<ETX>{LRC}

• ACK if LRC okay




<STX>C12RR[scripts processed][script 1 results]...[script n results]<ETX>{LRC}

• ACK if LRC okay




EMV SERVICES


6

• Performs all additional card data checks required by MasterCard Europe if the card’s AID indicates it is a MasterCard Europe card

• Tests for additional mandatory data objects.

• Validates track 2 equivalent data.

• Compares the second terminal application version number.

Call packet C13 after EMV processing restrictions and terminal risk management.

Packet C13 Length



Packet C13 Example

<STX>C13<ETX>{LRC}




















EMV SERVICES


Packet C14: GetCAPK

Packet C14 obtains the appropriate CA public key modulus and exponent required for SDA or DDA. It does this by opening the relevant CAPK configuration file and extracting the key + exponent in binary form.

This function must be called if the application is using an SDA or DDA module different from the one provided in the VeriFone Tool Kit.

Packet C14 Length


• MIN:18 characters

Packet C14 Example

<STX> C1400A0000000030C <ETX>{LRC}



PIN Pad

<STX>C13<ETX>{LRC}

• ACK if LRC okay





• ACK if LRC okay







[RID] 5H (10AN) Registered application ID (ASCII representation of hex)

[CAPK Index] 1H (2AN) Certification authority public key index (ASCII representation of hex)









EMV SERVICES


6


• MAX: depends on the length of CAPK



<STX>C1400040C2CC423911DC4697CC223F7CBBD82C100FF4313C2D0F06941DBEE34A9D512FAC7957CB4A03BF16A10103<ETX>{LRC}

Packet C15: SetDefault DDOL

Packet C15 sets the default DDOL directly.

This is for situations where the configuration data handling mechanism provided by the EMV Tool Kit is not appropriate.

[CAPK Modulus len] 3N CAPK modulus length (= n)

CAPK Modulus nH (2nAN) CAPK modulus (ASCII representation of hex)

[CAPK Exponent len] 2N CAPK exponent length (= 2m)

CAPK Exponent mH (2mAN) CAPK exponent (ASCII representation of hex)







PIN Pad

<STX>C14[RID][CAPK Index]<ETX>{LRC}

• ACK if LRC okay




<STX>C14RR<ETX>[CAPK Modulus le][CAPK Modulus][CAPK Exponent len][CAPK Exponent]{LRC}

• ACK if LRC okay







[DDOL len] 3N DDOL length (= n)(= n)

[DDOL] nH (2nAN) DDOL (ASCII representation of hex)


EMV SERVICES


Packet C15 Length



Packet C15 Example

<STX>C15010AABBCCDDEE<ETX>{LRC}

















PIN Pad

<STX>C15[DDOL len][DDOL]<ETX>{LRC}

• ACK if LRC okay





• ACK if LRC okay






EMV SERVICES


6

Packet C16: SetDefault TDOL

Packet C16 sets the default TDOL directly.

This for situations where the configuration data handling mechanism provided by the EMV Tool Kit is not appropriate.

Packet C16 Length



Packet C16 Example

<STX>C16010AABBCCDDEE<ETX>{LRC}










[TDOL len] 3N TDOL length (= n)(= n)

[TDOL] nH (2nAN) TDOL (ASCII representation of hex)












PIN Pad

<STX>C16[TDOL len][TDOL]<ETX>{LRC}

• ACK if LRC okay




EMV SERVICES


Packet C17: SetTACs

Packet C17 sets the TACs directly.


Packet C17 Length



Packet C17 Example

<STX>C17AAAAAAAAAABBBBBBBBBBCCCCCCCCCC<ETX>{LRC}






• ACK if LRC okay





PIN Pad





[TAC Decline] 5H (10AN) TAC decline (ASCII representation of hex)

[TAC Online] 5H (10AN) TAC online (ASCII representation of hex)

[TAC Default] 5H (10AN) TAC default (ASCII representation of hex)











EMV SERVICES


6



Packet C18: SetROS Parameter

Packet C18 sets the parameters for random online selection directly.


Packet C18 Length



Packet C18 Example

<STX>C18000000000000012300000000000000045600050000060000<ETX>{LRC}



PIN Pad

<STX>C17[TAC Decline][TAC Online][TAC Default]<ETX>{LRC}

• ACK if LRC okay





• ACK if LRC okay







[Floor Limit] 18N Floor Limit (in cents)

[RS Threshold] 18N RS Threshold (in cents)

[RS Target] 6N RS Target percentage (3 decimals)

[RS Max] 6N RS Max percentage (3 decimals)








EMV SERVICES







Packet C19: AddTLV to Collxn

Packet C19 is required when an application must add a tagged EMV data object in the data object collection (DOC) or to add a new data object to the DOC.

Packet C19 Length









PIN Pad

<STX>C18[Floor Limit][RS Threshold][RS Target][RS Max]<ETX>{LRC}

• ACK if LRC okay





• ACK if LRC okay







[Tag] 2H (4AN) Tag name (ASCII representation of hex)

[Len] 3N Data length (= n)(= n)

[Data] nH (2nAN) Data (ASCII representation of hex)




EMV SERVICES


6


Packet C19 Example

<STX>C19008E016AABBCCDDEEFFGGHH<ETX>{LRC}






Packet C20: GetTLV from Collxn

Packet C20 is required when an application must obtain a tagged EMV data object in the DOC or to add a new data object to the DOC.

Since someone may need to retrieve a set of tags, several tags may be required by the same packet. In this case, the response may be bigger than the 512-byte limit for a response packet, and the PIN pad needs to send additional response packets to perform the task. This situation can be recognized by a [response] = 03, indicating additional response packets are being transmitted.










PIN Pad

<STX>C19[Tag][Len][Data]<ETX>{LRC}

• ACK if LRC okay





• ACK if LRC okay




EMV SERVICES


The response packet(s) contain all tags required in the same order as asked for. If some tags required do not exist in the DOC, their length is set to zero.

Packet C20 Length



Packet C20 Example

<STX>C2002008E9F54<ETX>{LRC}





[number of Tags] 2N Total tags required (n).

• MAX = 10.

[Tag 1] 2H (4AN) First tag required (ASCII representation of hex)

[Tag 2] 2H (4AN) Second tag required (ASCII representation of hex)

... ... ...

[Tag n] 2H (4AN) nth tag required (ASCII representation of hex)








[Len 1] 3N First required tag data length (= n)(= n)

[Data 1] nH (2nAN) First required tag data (ASCII representation of hex)

[Len 2] 3N Second required tag data length (= n)(= n)

[Data 2] nH (2nAN) Second required tag data (ASCII representation of hex)

... ... ...

[Len n] 3N nth required tag data length (= n)(= n)

[Data n] nH (2nAN) nth required tag data (ASCII representation of hex)




EMV SERVICES


7





<STX>C2000016AABBCCDDEEFFGGHH006AABBCC<ETX>{LRC}

Packet C21:Update TLV in

Collxn

Packet C21 is required when an application needs to update a tagged EMV data object in the DOC or to add a new data object to the DOC.



PIN Pad

<STX>C20[number of Tags][Tag 1]...[Tag n]<ETX>{LRC}

• ACK if LRC okay




<STX>C2003[Len 1][Data 1]...<ETX>{LRC}

(optional)

• ACK if LRC okay



<STX>C20RR...[Len n][Data n]<ETX>{LRC}

• ACK if LRC okay







[number of Tags] 2N Total tags required (m).

• MAX = 10.

[Tag 1] 2H (4AN) Tag name (ASCII representation of hex)

[Len 1] 3N Data length (= n)

[Data 1] nH (2nAN) Data (ASCII representation of hex)

... ... ...

[Tag m] 2H (4AN) Tag name (ASCII representation of hex)

[Len m] 3N Data length (= n)

[Data m] nH (2nAN) Data (ASCII representation of hex)


EMV SERVICES


Packet C21 Length



Packet C21 Example

<STX>C21008E016AABBCCDDEEFFGGHH<ETX>{LRC}

















PIN Pad

<STX>C21[Tag][Len][Data]<ETX>{LRC}

• ACK if LRC okay





• ACK if LRC okay






EMV SERVICES


7

Packet C22: CheckFallback

When a magnetic stripe card is read, packet C22 must be issued to verify that the card is EMV and has a chip. This is done through the service code on the stripe. If this is the case, the magnetic stripe transaction is only allowed if the last ICC read failed. This is done internally by the EMV application. The following are possible scenarios:

• If does not contain an EMV chip, continue the MS transaction.

• If it does contain an EMV chip and the last ICC read failed, continue the MS transaction.

• If it does contain an EMV chip and the last ICC read did not fail, display a message and return the appropriate response code.

Packet C22 Length



Packet C22 Example











[service code] 3N Magnetic stripe service code











EMV SERVICES


Packet C23: CleanTransaction Data

Packet C23:

• Resets all the parameters for that transaction.

• Cleans all the TLV data objects at the DOC.

Packet C23 Length



Packet C23 Example

<STX>C23<ETX>{LRC}



PIN Pad

<STX>C22[service code]<ETX>{LRC}

• ACK if LRC okay





• ACK if LRC okay

















EMV SERVICES


7






Packet C24: GetCard Second

Certificate

Packet C24:

• Performs the second generate AC operation.

• Puts the card-generated 8-byte cryptogram (tag 9F26) in the DOC along with the cryptogram information data (CID, tag 9F27), the issuer application data (tag 9F10,) and the application transaction counter (ATC, tag 9F36).

The application must inspect the CID to decide how to proceed with the transaction (see EMV ’96, ICC spec., Part II, 2.4.5.4 & EMV ’96, Terminal spec., Part I, 2.2.7).



PIN Pad

<STX>C23<ETX>{LRC}

• ACK if LRC okay





• ACK if LRC okay







[host decision] 1N Host decision. Possible values:

• 0 = HOST_AUTHORISED

• 1 = HOST_DECLINED

• 2 = FAIL_TO_CONNECT

• 3 = REFERRAL_AUTHORIS

• 4 = REFERRAL_DECLINE




EMV SERVICES


Packet C24 Length



Packet C24 Example

<STX>C240<ETX>{LRC}






Packet C25: Writeto Script File

Packet C25 is required for script processing. It allows the creation of EMVS71.DAT and EMVS72.DAT files adding the scripts received from the host.














PIN Pad

<STX>C24[host decision]<ETX>{LRC}

• ACK if LRC okay





• ACK if LRC okay




EMV SERVICES


7

Scripts of type 71 are to execute before second AC generation, and scripts of type 72 after it. The maximum script size supported by the EMV specs. is 261 bytes. The maximum packet size supported by SC 5000 is 512 bytes. The maximum supported size for the script, according to the format below, is 249 bytes.

The solution is to transfer the script in two packets using

[number of scripts] 81 and [number of scripts] 91

The [number of scripts] element is described in Table 118.

Note that in this case, only one script can transfer in the two-packet message.

Packet C25 Length

• MAX: depends on the script length


Packet C25 Example

<STX>C25172010061A2B3C4D5E6F<ETX>{LRC}





[script type] 2N 71 or 72

[clear file flag] 1N • 0 = append script to existing file

• 1 = clear file before adding the script

[number of scripts] 2N Total number of scripts to follow.

Special values:

• 81: The first part of a two-packet message (for scripts larger than 249 bytes)

• 91: The second part of a two-packet message

[script 1 length] 3N Script 1 Data length (= n)

Transfers in this packet for a two-packet message.

[script 1 data] nH (2nAN) Script 1 (ASCII representation of hex)

... ... ..

[script n length] 3N Script n data length (= n)

[script n data] nH (2nAN) Script n data (ASCII representation of hex)

[script length] 3N Data length (= n)

[script data] nH (2nAN) Data (ASCII representation of hex)




EMV SERVICES







Packet C99:Unsolicited Packet

When certain events occur, the SC 5000 EMV application may need to send unsolicited data to the master device. Examples of this are the ICC insertion or removal events. EMV recommends–and some bank specifications require–that the master device is warned about these events and display appropriate messages.

To avoid packet collision, the SC 5000 first sends an ENQ (05h) to the master device, indicating the intention of sending a packet. If the master device answers this request with an ACK (06h), then the SC 5000 sends packet C99, according to the format listed in Table 121.

If the master device does not send an ACK or sends a request packet instead, the SC 5000 abandons the process without sending packet C99.










PIN Pad

<STX>C25<ETX>{LRC}

• ACK if LRC okay





• ACK if LRC okay




EMV SERVICES


7

Packet C99 Length



Packet C99 Example


Packet C3X: SuperCommand

We have designed this message to obtain the best possible performance in making an EMV transaction.

Packet C3X:

• Performs the tasks of C01, C02, C03, C04, C20, C21 and C22. This includes all transaction services, obtaining and updating data objects from and to the internal SC 5000 Data Object Collection, and checking for magnetic stripe fall back.

• Parameters are all binary to prevent the applications from making excessive data conversions.

• Parameters are TLV objects. If they are direct readings or updates to internal Data Object Collection, the tags will be known EMV tags. If the parameters are proprietary data from the application, the tags will be 0xC1, 0xE1, 0xC2, and 0xE2, as explained below.










PIN Pad

ENQ

ACK


• ACK if LRC okay




EMV SERVICES


• Once called, depending on the parameters provided and the transaction results, it will perform as many activities as possible. In the best case, one issue will be sufficient to perform all the transactions.

The idea is to call C3X, where X can be 0 through 4, in increasing order. The C30 is the first packet to be called. The minimum parameters are the same as for the C00 packet but, if C01, C02, C03 or C04 packets' parameters are already available, It is possible to provide them at C30.

Example Situation

Let's suppose that, at the beginning of the transaction, you already have the transaction type, the amounts and the currency code involved. This way you can call the C30 with C00 + C01 parameters. The result will be that the EMV application will perform both packets' services and return a C31 response packet containing the response parameters of C00 + C01 packets.

If, more than that, you are not performing card ranging (no issuer and acquirer specific data considered) and you already have the merchant decision, you will call C30 and receive a C33 response packet.

In the best case, if your terminal has no on-line capability enabled, you already know the host decision: FAILED TO CONNECT. In this case, C30 has a C34 response, completing the transaction with just one packet exchange.

Packet C3X Length

• MAX: depends on the length of the parameter list


Table 123 C3X Parameter Format



Packet type 3AN Value: C3X

X = 1, 2, 3 or 4

[param list size] 2H size of parameters list in 2 binary bytes

[param list] ?H list of parameters in TLV format



Table 124 C3X Response Format



Packet type 3AN Value: C3X

X = 1, 2, 3 or 4



EMV SERVICES


8

Packet C3X Length



Parameters and Response Fields Lists

As mentioned above, the tag labels may be known EMV ones, if directed related to the Data Object Collection present at the SC 5000. They may can also receive special tag labels if they use proprietary data.

The possible proprietary tag labels are:

• 0xC1 - for input parameters.

• 0xE1 - for input constructed objects.

• 0xC2 - for output parameters.

• 0xE2 - for output constructed objects.

Input - Parameters List

• C1<len><timeout>C1<len><terminal record>C1<len><DDMMYY>C1<len><HHMMSS>

• C1<len><txn type>C1<len><amt>C1<len><amt other>C1<len><curr code>

• C1<len><issuer record>C1<len><acquirer record>

[response fields list size]

2H size of response fields list in 2 binary bytes

[response fields list]

?H list of response fields in TLV format



Table 125 Packet C3X Communication Protocol


PIN Pad

<STX>C3X<size1><size2><param list><ETX>{LRC}

• ACK if LRC okay


• (EOT after 3 NAKs)


<STX>C3XRR<size1><size2><response fields list><ETX>{LRC}

• ACK if LRC okay



Table 124 C3X Response Format



EMV SERVICES


• C1<len><merchant decision>E1<len><min req obj>

• C1<len><host decision>E1<len><TLVs from host>

The parameters in the first list item are the minimum for C30 packet, the ones in the second list item are the minimum for C31, and so on.

Basically they all match with C01,..., C04 parameters except for min req objects and TLVs from host which matches with the C20 packets, issued to update the data needed to assemble the packet to perform an online transaction and the C21 packets to update the Data Collection with the objects received from the host at an online connection.

Output - Response Fields List:

• <4F><len><AID><9F12><len><Application Preferred

Name><50><len><Application Label>

• <5F30><len><Service Code><5F20><len><cardholder name><57><len><Track 2

Equivalent Data><5A><len><Application PAN><5F24><len><Expiration Date><5F34><Application PAN Seq. Number><C2><len><Authentication status>

• C2<len><Signature Flag><9500><len><TVR><9B><len><TSI>

• <9F27><len><Crypt. Info. Data><8A><Authorization Response Code>

• E2<len><Objects Required for an online transaction>

The response fields in the first list item are the minimum returned by C30 packet, the ones in the second list item are the minimum returned by C31, and so on.

Basically they all match with C01,..., C04 response fields except for the Objects Required for an online transaction which matches with the C20 packets, issued to obtain the data needed to assemble the packet to perform an online transaction.


EMV SERVICES


8

CHAPTER 6

EMV Configuration Tables

Use the following two tables to configure an EMV transaction:

• Card scheme table, EST.DAT

• EMV configuration table, MVT.DAT

EST.DAT

MVT.DAT

Name of card scheme VISA, MASTERCARD, and so on.

Registered application identification RID: for example, A000000003 for VISA

10 AID data sets with: Application identification (AID): for example, A0000000031010

Partial name selection flag: Allows or prohibits partial name selection for the AID.

Application version number: for example, 8300

Second application version number: for example, 8300

Pointer to a record in MVT.DAT

• -1 indicates no reference

Card scheme reference Pointer to a record in EST.DAT that this set of mandated data is for.

• -1 indicates non-scheme specific

Issuer reference Pointer to a record at EST.DAT that this set of mandated data is for.

• -1 indicates non-issuer specific.


EMV CONFIGURATION TABLES

8

Term risk management data present flag

Flag required because any one of the following data elements could be set to zero:

• Floor limit

• Random selection threshold

• Target random selection percentage

• MAX target random selection percentage

• Terminal action code – Default

• Terminal action code – Denial

• Terminal action code – Online

Default TDOL Terminal data object list

Default DDOL Dynamic data authentication data object list. Used for DDA.

Next record reference This means that there is another record mandated by the same entity but for a different scheme or issuer.

• -1 indicates no further records.

EMV Transaction Counter

Terminal Country Code

Terminal Currency Code

Terminal Capabilities

Terminal Additional Capabilities

Terminal Type

Merchant Category Code

Auto Select Flag • 1 enabled

• 0 disabled

Terminal ID 8-digit terminal ID

Merchant ID Up to 15 characters of the merchant ID.

Acquirer ID Up to an 11-digit acquirer ID.

Terminal CAPK index (tag 9F22 This tag that must be provided for some DOLs and has no relation to tag 8F.

PIN bypass flag • 1 enabled

• 0 disabled

PIN timeout For ICC card or online PIN, time, in seconds, to wait for a PIN entry.

PIN format For online PIN

• 0-1 Master Session

• 2-9 DUKPT

• B secure scripts



How the Tables are Used

How the Tablesare Used

• At EMV application initialization, all records from EST.DAT are read to generate the AID list, obtaining all supported AIDs for all card schemes (records).

• At transaction initialization when packet C00 is sent by the POS/ECR to the SC 5000, the application reads the MVT.DAT terminal record included in the packet (TR=1 means record=0) as the default-terminal EMV parameters for that transaction.

• During the risk management phase, packet C02 is sent by the POS/ECR to the SC 5000, including the issuer and acquirer record numbers at MVT.DAT. During packet C02 execution, the following fields of the MVT.DAT terminal record may be overruled:

• Floor Limit

• Random Selection Threshold

• Target Random Selection Percentage

• MAX Target Random Selection Percentage

• Terminal Action Code – Default

• Terminal Action Code – Denial

• Terminal Action Code – Online

• Default TDOL

• Default DDOL

PIN script number For online PIN

• 0-7 secure scripts

• 8 Master Session

• 9 DUKPT

PIN macro number For online PIN: if secure scripts are in use.

PIN key derivation flag For online PIN

• 0 = traditional

• 1 = using script

• 2 = none

PIN key derivation macro number For online PIN: If secure scripts are in use.

Card status display flag • 0 = does not display “CARD INSERTED” and “CARD REMOVED” messages on the SC 5000 when this event occurs and unsolicited packets are configured at EMVG_CNF.DAT

• 1 = displays the messages.



Field Format

8

These fields are referenced as ROL (the first 4), TAC (the three terminal action codes), TDOL, and DDOL. This overrule only can happen if the terminal record does not specify values for these fields.

Also during the risk management phase, the acquirer identifier (tag 9F01) is replaced if an acquirer record number is defined in package C02.

a Reads EST.DAT until the current RID record is found, and accesses the exact AID to determine the terminal AVN.

Steps b-d are only performed if any of the TAC, ROL, TDOL, and DDOL parameters are not the default value in the terminal record. In this case, only those with no default value receive a value.

b In the same EST.DAT record, checks for a pointer to any MVT.DAT record that indicates a EMV specific data mandate. If as pointer is found, reads the MVT.DAT record and overwrites the TAC, ROL, TDOL, and DDOL parameters.

c If an issuer record was defined in packet C02 ([rec num] > 0), reads the MVT.DAT record and checks if the card scheme reference matches the record read in step C. If so and any of the EMV parameters (TAC, ROL, TDOL and DDOL) were not loaded yet then load them. If issuer record was defined, check for the next record reference. If ≥ 0, reads this record and check for a match. Continues to scan the table until parameters are loaded or the next record reference = -1 (indicating no reference).

d If an acquirer record was defined in packet C02 ([rec num] > 0), reads the MVT.DAT record and updates the acquirer identifier (tag 9F01) at object collection. It also checks if the card scheme reference and the issuer reference match with the record read in steps c and d. If so and any EMV parameters (TAC, ROL, TDOL, or DDOL) have not been loaded, then loads them. If not, checks for the next record reference. If ≥ 0, reads the record checking for a match. Continues to scan the table until parameters are loaded or the Next Record Reference = -1 (indicating no reference).

Field Format The following tables are created outside the SC 5000, using the GENDATA utility.

Table 126 Card Scheme Table: EST.DAT

Field Name Type Size

1: Name of card scheme Null-terminated string 32 + 1

2: Registered application identification (RID) Null-terminated string 10 + 1

3, 7, 10,..., 39: Application identification Null-terminated string 32 + 1

4,8,11,...40: Partial name selection flag Null-terminated string 1 + 1

5,9,12,...,41: Application version number Null-terminated string 4 + 1

6,10,13,...,42: Second application version number Null-terminated string 4 + 1

43: Pointer to a record in MVT.DAT Null-terminated string 4 + 1



Field Format

Table 127 EMV Configuration Table: MVT.DAT

Field Name Type Size

1: Card scheme reference Null-terminated string 4 + 1

2: Issuer reference Null-terminated string 4 + 1

3: Term risk management data present flag Null-terminated string 1 + 1

4: Floor limit Null-terminated string 14 + 1

5: Random selection threshold Null-terminated string 14 + 1

6: Target random selection percentage Null-terminated string 5 + 1

7: MAX target random selection percentage Null-terminated string 5 + 1

8: Terminal action code: Default Null-terminated string 10 + 1

9: Terminal action code: Denial Null-terminated string 10 + 1

10: Terminal action code: Online Null-terminated string 10 + 1

11: Default TDOL Null-terminated string 64 + 1

12: Default DDOL Null-terminated string 64 + 1

13: Next record reference Null-terminated string 4 + 1

14: EMV transaction counter Null-terminated string 6 + 1

15: Terminal country code Null-terminated string 4 + 1

16: Terminal currency code Null-terminated string 4 + 1

17: Terminal capabilities Null-terminated string 6 + 1

18: Terminal additional capabilities Null-terminated string 10 + 1

19: Terminal type Null-terminated string 2 + 1

20: Merchant category code Null-terminated string 4 + 1

21: Auto select flag Null-terminated string 1 + 1

22: Terminal ID Null-terminated string 8 + 1

23: Merchant ID Null-terminated string 15 + 1

24: Acquirer ID Null-terminated string 11 + 1

25: Terminal CAPK index (tag 9F22) Null-terminated string 2 + 1

26: PIN bypass flag Null-terminated string 1 + 1

27: PIN timeout Null-terminated string 3 + 1

28: PIN format Null-terminated string 1 + 1

29: PIN script number Null-terminated string 1 + 1

30: PIN macro number Null-terminated string 2 + 1

31: PIN key derivation flag Null-terminated string 1 + 1

32: PIN key derivation macro number Null-terminated string 2 + 1

33: Card status display flag Null-terminated string 1 + 1



Certificate Serial Number Checking

8

CertificateSerial Number

Checking

To provide a mechanism to check for invalid issuer certificate serial numbers, you can download exception files to the SC 5000, with the extension .CSN. Their filenames are <RID>.CSN, for example:

A000000003.CNS

.CSN file are text files and each record contains eight ASCII bytes, as follows:

• The two first bytes correspond to two nibbles of CAPK index (for example, 96)

• The six subsequent bytes correspond to six nibbles (three binary bytes) of the CSN to check

These records are separated by CR/LF.


CHAPTER 7

Database Services

This section presents packets to control database services.

DatabaseCommunication

Packets

Database communication packets can be used to define application data objects, including downloadable configuration parameters. In addition, applications can be designed to allow data sharing and/or data object passing to other applications on the SC 5000.

Once the tables are created outside the SC 5000 and are downloaded into it with the applications, this set of commands is not mandatory and are only necessary if the master device application (ECR/POS) decides to change the initial configuration.

DatabaseConcepts and

Definitions

• SC 5000 database fields are all null-terminated strings.

• [Record] is sequence of fields (or strings) separated by an FS (field separator, 0x1C) character.

• [Table IDs] and [Record Numbers] all begin at 1.

• [Condition] is a comparison criteria between a field and a string value in the following format:

NNNCT<string>

where,

Table 128 Database Communication Packets

Packet Description

D00 Create Table

D01 Get Table(s) Info

D02 Seek Record

D03 Read Record

D04 Add New Record

D05 Update Record

D06 Delete Record

D07 Delete Table

D08 Get field from a Table

D09 Put field to a Table

NOTESpecific database implementation design and packet contents are not within the scope of this document.


DATABASE SERVICES

Database Communication Packets

9

• NNN = field number

• C = Comparison

• 0 (for equal)

• 1 (for not equal)

• 2 (for less than)

• 3 (for less or equal)

• 4 (for greater than)

• 5 (for greater or equal)

• T = Type

• 0 (for non-numerical comparison)

• 1 (for numerical comparison)

• [Table Info] is composed of:

<table name><FS><number of records><FS><record size><FS> <number of fields>

Packet ResponseCodes

All DXX response packets contain a two-digit response code (after the DXX identification) that reflects the result of the operation related to the packet. Table 129 describes these codes.

Table 129 Database Packet Response Codes

Code Description Comments

00 Operation successful

01 Invalid command code The packet ID (DXX) is not recognized.

02 Invalid data format One or more parameters are not valid.

03 Response has more packets The resultant packet has more than 512 bytes and the remaining contents are immediately sent in an additional packet.

04 Error opening table

05 Error reading table

06 Error writing to a table

07 Error closing table

08 Error in table record The file containing the table data is corrupt or has invalid data.

09 Table filename duplication The table filename is already registered and has an associated table ID.

10 Table ID invalid There is no table associated with the provided table ID.


DATABASE SERVICES


Packet D00: CreateTable

Packet D00 creates a table (database). Internally, the SC 5000 maintains a record of all created tables. It allows this set of DXX commands to manage the tables by table ID instead of filenames. Also, it checks to ensure that data received matches the table’s structure (that is, number of fields, maximum size, and so on).

The maximum number of tables is 30.

Packet D00 Length



11 Table limit reached The limit of tables to be created has been reached.

• MAX: 30

12 Field limit reached The number of fields is greater than limit.

• MAX: 100

99 Internal failure

Table 129 Database Packet Response Codes (continued)

Code Description Comments

NOTE Table IDs 1, 2, and 3 are reserved by the EMV application, as follows.

• 1 = EST.DAT

• 2 = MVT.DAT

• 3 = EMVG_CNF.DAT

Table 130 Packet D00 Format



Packet type 3AN Value: D00

[Data Base name] up to 30AN Name of the physical file, including its extension.

<FS> 1H Field separator, Value: 1Ch

[Len of Field Sizes] 3N Number of the fields making up the table record, multiplied by 3 (three bytes per field size – 3N).

• MAX: 100 X 3 = 300

[Field 1 Size] 3N Maximum string size accepted for field 1.

... ...

[Field n Size] 3N Maximum string size accepted for field n.




DATABASE SERVICES


9

Packet D00 Example

<STX>D00TEST.DAT<FS>009005010020<ETX>{LRC}





<STX>D000004<ETX>{LRC}




Packet type 3AN Value: DXX

[Response Code] 2N According to Table 129

[Table ID] 2N ID to use in further table accesses



Table 132 Packet D00 Communication Protocol


PIN Pad

<STX>D00[parms]<ETX>{LRC}

• ACK if LRC okay



Table created

<STX>D00RR[data]<ETX>{LRC}

• ACK if LRC okay




DATABASE SERVICES


Packet D01: TableInfo

Packet D01 extracts the internally recorded table data for all or one specific table.

Packet D01 Length



Packet D01 Example



• MAX: depends on the table features



<STX>D010001017TEST.DAT<FS>03<FS>50<FS>4<FS><ETX>{LRC}





[Table ID] 2N 00 for all tables








[Number of Data Tables] 2N Returns 01 for a specific table (Table ID different from 00 on request) or the number of recorded tables (= m).

[Length] 3N Length of the following data until the end of the packet.

[Table Info 1] var First recorded table info.

<FS> 1H Field Separator, Value: 1Ch

... ...

[Table Info m] var mth recorded table info





DATABASE SERVICES


9

Packet D02: SeekRecord

Packet D02 seeks the first record in a specified database that meets all specified conditions (AND logic).

Packet D02 Length

• MAX: depends on the length of the conditions




PIN Pad


• ACK if LRC okay



Database record inquiry.


• ACK if LRC okay







[Table ID] 2N • 01 = EST.DAT

• 02 = MVT.DAT


• 04-30 = user-defined

[Starting Record] 3N Continue searching from a specific record in the table, starting at 1.

[Number of Conditions] 2N • MAX = 5

[Length] 3N Length of the following data until the end of the packet.

[Condition 1] var First condition to meet.


... ...

[Condition m] var mth condition to meet.





DATABASE SERVICES


Packet D02 Example

<STX>D020400101007003011<FS><ETX>{LRC}


• MAX: depends on the length of the record



<STX>D0200003AAA<FS>BBB<FS>1<FS><ETX>{LRC}





[Response Code] 2N According Table 129

[Record Number] 3N Number of the first record found

[Num Fields] 3N Number of fields that follows

[Length] 3N Length of the following field

[Record] var Record fields separated by <FS>





PIN Pad


• ACK if LRC okay



Database search


• ACK if LRC okay




DATABASE SERVICES


9

Packet D03: ReadRecord

Packet D03 reads the contents of a specified record from a specified table.

Packet D03 Length



Packet D03 Example






<STX>D0300004012AAA<FS>BBB<FS>123<FS><ETX>{LRC}






• 02 = MVT.DAT


• 04-30 = user defined

[Record Number] 3N Starts at 1.







[Response Code] 2N According Table 129







DATABASE SERVICES


Packet D04: AddNew Record

Packet D04 adds a new record to the specified table. The new record is appended to the end of the table.

Packet D04 Length



Packet D04 Example

<STX>D0405003015111<FS>1234<FS>TESTE<FS><ETX>{LRC}



PIN Pad


• ACK if LRC okay



Database read record


• ACK if LRC okay








• 02 = MVT.DAT














DATABASE SERVICES


9






Packet D05:Update Record

Packet D05 updates the contents of a specific record in the specified table.

[Record Number] 3N Number of the first record available





PIN Pad


• ACK if LRC okay



Database append record


• ACK if LRC okay










• 02 = MVT.DAT










DATABASE SERVICES


Packet D05 Length



Packet D05 Example

<STX>D0504001003012AAA<FS>CCC<FS>123<FS><ETX>{LRC}






s

Packet D06: DeleteRecord

Packet D06 facilitates deletion of a specific record in the specified table. Subsequent records move up to the deleted record’s position (that is, if record 3 is deleted, record 4 becomes 3, 5 becomes 4, and so on).





[Response Code] 2N According to Table 129)





PIN Pad


• ACK if LRC okay



Database record update


• ACK if LRC okay




DATABASE SERVICES


1

Packet D06 Length



Packet D06 Example












• 02 = MVT.DAT


• 04–30 = user defined













PIN Pad


• ACK if LRC okay



Database record deleted


DATABASE SERVICES


Packet D07: DeleteTable

Packet D07 deletes an existing table (database).

Packet D07 Length



Packet D07 Example








• ACK if LRC okay



Table 150 Packet D06 Communication Protocol (continued)


PIN Pad






• 02 = MVT.DAT













DATABASE SERVICES


1

Packet D08: GetField from Table

Packet D08 gets a field and the maximum length accepted for the specified table.

Packet D08 Length



Packet D08 Example

<STX>D0801001005<ETX>{LRC}



PIN Pad


• ACK if LRC okay



Database table deleted


• ACK if LRC okay








• 02 = MVT.DAT



[Record Number] 3N Starts at 1

[Field Number] 3N Number of the field. See Field Format, page 86








[Field Data Len] 3N Current length of field data (x)


DATABASE SERVICES



• MAX: depends on the length of the field



<STX>D0800003ABC005<ETX>{LRC}

[Field Data] xAN Field data

[Maximum Field Data Len] 3N Maximum accepted length for the field.





PIN Pad


• ACK if LRC okay



Database inquiry


• ACK if LRC okay






DATABASE SERVICES


1

Packet D09: PutField into Table

Packet D09 updates a field value of the specified table.

Packet D09 Length

• MAX: depends on the length of the field


Packet D09 Example

<STX>D0901001005003ABC<ETX>{LRC}











• 02 = MVT.DAT



[Record Number] 3N Starting from 1

[Field Number] 3N Field number. See Field Format, page 86

[Field Data Len] 3N Current length of [Field Data] (x)

[Field Data] xAN Field data











DATABASE SERVICES




PIN Pad


• ACK if LRC okay



Database updated

<STX>D09RR<ETX>{LRC}

• ACK if LRC okay




DATABASE SERVICES


1

CHAPTER 8

Application Switching Packets

This section presents the packets for application switching.

Packet P00:Remote

ApplicationSelection

The master device (for example, an ECR) uses packet P00 to select the required application without user interface on the SC 5000.

• If the application GID received by the currently selected application is valid (that is, the selected application exists in the SC 5000), the SC 5000 (that is, the new application) responds with packet P00 and the result is 00.

• If the application ID received is invalid (that is, does not exist), the currently selected application responds with packet P00 and the result is 01.

Packet P00 Length



Packet P00 Example

<STX>P0001<ETX>{LRC}

NOTEAll information is provided by the OS in the SC 5000. No configuration table is required.

Table 160 Packet P00 Format



Packet type 3AN Value: P00

Application GID 2AN 01 to 15







Result 2N 00 = app selected

01 = impossible to select required app


APPLICATION SWITCHING PACKETS

1





<STX>P0000<ETX>{LRC}

Packet P01: “Whoare You?”

Packet P01 tells the master device which application is running on the SC 5000. The response contains the GID and executable filename (without the extension).

Packet P01 Length





Table 162 Packet P00 Communication Protocol


PIN Pad

<STX>P00[app GID]<ETX>{LRC}

• ACK if LRC okay

• NAK if LRC incorrect.


<STX>P00[result]<ETX>{LRC}

• ACK if LRC okay





NOTE

All information is provided by the OS SC 5000. No configuration table is required.

Table 163 Packet P01 Format








Packet P01 Example

<STX>P01<ETX>{LRC}





<STX>P010002EMVGAPP<ETX>{LRC}





Result 2N • 00 = success

• 01 = cannot to obtain application information

Application GID 2N 1 to 15

Application Name VAN Application executable filename without extension.



Table 165 Packet P01 Communication Protocol


PIN Pad

Master Device PIN-Pad

• ACK if LRC okay



<STX>P01[result][GID][Name]<ETX>{LRC}

• ACK if LRC okay





1

CHAPTER 9

EMV Application Configuration File

The EMVG_CNF.DAT file is a DAT file generated outside the SC 5000 unit by the GENDATA.EXE VeriFone utility. The file has only one record and contains all configurable data for the EMV Application, broken up into the following fields:

• UART Baud Rate - Baud Rate from 1200 to 115200

• UART Data Bits - Data Bits 7 or 8

• UART Parity - Parity O, E, N

• UART Stop Bits - Stop Bits 1 or 2

• UART Timeout - Protocol timeout (default = 15 seconds)

• Serial Number - Slot for an user application SN (optional use)

• Supported Language 1 - Supported Language 1 ISO-639 (default = English - "en")

• Supported Language 2 - Supported Language 2 ISO-639 (default = Spanish - "es")

• Supported Language 3 - Supported Language 3 ISO-639 (default = Portugese - "po")

• Supported Language 4 - Supported Language 4 ISO-639 (default = French - "fr")

• Selected Language - Current selected language - 1 to 4

• Active Language - Current selected language - 1 to 4

• Idle Prompt - User defined idle-prompt (after a Z8 message)

• Unsolicited Enable - 0 = Unsolicited Messages disabled, 1 = Enabled

• Unsolicited Timeout - Timeout to wait for an ACK after sending ENQ

• Back-Light Enable - 0 = Disabled, 1 = Enabled

• Key Injection Style - 0 = ClearText, 1 = 3DES (this is not used by EMV Application. VeriFone provides this option for compatibility with PIN pad Emulation Application).

• Magnetic Stripe Reading Config Byte - Reserved for future use. Its value has no effect at this release.


EMV APPLICATION CONFIGURATION FILE

1

Figure 2 Configuration Table - EMVG_CNF.DAT

Field • Type • Size

1-UART Baud Rate • Null Terminated string • 6 + 1

2-UART Data Bits • Null Terminated string • 1 + 1

3-UART Parity • Null Terminated string • 1 + 1

4-UART Stop Bits • Null Terminated string • 1 + 1

5- UART Timeout • Null Terminated string • 3 + 1

6- Serial Number • Null Terminated string • 16 + 1

7- Supported Language 1 • Null Terminated string • 2 + 1




11-Selected Language • Null Terminated string • 1 + 1

12-Active Language • Null Terminated string • 1 + 1

13- Idle Prompt • Null Terminated string • 32 + 1

14- Unsolicited Enable • Null Terminated string • 1 + 1

15- Unsolicited Disable • Null Terminated string • 3 + 1

16- Back Light Enable • Null Terminated string • 1 + 1

17- Key Injection Style • Null Terminated string • 1 + 1

18- Mag Stripe Reading Config Byte • Null Terminated string • 2 + 1


APPENDIX

Certification Authority Public Key Files

The SC 5000 unit uses Certification Authority Public Key (CAPK) files. These binary files contain:

• 5 bytes for the RID

• 1 byte for PK Index

• 1 byte CAPK Modulus length = n

• n bytes CAPK Modulus

• 1byte CAPK Exponent length = m

• m bytes CAPK Exponent

• 20 bytes CAPK Hash Value (optional)

VeriFone recommends using filenames with some reference to CAPK and PK Index. The file extension has to be .EMV.

Example:

A398.EMV for RID A000000003 and PK Index 98.


SC 5000

EMV Application Architecture and Interface Guide

VeriFone, Inc.2455 Augustine DriveSanta Clara CA 95054-3002Tel: 800-VeriFone (837-4366)www.verifone.com


sbofpefbia

pb`rofqv

ôèfqb`qrob

ljkf=PTuu

e^kaJlsboJ`lrkqbo

jriqfJ^mmif`^qflk

^mmif^k`bp

ljkf=PPuu

jriqfJ^mmif`^qflk

^mmif^k`bp

sbof`bkqob

j^k^dbjbkq

prfqb

^mmif^k`b=

p`=RMMM

fkqbdo^qba

moldo^jj^_ib

mfkmâ

http://www.verifone.com

llaves pinpad verifone emv_sc5000

Documents