v 810 and vx 820 sentinel -...

Integration Guide Author: ND

Circulation: Public Date: 22/02/2013

Vx 810 and VX 820 Sentinel

Author Document name Public ND Vx 810 & VX 820

Sentinel Integration Guide

Date 22nd February 2013 Phone Page number Version 08444 828 200 2 V1.16

Copyright © 2013 VeriFone All rights reserved. Copying and/or redistribution of this information in whole

or in part without the express permission of VeriFone prohibited.

Revision History Ver. Name Date Comments 1.16 ND Feb 2013 - Updated documentation in-line with solution re-

brand - On Hold Transaction functionality detailed - Updated Error Codes table with new error code

(-185) - Updated M-Voucher Response record with the

8th field - Added note in Receipt Printing for Screenless

mode - Updated CARDWAIT socket connection detail - Removed superfluous fields from L2 Record - Added Transaction Response Versions 7 & 8

1.15 ND Oct 2012 - Reformatted the document - Added detail to ‘Recovered Transaction’ (0040)

modifier - CARDWAIT functionality added - Fexco DCC receipt examples added - Updated Transaction Response results with ‘8’

(‘Comms Down’) - Automatic Return Online Functionality detailed - Bill Lodging removed

1.14 ND April 2012 - Pennies XML receipt information documented - Updated document with the new format - WebCom Test URL updated - Updated error codes list - DCC fields in Transaction Response (Version 2)

table updated

Introduction This document has been produced to provide merchants, Point of Sale solution providers and other system integrators with the information necessary to integrate to the Vx 810 and VX 820 Sentinel solution.

Information about the product, background information on VeriFone and all integration messages are included.

For step-by-step instructions on installing the product, please refer to the Vx 810 and VX 820 Sentinel Installation Guide.






Content Revision History ......................................................................................................................... 2

Introduction ................................................................................................................................ 2

1. Solution Overview .................................................................................................................. 7

1.1. Sentinel Software ....................................................................................................... 7

1.2. Supported PEDs ......................................................................................................... 8

1.2.1. Vx 810 ....................................................................................................................... 8

1.2.2. VX 820 ...................................................................................................................... 9

1.3. Operation Modes ...................................................................................................... 10

1.3.1. Screenless .............................................................................................................. 10

1.3.2. Semi Attended ........................................................................................................ 11

1.4. Backward Compatibility ............................................................................................ 11

1.4.1. Removed Features.................................................................................................. 11

1.5. PCI DSS Compliance ............................................................................................... 12

2. Solution Management .......................................................................................................... 13

2.1. EFT Merchant Account ............................................................................................. 13

2.2. Merchant Stores ....................................................................................................... 13

2.3. Testing Procedures .................................................................................................. 13

3. EFT Transaction Types ........................................................................................................ 14

3.1. Customer Present ..................................................................................................... 14

3.2. Customer Not Present .............................................................................................. 14

3.2.1. Account On File Transactions ................................................................................. 15

4. Integration ............................................................................................................................ 18

4.1. Integration Process ................................................................................................... 18

4.2. Testing Values .......................................................................................................... 18

4.3. Integration Methods .................................................................................................. 19

4.3.1. Socket Connection .................................................................................................. 19

4.3.2. Text File .................................................................................................................. 19

4.4. Integration Version ................................................................................................... 20

4.5. Ocius.ini File ............................................................................................................. 21

4.6. Receipt Printing ........................................................................................................ 23

4.6.1. Text File .................................................................................................................. 23

4.6.2. XML File .................................................................................................................. 24






4.6.3. Screenless Re-Print ................................................................................................ 26

4.6.1. Receipt Format – XML Mapping .............................................................................. 27

4.6.1. Dynamic Currency Conversion (DCC) ..................................................................... 38

4.6.2. Barclaycard Gift ...................................................................................................... 41

4.6.3. Transax SV ............................................................................................................. 43

4.6.4. Pennies ................................................................................................................... 44

4.7. Integration Messages ............................................................................................... 48

4.7.1. Transaction Request (T Record) ............................................................................. 48

4.7.2. Transaction Response (Initial) ................................................................................. 50

4.7.3. Transaction Response (Version2) ........................................................................... 51







4.7.10. Login Request (L2 Record) ................................................................................... 54

4.7.11. Logout Request (O Record) .................................................................................. 56

4.7.12. POS Progress/Customer Facing ........................................................................... 56

4.7.13. Continue Transaction (CONTTXN Record) ........................................................... 63

4.7.14. Transaction Value Modification ............................................................................. 66

4.7.15. REQINFO.............................................................................................................. 69

4.7.16. Additional Integration Commands ......................................................................... 70

5. Value Added Services .......................................................................................................... 72

5.1. Barclaycard Gift ........................................................................................................ 72

5.2. Barclaycard Gift Request (BGIFT Record) ................................................................ 72

5.3. Barclays Gift Response ............................................................................................ 73

5.4. Dynamic Currency Conversion (DCC) ...................................................................... 74

5.5. Givex ........................................................................................................................ 75

5.5.1. Givex Request (GIVEX Record) .............................................................................. 76

5.5.2. Givex Response ...................................................................................................... 77

5.6. M-Voucher ................................................................................................................ 77

5.6.1. M-Voucher Request (M Record) .............................................................................. 78






5.6.2. M-Voucher Details................................................................................................... 79

5.6.3. M-Voucher Response ............................................................................................. 80

5.7. Flexecash (Park Retail) ............................................................................................ 81

5.7.1. Flexecash Request (PRG Record) .......................................................................... 81

5.7.2. Flexecash Response ............................................................................................... 82

5.8. PayPoint ................................................................................................................... 84

5.8.1. PayPoint Request (PPOINT Record)....................................................................... 84

5.8.2. PayPoint Response ................................................................................................. 86

5.9. Stored Value Solutions (SVS) ................................................................................... 87

5.9.1. SVS Request (SVS Record) .................................................................................... 87

5.9.2. SVS Response ........................................................................................................ 89

5.10. Transax SV (Stored Value) ....................................................................................... 90

5.10.1. Transax SV Request (TSV Record)....................................................................... 91

5.10.2. Transax SV Response .......................................................................................... 94

5.1. Pennies .................................................................................................................... 95

6. Additional Functionalities ..................................................................................................... 96

6.1. Discretional Data ...................................................................................................... 96

6.2. External Hashing ...................................................................................................... 96

6.3. Get Card Details ....................................................................................................... 97

6.3.1. Get Card Details Request (GDET Record) .............................................................. 97

6.3.2. Get Card Details Response ..................................................................................... 97

6.4. PAN Masking ............................................................................................................ 99

6.5. PED Version Mapping .............................................................................................. 99

6.6. Procurement Card Processing .................................................................................. 99

6.7. Transaction Value Modification ................................................................................100

6.8. Card Wait ................................................................................................................101

6.8.1. Card Wait Request (CARDWAIT Record) ..............................................................101

6.8.2. Card Wait Cancel Request (CANCELCARDWAIT Record) ....................................103

6.8.3. Card Wait Response ..............................................................................................104

6.9. Contactless Payments .............................................................................................106

6.10. On Hold Transaction ................................................................................................107

6.10.1. On Hold Transaction Request ..............................................................................107

6.10.2. On Hold Transaction Response ...........................................................................108






6.10.3. Examples .............................................................................................................109

7. Offline Functionality and Floor Limits ..................................................................................110

7.1. EMV Floor Limit .......................................................................................................110

7.2. Voice Referral Floor Limit ........................................................................................111

7.3. Post Comms Floor Limit & Stand-In Authorisation ...................................................111

7.4. Offline Transaction Specifics ...................................................................................114

7.5. Offline Hash Generation ..........................................................................................114

7.6. Example EFT Scenarios ..........................................................................................115

7.7. SVS Offline Functionality .........................................................................................117

7.7.1. SVS Reversal Processing ......................................................................................117

7.8. Transax Offline Functionality ...................................................................................118

7.9. Automatic Return Online Functionality .....................................................................118

APPENDIX..............................................................................................................................119

Contact Details ....................................................................................................................119

Currency Code ISO 4217 ....................................................................................................120

Country Codes ISO 3166 ....................................................................................................124

VeriFone Error Codes..........................................................................................................128

Sentinel FAQs .....................................................................................................................136

Why do I get an “EFT is not allowed” integration response? ............................................136

Why do I get an integration service not allowed? .............................................................137

System.MissingMethodException in the log file ................................................................138

What version of .NET is required? ...................................................................................138

No System ID available ....................................................................................................138

Why did the hosted login process fail? .............................................................................139

How do I allow Sentinel to be installed on more machines? .............................................140

How do I move an Sentinel license to a new machine? ....................................................140

When does the offline voice referral floor limit take into effect? ........................................140

Why is the offline voice referral floor limit process different? ............................................140






1. Solution Overview This chapter provides brief details on all the components of the Vx 810 Sentinel and VX 820 Sentinel solutions, i.e. Sentinel software, supported PEDs, various operation modes and backward compatibility.

1.1. Sentinel Software Sentinel is part of VeriFone’s PAYware Ocius Managed Service, a PCI DSS Level 1 certified payment solution provider.

Developed by VeriFone, Sentinel is a software application that resides on a PIN Pad within a PCI PTS/APACS Common Criteria secure environment providing dual-layer data encryption from the point of card data capture. Sensitive cardholder data is encrypted within the PIN Pad using both 168-bit 3DES encryption (utilising a unique dynamic key system generated using transaction specific data elements) followed by further encryption using a 2048-bit RSA algorithm, before being sent to the Point of Sale for onward transmission to VeriFone’s managed service.

As card data remains fully encrypted throughout this process, and the merchant has no ability to decrypt the data, cardholder information is effectively removed from the merchant's system, significantly reducing the scope and cost of achieving and maintaining the Payment Card Industry Data Security Standards (PCI DSS). Cardholder data is only decrypted once safely inside the secure (and certified) environment of VeriFone's ICP Managed Service prior to transmission to the acquiring bank.

Sentinel is the final piece of the jigsaw to provide end-to-end encryption of cardholder data, significantly reducing the scope and associated costs of PCI DSS compliance for merchants and rendering cardholder data inaccessible to any potential cyber criminals.

Sentinel goes beyond compliance, providing a range of additional features, addressing issues such as PED Asset Management, including PED serial number tracking and swap out/power on-off alerts to help thwart physical attacks on PED assets. Sentinel also incorporates secure remote downloads to verify that any updates delivered to Sentinel are from verified as being from VeriFone’s PAYware Ocius service.

For full information on installation, configuration and registration of Sentinel please refer to the separate Installation Guide.



Date February 2013 Phone Page number Version 08444 828 200 8 V1.16



1.2. Supported PEDs Sentinel software can be integrated with PEDs (PIN Entry Devices) to allow merchants to perform payments via POS systems. The following PIN pads are generically certified and supported to use with the Sentinel solution:

1.2.1. Vx 810

The Vx 810 provides the right combination of features and functions in a sleek, stylish device that fits in the palm of your hand. This includes a magnetic stripe card reader, smart card reader, and integrated PIN pad.

The Vx 810 series supports both symmetric encryption algorithms (DES, 3DES, and AES) and asymmetric encryption (RSA). This device internally manages simultaneous multiple keys through either Master Session- or DUKPT-based processes, and offers high performance smart card processing, as well as support for the new generation of 3-volt cards. The Vx 810 is a programmable device, allowing a custom or EMV-approved transaction application to run from the VISA PCI-compliant PIN pad, either to meet local regulatory requirements or relieve the ECR or terminal of this task.

The single port connector allows for serial or USB connectivity as well as optional Ethernet connection which can be used as standalone terminal via IP connectivity (VX 810 IP). For more details on VX 810 IP solution, please refer to a separate guide “PAYware Ocius manual”.






1.2.2. VX 820

The VX 820 PIN pad is an advanced technology part of VeriFone’s VX Evolution Platform; enhanced with colour touch-screen display, a larger keypad and integrated contactless capability. Its advanced and intuitive technology provides reliable and robust customer facing PIN pad for ease of use in retail and hospitality environments.

The PIN pad provides merchants with a single-port connectivity offering the capability to install the terminal via USB, serial or Ethernet (for IP connectivity) connections using the appropriate cable.

The VX 820 provides the right combination of features and functions in a sleek, stylish device that fits in the palm of your hand. VX 820 securely and efficiently handles all payment needs including magnetic stripe card reader, smart card reader, an integrated PIN pad, and optional integrated contactless for EFT transactions.

Additional security - The optional privacy shield is available with both PIN pads; which can be easily inserted above the keypad to hide the keys when a user is pressing to enter the PIN for a transaction.

Please contact your Account Manager for details on all accessories available with the PIN pads.






1.3. Operation Modes The Sentinel application can be utilised in various operation modes, the following are available:

• Normal • Minimised • Screenless • Semi-attended* • Unattended*

* Currently unavailable, please speak to your Account Manager for more details.

1.3.1. Screenless

Sentinel provides a “Screenless” mode of operation, providing POS solutions with the ability to retain focus whilst Sentinel silently processes transactions in the background.

This results in the POS system being able to use the entire POS screen and removes any requirement to reserve screen space for Sentinel to occupy during a transaction; whilst also enabling the Point of Sale solution provider to effectively hide the application from their customer (the merchant).

When processing transactions whilst using the Screenless mode, a progress status message will be exported for the POS for monitoring purposes. This information can be received by either a socket connection or text file; configuration options are included within the settings file. This configuration process is detailed within the Installation Guide.

By default, the text file integration outputs a progress file named ‘StatusFile.txt’ to the “TIPath” as defined within the settings. If using socket integration then the information will be exported on port 25001. One single mode of integration (socket or text) MUST be used throughout development for both transaction integration and status message retrieval.

Please note that when utilising this mode that the Refund PIN will need to be disabled.






1.3.2. Semi Attended

Semi Attended environments are those in which the payment is driven entirely by the POS, without any interaction from an operator. Should there be a problem, operators are on hand to help and resolve the issue. This is commonplace in supermarkets whereby one operator will be watching over several POS.

Sentinel can be utilised in a Semi Attended environment using one of the standard PIN entry devices, without the need to utilise an Unattended PED.

When integrating in this environment there are additional requirements in terms of the on-screen messages. The merchant must integrate utilising the Progress Messages and Continue Transaction functionality, ensuring that the cardholder can be updated on screen at each stage of the transaction.

1.4. Backward Compatibility Sentinel provides full backward compatibility for most integrators who have previously supported a PAYware Ocius Chip & Pin solution, particularly those who have developed against the PAYware Ocius for PC V2 or V3 interface previously. There are, however, some optional additional fields in the Sentinel interface that would be required to take advantage of some new features. Whilst every effort has been made to ensure adequate backward compatibility, VeriFone insists that integration testing takes place prior to any upgrade.

Please contact the Implementations Department to arrange for this integration testing.

1.4.1. Removed Features

In order to support Sentinel’s overall security credentials, a small number of items have had to be removed from the previous PAYware Ocius for PC integration records. These predominately relate to the sending or receiving of sensitive cardholder data between PAYware Ocius and the Point of Sale under certain circumstances as defined below:

• ‘CONTTXN,6,CARDNUMBER=X’ command removed, as card number must now be entered on the PED directly

• Direct transaction records (D-Records) • Disabling of the integration logout message using an ‘Ocius.ini’ parameter

(‘NOINTLOGOUTMSG’) • E-Commerce transaction support, modifier removed. • External swipe capture methods • Keyed card number entry within the Sentinel application – this can only be performed

directly on the PED • Provision of cashback as part of the integration transaction request record removed (can

be defined within Continue Transaction Message in Screenless mode when a cashback enabled card is presented)

• Provision of gratuity as part of the integration transaction record • Retrieval of scheme branded payment card data from the PED to the POS • Update PED from the PED configuration screen • Retrieval of EFT swipe card data from the PED to the POS






1.5. PCI DSS Compliance The Payment Card Industry Data Security Standard (PCI DSS) is an extremely important initiative driven by Card Schemes, Industry Bodies and Acquiring Banks worldwide. Its effect on merchants differs depending on a number of factors such as annual transaction volumes.

As a Payment Service Provider (PSP), VeriFone have a responsibility to be fully accredited with all industry security protocols. The PCI DSS programme is in fact an amalgamation of both Visa’s AISP (Account Information Security Programme) and MasterCard’s SDP (Secure Data Programme). Both standards were combined to create a new worldwide security standard, to help secure confidential card information from otherwise vulnerable systems.

As part of these newer security regulations, merchants also have a greater level of responsibility for security than ever before and, as a result, PSPs and Acquirers alike are advising merchants accordingly. Initially, the best advice is to ensure that operating systems used for the storage or processing of card data are maintained to the highest level of security and adopt other security measures such as:

• High security firewall protection for all public network access (internet) • Strong authentication methods for all local network access • Regularly updated antivirus protection • Strong localised access restrictions • Passwords should consist of a mixture of at least 8 alphanumeric characters, and

where possible be changed at least every 90 days • Passwords should not be obvious words like months, birthdays, pets names etc • Passwords should be known by as few people as possible • Where possible each user should have a unique password • Passwords should not be written down • Operating system patches should be applied within 30 days of release

Further information on PCI DSS compliance can be found on the Visa or MasterCard websites as shown below:

• https://www.pcisecuritystandards.org • http://www.visaeurope.com/aboutvisa/security/ais/resourcesanddownloads.jsp • https://sdp.mastercardintl.com/documentation/index.shtml

For information regarding becoming compliant with the security rules and regulations of the card associations, including an online questionnaire, please visit:

https://VeriFone.trustkeeper.net

https://www.pcisecuritystandards.org/

http://www.visaeurope.com/aboutvisa/security/ais/resourcesanddownloads.jsp

https://sdp.mastercardintl.com/documentation/index.shtml

https://commidea.trustkeeper.net/






2. Solution Management This chapter provides pre-requisites to ensure the merchant has completed all the necessary procedures required prior to installing or integrating the Sentinel solution to their environment.

2.1. EFT Merchant Account Merchants are required to setup an Electronic Funds Transfer (EFT) account in order to process payment transactions. To setup an EFT account, a Merchant ID (MID) is required from the Acquirer. Terminal IDs (TIDs) are then allocated to the Merchant ID and a merchant system ID is created.

A merchant can have more than one system ID in order to setup multi-channel solutions. To ensure a merchant system is configured please speak to your Account Manager in Sales.

2.2. Merchant Stores Merchant Stores enable merchants to remotely manage terminals across an entire estate. Each merchant store links PTIDs (Payment Terminal IDs) of each terminal onto a merchant store. Merchant stores contain information specific to the store/location that is required by the terminals to successfully perform their processing, e.g. customised receipt/voucher details.

An advantage of a merchant store configured can be utilised to configure terminal with a country code to locate the terminal outside of the UK. This is implemented by associating the terminal with a given store and configuring the terminal country code based upon the country of the store.

In addition, merchant stores support a variety of value adds as appropriate to ensure that value add specific information is held distinct from the core non-value add specific information.

To configure a merchant store, please contact the Helpdesk team.

2.3. Testing Procedures In order to ensure that all credit and debit payments are processed as intended, VeriFone insist on a full testing procedure to be carried out by a VeriFone Implementations Engineer before live processing can take place.

To fully test the system, VeriFone configure an exact replica of the credit card processing solution in ‘test’ mode, which enables a wide range of different transaction types to be simulated in a controlled environment.

Once the testing has been completed, VeriFone will issue a signoff certificate which shows that the system(s) tested have met the required standard and may be implemented on site as required.

However, if any amendments are made to the third party software, re-testing will have to take place.






3. EFT Transaction Types This section provides details on the various Customer Present (CP) and Customer Not Present (CNP) transaction types supported with the Sentinel solution.

3.1. Customer Present The following CP transaction types are supported with this solution:

• Purchase – the ability to process a sale • Refund – the ability to cancel a sale • Cash Advance – the ability to withdraw cash value from cardholder’s card

3.2. Customer Not Present Sentinel provides the ability for merchants to process the following CNP transactions:

• Mail Purchase – the ability to process a sale received via mail • Mail Refund - the ability to process a refund received via mail • Telephone Purchase – the ability to process a sale via telephone • Telephone Refund - the ability to process a refund via telephone • Account On File – merchant stores the cardholder’s details and at the point of payment

can retrieve them for the processing of the transaction When processing a CNP transaction, the operator will be required to key the card number into the pin entry device (PED) to ensure that the sensitive cardholder data is encrypted on the PED before traversing the merchant’s network.

The solution will also request Address Verification System (AVS) details in order to check the billing address of the card provided by the user with the address on file with the card issuer. The information requested by Sentinel for address verification is both the House Number and numbers from the Post Code (e.g. for TN25 4AZ these will be “254”).

The Card Security Code (CSC1) will also be requested as part of the CNP process. Supplying the CSC during a transaction is intended to verify that the cardholder has the card in their possession, as the code is not contained within the magnetic swipe data or within the chip on ICC cards. The CSC is stored by the card issuer and verified as part of an authorisation request, as with the AVS details.

For integrated merchants configured to utilise Sentinel’s ‘Screenless Mode’, the POS Progress Messages should be translated to provide instruction to the POS operator of the information required at each stage (e.g. Status IDs 39, 40, 41).

Sentinel does not automatically accept AVS/CSC results, the card acceptor will be required to decide if they wish to confirm the transaction based upon the result of the verification performed, as defined within the APACS specification which VeriFone conforms to.

1 sometimes called Card Verification Data (CVD), Card Verification Value (CVV or CVV2), Card Verification Value Code (CVVC), Card Verification Code (CVC or CVC2), Verification Code (V-Code or V Code), or Card Code Verification (CCV)






The only exception to this is in the instance of where the transaction was authorised by the acquirer (not by voice referral) and the CSC result is “Not Matched” – VeriFone is mandated by the card schemes to take this action. Card issuers should decline transactions where the CSC does not match, but this action is in place as a failsafe.

Below is a table to show the results returned by Sentinel and the definition of each:

Result Definition Address Match Only

AVS details valid, CSC data invalid

Data Matched Valid AVS and CSC details Data Not Checked AVS nor CSC data supplied with transaction Data Not Matched AVS and CSC data invalid Sec Code Match CSC data are valid, but at least one of the AVS data was invalid

3.2.1. Account On File Transactions

Account on File is a Cardholder Not Present payment method whereby the cardholder does not need to re-enter their card details in order to perform a payment. The merchant (or payment service provider) stores the cardholder’s details and at the point of payment can retrieve them for the processing of the transaction.

Account on File transactions do not require any CSC or AVS details to be supplied.

Stable Tokenisation

As standard, VeriFone ensures that any card payment details being registered have not already been stored for the merchant in question. Should the details already have been stored then the token ID assigned will be returned, rather than creating a new token ID for the same details.

Account On File Registration

In order to perform an account on file transaction, the cardholder’s payment details must first be registered. Sentinel supports registering card details using two functions: Registration and Payment, or Registration only.

Both functions capture the details using an EFT transaction flow via any capture method other than Contactless.

Registration and Payment

This registration mechanism allows the merchant to perform a standard transaction whilst also storing these details for future ‘Account on File’ payment transactions.

The merchant performs a standard purchase or refund transaction in the normal fashion. If the merchant system is configured to support ‘Account on File’ and Sentinel is operating in Online Mode, Sentinel will prompt the user to make for their decision on account registration. This prompt occurs after the “Merchant Reference” prompt (again, if configured). After the decision has been made, standard transaction processing will continue.






When processing a transaction via integration, with ‘Account on File’ enabled, the decision on registering the details can be specified within the transaction record using field 27. See the transaction record definition for full details on the options available.

Prior to the transaction being sent for authorisation, Sentinel will submit the payment details for ‘Account on File’ registration. After completion of the ‘Account on File’ registration process, standard authorisation processing will continue. Upon completion of the authorisation processing, Sentinel will include the ‘Account on File’ registration details on the receipts.

Upon completion of the transaction, if the transaction is integrated, Sentinel will return the integration response with additional fields added providing the token registration result details.

Registration Only

This registration function allows the merchant to store the cardholder’s payment details for ‘Account on File’ payment transactions without processing any form of authorisation.

This registration mechanism is initiated by starting a modified transaction, either by selecting the customer present modifier or the customer not present modifier. Sentinel will then follow a standard transaction flow. However, Sentinel will automatically set the transaction value to 0.00, and skip the decision prompt for whether to perform the registration process.

At the point where a transaction would normally be authorised, Sentinel will perform the registration process as defined in the ‘Registration and Payment’ function. Instead of sending the transaction for authorisation, Sentinel will automatically decline the transaction locally, and complete as a registration only transaction. As the transaction is registration only, Sentinel will print receipts tailored for this type of transaction. At no point in this process are any payments attempted to be authorised and as such the card details are not validated in any way with the acquiring bank or card issuer.

Upon completion, if the transaction is integrated, Sentinel will return the integration response with additional fields providing the Account on File registration result details.






Account on File Registration Validity Period

Payment details registered using the ‘Account on File’ mechanism will only be valid for a finite period of time. This time period is based upon ‘Account on File Validity Period’ configured against the merchant’s system. The ‘Account on File Validity Period’ is defined in days, by default this is configured to 365 days.

Account On File Payment

Account on File payment is a Cardholder Not Present transaction type. As such, it can be initiated by selecting the corresponding Purchase or Refund option on the ‘Card Not Present’ transaction type screen.

Sentinel will then process the transaction as normal. Upon processing the requested transaction, the attached PED will request the token ID rather than card details. Within an Integrated environment the token ID can be supplied within the Transaction Record (integration is highly recommended when utilising Token functionality).

The transaction processing will continue by submitting the transaction to the ICP Service for authorisation. The ICP Service will retrieve the relevant cardholder details from its database of registered cards, using those details for the requested transaction.

Sentinel will complete the transaction in a similar manner to a standard transaction, printing the appropriate merchant and cardholder receipts.

Upon completion, if the transaction is integrated, Sentinel will return the integration response with additional fields added providing the Account on File payment details.






4. Integration This section aims to inform the user of the options available to them to integrate into Sentinel, as well as detailing the process of achieving certification from VeriFone for the interface.

4.1. Integration Process In order to ensure that all credit and debit payments are processed as intended, VeriFone insist on a full testing procedure to be carried out by a VeriFone Implementations Engineer before live processing can take place.

Once the system integrator believes that the development is complete and is ready for a full integration test, a VeriFone on site engineer is booked to attend site to complete a full set of tests ensuring the system operates as required.

To fully test the system, the engineer will test an exact replica of the completed credit card processing solution in ‘test’ mode, which enables a wide range different transaction types to be simulated in a controlled environment.

After the testing has been completed, VeriFone will issue an integration report which shows that the system(s) tested has met the required standard and may be implemented on site as required. Should there be any issues which result in sign off not being achieved during testing; full details of the outstanding issues will be provided.

If any amendments are made to the third party software after certification has been issued, retesting will have to take place.

Once live with Sentinel, merchants will be supported by the Merchant Helpdesk, contact details for which are provided within Appendix A.

4.2. Testing Values To allow integrators to simulate responses which will need to be catered for within the integration, the following test values have been provided:

Values ending in 2pence (e.g. £10.02) will simulate a Voice Referral Values ending in 5pence (e.g. £10.05) will simulate a Decline Values ending in 7pence (e.g. £10.07) will simulate ‘Comms Down’






4.3. Integration Methods In an effort to provide a solution to suit a broad range of clients, Sentinel offers two integration methods.

Please note: system integrators should select and utilise just one integration method for all message types. Mixed integrations can produce

unexpected results and as such will not pass the integration testing process.

4.3.1. Socket Connection

VeriFone recommend the use of IP Socket connections to integrate with Sentinel.

The Point of Sale application must establish an IP socket connection with the Sentinel application via the appropriate port. Once established, the connection can be used to send and receive data during the transaction, providing the Point of Sale application with control over the transaction.

The data sent by the POS is defined within Section 10 of this manual, for integration message details please see this section.

The socket connection will be terminated by Sentinel once the requested operation has completed. The integrator should never break the socket connection as this will cause the transaction to be cancelled. If a socket connection is opened but no data transmitted within 20 seconds, PAYware Ocius will automatically disconnect the client.

Each record sent to the terminal must be terminated by a carriage return line feed (CRLF), unless configured otherwise within the software.

Each record received by PAYware Ocius will be acknowledged, by responding with an ASCII character of 0x06 (ACK).

Sentinel is designed to communicate with one client at any one time; therefore, only a single integration client should be attached

4.3.2. Text File

Text File integration is offered primarily for backward compatibility purposes. Whilst fully functional, VeriFone do advise use of the IP Socket interface.

A text file should be created, or created and then placed, within a pre-defined shared directory. The filename will need to confirm with any filename mask pre-configured within the Sentinel settings and must be 8 characters long, the default being ‘T0000001.in’. The filename would either be incremented for each subsequent transaction (T0000001 – T9999999), or the existing ‘T0000001.in’ file would be moved or removed from the directory and the same filename used for each transaction.

VeriFone strongly recommend that integrators with several different POS allocate file names to each POS.






Once the ‘.in’ file has been processed, a response will be created in the folder allocated in the form of an ‘.out’ file. This should then be read in and any necessary response sent using another ‘.in’ file. It is essential that the same file name is used during the entire transaction processing cycle. Once in use the same file name must not be allocated to another transaction, failure to do so will result in incorrect operation. Therefore the response to a ‘T0000001.in’ file will be ‘T0000001.out’.

4.4. Integration Version When configuring Sentinel, within the program settings file (‘Program.Settings.ccf’), there is an option to configure the Integration Version. This controls the format of the integrated response which will be returned to the POS. By default this is configured to ‘1’ (Initial) and will need to be changed to ‘2’ (Version2) should the POS require data to be returned to include any DCC or Account On File transaction details, such as token identifier.

When making use of the ability to return the Card Number Hash as part of the transaction output message, the Version3 iteration will be required. This can be configured within the settings by amending the value to ‘3’.

Procurement Card Data can be passed as part of the transaction request message, and should this functionality be utilised the integration version will need to be amended. In this instance, the integration version value will need to be set to ‘4’.

Discretional Data can be returned within the transaction response message when the Integration Version is set as ‘5’.

When utilising the Pennies charity donation functionality, the Integration Version will need to be configured to ‘6’. This will result in the Charity Donation Value, Charity Donation Merchant Number and Original Charity Donation Value being returned within the Transaction Response message.

For more information on configuring the settings file, please consult the latest version of the Sentinel Installation Manual.






4.5. Ocius.ini File To customise the integration it is possible to create an ‘Ocius.ini’ file to supply startup parameters to Sentinel.

Once launched, the contents of the file are interrogated and can trigger desired effects with regards to how the application behaves.

This file is not built by the software installer, and will therefore need to be created by the integrator if required. It should be placed in the folder ‘C:\Program Files\Commidea\Ocius Sentinel’. Each parameter used should be separated by a carriage return and line feed.

Parameter Usage Description of effect /AL Optional “Auto-Login” The application will load straight into the “Login ID”

screen, skipping the “Press ‘Enter’ To Start Communications” and “Setup – F4” prompts.

/CRECNODISP Optional Disables the customer receipt screen and automatically completes processing. This option can only be used if the Integrator can show evidence that they can use the reprint command which is “REP,101”, else cardholder voucher reprints are not possible in any other way with this feature enabled.

/CUTCMD:xxx Optional Where XXX is the ASCII representation of a printer control code used for paper cutting at the end of a voucher print. This may or may not be required depending on how the system is configured. Refer to printer manufactures guidelines for more information.

/DISABLEFUNCTION Optional Disables the function button on the Sentinel form (House Icon). /DISABLEPEDPOLLING Optional Disables PED Polling when Sentinel is on the idle screen /ENABLEVISIBLELOGOUT Optional Forces Sentinel to become visible during the logout process when

running in minimised mode. /EXTENDLOG Optional Configures Sentinel to produce extended log files. This should be used

for trouble shooting purposes only, and will create extremely large log files.

/EXTVCH Mandatory Enable extended voucher to be printed. Support for this functionality is Mandatory to pass Integration Testing as it may be required for troubleshooting purposes in both live and test environments.

/PRINTER:<Printer> Optional Allows for selecting the desired receipt printer, without the need to manually select the device from within the setup menus. If used, this setting will override any selected device, else that stored within the configuration files will be used. <Printer> = The full Printer Name as configured within windows e.g.: /PRINTER:EPSON TM-T88IIR Partial Cut This can also include the network path/IP address if it’s a shared device on the network: /PRINTER:\\10.0.0.1\Epson TM-T88IIR Partial Cut

/PRNPATH:<path> Optional Specifies the path on the system where Sentinel will output a file to be used for POS voucher printing. The default is ‘C:\’. Please refer to the Installation Guide for information on how configuring the voucher output location.

/RAW Optional Sets the RAW printing mode when printing to Windows Printers. This may significantly speed up the voucher printing process, but does remove all formatting (fonts, bold, size etc) as the data is passed as standard ASCII text. It is possible that auto-cutters on receipt printers may not work in this mode.






/SKIPSTARTCONNFAIL Optional Skips the connection failed message when Sentinel is launched if no internet connection is available for the updates to be performed. The result is that Sentinel logs into the Main Menu straightaway.

/STARTMINIMISED Optional Sentinel will start minimised to the taskbar when this parameter is used.

An example of an ‘Ocius.ini’ file:

As with all changes made to settings files, any change made to this file will only take effect once the software has been restarted.






4.6. Receipt Printing PAYware Ocius Terminals are generically certified within the UK and as such the receipts produced form part of the accreditation – the contents and layout are all predetermined.

Please note that when making changes to receipts, even from an existing integration which has been certified by VeriFone, that

it is necessary to contact Implementations for re-approval.

With Sentinel, there are various receipt printing options, which also includes the ability to output the receipts to a text file or an XML file.

4.6.1. Text File

When printing to text file, Sentinel outputs the receipt to a text file on the point of sale in a preconfigured location.

This is preferable in scenarios whereby merchants have requirements to produce receipts containing more information than that produced by PAYware Ocius, for example details of the product or service purchased.

The entire contents of the text file are mandatory and the receipts produced by PAYware Ocius form part of the generic certification of the solution. The text file receipt produced by Sentinel is formatted and this should not be changed. If using the information within the file to build custom receipts then the information provided in this receipt should only be added to, and not amended.






4.6.2. XML File

When printing to XML file with Sentinel, all information is exported and displayed in field elements.

The XML data output contains a wide array of additional, option information. Mandatory fields are marked in the table below and are required in order to maintain acquirer certification for the solution.

Please note: Acquirer accreditation will be required for any merchant wishing to use the XML receipt option. The only exception to this being; if the XML receipts are built to

exactly represent the text file format.

Please contact Implementations if you have any queries on this - no solution using XML receipts will be passed for live processing until the acquirer confirmation is gained.

Changes to the content of the XML File are mandated by schemes at which time VeriFone will need to make amendments or additions to the file; for this reason the integrator must accept that updates to their application may be required in this regard in the future.

The following table describes each field in the XML receipt layout; all required fields must be printed in order to pass integration testing.

Field Description Required AC Application cryptogram AID Correlates to AID used to process chip and PIN card Mandatory AIP Application interchange profile Amount Transaction amount Mandatory AmtO Amount other AppEff ICC app effective date Mandatory AppExp ICC app expiry date Mandatory

(Or <ExpiryDate>) AppSeq ICC app sequence Mandatory ATC Application transaction counter AuthCode Authorisation code Mandatory AuthOnly If the transaction is auth only CAPK Certification Authority Public Key CaptureMethod Capture method used to obtain card information Mandatory CardAVN Card Application Version Number CardHolder The cardholder name CardScheme Card scheme name Mandatory Cashback Cashback value CID Cryptogram identifier ContAuth If the transaction is continuous auth or not CreditDebitMessage Credit debit message displayed on the receipt CryptoTxnType Cryptogram transaction type CurrencyAbbreviation EUR/GBP/USD (See Appendix for further information) CurrencySymbol €, £, $ Mandatory CustomerPresent If the customer is present or not when the transaction was

processed Mandatory

CVM Cardholder verification method (text) Mandatory CVMR Cardholder verification method (numbers) DDOL Dynamic data authentication data object list DisableCurrencySymbol Duplicate Duplicate receipt or not Ecommerce Txn is Ecommerce or not






EFTSN The EFTSN ExpiryDate The expiry date Mandatory

(Or <AppExp>) ExtendedReceipt If extended receipt or not FloorLimit Scheme floor limit Footer Receipt footer Mandatory Gratuity Gratuity value GratuityBoxRequired Whether to print the gratuity box for customer to fill in Header Receipt header (to contain Merchant Name and Address) Mandatory IACDef Issuer Action Code Default IACDen Issuer Action Code Denial IACOnl Issuer Action Code Online IAD Issuer Application Data IssueNo Card issue number Mandatory KeepText1 This the text in the receipts centre (e.g. “Please keep this

for your records”) Mandatory

KeepText2 This the text in the receipts centre (e.g. “Please keep this for your records”)

Mandatory

MCC Merchant Category Code MID Merchant ID Mandatory PAN Primary Account Number (card number) Mandatory PinEntered Whether the PIN was entered or not (PIN Verified) PTID Permanent terminal identifier Mandatory ReceiptType Merchant signature / Merchant declined / Merchant void

Reference Reference number Mandatory StartDate Card start date TACDef Terminal action code Default TACDen Terminal action code denial TACOnl Terminal action code online TCtry Terminal country code TDOL Transaction Certificate Data Object List TID Terminal Identifier Mandatory Total Total transaction value Mandatory TrainingMode Training mode transaction or not TSI Transaction Status information TVR Terminal verification result TxnDateTime Transaction date / time Mandatory TxnType Transaction type (Sale/Refund) Mandatory UN Unpredictable number

The below are a set of guidelines to be used for the layout for different cardholder interfaces (CVM – Cardholder Verification Method):

- Signature CVM Space for cardholder's signature. (merchant copy only) Cardholder declaration wording: (variable, both copies) Your account will be debited/credited with the above amount' ‘Transaction confirmed' ‘------------------------' ‘Cardholder signature'

- PIN CVM Cardholder declaration wording: (variable) ‘Your account will be debited/credited with the above amount'






‘PIN verified’

- No CVM Cardholder declaration wording: (variable) ‘Your account will be debited/credited with the above amount' ‘No Cardholder verification’

- Along with Information to advise cardholder to retain the receipt: (variable) ‘Please keep this copy for your records’ Thank you message (optional to the merchant) In the event of a dual CVM (PIN & Signature) the line ‘PIN verified’ should be inserted in the Signature CVM prior to the line ‘Transaction confirmed’.

Transactions cancelled after the receipt or voucher has been printed should overprint the original voucher, or reprint the original receipt with the words ‘CANCELLED’,

‘VOID’ or ‘XXXXXXXXX’s in a prominent position.

For Mail Order / Telephone Order transactions where the customer is not present a receipt should still be produced and either ‘Mail Order’ or ‘Telephone Order’ written in the space for the customer signature.

As detailed above, please note that all merchant owned terminals must truncate the PAN on the cardholder copy of the transaction receipt with immediate effect.

4.6.3. Screenless Re-Print

When operating in this mode, it is necessary for integrators to re-print receipts following status ID messages; ‘Signature Confirmation Required’ and ‘Continue Required’.

This can be performed by sending a value of ‘5’ (Reprint Receipt) in the ‘CONTTXN’ record.

Example message:

CONTTXN,5






4.6.1. Receipt Format – XML Mapping

In order to provide guidance for integrators when producing receipts using the XML file, three different receipts type are detailed below, with the XML fields which contain the data outlined alongside each receipt:

Cashback:

<Header> --------------------------------------------- <CardScheme> <PAN> Expiry: <AppExp> <CaptureMethod> <TxnType> <CreditDebitMessage> Amount: <Amount> Cashback: <Cashback> Total: <Total>

<CVM> <KeepText1> <KeepText2> PTID: <PTID> MID: <MID> TID: <TID> Date/Time: <TxnDateTime> EFTSN: <EFTSN> Authcode: <AuthCode> Ref: <Reference> AID: <AID> App Eff: <AppEff> App Seq: <AppSeq> --------------------------------------------- <Footer>

<Header> --------------------------------------------- <CardScheme> <PAN> Expiry: <AppExp> <CaptureMethod> <TxnType> <CreditDebitMessage> Amount: <Amount> Cashback: <Cashback> Total: <Total>







Chip & PIN:

<Header> --------------------------------------------- <CardScheme> <PAN> Expiry: <AppExp> <CaptureMethod> <TxnType> <CreditDebitMessage> Amount: <Amount> Total: <Total>









Decline:


<CVM> <KeepText1> <KeepText2> PTID: <PTID> MID: <MID> TID: <TID> Date/Time: <TxnDateTime> EFTSN: <EFTSN> Ref: <Reference> AID: <AID> App Eff: <AppEff> App Seq: <AppSeq> --------------------------------------------- <Footer>


<CVM> <KeepText1> <KeepText2> PTID: <PTID> MID: <MID> TID: <TID> Date/Time: <TxnDateTime> EFTSN: <EFTSN> Ref: <Reference> AID: <AID> App Eff: <AppEff> App Seq: <AppSeq> --------------------------------------------- <Footer>






Gratuity:

<Header> --------------------------------------------- <CardScheme> <PAN> Expiry: <AppExp> <CaptureMethod> <TxnType> <CreditDebitMessage> Amount: <Amount> Gratuity: <Gratuity> Total: <Total>


<Header> --------------------------------------------- <CardScheme> <PAN> Expiry: <AppExp> <CaptureMethod> <TxnType> <CreditDebitMessage> Amount: <Amount> Gratuity: <Gratuity> Total: <Total>







ICC Signature:


PLEASE SIGN BELOW

--------------------------------------------------

<KeepText1> <KeepText2> PTID: <PTID> MID: <MID> TID: <TID> Date/Time: <TxnDateTime> EFTSN: <EFTSN> Authcode: <AuthCode> Ref: <Reference> AID: <AID> App Eff: <AppEff> App Seq: <AppSeq> --------------------------------------------- <Footer>








Keyed Cardholder Not Present:

<Header> -------------------------------------------------- <CardScheme> <PAN> Expiry: <ExpiryDate> <CaptureMethod> <TxnType> <CreditDebitMessage> Amount: <Amount> Total: <Total>

<CVM> <KeepText1> <KeepText2> PTID: <PTID> MID: <MID> TID: <TID> Date/Time: <TxnDateTime> EFTSN: <EFTSN> Authcode: <AuthCode> Ref: <Reference> -------------------------------------------------- <Footer>

<Header> -------------------------------------------------- <CardScheme> <PAN> Expiry: <ExpiryDate> <CaptureMethod> <TxnType> <CreditDebitMessage> Amount: <Amount> Total: <Total>







No Cardholder Verification Method (CVM):










PIN & Signature:


PLEASE SIGN BELOW

--------------------------------------------------









Refund:


PLEASE SIGN BELOW

--------------------------------------------------









Swiped Cardholder Present:

<Header> -------------------------------------------------- <CardScheme> <PAN> Expiry: <AppExp> <CaptureMethod> <TxnType> <CreditDebitMessage> Amount: <Amount> Total: <Total>

PLEASE SIGN BELOW

--------------------------------------------------

<KeepText1> <KeepText2> PTID: <PTID> MID: <MID> TID: <TID> Date/Time: <TxnDateTime> EFTSN: <EFTSN> Authcode: <AuthCode> Ref: <Reference> -------------------------------------------------- <Footer>

<Header> -------------------------------------------------- <CardScheme> <PAN> Expiry: <AppExp> <CaptureMethod> <TxnType> <CreditDebitMessage> Amount: <Amount> Total: <Total>







VeriFone recommends that best practice when controlling receipt formatting would be to interrogate the “<CaptureMethod>” field and to amend the layout of the receipt accordingly.

E.g. when the capture method is ‘Swiped’, the merchant receipt will need to include ‘PLEASE SIGN BELOW’ and space for the cardholder to sign.






4.6.1. Dynamic Currency Conversion (DCC)

When processing a DCC transaction, prior to authorisation, the cardholder is asked to confirm that they are happy with the rate of exchange being offered and are given the option to pay in the original currency or the transaction currency. A receipt is produced at this stage, as well as on-screen prompts being displayed for the cardholder to respond to (to select which currency is desired).

When using Text Files to produce receipts, the currency rates information will be printed to text file and, once printed, should be passed to the cardholder along with their receipt. This currency printout is outputted to a ‘Report.txt’ file within the preconfigured report output folder, and should be collected and printed from this location.

An example of DCC text receipt is included below:

Merchant Receipt

###################DefaultMerchantHeader###################

P:PW001106 T:T:20420001 M:6819049 24/11/2011 11:54:39 ------------------------------- Visa ************0006 Expiry: 12/12 KEYED CP SALE Please debit my account AMOUNT £10.00 TOTAL £10.00 ------------------------------- Please Sign Below

------------------------------- Please Keep This Receipt For your Records EFTSN: 1150 Auth Code: 789DE Ref:

###################DefaultMerchantFooter###################






Customer Receipt

###################DefaultCustomerHeader###################

P:PW001106 T:****0001 M:**19049 24/11/2011 11:54:39 ------------------------------- Visa ************0006 KEYED CP SALE Please debit my account AMOUNT £10.00 TOTAL £10.00 SIGNATURE VERIFIED ------------------------------- Please Keep This Receipt For your Records Auth Code: 789DE Ref:

###################DefaultCustomerFooter################### An example of DCC receipts in XML format is included below to aid integrations:

Merchant Receipt

<?xml version="1.0" encoding="utf-8"?> <VoucherDetails xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <TrainingMode>false</TrainingMode> <ReceiptType>Signature</ReceiptType> <Header>###################DefaultMerchantHeader###################</Header> <PTID>PW001106</PTID> <TID>20420001</TID> <MID>6819049</MID> <mkTransactionID>3977914</mkTransactionID> <TxnDateTime>2011-11-25T10:17:08.2775612+00:00</TxnDateTime> <CardScheme>Visa</CardScheme> <PAN>************0006</PAN> <ExpiryDate>12/12</ExpiryDate> <TxnType>Sale</TxnType> <CaptureMethod>KEYED</CaptureMethod> <CustomerPresent>true</CustomerPresent> <ECommerce>false</ECommerce> <ContAuth>false</ContAuth> <AccountOnFile>false</AccountOnFile> <PinEntered>false</PinEntered> <CreditDebitMessage>Please debit my account</CreditDebitMessage> <CurrencySymbol>JPY</CurrencySymbol> <CurrencyAbbreviation>JPY</CurrencyAbbreviation> <Amount>19100</Amount> <Total>19100</Total> <CVM>Please Sign Below</CVM> <KeepText1>Please Keep This Receipt</KeepText1> <KeepText2>For your Records</KeepText2> <EFTSN>1021</EFTSN> <AuthCode>789DE</AuthCode>






<Footer>###################DefaultMerchantFooter###################</Footer> <GratuityBoxRequired>false</GratuityBoxRequired> <ExtendedReceipt>false</ExtendedReceipt> <DisableCurrencySymbol>false</DisableCurrencySymbol> <AuthOnly>false</AuthOnly> <CardSchemePrintText /> <PrintAttempts>1</PrintAttempts> <ContactlessMSD>false</ContactlessMSD> <DCCDetails> <OriginalTransactionValue>100.00</OriginalTransactionValue> <OriginalGratuityValue>0.00</OriginalGratuityValue> <OriginalCashbackValue>0.00</OriginalCashbackValue> <OriginalTotalValue>100.00</OriginalTotalValue> <OriginalCurrencySymbol>£</OriginalCurrencySymbol> <OriginalCurrencyAbbreviation>GBP</OriginalCurrencyAbbreviation> <OriginalCurrencyDecimalPlaces>0</OriginalCurrencyDecimalPlaces> <DCCConversionRateApplied>191.00000</DCCConversionRateApplied> <DCCCommissionFee>0.00000</DCCCommissionFee> <DCCMarkUpFee>2.99000</DCCMarkUpFee> <ReceiptDisclaimer>CARDHOLDER HAS CHOSEN TO PAY IN JPY. THIS TRANSACTION IS BASED ON REUTERS WHOLESALE INTERBANK EXCHANGE RATE PLUS 2.99 PERCENT INTERNATIONAL CONVERSION MARGIN. THIS IS NOT AN ADDITIONAL FEE AND REPLACES CURRENCY CONVERSION CHARGES NORMALLY APPLIED. MY CHOICE IS FINAL. TRANSACTIONS CAN ALSO BE CONDUCTED IN GBP. THE CURRENCY CONVERSION SERVICE IS PROVIDED TO THE MERCHANT BY FEXCO DCC IN ASSOCIATION WITH Barclays Merchant Services.</ReceiptDisclaimer> </DCCDetails> <TokenRegistrationResult>NotSet</TokenRegistrationResult> <TokenRegistrationOnly>false</TokenRegistrationOnly> </VoucherDetails> Customer Receipt

<?xml version="1.0" encoding="utf-8"?> <VoucherDetails xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <TrainingMode>false</TrainingMode> <ReceiptType>Customer</ReceiptType> <Header>###################DefaultCustomerHeader###################</Header> <PTID>PW001106</PTID> <TID>20420001</TID> <MID>6819049</MID> <mkTransactionID>3977914</mkTransactionID> <TxnDateTime>2011-11-25T10:17:08.2775612+00:00</TxnDateTime> <CardScheme>Visa</CardScheme> <PAN>************0006</PAN> <ExpiryDate>12/12</ExpiryDate> <TxnType>Sale</TxnType> <CaptureMethod>KEYED</CaptureMethod> <CustomerPresent>true</CustomerPresent> <ECommerce>false</ECommerce> <ContAuth>false</ContAuth> <AccountOnFile>false</AccountOnFile> <PinEntered>false</PinEntered> <CreditDebitMessage>Please debit my account</CreditDebitMessage> <CurrencySymbol>JPY</CurrencySymbol> <CurrencyAbbreviation>JPY</CurrencyAbbreviation> <Amount>19100</Amount> <Total>19100</Total> <CVM>SIGNATURE VERIFIED</CVM> <KeepText1>Please Keep This Receipt</KeepText1> <KeepText2>For your Records</KeepText2> <EFTSN>1021</EFTSN>






<AuthCode>789DE</AuthCode> <Footer>###################DefaultCustomerFooter###################</Footer> <GratuityBoxRequired>false</GratuityBoxRequired> <ExtendedReceipt>false</ExtendedReceipt> <DisableCurrencySymbol>false</DisableCurrencySymbol> <AuthOnly>false</AuthOnly> <AcquirerPrintText /> <CardSchemePrintText /> <PrintAttempts>1</PrintAttempts> <ContactlessMSD>false</ContactlessMSD> <DCCDetails> <OriginalTransactionValue>100.00</OriginalTransactionValue> <OriginalGratuityValue>0.00</OriginalGratuityValue> <OriginalCashbackValue>0.00</OriginalCashbackValue> <OriginalTotalValue>100.00</OriginalTotalValue> <OriginalCurrencySymbol>£</OriginalCurrencySymbol> <OriginalCurrencyAbbreviation>GBP</OriginalCurrencyAbbreviation> <OriginalCurrencyDecimalPlaces>0</OriginalCurrencyDecimalPlaces> <DCCConversionRateApplied>191.00000</DCCConversionRateApplied> <DCCCommissionFee>0.00000</DCCCommissionFee> <DCCMarkUpFee>2.99000</DCCMarkUpFee> <ReceiptDisclaimer>CARDHOLDER HAS CHOSEN TO PAY IN JPY. THIS TRANSACTION IS BASED ON REUTERS WHOLESALE INTERBANK EXCHANGE RATE PLUS 2.99 PERCENT INTERNATIONAL CONVERSION MARGIN. THIS IS NOT AN ADDITIONAL FEE AND REPLACES CURRENCY CONVERSION CHARGES NORMALLY APPLIED. MY CHOICE IS FINAL. TRANSACTIONS CAN ALSO BE CONDUCTED IN GBP. THE CURRENCY CONVERSION SERVICE IS PROVIDED TO THE MERCHANT BY FEXCO DCC IN ASSOCIATION WITH Barclays Merchant Services.</ReceiptDisclaimer> </DCCDetails> <TokenRegistrationResult>NotSet</TokenRegistrationResult> <TokenRegistrationOnly>false</TokenRegistrationOnly> </VoucherDetails>

4.6.2. Barclaycard Gift

To provide receipt information for Barclaycard Gift transactions, Sentinel has specific fields returned for these transactions. An example of these receipts is included below to aid integrations:

Merchant Receipt

<?xml version=”1.0” encoding=”utf-8”?> <BarclaysGiftReceiptDetails xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema”> <Header>Test</Header> <Footer>Thank You</Footer> <PTID>PW000045</PTID> <TID>04380001</TID> <MID>99800000001</MID> <GiftCardNumber>************2200</GiftCardNumber> <OriginalTransactionID>0</OriginalTransactionID> <mkBarclaysGiftTransactionID>962</mkBarclaysGiftTransactionID> <TransactionDateTime>2011-11-08T10:58:00.2577368+00:00</TransactionDateTime> <CurrencySymbol>£</CurrencySymbol> <CurrencyAbbreviation>GBP</CurrencyAbbreviation> <PreviousBalance>0.00</PreviousBalance> <TxnAmount>100.00</TxnAmount> <RemainingBalance>100.00</RemainingBalance>






<PIN /> <AuthCode>004579000</AuthCode> <ReceiptType>Merchant</ReceiptType> <Message /> <TransactionType>NewCard_TopUp</TransactionType> <PrintAttempts>1</PrintAttempts> <MessageNumber>0132</MessageNumber> <DisableCurrencySymbol>true</DisableCurrencySymbol> <CaptureMethod>Swiped</CaptureMethod> <Reference>1234</Reference> </BarclaysGiftReceiptDetails>

Customer Receipt

<?xml version=”1.0” encoding=”utf-8”?> <BarclaysGiftReceiptDetails xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema”> <Header>Test</Header> <Footer>Thank You</Footer> <PTID>PW000045</PTID> <TID>04380001</TID> <MID>99800000001</MID> <GiftCardNumber>6280390007672200</GiftCardNumber> <OriginalTransactionID>0</OriginalTransactionID> <mkBarclaysGiftTransactionID>962</mkBarclaysGiftTransactionID> <TransactionDateTime>2011-11-08T10:58:00.2577368+00:00</TransactionDateTime> <CurrencySymbol>£</CurrencySymbol> <CurrencyAbbreviation>GBP</CurrencyAbbreviation> <PreviousBalance>0.00</PreviousBalance> <TxnAmount>100.00</TxnAmount> <RemainingBalance>100.00</RemainingBalance> <PIN /> <AuthCode>004579000</AuthCode> <ReceiptType>Customer</ReceiptType> <Message /> <TransactionType>NewCard_TopUp</TransactionType> <PrintAttempts>1</PrintAttempts> <MessageNumber>0132</MessageNumber> <DisableCurrencySymbol>true</DisableCurrencySymbol> <CaptureMethod>Swiped</CaptureMethod> <Reference>1234</Reference> </BarclaysGiftReceiptDetails>






4.6.3. Transax SV

To provide receipt information for Transax SV transactions, Sentinel has specific fields returned for these transactions. An example of the receipts information is included below to aid integrations:

<VoucherDetails> <Header>Test</Header> <PTID>PW345678</PTID> <MID>12345678</MID> <TID>87654321</TID> <TransactionDateTime>2011-09-29 17:06:23.394</TransactionDateTime> <CardScheme>CardSchemeName</CardScheme> <CardNumber>************3505</CardNumber> <ExpiryDate>1013</ExpiryDate> <IssueNumber>1</IssueNumber> <TransactionType>Sale</TransactionType> <CaptureMethod>Swiped</CaptureMethod> <Amount>10.00</Amount> <CurrencySymbol>£</CurrenctSymbol> <CurrencyExponent>2</CurrencyExponent> <CurrencyDecimalPointCharacter>.</CurrencyDecimalPointCharacter> <CurrencyAbbreviation>GBP</CurrencyAbbrevaiation> <TransactionResult>AUTHORISED</TransactionResult> <TransactionID>1234</TransactionID> <AuthorisationCode>123456</AuthorisationCode> <MerchantReference>Test1</MerchantReference> <DisableCurrencySymbol>True</DisableCurrecnySymbol> <ReceiptType>Merchant</ReceiptType> <AcquirerResponseCode>00</AcquirerResponseCode> <PrintAttempts>1</PrintAttempts> <AmountDisplay>AMOUNT</AmountDisplay> <DebitRefundMessage>Please Debit My Account</DebitRefundMessage> <Message>AUTH CODE: 123456 BAL:10.00</Message> <SignatureVerificationResult>SIGNATURE VERIFIED</SignatureVerificationResult> </VoucherDetails>






4.6.4. Pennies

To provide receipt information for Pennies transactions, Sentinel has specific fields returned for these transactions. An example of the receipts information is included below to aid integrations:

Merchant Receipt

<?xml version="1.0" encoding="utf-8"?> <VoucherDetails xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <TrainingMode>false</TrainingMode> <ReceiptType>Merchant</ReceiptType> <Header>Test</Header> <PTID>PW000045</PTID> <TID>22270438</TID> <MID>21249872</MID> <mkTransactionID>2983057</mkTransactionID> <TxnDateTime>2012-01-18T15:38:29.5349028+00:00</TxnDateTime> <CardScheme>VISA BARCLAYCARD</CardScheme> <PAN>************0002</PAN> <TxnType>Sale</TxnType> <CaptureMethod>ICC</CaptureMethod> <CustomerPresent>true</CustomerPresent> <ECommerce>false</ECommerce> <ContAuth>false</ContAuth> <AccountOnFile>false</AccountOnFile> <PinEntered>true</PinEntered> <CreditDebitMessage>Please debit my account</CreditDebitMessage> <CurrencySymbol>£</CurrencySymbol> <CurrencyAbbreviation>GBP</CurrencyAbbreviation> <Amount>1.02</Amount> <Total>2.00</Total> <CVM>PIN VERIFIED</CVM> <KeepText1>Please Keep This Receipt</KeepText1> <KeepText2>For your Records</KeepText2> <EFTSN>2624</EFTSN> <AuthCode>789DE</AuthCode> <Reference>Normal</Reference> <AID>A0000000031010</AID> <AppEff>0402</AppEff> <AppSeq>00</AppSeq> <AppExp>0308</AppExp> <CryptoTxnType>00</CryptoTxnType> <CID>40</CID> <CardHolder>BMSTESTCARDO5603/O </CardHolder> <CVMR>410302</CVMR> <TSI>E800</TSI> <TVR>40C0000000</TVR> <IACDef>4040488000</IACDef> <IACDen>1010A00060</IACDen> <IACOnl>40E84C9800</IACOnl> <AC>CB93F502E701D49F</AC> <AIP>5C00</AIP> <CardAVN>0084</CardAVN>






<FloorLimit>5.00</FloorLimit> <TDOL>9F02065F2A029A039C0195059F3704</TDOL> <DDOL>9F3704</DDOL> <MCC>2701</MCC> <CAPK>A0000000031010.99</CAPK> <TACDef>DC4000A800</TACDef> <TACDen>0010000000</TACDen> <TACOnl>DC4004F800</TACOnl> <IAD>06FE0A0364AD00</IAD> <ATC>0388</ATC> <AmtO>0.00</AmtO> <UN>203ADAA0</UN> <TCtry>826</TCtry> <Footer>Thank You</Footer> <GratuityBoxRequired>false</GratuityBoxRequired> <ExtendedReceipt>false</ExtendedReceipt> <DisableCurrencySymbol>true</DisableCurrencySymbol> <AuthOnly>false</AuthOnly> <CardSchemePrintText /> <PrintAttempts>1</PrintAttempts> <ContactlessMSD>false</ContactlessMSD> <TokenRegistrationResult>NotSet</TokenRegistrationResult> <TokenRegistrationOnly>false</TokenRegistrationOnly> <TransactionCurrencyCode>826</TransactionCurrencyCode> <CharitableDonation>0.98</CharitableDonation> <CharitableDonationReceiptText>CHARITY DONATION RECEIPT TEXT</CharitableDonationReceiptText>

</VoucherDetails>






Customer Receipt <?xml version="1.0" encoding="utf-8"?> <VoucherDetails xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <TrainingMode>false</TrainingMode> <ReceiptType>Customer</ReceiptType> <Header>Test</Header> <PTID>PW000045</PTID> <TID>22270438</TID> <MID>21249872</MID> <mkTransactionID>2983057</mkTransactionID> <TxnDateTime>2012-01-18T15:38:29.5349028+00:00</TxnDateTime> <CardScheme>VISA BARCLAYCARD</CardScheme> <PAN>************0002</PAN> <TxnType>Sale</TxnType> <CaptureMethod>ICC</CaptureMethod> <CustomerPresent>true</CustomerPresent> <ECommerce>false</ECommerce> <ContAuth>false</ContAuth> <AccountOnFile>false</AccountOnFile> <PinEntered>true</PinEntered> <CreditDebitMessage>Please debit my account</CreditDebitMessage> <CurrencySymbol>£</CurrencySymbol> <CurrencyAbbreviation>GBP</CurrencyAbbreviation> <Amount>1.02</Amount> <Total>2.00</Total> <CVM>PIN VERIFIED</CVM> <KeepText1>Please Keep This Receipt</KeepText1> <KeepText2>For your Records</KeepText2> <EFTSN>2624</EFTSN> <AuthCode>789DE</AuthCode> <Reference>Normal</Reference> <AID>A0000000031010</AID> <AppEff>0402</AppEff> <AppSeq>00</AppSeq> <AppExp>0308</AppExp> <CryptoTxnType>00</CryptoTxnType> <CID>40</CID> <CardHolder>BMSTESTCARDO5603/O </CardHolder> <CVMR>410302</CVMR> <TSI>E800</TSI> <TVR>40C0000000</TVR> <IACDef>4040488000</IACDef> <IACDen>1010A00060</IACDen> <IACOnl>40E84C9800</IACOnl> <AC>CB93F502E701D49F</AC> <AIP>5C00</AIP> <CardAVN>0084</CardAVN> <FloorLimit>5.00</FloorLimit> <TDOL>9F02065F2A029A039C0195059F3704</TDOL> <DDOL>9F3704</DDOL> <MCC>2701</MCC> <CAPK>A0000000031010.99</CAPK>






<TACDef>DC4000A800</TACDef> <TACDen>0010000000</TACDen> <TACOnl>DC4004F800</TACOnl> <IAD>06FE0A0364AD00</IAD> <ATC>0388</ATC> <AmtO>0.00</AmtO> <UN>203ADAA0</UN> <TCtry>826</TCtry> <Footer>Thank You</Footer> <GratuityBoxRequired>false</GratuityBoxRequired> <ExtendedReceipt>false</ExtendedReceipt> <DisableCurrencySymbol>true</DisableCurrencySymbol> <AuthOnly>false</AuthOnly> <AcquirerPrintText /> <CardSchemePrintText /> <PrintAttempts>1</PrintAttempts> <ContactlessMSD>false</ContactlessMSD> <TokenRegistrationResult>NotSet</TokenRegistrationResult> <TokenRegistrationOnly>false</TokenRegistrationOnly> <TransactionCurrencyCode>826</TransactionCurrencyCode> <CharitableDonation>0.98</CharitableDonation> <CharitableDonationReceiptText>CHARITY DONATION RECEIPT TEXT</CharitableDonationReceiptText>

</VoucherDetails>






4.7. Integration Messages All available record formats are detailed within this section, giving an understanding of how it is possible to customise integration to suit the requirements of the merchant.

As aforementioned, each record sent to Sentinel must be formatted as a comma separate string of data and terminated by a carriage return line feed (CRLF), unless configured otherwise within the software. For more information, please see the Vx 810 & VX 820 Sentinel Installation Guide, section 6.

4.7.1. Transaction Request (T Record)

Detailed below is the format of the most frequently used record, the Transaction Record. This is used for initiating payment transactions with Sentinel.

The T Record is followed by the output response generated after the transaction record has been processed. Please note that the format of the response returned by Sentinel is controlled by configuring the Integration Version.

Field Name Type Description 1 Message Type String

Mandatory Identifier for the message type, which for transaction requests is: “T”

2 Account Number This field is no longer used. Field 24, Account ID, is used to define the merchant parameter set to use. If populated this field will be ignored.

3 Transaction Type Integer Mandatory

‘01’ – Purchase ‘02’ – Refund ‘04’ – Cash advance

4 Modifier Integer Mandatory

Available modifiers with Sentinel:

‘0000’ – Cardholder Present ‘0002’ – Offline (Capture) ‘0008’ – CNP – Mail Order ‘0010’ – Authorisation Only ‘0040’ – Recovered Transaction (reserved for future use) ‘0080’ – Allow Zero Value Pre-Auth ‘0100’ – Unattended Device ‘0400’ – CPC – Minus I and L Records ‘0800’ – Allow Electron CNP (Tele/Spread-betting) ‘1000’ – CNP – Telephone Order ‘2000’ – CNP – Account On File

5 PoS Routing / Bill ID Reserved, leave empty 6 PAN / Track 2 Reserved, leave empty 7 CSC Reserved, leave empty 8 Expiry Date Reserved, leave empty 9 Issue No Reserved, leave empty 10 Start Date Reserved, leave empty 11 Txn Value Integer

Mandatory Total value of the transaction applies to: Purchase, Refund, Cheque Guarantee, and Cash Advance. Provision of the decimal point is recommended although optional. For example: 1.23 = £1.23 123=£123.00, 000001.2389 = £1.23. Values should always be positive, and will be truncated to






the correct number of decimal places required for the currency. For example: 1.23 = 1¥ (one Japanese Yen) (0 decimal places)).

12 Cash Back Value Reserved for future use (not currently supported) 13 Bank Acc No Reserved, leave empty 14 Sort Code Reserved, leave empty 15 Cheque No Reserved, leave empty 16 Cheque Type Reserved, leave empty 17 Cardholder Name Reserved, leave empty 18 Cardholder Billing Address Reserved, leave empty 19 EFTSN Reserved, leave empty 20 Auth Source Reserved, leave empty 21 Auth Code Reserved, leave empty 22 Txn Date Time Reserved, leave empty 23 Reference String

Optional Reference numbers can be supplied up to a maximum length of 50 characters. When forwarded to the acquirer these are truncated to 25 characters

24 Account ID String Optional

Defines merchant parameter set to be used

25 Gratuity Reserved for future use (not currently supported) 26 NDI Value Integer

Optional Non Discounted Items – this value field is available to define how much of the transaction value is not applicable for the cardholder to earn rewards against. If no value is supplied, this field will default to 0.00 and the cardholder will earn rewards against the full value of the transaction (from “Txn Value” field). Available when Barclaycard Freedom value added service is enabled

27 Register For Account On File Integer Defines Account On File Registration. Supported values are: ‘0’ – Not Set ‘1’ – Do Not Register ‘2’ – Register ‘3’ – Register Only* ‘4’ – Register, decline transaction if registration fails *When performing a ‘Register Only’ registration, the value of the transaction must be set to ‘0.00’ and a modifier of ‘0000’ (Cardholder Present) used

28 Token ID Integer Token ID value if processing an Account On File Payment 29 Suppress Charitable Donation Integer Field to indicate whether the charitable donation should be

suppressed. This functionality is designed to allow the retailer to account for scenarios whereby the transaction needs to be repeated and that the cardholder should not be prompted again. Valid values are: ‘0’ – Not Set ‘1’ – Suppress

Please note that additional fields may be required in order to support Procurement Card Processing and these are described within a Procurement Card Specification available separately.






4.7.2. Transaction Response (Initial)

Field Name Type Description 1 Result Integer Transaction result:

‘0’ – Completed ‘7’ – Declined ‘-nn’ – All other negative values are used to

define error conditions Appendix B contains a full list of error codes and messages. Screenless transaction results: ‘0’ – Completed ‘2’ – Referred ‘5’ – Declined ‘6’ – Authorised ‘7’ – Reversed ‘8’ – Comms Down ‘-nn’ – Negative values are used to define error

conditions 2 Terminate Loop Integer Reserved, Ignore 3 Total Transaction Value Processed Integer Values will be truncated to the correct number

of decimal places required for the transaction currency. For example: 1.23 = 1 (one Japanese Yen) Field will show total that will be debited

4 Cashback Value Integer As above 5 Gratuity Value Integer As above 6 PAN Integer The Primary Account Number (Card Number).

Please note: This value will not be returned in full due to PCI requirements. The PAN will be masked apart from the last four digits, e.g. ‘************1234’

7 Expiry Date MMYY Integer Card Expiry Month and Year. 8 Issue Number Integer Card Issue Number. Blank when scheme does

not provide an issue number. 9 Start MMYY Integer Card start month and year. 10 Transaction Date / Time Integer CCYYMMDDHHMMSS 11 Merchant Number Integer The Merchant Number for the given

card scheme and account. 12 Terminal ID Integer Terminal ID used for this transaction. 13 Scheme Name String Card scheme name 14 Floor Limit Integer Floor limit for the card scheme/account. 15 EFT Sequence Number Integer Four digits in the range 0001 – 9999. (Prefixed

with “OL” when offline) 16 Authorisation Code String Blank if the transaction is declined or is below

the floor limit. 17 Referral Telephone Number. Reserved, ignore 18 Customer Verification Method / Authorisation

Message / Error Message / Status Message String As returned by communications process.

Normally direct from acquirer. Also contains status message if enabled






4.7.3. Transaction Response (Version2)

Field Name Type Description First 18 fields are the same as Transaction Output Record (Initial)

19 Capture Method String Valid values are: ContactlessEMV ContactlessMagswipe Swipe ICC Keyed

20 Transaction Currency Code Currency Code associated with the transaction 21 Original Transaction Value Transaction value based on the original base currency 22 Original Cashback Value Cashback value based on the original base currency 23 Original Gratuity Value Gratutiy Value based on the original base currency 24 Original Transaction Currency Code Currency code associated with the base currency 25 Barclaycard Freedom Discount Value Integer The value of discount, inclusive of any Campaigns or

eCoupons, earned from the transaction (e.g. 4.00) 26 Barclaycard Freedom Redemption

Value Integer The total value redeemed against the transaction, using

available Barclaycard Freedom rewards earned (e.g. 10.00)

27 Account on File Registration Result Integer This is the result of the Account on File registration. Valid values are: ‘0’ – Not Set ‘1’ – Not Performed ‘2’ – Success ‘3’ – Failed

28 Token ID String This is the token allocated to the payment details as part of the Account on File registration process or the token used for the Account on File payment.

29 AVS Post Code Result Integer This is the result of any AVS post code checking. Valid values are: ‘0’ – Unknown ‘1’ – Not Checked ‘2’ – Matched ‘4’ – Not Matched ‘8’ – Reserved

30 AVS House Number Result Integer This is the result of any AVS house number checking. Valid values are: ‘0’ – Unknown ‘1’ – Not Checked ’2’ – Matched ‘4’ – Not Matched ‘8’ – Reserved

31 CSC Result Integer This is the result of any CSC verification. Valid values are: ‘0’ – Unknown ‘1’ – Not Checked ‘2’ – Matched ‘4’ – Not Matched ‘8’ – Reserved







Field Name Type Description Fields 19 to 31 are the same as Transaction Output Record (Version2)

32 Card Number Hash String (base64-encoded binary)

This is a SHA-256 hash of the PAN with a merchant specific salt


Field Name Type Description Fields prior to 33 are the same as Transaction Output Record (Version3)

33 VGIS Reference String This is the VGIS reference generated if the transaction was flagged as a VGIS transaction (see Procurement Guide for further information)



34 Track1 Discretionary Data

String Data captured from the Track1 Discretionary Data field, e.g. Loyalty Card Number



35 CharityDonationValue Decimal The donation value which has been incorporated as part of the transaction value

36 CharityDonationMerchantNumber String The charitable donation provider allocated merchant number

37 OriginalCharityDonationValue Decimal The donation value which has been incorporated as part of the transaction value prior to currency conversion being performed (if applicable)



38 Transaction Id Decimal This is the ID of the transaction assigned by the hosted service.

39 Authorisation Server Name String This is the name of the authorisation server that processed the transaction.



40 Card Scheme ID Decimal This is the ID of the card scheme






Example (40 fields):

0,1,10.00,0.00,0.00,************0002,0308,,0402,20121212152308,22048042,28200005,Visa,,2206,060377,,PIN VERIFIED,ICC,826,,,,,,,1,,0,0,0,SFJtHyYqGFm0r4ksPY6vGTE9x9s=,,,0.00,,,108112,AuthDB\RND-DB-1,2,

Please note that the format of the response returned by Sentinel is controlled by configuring the Integration Version.






4.7.10. Login Request (L2 Record)

To provide the ability to log into Sentinel remotely via an integration message, the L2 record is available. The record, as well as containing the terminal user credentials, can be used to stipulate which menu structures are enabled for the operator.

Field Name Type Description 1 L2

(Upper Case) String Mandatory

‘L2’ – Indicates an L2 format Login Record

2 UserID String Mandatory

User ID

3 PIN String Mandatory

User PIN

4 Menu Options String Conditional

See Menu Options below this table

Menu Options:

1. New Transaction

2. Menu 1. Transaction Management 1. Reports 1. Live Store 2. X Report 3. Z Report 4. Session Report 5. Transaction Report 6. Summary Settlement Report 7. Detailed Settlement Report 8. Q Report 9. Stored Offline Txn Report 2. Submit Offline Txns 2. Reprint 1. Merchant Receipt 2. Customer Receipt 3. Last Report 3. System 1. Print Stored AID's 2. System Info 3. Voucher Type 1. Enabled 2. Disabled 4. Change Setup PIN 5. Download 4. Ordering 1. Product List 2. Place Order 5. User Management 1. Change User ID 2. Change User PIN 3. Change Stationary PIN 6. Terminal Management 1. ----- 2. Reboot Pinpad 3. -----

3. Select Bill 1. Close Bill on POS






2. Get Bill 3. Get/Print Bill

4. Print Bill 4. Logoff 5. Other 1. [Reserved for Future Use]

2. PayPoint 3. Givex 4. M-Voucher 5. UKASH 6. GRTFS

7. Barclays Bonus 8. Barclays Gift 9. GTP

The options are listed by placing all those required in the fourth field of the record. For example, to include all the menus and their sub-menus (for a user with a Login ID and PIN of 1234):

L2,1234,1234,*

For more specific configurations, it is possible to only enable the operator access to the logout option. This would be achievable using the following record:

L2,1234,1234,4

By including a 4, none of the other options are accessible.

Leaving the fourth field blank would specify that no options would be available at all, rendering the application completely controlled by records from the POS.

To control the sub menus as well a set of “{ }” must be included after the option selected, and within the brackets list which sub options are utilisable. An example here would be where Select Bill is required, but only Print Bill to be available within the sub menu (option 4 of the four sub-options):

L2,1234,1234,3 {4} 4

As with the previous example, for all sub options to be available then include {*} after the option. Not including anything will only allow the top menu to be accessed. The only exception to this rule is the New Transaction option, which is controlled using the permissions setup on the account.

Please note: it is also possible to control user menu options by configuring a ‘Permission Profile’ within WebCom. For instructions

on how to do this, please refer to the WebCom manual






4.7.11. Logout Request (O Record)

When there is a requirement to logout of Sentinel, the O Record can be used to perform this action.

Field Name Type Description 1 O

(Upper case)

String Mandatory

‘O’ – Indicates Logout Record

2 Function Integer Mandatory

‘0’ – Logout ‘1’ – Print Q Report and logout ‘2’ – Exit and logout ‘3’ – Exit and logout with Q report ‘4’ – Submit offline transactions, logout and shut down

A response is sent once the request has been processed, informing the integrated system of the result. As with the login record, a ‘0’ record is received back to confirm a successful logout, or a ‘-31’ for a processing error. If attempting to logout when there is no user logged in, a ‘-85’ error message is received.

4.7.12. POS Progress/Customer Facing

The POS Progress Message is sent to the POS either via a socket connection (set to port 25001 by default) or via a text file named ‘StatusFile.txt’, which is written to the ‘TIPath’ as defined within the ‘Program.Settings.ccf’ file when the solution is operating in Screenless Mode.

For further information on amending these details please see the Installation Guide, which details amending the configuration files.

When operating in this mode, Sentinel operates silently whilst minimised in the taskbar; therefore, in order for the integrated solution to react and provide information as required, the POS Progress message continually sends status messages which are monitored and can be responded to by sending a ‘Continue Transaction’ record.

Field Name Type Description 1 Result Integer This indicates the result code (100) 2 Terminate

Loop Integer Reserved, Ignore

3 Status ID Integer Status ID of the transaction. All responses listed below in separate table 4 Status String This is a text representation of the progress status 5 Parameters String This field will contain any information that the POS may require that is associated

with that status. Each parameter will be ‘;’ delimited and will be defined as follows:

<Name>=<Value> Here is a list of all possible parameters: TXN VALUE CASHBACK GRATUITY TOTAL AMOUNT AUTH CODE VR TEL NO CARD






EXPIRY MID TID FILENAME PROGRESS SCHEME ID MERCHANT NAME

Status ID Messages

Listed below are all the available Status ID messages which could be returned by Sentinel, along with the parameters which may be returned.

Please note: where the Status ID is described as ‘Not Used’ the status is not returned by Sentinel.

Status ID Description Parameters / Not Used Suggested on screen message to display to customer for each status:

0 Processing Transaction Not Used 1 Waiting For Gratuity “Enter Gratuity” 2 Gratuity Being Entered No message required

[Informs POS that the gratuity is being entered on screen]

3 Awaiting Card TXN VALUE CASHBACK VALUE GRATUITY VALUE TOTAL AMOUNT

“Present Card” / ”Insert Card”

4 Swipe Card TXN VALUE CASHBACK VALUE GRATUITY VALUE TOTAL AMOUNT

“Swipe Card” / “Remove Card”

5 Card Inserted “Please Wait” 6 Card Removed “Please Wait” 7 Card Processing “Do Not Remove Card” 8 Change Card “Use Alternative Payment Method” 9 Contact Transaction

Required Not Used

10 Key In Card Details TXN VALUE CASHBACK VALUE GRATUITY VALUE TOTAL AMOUNT

“Key Card Number”

11 Waiting For Cashback “Enter Cashback” 12 Pin Entry “Enter PIN” 13 Risk Management

Complete No message required

[Informs POS that PIN has been entered/stage where PIN would be entered has been completed]

14 Authorising Transaction “Please Wait” 15 Waiting For Result “Please Wait” 16 Auth Result Received “Please Wait” 17 Printing Merchant Receipt “Please Wait” 18 Signature Confirmation

Required “Please Wait”

19 Continue Required No message required [Informs POS that PAYware Ocius requires information]

20 Confirm Auth Code AUTH CODE [Display all the information on screen to allow a Voice Referral to be processed; Merchant Number, Correct Bank Telephone






Number and all transaction details] 21 Confirming Transaction “Please Wait” 22 Rejecting Transaction “Declined” 23 Final Result Received “Please Wait” 24 Voice Referral VR TEL NO

CARD EXPIRY MID TID

“Referral”

25 Remove Card “Remove Card” 26 Auth Result Error Not Used 27 Fallback To Swipe

Disabled Not Used

28 Downloading File FILENAME PROGRESS

“Loading”

29 Updating PED FILENAME PROGRESS

“Loading”

30 Invalid PED Configuration Not Used 31 Card Data Retrieval 32 Starting Transaction “Please Wait” 33 Performing Download “Loading” 34 Requesting Report “Please Wait” 35 Gratuity Selection Required Not Used 36 Expiry Date Required “Expires MM/YY” 37 Start Date Required “Valid From MM/YY” 38 Issue Number Required “Issue Number” 39 AVS House Number

Required “Enter House Number”

40 AVS Post Code Required “Enter Post Code” 41 CSC Required “Enter Card Security Code” 42 Customer Present / Not

Present Selection Required Not Used “Customer Present? Yes/No”

43 Customer / Not Present Option Selection Required

Not Used

44 Enter Charge Auth Code “Enter Charge Auth Code” 45 Login Required No message required

[Informs POS that PAYware Ocius is ready to be logged in]

46 Ready “Ready” 47 Card Not Accepted “Not Accepted” 48 Card Blocked Not Used 49 Transaction Cancelled “Transaction Void” 50 Invalid Expiry Not Used 51 Gratuity Invalid Not Used 52 Invalid Card Not Used 53 Printing Customer Receipt “Please Wait” 54 Initialising PED “Please Wait” 55 PED Unavailable No message required

[Informs POS that the PED is unavailable] 56 Card Application Selection “Select Payment Type” 57 Retry Download No message required 58 Restart After Software

Update No message required

59 Requesting DCC “Please Wait” 60 DCC Currency Choice No message required 61 Cardholder DCC Currency

Choice “Please select currency” [include details of

currency options] 62 Unsafe Download No message required 63 Unexpected Login No message required 64 Start Barclays Bonus

Transaction Not Used

65 Update Barclays Bonus Not Used






Transaction 66 Cancel Barclays Bonus

Transaction Not Used

67 Confirm Gratuity Not Used 68 Register For Account On

File Decision No message required

69 Awaiting Token ID TXN VALUE CASHBACK VALUE GRATUITY VALUE TOTAL AMOUNT

No message required

70 Barclays Bonus Discount Summary

Not Used

71 Barclays Bonus Use Bonus Not Used 72 Barclays Bonus Enter

Redemption Not Used

73 Barclays Bonus Not Available

Not Used

74 Download Complete No message required 75 Download Still Being

Prepared No message required

76 Server Connection Failed No message required 77 Resume Download No message required 78 PayPoint Account

Extraction Failed No message required

79 PayPoint Amount Outside Allowed Range

“Invalid Amount”

80 PayPoint Card Expired “Not Accepted” 81 PayPoint Initialised No message required 82 PayPoint Initialisation

Failed No message required

83 PayPoint Initialising “Loading” 84 PayPoint Invalid Account No message required 85 PayPoint Invalid Amount No message required 86 PayPoint Invalid Capture

Method No message required

87 PayPoint Invalid Card Number

No message required

88 PayPoint Invalid Configuration

No message required

89 PayPoint Invalid Denomination

No message required

90 PayPoint Invalid Expiry Date

No message required

91 PayPoint Invalid Scheme No message required 92 PayPoint Invalid Scheme

Option No message required

93 PayPoint Invalid Top-up Type

No message required

94 PayPoint Invalid Service Provider

No message required

95 PayPoint Invalid Track2 Format

No message required

96 PayPoint Invalid Transaction Type

No message required

97 PayPoint Keyed Entry Not Allowed

No message required

98 PayPoint Merchant Reference Required

“Please Wait”

99 PayPoint No Accounts No message required 100 PayPoint Processing

Transaction “Please Wait”

101 PayPoint Retry “Please Wait”






Confirmation Decision 102 PayPoint Scheme Not

Recognised “Invalid Scheme”

103 PayPoint Transaction Cancelled

“Transaction Void”

104 PayPoint Transaction Type Not Allowed

“Not Accepted”

105 PayPoint Select Scheme Option

SCHEME ID “Select Scheme”

106 PayPoint Download Required

No message required

107 PayPoint Select Account No message required 108 Printing PayPoint Receipt “Printing Receipt” 109 Licence Detail Confirmation MERCHANT NAME “Please Wait” 110 Licence File Required “Loading” 111 Pay Point Service

Unavailable

112 Park Retail Gift Account Extraction Failed

113 Park Retail Gift Amount Outside Allowed Range

114 Park Retail Gift Card Expired

115 Park Retail Gift Initialisation Failed

116 Park Retail Gift Initialising 117 Park Retail Gift Invalid

Account

118 Park Retail Gift Invalid Amount

119 Park Retail Gift Invalid Capture Method

120 Park Retail Gift Invalid Card Number

121 Park Retail Gift Invalid Configuration

122 Park Retail Gift Invalid Expiry Date

123 Park Retail Gift Invalid Track2 Format

124 Park Retail Gift Invalid Transaction Type

125 Park Retail Gift Keyed Entry Not Allowed

126 Park Retail Gift Merchant Reference Required

127 Park Retail Gift No Accounts

128 Park Retail Gift Service Unavailable

129 Park Retail Gift Processing Transaction

131 Park Retail Gift Scheme Not Recognised

132 Park Retail Gift Select Account

133 Park Retail Gift Transaction Cancelled

134 Park Retail Gift Transaction Type Not Allowed

135 Printing Park Retail Gift Receipt






136 PED In ESD Recovery Mode2

137 Update Transaction Value Decision

CAPTUREMETHOD CARDDATA SCHEMENAME HASH TXNVALUE GRATUITYVALUE CBVALUE

138 Update Barclaycard Freedom Config

139 Processing Key Exchange 140 Barclays Gift Initialising

141 Global Blue Tax Free Shopping Initialising

142 GiveX Initialising 143 M-Voucher Initialising

144 Performing Post Confirm Reversal

145 Invalid Amount

146 Merchant Reference Required

147 Merchant Reference Length Invalid

148 Initialising 149 Account Extraction Failed

150 Amount Outside Allowed Range

151 Enter Amount 152 Confirm Authorisation 153 Card Expired

154 Transax SV Initialisation Failed

155 Transax SV Initialising 156 Invalid Account 157 Invalid Capture Method 158 Invalid Card Number 159 Invalid Configuration 160 Invalid Expiry Date 161 Invalid Track2 Format 162 Invalid Transaction Type 163 Keyed Entry Not Allowed 164 No Accounts

165 Card Scheme Not Recognised

166 Transaction Type Not Allowed

167 Transax SV Service Unavailable

168 Invalid Issue Number 169 Invalid Card Security Code 170 Confirmation Failed 171 Printing Receipt 172 Waiting For Donation 173 Pin Blocked 174 Pin Try Limit Exceeded

2 states that PED is in electrostatic discharge recovery mode and needs to be power cycled






175 Further Payment Required 176 SVS Initialising 177 SVS Initialisation Failed 178 SVS Invalid Configuration 179 SVS Service Unavailable

180 Cannot Continue Transaction

181 Part Payment 182 Obtain STAN 183 Invalid STAN 184 IVR Required

185 Prompt For Authorisation Code

186 Invalid Auth Code 187 Offline Txn Failed 188 Enter Reference 189 Print Shop Copy 190 Must Insert Card 191 PIN Entered 192 Card Swiped 193 PIN Bypassed 194 Cancelling Transaction 195 Card Presented 196 Server Error 197 On Hold Transaction






4.7.13. Continue Transaction (CONTTXN Record)

This record is used with Sentinel in Screenless mode and allows the POS system to progress a transaction when further information is required. This message is sent via the standard integration port (25000 by default).

Field Name Type Description 1 Message Type String CONTTXN 2 Action ID Integer This is the required action to perform. These are defined below within a

separate table. 3 Parameters String This field will contain any information that the POS may require that is

associated with that status.

Each parameter will be semi-colon ; delimited and will be defined as follows:

<Name>=<Value> The following parameters are available: REPRINTOPT=FILE Reprint to file rather than current printer AUTHCODE=… The auth code to be supplied to PAYware Ocius for VR transactions / Charge Only transactions CASHBACK=… The cashback to be added to the transaction MGRPIN=… The manager PIN to use PAYPOINTACCID=… The PayPoint account ID to use PAYPOINTOPTIONID=… The PayPoint Scheme Option to use

Action ID Messages

Listed below are all the available Action ID messages which could be returned by Sentinel, along with the parameters which may be returned.

Please note: where the Action ID is described as ‘Not Used’ the status is not returned by Sentinel.

Action ID Description Parameters / Not Used 0 Not Specified Reserved for Internal Use 1 Bypass PIN 2 Continue Transaction 3 Confirm Signature 4 Reject Signature 5 Reprint Receipt REPRINTOPT 6 Keyed Entry Required Not Used 7 Voice Referral Authorised AUTHCODE 8 Voice Referral Rejected 9 Gratuity Required Not Used 10 Gratuity Not Required Not Used 11 Gratuity On PED Not Used 12 Cancel Transaction 13 Alternate Payment 14 Customer Present Required Not Used






15 Customer Not Present Required Not Used 16 E-Commerce Required Not Used 17 Mail Order Required Not Used 18 Telephone Order Required Not Used 19 Change Card Not Used 20 Confirm Auth Code 21 Reject Auth Code 22 Charge Auth Code AUTHCODE 23 Reverse UAT ICC Txn 24 Retry Device 25 Continue Without Device 26 Abort Device Connectivity 27 Retry Download 28 Cancel Download 29 Cashback Required CASHBACK 30 Cashback Not Required 31 Restart 32 Accept Unsafe Download 33 Reject Unsafe Download 34 Replace Account MGRPIN 35 Cancel Replace Account 36 Confirm Gratuity Not Used 37 Change Gratuity Not Used 38 Account On File Registration Required 39 Account On File Registration Not Required 40 Reconnect To Server 41 Abort Reconnect To Server 42 Select PayPoint Account PAYPOINTACCID 43 Select PayPoint Option PAYPOINTOPTIONID 44 Retry PayPoint Confirmation 45 Cancel PayPoint Confirmation 46 Accept Licence Key 47 Reject Licence Key 48 Cancel Licence Key Verification 49 Continue Licence Key Verification 52 Confirm Park Retail Gift Transaction 53 Reverse Park Retail Gift Transaction 54 Cancel Get Card Details (GDET) 55 No Transaction Value Update Required 56 Transaction Value Update Required TXNVALUE 57 Merchant Currency Required 58 Cardholder Currency Required 59 Merchant Reference Entered REF 60 Supply IVR Details 61 Reject IVR 62 Print Shop Copy Receipt 63 Cancel Shop Copy Receipt 64 Supply STAN 65 Accept Part Payment 66 Reject Part Payment 67 Further Payment Required 68 No Further Payment Required

Some actions are dependent upon the stage the transaction has reached, e.g. bypassing the PIN can only be actioned at the stage where PIN entry is requested. Please see the below table for a list of the actions available and what stage the transaction must have reached before being able to perform the required action.

Action Required Transaction Stage






Bypass PIN PIN Entry Continue Txn Continue Required,

Change Card

Confirm Signature Signature Confirmation Required Reject Signature Signature Confirmation Required Reprint Receipt Signature Confirmation Required,

Continue Required

Voice Referral Authorised Voice Referral Voice Referral Rejected Voice Referral Cancel Transaction Present Card,

Card Data Retrieval, Enter Card Number, Expiry Date Required, Start Date Required, Issue Number Required, AVS House Number Required, AVS Post Code Required, CSC Required, Selection Required, Enter Charge Auth Code, Change Card, Invalid Expiry, Waiting For Cashback, PayPoint Select Account PayPoint Select Scheme Option

Alternate Payment Present Card, Invalid Expiry

Change Card Change Card Confirm Auth Code Confirm Auth Code Reject Auth Code Confirm Auth Code Charge Auth Code Enter Charge Auth Code Reverse UAT ICC Txn Continue Required (merchant receipt stage only) Retry Device PED Unavailable Continue Without Device PED Unavailable Abort Device Connectivity PED Unavailable Retry Download Retry Download Cancel Download Retry Download Cashback Required Waiting For Cashback Cashback Not Required Waiting For Cashback Restart Restart After Software Update Accept Unsafe Download Unsafe Download Reject Unsafe Download Unsafe Download Replace Account Unexpected Login Cancel Replace Account Unexpected Login Account on File Registration Required Register For Account On File Decision Account on File Registration Not Required Register For Account On File Decision Select PayPoint Account PayPoint Select Account Select PayPoint Option PayPoint Select Scheme Option Retry PayPoint Confirmation PayPoint Retry Confirmation Decision Cancel PayPoint Confirmation PayPoint Retry Confirmation Decision Accept Licence Key Licence Detail Confirmation Reject Licence Key Licence Detail Confirmation Cancel Licence Key Verification Licence Detail Confirmation






4.7.14. Transaction Value Modification

As described earlier within the document, the transaction value modification functionality allows for an initial transaction value to be updated after the card has been inserted.

The transaction flow is as follows:

1. Transaction initiated using standard transaction request (“T Record”), with a nominal dummy value, e.g. £1

2. PAYware Ocius prompts for Card Entry

3. PAYware Ocius reads and hashes the card details

4. POS Progress message (Status ID = 137) returned detailing the card hash and card type

5. POS uses information as required for perform lookups/additional processing

6. POS returns a “CONTTXN” message (action ID = 55/56) to proceed with transaction processing, including any discounts required Please note: When proceeding with the transaction using action ID 56 to update the details, it is possible to flag the transaction as a procurement card transaction. Please see the Procurement Card Specification for full details.

7. PAYware Ocius updates the value and proceeds with standard transaction processing

This feature must be enabled on the terminal before to the above flow will be adhered to.

POS Progress Message – Status ID = 137

This progress message will be returned as shown in step 4 of the above flow.

Field Name Type Description 1 Result Integer This indicates the result code (100) 2 Terminate Loop Integer Reserved, Ignore 3 Status ID Integer Status ID of the transaction.

For the Transaction Value Modification process, the Status ID will be ‘137’

4 Status String This is a text representation of the progress status For the Transaction Value Modification process the Status will be ‘Update Transaction Value Decision’

5 Parameters String This field will contain any information that the POS may require that is associated with that status. Each parameter will be ‘;’ delimited and will be defined as follows: <Name>=<Value> Here is a list of all possible parameters: CAPTUREMETHOD* Capture method, from: 1 = Keyed_CP






2 = Keyed_CNP_MailOrder 3 = Swiped 4 = ICCFallbackToSwipe 5 = ICCFallbackToSignature 6 = ICCPINOnly 7 = ICCPINAndSignature 8 = ICCNoCVM 9 = ContactlessEMV 10 = ContactlessMagswipe 11 = Keyed_CNP_TelephoneOrder 12 = Keyed_CNP_ECommerce 13 = ICCUnknown 14 = Keyed_CNP_AccountOnFile CARDDATA Card number SCHEMENAME Name of the card scheme HASH Hash representation of the card number TXNVALUE Current transaction value GRATUITYVALUE Gratuity value CASHBACKVALUE Cashback value ISCPCCARD Mark the transaction as being CPC card *Please Note: when the capture method is obtained from the initial card insertion, no risk management is performed. It is therefore possible that the capture method may change when performing standard transaction processing after updating the transaction value.

Example message:

100,0,137, UpdateTransactionValueDecision,CAPTUREMETHOD=6,CARDDATA=492912*******;SCHEMENAME=Visa;HASH=<Hashed_card_details>;TXNVALUE=1.00;GRATUITYVALUE=0.00;CBVALUE=0.00

Continue Transaction Message

After receiving a Progress Message with a status ID of 137, the transaction will not progress until the correct Continue Transaction Message is returned.

With the transaction value modification functionality, a continue transaction message with an Action ID of ‘55’ or ‘56’ must be returned. This informs the terminal of the transaction value to proceed with:

Field Name Type Description 1 Message Type String CONTTXN 2 Action ID Integer This is the required action to perform.

For the Transaction Value Modification functionality this should be either: 55 = No transaction value update 56 = Transaction value update required

3 Parameters String This field will contain any information that the POS may require that is associated with that status. Each parameter will be semi-colon ; delimited and will be defined as follows: <Name>=<Value>






The following parameter should be provided with the Action ID of ‘56’: TXNVALUE The value of the transaction

Example messages:

If the transaction value does not require any change: ‘CONTTXN,55’

If the transaction value requires an update: ‘CONTTXN,56,TXNVALUE=10.00’






4.7.15. REQINFO

Should information be required from Sentinel, then a request for information can be sent.

Via a response a report will be produced containing the requested information from a terminal, or an estate of terminals, depending on how the message is sent.

Detailed within the table below are the available commands:

Field Name Type Description 1 Message Type String

Mandatory Identifier for the message type, which for information requests is: “REQINFO”

2 REQINFO Type Integer Mandatory

Integer to identify which information is required: ‘1’ – Returns the PTID of the terminal ‘2’ – Software version on the terminal ‘3’ – Login status report ‘4’ – Displays “Please wait”, and performs connection test to transaction server ‘5’ – Returns the status of the PED from the last check performed by PAYware Ocius ‘6’ – Returns the hardware PTID of the PED, serial number of the attached PED and PED firmware version number

The following parameters are only available with REQINFO,6 3 Data Type Integer

Optional The type of data required: ‘0’ – PTID, serial number and firmware data of device ‘1’ – PTID of device only ‘2’ – Serial number of device only ‘3’ – Firmware data of device only

4 Reader Type String Optional

Available modifiers with Sentinel:

‘ALL’ – Return details from Contactless or EMV devices ‘CONTACTLESS’ – return details from Contactless devices only ‘EMV’ – Return details from EMV devices only

5 Device Index String Optional

Reserved for future use – when multiple devices can be attached to Sentinel

Where multiple data is returned within the same field within the output record, field separators are used.

Example record for REQINFO,6:

0,1,,,,,,,,,,,,,,,,1|Contactless|12345678<FS>123-456-789<FS>2.14






4.7.16. Additional Integration Commands

The following commands are available to provide extra (non-transaction) functionality to the host system. They can be used with either of the integration methods (text or socket):

Output Message Description OLS, On receipt of this integrated function, Sentinel will submit all offline transactions and respond

with a message informing the operator of the outcome. N.B. if the terminal is offline when OLS is sent, then a reconnection attempt will be made. If this fails, an error message of -87 will be returned to inform the POS of this result. The command can be followed by NOMSG, which will result in the terminal remaining minimised during submission, e.g. ‘OLS,NOMSG’.

REP,x Report command which when sent to Sentinel will produce a report, where x is the report required. Another variable; y (optional, in which case the format of the record is REP,x,y) can be supplied to provide the full filename to output the report to. Here are the reports available (x): ‘1’ – Z Report – report detailing all transactions since last Z report run ‘2’ – X Report – report detailing all transaction since last Z report, but without resetting the values as with Z report ‘3’ – Txn Report – report of last 10 processed transactions ‘5’ – Q Report – quick report showing total processed amount since last Z report, and the date and time of the last Z report ‘10’ – Last Printed Report (Re-print) – reprints the last printed report ‘11’ – Stored Offline Txn Report – report of any stored offline transactions which are yet to be submitted to the ICP server ‘100’ – Product List – prints a list of available products, e.g. till roll ‘101’ – Reprints customer receipt – reprints customer receipt from the last processed transaction ’102’ – Reprint Merchant – reprints the merchant receipt from the last processed transaction ‘103’ – Prints System Information report – prints System Info report, which contains information about the software running on the device as well as all the network settings for the terminal ‘201’ – Live Store – prints a report showing all transaction in the live store waiting to be sent for settlement ‘202’ – Session Report –prints a report showing all transactions processed during the current logon session ‘203’ – Summary Settlement Report – prints a report showing the totals, broken down by card scheme, of transaction from the last time the account was settled ‘204’ – Detailed Settlement Report – prints a report showing each settled transaction included in the last settlement (e.g. the night before). ‘205’ – Barclays Gift Report – prints report on all Barclays Gift transactions The REP command can be followed by ‘NOMSG’ which will result in the terminal remaining minimised whilst the receipt is being produced, e.g. to produce a Z Report to the default report location silently ‘REP,1,,NOMSG’.

REQLASTMSG, Returns the last message sent to the POS. If a value is not stored, a ‘-29’ response will be returned.

SCRPOS,x,y This provides the ability to adjust the screen position, where x and y are the co-ordinates (integer values). This message will be accepted when Sentinel is on the login screen or the main idle screen.

STAYOFFLINE,x This message allows a command to be sent to the application to instruct PAYware Ocius to Stay Offline for a period off time. The available options to supply for the value are: ‘0’ – Online ‘1’ to ‘98’ – Stay offline for x minutes (minimum of 1, maximum of 98) ‘99’ – Stay offline until the end of the day

UPDAPP, This function will check for updates. Once the updates are completed, the standard response will be sent to the POS with details of download being successful ‘0,1,,,,,,,,,,,,,,,,Download Successful’. If there are no downloads to be acquired by the terminal then a response of ‘0,1,,,,,,,,,,,,,,,,No Downloads Available’ will be returned to the host.

WINSTATE,x The WINSTATE messages allows the system to control the status of the window, using the






following commands: ‘0’ – Normal ‘1’ – Minimised ‘2’ – Maximised The response received after the action has been performed will be either: ‘0,1,,,,,,,,,,,,,,,,Window State Changed’ or ‘-31,1,,,,,,,,,,,,,,,,Failed To Change Window State’






5. Value Added Services

5.1. Barclaycard Gift Barclaycard Gift is a prepay gift card supported by VeriFone’s PAYware Ocius platform.

The gift card can be purchased in store from any participating merchant and has a prepaid balance, the amount of which is loaded upon purchase. The card can then be given as a gift to allow the cardholder to spend the balance at any of the participating merchants.

A 4 digit PIN is printed on the receipt when the gift card is initially purchased and can be used to access the balance of the card online at:

www.showmybalance.com

5.2. Barclaycard Gift Request (BGIFT Record) Requires Barclaycard Gift Value Add to be enabled

When utilising the Barclaycard Gift value added service, integrated Barclaycard Gift transactions can be automated by the POS using the below request message:

Field Name Type Description 1 Message Identifier String Identifier for the message type, for Barclaycard Gift:

“BGIFT” Mandatory

2 Account ID Decimal Account ID under which to process the transaction. Conditional Note: This is not required for void transactions. It is mandatory for all other transaction types.

3 Transaction Type Integer Barclays Gift Transaction type. Valid values are: Balance Enquiry = 1 New Card / Top-Up = 2 Sale = 3 Refund = 4 Cash = 5 Void = 6 Mandatory

4 Amount Decimal Transaction value to be processed Conditional Note: This is not required for Void / Balance Enquiry transaction types. For all other transaction types this is mandatory.

5 Reference String Merchant supplied reference for the purpose of tracking the transaction. Conditional Note: The requirement of this field will be dependent upon Merchant settings.

6 Original Transaction Decimal ID of the original transaction to be voided.

http://www.showmybalance.com/






ID Conditional Note: This is mandatory for void transactions. For all other transaction types, this field is not to be supplied.

5.3. Barclays Gift Response After receiving and processing the request, the below response message will be returned via integration:

Field Name Type Description 1 Result Code Integer Result of the transaction. Valid values are:

Success = 0 Reversed = 1 Rejected = 2 Error = -ve

2 Response Code String Ok = 0 NoCard = 10 CardValidButNotForThisMerchant = 20 PartialPurchaseTransaction = 30 ExchangeRateNotPresent = 40 MaximumLoadExceeded = 50 MinimumLoadNotMet = 51 MaximumValueOnCardExceeded = 52 CardExpired = 60 MessageTypeInvalid = 71 VoidPeriodElapsed = 72 MessageDetailsIncorrect = 73 InsufficientFunds = 74 CallCallCentre = 99 ConfigurationProblem = -1

3 Transaction Auth Code String Authorisation Code assigned by Card Commerce 4 Amount Decimal Amount of the transaction 5 Remaining Card

Balance Decimal Remaining Balance of the card returned in the transaction response

6 Message String Authorisation message indicating the result of the transaction 7 Message Number String Message number allocated to the transaction by VeriFone 8 Transaction Date/Time String Transaction date/time in the format DD MMM YYYY HH:MM:SS 9 Transaction ID Decimal Transaction ID assigned by VeriFone’s processing system






5.4. Dynamic Currency Conversion (DCC) As companies become increasingly globalised and cheaper travel encourages individuals to travel the world more and more frequently, the need for retailers to increase footfall from international tourists has become more pressing. Dynamic Currency Conversion (DCC), provided by FEXCO, offers retailers the functionality to allow overseas customers to make purchases by Visa and MasterCard in their home billing currency.

DCC enables overseas customers making purchases by Visa and MasterCard the choice to pay in their card billing currency.

The benefits to the Merchant include:

• Creates revenue stream for merchants from foreign exchange • Settlement is in GBP, eliminating the risk of foreign exchange • Eliminates need to display multi-currency pricing

The benefits to Customer include:

• Competitive exchange rates • Provides customers with choice to pay in their own currency, providing transparency and

familiarity • No additional charges

POS Progress Message

This progress message will be returned when processing DCC transaction in Screenless mode where a Continue Message is required.

Field Name Type Description 1 Result Integer This indicates the result code (100) 2 Terminate

Loop Integer Reserved, Ignore

3 Status ID Integer Status ID of the transaction. All responses listed below in separate table 4 Status String This is a text representation of the progress status 5 Parameters String This field will contain any information that the POS may require that is associated

with that status. Each parameter will be ‘;’ delimited and will be defined as follows:

<Name>=<Value> The following Statuses are valid for DCC: MERCHANTTXNVALUE

MERCHANTGRATVALUE

MERCHANTCBVALUE

MERCHANTCHARITYVALUE






MERCHANTTOTALVALUE

MERCHANTCURRENCY

MERCHANTCURRENCYABBR

MERCHANTCURRENCYSYM

CARDHOLDERTXNVALUE

CARDHOLDERGRATVALUE

CARDHOLDERCBVALUE

CARDHOLDERCHARITYVALUE

CARDHOLDERTOTALVALUE

CARDHOLDERCURRENCY

CARDHOLDERCURRENCYABBR

CARDHOLDERCURRENCYSYM

5.5. Givex Givex provides the ability for Merchants to sell and redeem electronic gift cards through multiple sales interfaces and locations. Supplying Gift and Loyalty functionality provides customers with the opportunity to earn rewards that can equate to a future purchase or receive special discounts from promotions.

According to research, increasing customer loyalty drives long-term profitability more than any other strategic factor. It is estimated that companies can boost profits by between 50% by retaining just 5% of their customers (Frederick Reichheld, “The Loyalty Effect”). This is due to the fact that these gift and loyalty cards can increase customer spending by 10%-40%.

Customer loyalty also allows the retailer to build a customer database for effective marketing and enables spending habits to be tracked to develop customer profiles.






5.5.1. Givex Request (GIVEX Record)

Requires Givex Value Add to be enabled

When utilising the Givex value added service, integrated Givex transactions can be automated by the POS using the below request message:

Field Name Type Description 1 Message Identifier String Identifies the type of message. This will always be ‘GIVEX’

Mandatory

2 Transaction Type Integer Indicates the type of Givex transaction to perform. Valid values are: Gift Certificate Register = 904 Gift Certificate Activation = 906 Gift Certificate Increment = 905 Gift Certificate Redemption = 901 Gift Certificate Forced Redemption = 902 Gift Certificate Cash Back = 903 Gift Certificate Forced Cash Back = 919 Gift Certificate Forced Pre Auth = 920 Gift Certificate Post Auth = 921 Gift Certificate Cancel = 907 Gift Certificate Adjustment = 908 Balance Enquiry = 909 Balance Transfer = 910 Points Issuance = 911 Points Redemption = 912 Points Cancel = 913 Cash Out = 915 Mandatory

3 Givex Number String Full Givex number Optional

4 Amount Decimal Transaction value Optional

5 Security Code String Security Code assigned to a customer’s card which can be provided for additional security purposes Optional

6 Auth Code String Authorisation Code assigned to a transaction. Conditional Notes: The Authorisation Code is only required when adding Gratuity to a transaction or when performing a Gift Certificate Cancel

7 Units Int64 This field can contain a numeric value for any purpose as determined by the Merchant, it could be the number of items in the sale or the number of points to be assigned for the sale Optional

8 Promotion Code String Reserved for future use 9 Points Int64 Number of points added as a result of the current transaction

Optional

10 Givex Number To String Full Givex number to transfer Balance/Points to






Conditional Notes: Required for Balance Transfer transaction types

11 Reference String Reference associated with the transaction, supplied by the Merchant Optional

5.5.2. Givex Response

After having received and processed the request message, Sentinel will return a response message detailing the below information:

Field Name Type Description 1 Result Integer Givex transaction status

-99 – Transaction Cancelled 0 – Pending 1 – Authorised 2 – Completed 3 – Error 4 – Reversed 5 – Declined -ve – Error codes defined within Appendix B

2 Result Message String Message to provide a text representation of the transaction result 3 Transaction Type Integer Indicates the type of Givex transaction which was performed 4 Auth Code String Authorisation Code assigned to the transaction 5 Cert Balance String Balance of the Certificate 6 Expiry Date String Expiry date of the card/certificate 7 Security Code String Security code of the card/certificate 8 Amount String Transaction value for the transaction processed 9 Givex Number String Masked version of the Givex Number 10 Points String Number of points given to this transaction 11 Points Balance String Points balance of the card 12 First Name String First Name of the cardholder 13 Middle Name String Middle Name of the cardholder 14 Surname String Surname of the cardholder 15 Points Auth Code

From String When performing a balance transfer, the auth code assigned to the

card which the balance has been transferred from 16 Points Auth Code To String When performing a balance transfer, the auth code assigned to the

card which the balance has been transferred to 17 Cert Auth Code From String When performing a balance transfer, the auth code assigned to the

certificate which the balance has been transferred from 18 Cert Auth Code To String When performing a balance transfer, the auth code assigned to the

certificate which the balance has been transferred to 19 Cash Out ID String Number assigned to a batch of transactions after a close request 20 Transaction ID Decimal Unique Givex transaction ID

5.6. M-Voucher Mobile vouchers (M-Vouchers) are a development of existing mobile phone technology and retail POS systems to transmit, receive, store and redeem retail vouchers via SMS (text) message. The system also allows for MMS (Multi-Media or Picture messaging) and future support for NFC (Near-Field Communication), contactless style voucher transmission.

The vouchers have numerous marketing applications and provide the first true step into the field of stored value mobile purses and interactive mobile marketing.






Consumers may respond to a “call to action”, following instructions via a more traditional advertising medium such as print or television, to “text” into a service in order to receive their promotional voucher. Alternatively, voucher codes can also be sent to consumers whose details have previously been collected by another means and as such are already recorded within the retailers own marketing database.

The consumer then receives a text message containing a unique ID voucher code, with the message also containing personal or promotional details and redemption instructions.

The relevant retail outlet is then visited by the consumer and they pay for the item using the M-Voucher, redeeming the discount offered in the advertisement.

The M-Voucher scheme is a real-time solution supported by VeriFone’s ICP Managed Service. The M-Voucher service is provided by Eagle Eye Solutions.

5.6.1. M-Voucher Request (M Record)

Requires M-Voucher Value Add to be enabled

When utilising the M-Voucher value added service, integrated M-Voucher transactions can be automated by the POS using the below request message:

Field Name Type Description 1 Message Identifier String This identifies the type of message. ‘M’ is used to signify a M-Voucher

transaction type. 2 Account ID Decimal

Mandatory This identifies the M-Voucher Account to use

3 Voucher Number String (20) This is the voucher number supplied by the customer Mandatory for Redemption Entry Type Dependent for Verification & Creation For verification & creation transactions, if the entry type is set to keyed – customer, the terminal will prompt for the voucher number irrespective of whether this field is populated. For any other entry types, this field is mandatory.

4 Transaction Type Integer This is the type of transaction being performed. Allowed values are: LITE = 1 STANDARD = 2 This will always be set to ‘STANDARD’ Mandatory

5 Message Type Integer Mandatory

This identifies the transaction being performed. Allowed values are: LITE = 1 VERIFY = 2 REDEEM = 3 CREATE = 4 CANCEL = 5 In the VeriFone implementation ‘LITE’ will never be used. ‘CANCEL’ is a VeriFone internal processing option and will not be available from an






integration perspective Mandatory

6 Entry Type Integer This identifies how the customer specific details were captured Allowed values are: KEYED – CUSTOMER = 1 KEYED – OPERATOR = 2 SCANNED = 3 NFC = 4 In the VeriFone implementation, ‘SCANNED’ and ‘NFC’ will never be used. Mandatory

7 Voucher Details String This is the details of the voucher(s) to be redeemed. Each voucher detail record will be pipe (|) separated. Mandatory for Redemption & Creation

The voucher details section supports the provision of multiple voucher details records. This functionality is supported for redemption transactions; however, when creating a voucher, the POS must only supply one record in this field.

5.6.2. M-Voucher Details

The Voucher Details component of the integration record will consist of the following semi colon (;) delimited fields.

Field Name Type Description 1 Voucher ID String (20)

This is a unique ID identifying the M-Voucher. Mandatory for Redemption

2 Discount Value Integer Max=1000000

The value of the discount to be applied per item Mandatory for Redemption & Creation

3 Usage Integer (4) The number of distinct times the product / product group should be present for qualifying usage in the rule. If the usage returned as part of the verification result is 0 then populate this field with 1. Mandatory for Redemption & Creation For creation transactions pass in a value of 1.

4 Voucher Target Type Integer

This indicates the target of the voucher being created. Valid values are: 0 = Not Set 1 = POS 2 = SMS Mandatory for Creation For all other transaction types set the value to 0.

5 Mobile Number String (20) This is the mobile number to be supplied with the voucher creation request. This must either be supplied with the leading zero (e.g. 079xxxxxxxx) or with the country identifier (e.g. +4479xxxxxxxx)






Mandatory for Creation when Voucher Target Type = 2

5.6.3. M-Voucher Response

After receiving and processing the request message, Sentinel will respond with a message containing the following information:

Field Name Type Description 1 M-Voucher Transaction

ID Decimal This is the unique ID of the transaction as allocated by VeriFone

2 Auth Result String (20) This is the result of the authorisation. Allowed values are: VERIFIED REDEEMED ISSUED ERROR

3 Auth ID Integer (2) If an error response is returned in the Auth Result field, this field will detail the error code relating to the error

4 Voucher Number String (20) This is the voucher number delivered to the consumer 5 Campaign ID Int64 This is the ID of the campaign that the vouchers belong to 6 Reference ID String (50) This is a unique ID of the transaction 7 Voucher Details String This is the details of the voucher(s) that relate to the supplied

voucher number. Each voucher detail record will be pipe (|) separated.

8 Error Message String This field will return description of the error message.

Voucher Details

The Voucher Details component of the integration record will consist of the following semi colon (;) delimited fields.

Field Name Type Description 1 Voucher ID Int64 This is a unique ID identifying the M-Voucher 2 Type Integer (2) This is the required voucher type returned by M-Voucher 3 Reference ID String (50) This is the Reference ID of the voucher, returned by M-Voucher 4 Discount Type String (5) This is the type of discount to be applied, returned from M-

Voucher 5 Discount Value Decimal

Max=1000000 The value of the discount to be applied per item

6 Usage Integer (4) The number of distinct times the product / product group should be present for qualifying usage in the rule

7 Min Spend Integer (4) This is the minimum spend for the voucher to apply, returned by M-Voucher

8 Description String (50) This is the description of the voucher as returned by M-Voucher 9 Voucher Target Type Integer This indicates the target of the voucher being created.

Valid values are: 1 = POS 2 = SMS

10 Mobile Number String (20) If the voucher target type is set to 2 (SMS), this is the mobile number that the voucher was issued to.






5.7. Flexecash (Park Retail) Flexecash (previously known as Park Retail) is a prepaid high street gift card service, provided by Park Group PLC. The prepaid gift card allows consumers to do their shopping keeping to a pre-determined budget without the need to carry cash.

The functionality is provided in both standalone and integrated modes, with integration records included later on within this document. Screenless mode is also supported, allowing Sentinel to return progress messages information the POS of the state of the transaction.

Flexecash amount validation ensures both Ceiling and Floor limits are correctly processed, i.e. via integration if the amount returned is outside the allowed limits then the operator will be informed and transaction cancelled. However, for manual transaction; an amount between the two limits will be required in order to continue.

5.7.1. Flexecash Request (PRG Record)

Requires Flexecash Value Add to be enabled

When utilising the Flexecash value added service, integrated Flexecash transactions can be automated by the POS using the request message detailed below.

Field Name Type Description 1 Message Type String This will always be PRG 2 Transaction Type Integer This is the type of transaction to process.

Accepted values are: 0 = Sale 1 = Refund 2 = Balance Enquiry This field is mandatory. If it is not present the record will be rejected

3 Transaction Amount Decimal This will be the full transaction amount including the decimal place i.e. 10.00. If the Transaction value is not supplied as part of the integration record then PAYware Ocius will reject the integration record

4 Merchant Reference String The Merchant reference is dependent upon the configuration. If the reference is optional and not provided then the request will be processed without a reference. If the reference is required and one is not provided the integrated request will be rejected

5 Account ID Decimal This is the Account ID of the required account for processing. If not supplied and only one account is present this will be selected automatically, otherwise the request will be rejected

Example: PRG,1,50.00,Test1,12345678






5.7.2. Flexecash Response

The response message returned after processing an integrated Flexecash transaction will conform to the following formats dependent upon which Flexecash integration version is configured within the Program Settings file:

Version 1 Response

Field Name Type Description 1 Result Code String This is the result code as returned by Flexecash or set by VeriFone.

Authorised = 0 please see below Acquirer Response Code table for possible results.

2 VeriFone Error Code String This is the error code if the transaction has encountered an error. Please see Sentinel standard VeriFone Error Codes

3 Transaction Value Decimal This is the value of the transaction processed including the decimal place

4 Starred PAN String This is the starred PAN used for processing only showing the last 4 digits

5 Expiry Date String This is the expiry date of the card processed 6 Transaction Date Time String This is the date time of the transaction in the format of DD MMM

YYYY HH:MM:SS e.g. 10 Jun 2011 11:39:06 7 MID String This is the MID (Card Acceptor Number) used for processing 8 TID String This is the TID assigned to the transaction 9 Message ID String This is the internal ID assigned to the authorisation request 10 Merchant Reference String This is the Merchant reference if supplied by the Merchant 11 Account ID Decimal This is the Account ID that the transaction was process under

Example: 0,0,10.00,***************0325,1212,10 Jun 2011 11:39:06,365678,4380001,754,Test1,12345678

Version 2 Response

Field Name Type Description 1 Result Code String This is the result code as returned by Flexecash or set by VeriFone.

Authorised = 0 please see below Acquirer Response Code table for possible results.

2 VeriFone Error Code String This is the error code if the transaction has encountered an error. Please see Sentinel standard VeriFone Error Codes

3 Transaction Value Decimal This is the value of the transaction processed including the decimal place

4 Starred PAN String This is the starred PAN used for processing only showing the last 4 digits

5 Expiry Date String This is the expiry date of the card processed 6 Transaction Date Time String This is the date time of the transaction in the format of DD MMM

YYYY HH:MM:SS e.g. 10 Jun 2011 11:39:06 7 MID String This is the MID (Card Acceptor Number) used for processing 8 TID String This is the TID assigned to the transaction 9 Message ID String This is the internal ID assigned to the authorisation request 10 Authorisation Code String This is the authorisation code returned for the transaction request 11 Merchant Reference String This is the Merchant reference if supplied by the Merchant 12 Account ID Decimal This is the Account ID that the transaction was process under

Example: 0,,50.00,***************0325,1212,10 Jun 2011 11:38:01,00365678,04380001,753,549976,Test1,12345678

Acquirer Response Codes






Code ISO Meaning Action Applicable To Message

-1 Not Set Decline Sale Authorisation, Reversal, Balance Enquiry

00 Confirmed Accept Sale Authorisation “Auth Code: xxxxxx Bal: £xxx.xx”

Reversal “Completed Bal: £xxx.xx”

Balance Enquiry “Bal: £xxx.xx”

01 Transaction Failed Decline Sale Authorisation, Reversal, Balance Enquiry

02 System Unavailable Decline Sale Authorisation, Reversal, Balance Enquiry

03 Reversed Reversal

05 Do Not Honour Decline Sale Authorisation, Reversal, Balance Enquiry

“Declined”

12 Invalid Transaction Decline Sale Authorisation, Reversal, Balance Enquiry

“Invalid Transaction”

14 Invalid Card Number Decline Sale Authorisation, Reversal, Balance Enquiry

“Not Authorised”

30 Format Error Decline Sale Authorisation, Reversal, Balance Enquiry

“Format Error”

41 Lost or Stolen Decline Sale Authorisation, Balance Enquiry

“Not Authorised Lost Card”

51 Not Sufficient Funds Decline Sale Authorisation “Insufficient Funds Bal: £xxx.xx”

54 Expired Decline Sale Authorisation, Balance Enquiry

“Declined Expired”

62 Restricted Decline Sale Authorisation, Balance Enquiry

“Card Not Accepted”

96 System Malfunction Decline Sale Authorisation, Reversal, Balance Enquiry

“System Error”

99 VeriFone Error Decline Sale Authorisation, Reversal, Balance Enquiry






5.8. PayPoint To provide the ability to process E-Card and E-Voucher topups, VeriFone supports PayPoint transactions with Sentinel. Via either standalone, integrated or screenless transactions; PayPoint add E-TopUp capabilities to a merchant site. A host of network operators are available; along with BT Bill Payments, which allows cardholders to pay for their BT line using their BT account card.

Please note that when installing the software with the intention of utilising the PayPoint functionality on the Sentinel version that the Microsoft .NET Framework version will need to be V3.5.

The PayPoint transaction is processed independently of any EFT processing to collect payment. VeriFone recommend that payment is collected prior to the PayPoint transaction, or that the two are linked together via integration to form one process.

The integration process for PayPoint should be built using the PayPoint specific XML files within the Sentinel directory. This will ensure that the integration is dynamic and should there be any changes within these configuration files that the integration will be automatically updated should all the available schemes be accepted by the merchant.

5.8.1. PayPoint Request (PPOINT Record)

Requires PayPoint Value Add to be enabled

Please note: when utilising the PayPoint value added service, the .NET Framework version utilised on each machine where Sentinel is installed must be V3.5.

When utilising the PayPoint value added service, integrated PayPoint transactions can be automated by the POS using the request message detailed below.

The Service User, Scheme ID and available top up amounts for each scheme should be dynamically sourced from the PayPoint XML files which are stored within the Sentinel directory once PayPoint has been enabled on the merchant system. These files contain information on the following elements of a PayPoint transaction:

• Amount Top up value available for an option

• Option Each network provider has different voucher options available for purchase, e.g. text packs or voice packs. Each pack has different options available which are usually different prices. An option would be ‘£5 Text Pack’.

• Service User Service user is the name given refer to a network operator (e.g. BT, O2, Vodafone)

• Scheme The type of voucher pack required, e.g. BT Pay & Call, Pay As You Go, Top Up Voucher, Text Pack.

The files downloaded which should be used to build the request messages are:






• PayPointOptionAmounts.xml Provides a list of the top up amounts available for each option.

• PayPointSchemeDetails.xml Provides details for each scheme, e.g. currency (‘978’ Irish, ‘826’ UK), scheme name, min/max/lowest denomination.

• PayPointSchemeOptions.xml Provides breakdown of the options for each scheme which are available.

• PayPointServiceUsers.xml Provides a breakdown of the service user name for each service user ID.

After deciding which schemes are to be supported, the integration should build the request messages using the information from these XML. Avoiding hard coding these values will also ensure that should the PayPoint files be updated that no integration changes are required to add new schemes.

Field Name Type Description 1 Message Identifier String This is identifies the type of message. This will always be ‘PPOINT’ 2 Account ID Decimal

Optional This is the PayPoint Account ID to process the transaction under.

3 Transaction Type Integer This indicates the type of transaction to perform. Valid values are: Sale = 1 Refund = 2 Mandatory

4 Top-Up Type Integer Mandatory

This indicates the type of top-up to perform. Valid values are: E-Card = 1 E-Voucher = 2

5 Service User Integer This is the Service User ID for the operator required. Mandatory for E-Voucher transactions Not required for E-Card transactions

6 Scheme Detail ID Integer This is the Scheme Detail ID required, this information can be found in the ‘PayPointSchemeDetails.xml’ in the Sentinel directory. Please note that these need to be matched to the correct Service User. Mandatory for E-Voucher transactions Not required for E-Card transactions

7 Amount Decimal Mandatory

This is the value of the transaction being performed.

8 Merchant Reference String Conditional

This is a merchant allocated reference to aid identifying the transaction.

9 Capture Method Integer Optional

EFT Capture Method indicating how the card details were obtained. This is to be populated when supplying the card number via integration. Accepted values: Keyed Cardholder Present = 1 Swiped = 3

10 Card Number String Conditional

The card number to be supplied via integration, the format of which is dependent upon the capture method. When the Capture Method is Keyed CP (1), supply the full card number. When the Capture Method is Swiped (3), supply the track2 data obtained by swiping the card.

11 Expiry Date Integer Expiry date of the PayPoint card.






Conditional Conditionally required, if the E-Card details are supplied and an expiry date is required by the card

5.8.2. PayPoint Response

The response message returned after processing an integrated PayPoint transaction will conform to the following format:

Field Name Type Description 1 Result Integer This is the result of the transaction. Valid values are:

-ve = VeriFone Error Code

Confirmed = 0 Transaction Failed = 1 Declined = 2 System Unavailable = 3 Reversed = 4

2 Transaction Date / Time String This is the date / time that the transaction was started on the terminal. This will be in the format: DD MMM YYYY HH:MM:SS

3 Service User Name String This is the operator as defined in the PayPoint scheme specification.

4 Scheme Name String This is the scheme name as defined in the PayPoint scheme specification.

5 Capture Method Integer This indicates how the card details were captured. Valid values are the following subset from the values acceptable for the standard transaction capture method: Keyed Cardholder Present = 1 Swiped = 3

6 Response Outcome Message String This will be either the response outcome message returned by PayPoint or will be a textual description of the VeriFone Error






5.9. Stored Value Solutions (SVS) Stored Value Solutions provide prepaid services to merchants. VeriFone support SVS’ branded prepaid cards which are used to:

• Reward and incentivise employees, customers, and partners • Improve foot traffic to your locations • Increase brand awareness • Facilitate new promotional and co-branding opportunities • Allow easy gift card acceptance across multiple point-of-sale systems

Prepaid cards are accepted the same way as any standard electronic funds transfer card through VeriFone’s PAYware Ocius platform.

Integration records are provided within this manual, allowing the merchant to utilise the functionality integrated into the POS, or in standalone mode without integration in place.

Store ID

Each terminal/installation needs to be linked to the correct SVS Merchant Store; this will ensure that the correct configuration details are downloaded with the accounts files.

To support merchants utilising Sentinel and to avoid the need for manual intervention to link the Sentinel PTID to a merchant store, the Login Record includes an optional 5th field in which to supply the Store ID. When this information reaches the VeriFone Server, the PTID is automatically linked to the Merchant Store.

5.9.1. SVS Request (SVS Record)

To support integrated Stored Value Solution transactions a comma delimited integration record must be supplied, conforming to the below format:

Field Name Type Description 1 Message Type String This field will always be set to SVS. 2 Transaction Type Integer Valid values are:

Balance Enquiry 0 *Pre-Authorization 1 Redemption 2 *Tip 3 Cancellation 4 Return 5 Card Reload 6 *Pre-Auth Completion 7 *Activate Card 8 Issue Card 9 *Issue Virtual Card 10 *Reversal 11 *Network Message 12 Cash Out 13 [* = reserved for future use]

3 Amount Decimal The amount of the SVS transaction 4 Account ID String The SVS Account under which the transaction is to be processed 5 STAN String Systems Trace Audit Number






6 Reference String Reference supplied by the merchant

Example record:

SVS,9,1.00,10459,123456,Test






5.9.2. SVS Response

Upon completion of the SVS transaction the terminal will provide the POS with a comma delimited message in the below format:

Field Name Type Length (Max)

Description

1 Response Code String 3 SVS response codes: None 0 Approved 1 Card Inactive 2 Invalid Card Number 3 Invalid Transaction Code 4 Insufficient Funds 5 No Previous Transaction 6 Invalid Message 7 No Card Found 8 Insufficient Funds Pre-Auth 9 Denial No Previous Auth 10 Exceeded Maximum Single Reloads 13 Exceeded Max Balance 14 Shut Down 15 Invalid Card Status 16 Unknown Store Number 17 Exceeded Max Reloads 18 Invalid Verification Value 19 Invalid Pin Number 20 Card Already Issued 21 Card Not Issued 22 Card Already Used 23 Manual Transaction Not Allowed 24 Invalid Magnetic Read 25 Unknown Transaction Type 26 Invalid Tender Type 27 Invalid Customer Type 28 Pin Locked 29 Exceeded Maximum Redemptions 30 Invalid Currency Code 31 Invalid Server ID 32 Frozen 33 Invalid Amount 34 Application Error -1 Cancelled -99

2 Amount String 8 Value of the transaction 3 Balance String 8 Value of the card balance 4 Currency Code String 4 Standard accepted alpha code of the currency (e.g. GBP) 5 Conversion Rate String 8 Conversion rate between merchant and cardholder currencies 6 Masked PAN String 20 Masked Card number used in the transaction 7 STAN String 6 Systems Trace Audit Number 8 Message String Variable Text returned by SVS host server

Example record: 01,0.00,39.99,GBP,1.00000,***************4179,110009,Approval






5.10. Transax SV (Stored Value) Transax SV is a value added service provided by FIS. It can be integrated into merchant’s existing retail payment systems to provide a Gift Card programme.

The following functionality is supported:

• Balance Enquiry • Load/activate • Refund • Sale • Top-up

Gift Cards can be used for a range of retail sales and marketing applications including savings schemes, insurance claim schemes, promotions and staff incentives.

Duplication Checking

As potential communication and technical issues may cause duplicate transactions to be requested, the Transax SV Host comprises a Duplicate Checking Mechanism to ensure that cards are only debited or credited once for each genuine transaction performed at the Point of Sale.

When the host receives a new transaction for a card, it retrieves the previous (last) transaction to carry out a comparison check between the two (current and previous) transactions, to ensure they are not duplicates.

There are two flavours of duplicate handling provided by Transax SV:

• If the merchant is supplying a Unique Merchant Reference (UMR) for every transaction, where this reference matches the reference for the previous transaction on the same card and the transaction amount, transaction type and merchant number all match then the latest transaction will be considered a duplicate and the result of the previous transaction will be returned

• If no UMR is provided for each transaction; where the transaction amount, transaction type and merchant number all match then if the two transactions are within X minutes (where X is the duplicate window in minutes set on the Transax SV host on a card scheme level) of each other then the latest transaction will be considered a duplicate and the result of the previous transaction will be returned

If merchants do not wish for this duplication checking to be in place, then the duplication window should be configured with Transax SV to be ‘0’ and no UMR should be supplied with each transaction.






5.10.1. Transax SV Request (TSV Record)

To support integrated Transax SV requests, a comma delimited integration record must be supplied, conforming to the below format:

Field Name Type Description 1 Record Type String This is always set to:

TSV Mandatory

2 Account ID Decimal This is the Account ID to identify the required account for processing Mandatory

3 Transaction Type Integer This is the Transax SV Transaction type. Valid values are: Load / Activate = 1 Top-Up = 2 Sale (Debit) = 3 Balance Enquiry = 4 Refund = 5 Mandatory

4 Cardholder Not Present

Boolean This determines if a Cardholder Present or Cardholder Not Present transaction is required. Valid Values are: 0 = Cardholder Present 1 = Cardholder Not Present Mandatory

5 Amount Decimal This is the amount for the transaction. Mandatory Note: For Balance Enquiries this must be set to 0.01

6 Reference String This indicates the unique Merchant Reference Conditional Note: The requirement for this is deemed by the account. This is either enabled or disabled. If disabled and supplied it will be ignored. If enabled and not supplied the transaction will be rejected

Examples:

TSV,1,1,0,10.00,TEST






POS Progress Message

This progress message will be returned when processing Transax SV transaction in Screenless mode where a Continue Message is required.

Field Name Type Description 1 Result Integer This indicates the result code (100) 2 Terminate Loop Integer Reserved, Ignore 3 Status ID Integer Status ID of the transaction.

The following Statuses are valid for Transax SV: 149 = Account Extraction Failed 150 = Amount Outside Allowed Range 151 = Enter Amount 152 = Confirm Authorisation 153 = Card Expired 154 = Transax SV Initialisation Failed 155 = Transax SV Initialising 156 = Invalid Account 157 = Invalid Capture Method 158 = Invalid Card Number 159 = Invalid Configuration 160 = Invalid Expiry Date 161 = Invalid Track 2 Format 162 = Invalid Transaction Type 163 = Keyed Entry Not Allowed 164 = No Accounts 165 = Card Scheme Not Recognised 166 = Transaction Type Not Allowed 167 = Transax SV Service Unavailable 168 = Invalid Issue Number 169 = Invalid Card Security Code 170 = Confirmation Failed 171 = Printing Receipt

4 Status String This is a text representation of the progress status 5 Parameters String This field will contain any information that the POS may require that is

associated with that status. There are no parameters associated with the status messages applicable for Transax SV (listed above) specific processing.






Continue Message

After receiving a Progress Message, the transaction will not progress until the correct Continue Transaction Message is returned.

With the Transax SV functionality, a continune transaction message with an Action ID of one of the below must be returned. This infroms the terminal of the tranasction value to proceed with:

Field Name Type Description 1 Message Type String CONTTXN 2 Action ID Integer This is the required action to perform.

For Transax SV, the action required is either: 2 = Continue Transaction 3 = Confirm Transaction 4 = Reject Signature 5 = Re-Print 20 = Confirm Transaction 21 = Reject Transaction

3 Parameters String This field will contain any information that the POS may require that is associated with that status. There are no parameters associated with the action IDs applicable for Transax SV (listed above) specific processing






5.10.2. Transax SV Response

Upon completion of the Transax transaction the solution will provide the POS with a comma delimited message in the below format:

Field Name Type Description 1 Result Code Integer This is the result of the transaction. Valid values are:

0 = Authorised 1 = Declined 2 = Reversed -ve = VeriFone Error

2 Response Code String This is the Acquirer Response Code. Valid values are: 00 = Authorised 05 = Declined

3 Auth code String This is the authorisation code 4 Amount Decimal This is the amount for the transaction 5 Balance Decimal This is the remaining card balance 6 Message String This is the message from the authorisation host 7 Transaction ID Decimal This is the Transaction ID supplied by the VeriFone processing system 8 Message Number String This is the message number for processed transaction 9 MID String This is the MID for the account used to process the transaction 10 TID String This is the TID assigned to the transaction for processing

Example message:

0,00,12345,10.00,40.00,AUTHORISED,999999,123,123456,01230123






5.1. Pennies The Pennies Foundation has created Pennies, the electronic charity box. Pennies is designed to make giving to charity easy, quick and affordable. It’s new, inclusive and will raise additional money for many UK registered charities.

With one touch of a button shoppers can choose to donate a few pennies in private when they pay by debit card, credit card or electronically. Merchants can configure the functionality to either round up to the nearest adjustment value (e.g. the nearest £1) or top up according to the adjustment value (e.g. top up by £1). The adjustment value is configured on the merchant account.

All the pennies are then added together and all of the money that’s been collected is given to UK charities, both big and small.

Pennies are powerful – a few pennies a month from many people add up to millions of pounds. It would take just 8 pence a week (just over £4 a year) from half of the UK’s card-holders to raise £89 million a year.






6. Additional Functionalities Sentinel provides additional functionality which is detailed within this section.

For further information on any of the additional functionality supplied merchants should consult their Account Manager.

6.1. Discretional Data Sentinel supports the ability to capture data from the track1 “discretional data” field. This allows for additional information stored on the card within this field to be returned to the merchant via integration messages. This field is often used for retailer specific data, often in conjunction with large retailers such as loyalty card data.

The merchant will need to be integrated to Sentinel and the feature enabled within the merchant system. The integration output field can be enabled by configuring the Integration Version to ‘5’ as advised within section 8.4 Integration Version, which will ensure that as part of an integrated solution that the data is returned within the 34th field of the transaction response.

6.2. External Hashing Sentinel provides an External Hashing process whereby merchants are provided with a unique identifier for each payment card that is processed, which can be safely stored within the Merchant’s own systems without risk of data compromise.

This is often referred to as ‘Tokenisation’, but VeriFone use the term ‘(External) Hashing’ to avoid confusion with the ‘Account On File’ feature which provides merchants with Token IDs to reference card details stored within VeriFone’s infrastructure.

VeriFone’s External Hashing functionality converts the payment card number (PAN) into a one-way hash value – a form of data encryption. This SHA-256 hash value returned via integration is a base64 encoded binary which cannot be reverse engineered to reveal the card number it represents. This hash value will be returned in the transaction output record produced by Sentinel, within field 32 of the Transaction Response Record and will require base64 decoding before producing a 32 byte string.

The hash is generated by the PED and should be base64 decoded before being stored by the merchant.

This value is unique per card number and can be stored by the merchant in order facilitate searching for transactions with which that card was processed.

Should the external hash not be stored routinely by the merchant or in the scenario whereby a cardholder contacts the merchant and the hash value is not available; WebCom does contain the functionality to convert the PAN into its equivalent hash representation.






6.3. Get Card Details Should the merchant require the ability to obtain details from the card prior to onward processing, the Get Card Details functionality can be utilised via integration record.

The request must define if the card is EFT or non-EFT (e.g. loyalty card, gift card) and the response will define the card number (masked for EFT cards and in full for non-EFT) as well as the card scheme name and a hashed version of the card number for secure storage.

An alternative to this approach may be the Transaction Value Modification feature.

6.3.1. Get Card Details Request (GDET Record)

In order to retrieve the details of the card provided, Sentinel supports the Get Card Details request record:

Field Name Type Description 1 Message Identifier String This is identifies the type of message. This will always be ‘GDET’ 2 Operation Mode Integer This identifies what type of card details to retrieve. Valid values are:

‘0’ – Non-EFT ‘1’ – EFT

3 Remove Card Setting Integer This indicates whether the card removal processing should be performed or not. Valid values are: ‘0’ – Don’t Remove Card ‘1’ – Remove Card

4 POS Version Integer Optional

This indicates if the Hashed Card Number is to be returned. Accepted values are: Standard Version = 0 Version 1 = 1 This field is optional and does not have to be present. In the event that this field is not present fields 1 through 3 of the output response will be returned as normal, this is the same when the POS Version is set to 0. If the POS Version is set to 1 then the Hashed Card Number will be returned to the POS in field 4 of the response

6.3.2. Get Card Details Response

Once the request has been received and processed by Sentinel, the PED will request the card is inserted/swiped and will respond with a message containing the below information:

Field Name Type Description 1 Result Integer This identifies the result of the processing. Valid values are:

‘0’ – Success ‘-4’ – Card Not Recognised ‘-5’ – EFT Card Presented For Non-EFT Operation Mode or Non-EFT Card Presented For EFT Operation Mode ‘-12’ – Invalid Record ‘-30’ – Processing Failed ‘-70’ – Operation Mode Not Supported ‘-85’ – User Not Logged In ‘-90’ – Service Not Allowed ‘-99’ – Retrieval Cancelled ‘-135’ – Timeout Waiting For Card






The error codes correspond to standard VeriFone Error Codes. 2 Card Data String For EFT identified cards, this will be the starred card number where all

digits bar the first 6 are starred. For Non-EFT cards, this will be the full track 2.

3 Scheme Name String For EFT identified cards, this is the name as stored against the IIN table. 4 Hash String

(base64-encoded binary)

The SHA-256 hash of the PAN, with salt to ensure that the same PAN gives a different hash for different merchants.






6.4. PAN Masking With the settings file of Sentinel it is possible to enable or disable the ‘StarOutIIN’ setting which controls how the PAN is masked when being returned to the POS via integration message.

When this setting is enabled, the last four digits only of the PAN are returned (e.g. *********3123). When disabled, the PAN will be masked apart from the first six and last four digits (e.g. 492912***3123).

6.5. PED Version Mapping In order to supply the ability to define which version of the Sentinel POS software should be utilised with specific version of the PED Sentinel software, the ‘PED Version Mapping’ functionality has been created.

Within WebCom, a section has been provided to allow a merchant to create a table which maps Sentinel POS and PED versions together.

Once this mapping has been created within WebCom, each time a PED validation is performed (typically during registration and when performing a configuration download), Sentinel will compare the POS version to the information stored within the ICP Managed Service and ensure that any PED version mappings are adhered to. Should the PED version need updating, then a software update will be sent to the PED and installed. If no PED Version Mapping exists then Sentinel will progress as standard.

6.6. Procurement Card Processing For merchants requiring the ability to process corporate purchasing cards, VeriFone has developed a Procurement Card Specification which is documented separately.

This functionality can be supported via integration with Sentinel, providing the ability for Procurement Card Data to be submitted to VeriFone via the transaction request message. This message format is documented within the aforementioned procurement card specification.

The Integration Version for Sentinel will need to be set to ‘Version 4’ to ensure that the VGIS reference is returned via integration within the transaction response message.






6.7. Transaction Value Modification As part of a transaction process it is feasible that the merchant will need to apply a discount to the initial transaction value.

This functionality must be enabled on the terminal and will result in a change to the standard processing flow, described below:

1. Transaction initiated using standard transaction request message (“T Record”), with a nominal dummy value, e.g. £1

2. PAYware Ocius prompts for Card Entry

3. PAYware Ocius reads and hashes the card details

4. POS Progress message returned detailing the card hash and card type

5. POS uses information as required for perform lookups/additional processing

6. POS returns a “CONTTXN” message to proceed with transaction processing, including any discounts required

7. PAYware Ocius updates the value and proceeds with standard transaction processing

This functionality could be viewed as an alternative to the Get Card Details feature.






6.8. Card Wait The Card Wait functionality has been introduced to provide additional integration flexibility for merchants.

The functionality allows for the integration to place Sentinel in a wait state, prior to processing a transaction, ready for a card to be presented. Once a card is presented and read by the PED, the card details are returned to the POS and based upon this information a decision on how to continue to be made.

The card details presented are securely stored within the PED and should the merchant decide to proceed with a transaction after receiving the response from the card wait record (CARDWAIT message type), then the card initially presented will not need to be re-inserted/swiped.

After the result from the card wait record has been returned to the POS, Sentinel will close the socket connection. A new socket connection will be required to instruct any of the following:

• Cancel the Card Wait state (CANCELCARDWAIT) • Proceed with one of the following transaction types, utilising the store card details:

o Barclays Gift transaction (BGIFT) o EFT transaction (T Record) o Flexecash Gift transaction (PRG) o PayPoint transaction (PPOINT) o SVS transaction (SVS)

• Request the last message be resent • Screen position change (SCRPOS) • Send a request for information command (REQINFO) • Window state (WINSTATE)

Should a Cancel Card Wait request be sent to PAYware Ocius, all securely stored card details are removed from the PED, before returning to the PAYware Ocius Main Menu.

Please note: By default, the Card Wait response message will define the Capture Method as “ICC Unknown”. This is due to the fact that the data is only being read from the card at this stage and no Cardholder Verification Method is required until a transaction is processed using the card.

6.8.1. Card Wait Request (CARDWAIT Record)

As discussed, the Card Wait functionality allows for PAYware Ocius to be placed in a wait for card state. Details of the card presented are returned to the POS, allowing merchants to decide upon a final transaction value (in case discounts are to be applied according to which card type is presented for example) and if they wish to proceed with a transaction as a result.

The request message should adhere to the following format:

Field Name Type Description






1 Message Identifier String Mandatory

This identifies the type of message. This will always be ‘CARDWAIT’

2 Header String Optional

This is the header text to display on the PED when it prompts for the card details to be presented. To indicate that the section should be left empty, supply the following: <Blank> An empty field indicates that the terminal should display its standard data within this section

3 Body String Optional

This is the body text to display on the PED when it prompts for the card details to be presented. To indicate that the section should be left empty, supply the following: <Blank> An empty field indicates that the terminal should display its standard data within this section

4 Footer String Optional

This is the footer text to display on the PED when it prompts for the card details to be presented. To indicate that the section should be left empty, supply the following: <Blank> An empty field indicates that the terminal should display its standard data within this section

5 Wait for Card Timeout3 Integer Optional

This is the time in seconds for the PED to wait for the card details to be presented. This value must be greater than or equal to 0 and must be less than or equal to the maximum value allowed for a 32-bit integer – 10 seconds when expressed in milliseconds (i.e. 2147483 seconds / 24 days). A value of 0 means do not timeout4. Default: 0

6 Allowed Capture Methods

String Optional

This is a hex bitmap of the capture methods that the PED is to allow. The hex bitmap is comprised of the following hex values:- Keyed = 01 Swipe = 02 ICC = 04 Reserved = 08 Default: ICC + Swipe + Keyed = 07

7 Allowed Fallback String This is a hex bitmap of the fallback methods that the PED is to

3 PAYware Ocius will timeout 10 seconds after this timeout to try to ensure that the PED times out before PAYware Ocius does. This is similar to the wait for card timeout employed by standard transaction processing. Also, the timeout is referenced against either the time that the request was sent to the PED or the last PED message received, whichever is the latter. 4 PAYware Ocius will treat a value of zero for the wait for card timeout to be 2147463647 milliseconds (24 days)






Methods Optional allow. The hex bitmap is comprised of the following hex values:- Fallback from ICC to Swipe = 01 Fallback from Swipe to Key = 02 Default: Fallback from ICC to Swipe + Fallback from Swipe to Key = 03

Example record:

CARDWAIT,Welcome to The Shop,Please Present Card,Thank You,0,07,03

6.8.2. Card Wait Cancel Request (CANCELCARDWAIT Record)

In order to cancel a Card Wait request, the below message should be sent to PAYware Ocius:

Field Name Type Description 1 Message Identifier String

Mandatory This is identifies the type of message. This will always be ‘CANCELCARDWAIT’

The Card Wait Cancel request response will follow the same format as defined within the Card Wait Response.

The CANCELCARDWAIT command will be dependent on two scenarios; whether PAYware Ocius is still waiting for the card details or is in the “Wait for Card” transaction mode.

• If PAYware Ocius is still waiting for the card details, the Card Wait Cancel command must be sent down the existing socket connection (similar to the continue transaction commands). This is to allow other client connections to process a request.

• If PAYware Ocius is in the “Wait for Card” transaction mode, the original socket connection will no longer be available.






6.8.3. Card Wait Response

The result of the card wait request will follow the below format:

Field Name Type Description 1 Result Integer This indicates the result of the Wait for Card request

Valid values are:- Success = 0 Error = -ve The likely error codes are: -99 = Cancelled 135 = Wait for card timed out

2 Card Type Integer This indicates the type of card that was captured. Valid values are:- -1 = Not Recognised 0 = EFT 1 = Barclays Gift 2 = GiveX 3 = PayPoint 4 = SVS 5 = PayZone ETU 6 = Nectar 7 = ChockStone 8 = Ukash 9 = Flexecash 10 = Merchant Specific Card Type 11 = Merchant Specific Card Type Default: Not Recognised = -1

3 Track2 String This is the full track2 data of the non-EFT card. 4 PAN String For Standard EFT cards this will be the starred PAN using either the

“all starred bar the first 6 and last 4” formatting or the “all starred bar the last 4” formatting as determined by configuration. For non-Standard EFT cards, which are identified as allowing the full PAN to be returned, this will be the full PAN. For non-EFT cards, this will be the full PAN.

5 Expiry Date / Application Expiration Date

String This is the EFT card’s expiry date / application expiration date in the format MMYY, if applicable. For non-EFT cards, this field will not be returned.

6 Start Date / Application Effective Date

String This is the EFT card’s start date / application effective date in the format MMYY, if applicable For non-EFT cards, this field will not be returned.

7 Issue Number / Application Sequence Number

String This is the EFT card’s issue number / application sequence number, if applicable

8 Scheme Name String This is the scheme name as identified from the relevant IIN table entry used to identify the card

9 Capture Method Integer This identifies the method used to capture the card details. Valid values are:- Not Set = 0 Keyed Cardholder Present = 1 Keyed Cardholder Not Present (Mail Order) = 2 Swiped = 3






ICC Fallback To Swipe = 4 ICC Fallback To Signature = 5 ICC PIN Only = 6 ICC PIN And Signature = 7 ICC No CVM = 8 Contactless EMV = 9 Contactless Magswipe = 10 Keyed Cardholder Not Present (Telephone Order) = 11 Keyed Cardholder Not Present (E-Commerce) = 12 ICC Unknown = 13 Keyed Cardholder Not Present (Account On File) = 14

10 Hash String This is a SHA-256 hash of the PAN with a merchant specific salt 11 Track1 String This is the full track1 data of the non-EFT crad.






6.9. Contactless Payments

In order to process contactless transactions with Sentinel; a contactless enabled device is required. The VX 820 PIN pad supports contactless transactions through an integrated contactless module for EFT transactions. The feature offers on-screen tap zone (CTLS logo) on the PED for optimised user experience and accepts EMV and mag-stripe contactless payments as well as PIN-based transactions. The PED only becomes active for contactless smart card transactions when enabled on the PIN pad.

Provided the total transaction amount is less than the value of £20.00, a contactless payment can be used. If the amount is over £20.00* in value, then the sale becomes a standard Chip and PIN transaction.

Please note: The contactless functionality is optional and only available if configured at merchant account level. For more details, please speak to your Account Manager.

To perform a contactless transaction, please follow the below instructions:

1. Gently tap the card on the contactless logo on the screen

2. An activated LED visual on the display followed by a short beeping sound indicates a successful transaction

Please note this functionality is optional; to take advantage of this functionality it must be enabled at merchant account level. For more details, please contact your Account Manager.

* The value of £20 is subject to change in accordance with scheme rules.






6.10. On Hold Transaction The On Hold Transaction functionality provides merchants with the ability to place transactions on hold and release once the transaction is complete from a merchant’s perspective.

In order to achieve this, the functionality will be provided via integration, and will solely be driven by the POS.

When processing a “Release On Hold Transaction” request, Sentinel acts as a message processing service; translating and forwarding the request to the VeriFone hosted infrastructure, obtaining the response, translating it, and then sending the translated response back to the POS.

The integration command can only be processed when Sentinel is logged in and idle.

Functionality Limitations

The On Hold Transaction functionality is not supported for accounts that are configured to make use of nursery submissions and terminal initiated end of day submissions. These are designated by having one of the following EOD statuses:-

• ‘M’ – Account level EOD • ‘T’ – Terminal level EOD

6.10.1. On Hold Transaction Request

The request message type requires the message type set to ‘RELEASEONHOLDREQUEST’.

Field Name Type/Format Description Message Identifier String This will always be ONHOLDTXN Authorisation Server String (50) This is the authorisation server / database that processed the

EFT transaction Transaction ID Decimal This is the transaction ID (mkTransactionID) of the EFT

transaction Place on Hold Boolean This indicates that the transaction should be put on hold rather

than releasing it






6.10.2. On Hold Transaction Response

This message is generated when the VeriFone hosted infrastructure has successfully been able to process the request message.

The message type will be set to ‘RELEASEONHOLDRESPONSE’.

Field Name Type/Format Description Result Integer This indicates the result of the request.

Valid values are:- 0 = Released 1 = On hold -ve = Error as defined in VeriFone error code list Examples: -12 when the message format is invalid -31 when Ocius is not idle or Ocius is already processing a message for another client -85 when Ocius is not logged in -87 when Ocius fails to send the request to the VeriFone hosted infrastructure -139 when the communications to the VeriFone hosted infrastructure times out -185 when an unexpected response or error response is returned by the VeriFone hosted infrastructure

Message String Text representation of the result

Example Records:

On Hold Transaction:

Request: ONHOLDTXN,Authserver,0123456,1,

Response: 1,Transaction Placed On Hold

Release Transaction:

Request: ONHOLDTXN,Authserver,0123456,0,

Response: 0,Transaction Released






6.10.3. Examples

The following examples illustrate xml messages used for On Hold Transaction request and response messages:

Request Message:

<?xml version="1.0"?> <releaseonholdrequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="ONHOLD"> <mktransactionid>...</mktransactionid> <authdb>...</authdb> <uniquestring>...</uniquestring> <placeonhold>...</placeonhold> </releaseonholdrequest>

Response Message:

<releaseonholdresponse xmlns="ONHOLD"> <result>...</result> <mktransactionid>...</mktransactionid> <authdb>...</authdb> </releaseonholdresponse>






7. Offline Functionality and Floor Limits If no Floor Limits are configured then Sentinel will voice refer all offline keyed and swiped for transactions. For ICC transactions the decision to allow the transaction to be processed offline is controlled by the chip on the card. There will be instances whereby the card does not allow the transaction to be authorised and this will result in the transaction being declined as opposed to voice referred. Voice referral due to being in offline mode (or Comms Down, see below) is not supported in Sentinel.

There are options available with PAYware Ocius to add a level of control when faced with this situation. These options are provided by floor limits, which can be configured on the merchant system (which will apply to each and every merchant account within that merchant system), and these are explained in more detail within the next two sections.

There are no floor limits configured by default with Sentinel, and any floor limit being added should be carefully considered and approved by the acquiring bank.

7.1. EMV Floor Limit

Sentinel has a configurable EMV Floor Limit, whereby all transactions below the configured value inform the card that an attempt to authorise offline is being made prior to any communication attempt (i.e. before authorisation online is attempted). The card may choose to accept, decline or force the transaction online. The EMV floor limit is only used at the 1st generate stage of a transaction. It is just one factor taken into consideration as to whether the card can authorise the transaction offline or requires it to be sent online to the acquirer or the card issuer.

In the event that there is a communication issue and the card instructs the terminal to authorise online, in most cases this is expected to result in a Decline or Voice Referral outcome.

This is not a suitable solution to the majority of merchants due to the fact that transactions authorised offline in this manner carry greater risk and therefore higher merchant fees. This is unnecessary in the event that communications are available, which would mean that online authorisation was available and carry a lower merchant fee due to the cardholder being verified. Most of the current VeriFone merchant base has this floor limit set to ‘0.00’ (zero) and it is always VeriFone’s recommendation that this floor limit is set to zero. The merchant’s acquirer is required to approve a floor limit of any value other than zero.

Please note: VeriFone requires a copy of this agreement before the EMV Floor Limit can be enabled on an account.






7.2. Voice Referral Floor Limit The Voice Referral floor limit will come into effect after any EMV Floor Limit in place has been checked.

ICC Transactions

The Voice Referral floor limit does not apply to ICC transactions.

For Keyed and Swiped Transactions

In the event that Sentinel cannot communicate with the VeriFone Managed Service or if Sentinel receives a ‘Comms Down’ response from the VeriFone Managed Service, it will request manual authorisation of the transaction by performing a voice referral. In this scenario, the voice referral floor limit, if configured on the merchant system, will be taken into account to determine how the voice referral is processed.

If the transaction value is less than the Offline Voice Referral floor limit then the transaction will be authorised locally, supplying the authorisation code agreed between the merchant and acquirer and stipulated on the signed agreement between the two parties.

7.3. Post Comms Floor Limit & Stand-In Authorisation Permission from the acquirer is required before enabling this feature.

Please note: VeriFone requires a copy of this agreement before the Post Comms floor limit can be enabled on an account.

The Post Comms floor limit applies to ICC transactions only.

The Post Comms floor limit allows the merchant to configure an authorisation floor limit that is taken into consideration after communication to authorise the transaction online with the acquirer has been attempted and cannot be successfully completed. Sentinel will make use of this floor limit for ICC transactions if either Sentinel cannot communicate with, times out waiting for the authorisation response from, or receives a Comms Down response from the VeriFone Managed Service. Unlike the EMV floor limit, it is not taken into consideration before the authorisation stage of the transaction, only being utilised in these specific scenarios.

A merchant can have an EMV floor limit and a Post Comms floor limit configured. In this setup, any card approved offline at the 1st card action analysis will remain as approved offline as the Post Comms floor limit does not apply in this scenario.

If the PAYware Ocius setup is configured with a Post Comms floor limit, and the transaction value is above the Post Comms floor limit, the terminal will implement the new higher value of the floor limit. The terminal then proceeds with the 2nd Card Action Analysis, informing the card that a communications failure occurred. The chip on the card utilises this information to make a final decision on whether to authorise or decline the transaction. It is still possible for transactions to be rejected in this scenario due to the card overriding the authorisation within the 2nd Card Action Analysis stage of the EMV Transaction Flow.






If the PAYware Ocius setup is configured with a Post Comms floor limit, and the transaction value is below the Post Comms floor limit Sentinel will determine whether it can stand-in for the issuer and attempt to accept transactions up to that floor limit that do not have a TVR (Transaction Verification Result) value which indicates a reason that the transaction should be declined. This process is automatically handled by Sentinel and is at the card acceptor (merchant)’s risk. If the card acceptor does not wish to take this risk, the Post Comms floor limit should be set to zero.

Should a ‘Comms Fail’ authorisation result be received from the hosted service or Sentinel falls back to offline mode due to failure to successfully communicate to the hosted service, then the following transaction flow will be adopted, dependent upon the transaction value:

1. If the total transaction value (inclusive of any gratuity and cashback) is below or equal to the Post Comms floor limit:

a. If the TVR indicates a reason that the transaction should be declined (see Decline Conditions), Sentinel will inform the PED that the transaction should be declined

b. If the TVR does not indicate a reason that the transaction should be declined, Sentinel will inform the PED that the transaction should be authorised, i.e. that the decision has been made by the Card Acceptor (Merchant) to authorise the transaction.

2. If the total transaction value is above the Post Comms floor limit, the 2nd Card Action Analysis will be advised by the terminal that there was a communications failure. This stage of the transaction process will then provide an authorised or decline result, as decided by the chip.

It is possible that the 2nd Card Action Analysis (also known as “2nd Generate”) could still decide to decline the transaction even if the transaction value is below the Post Comms floor limit and stand-in authorisation is configured; however, this is understood to be an unlikely outcome.






Decline Conditions

Should any of the elements listed below in the TVR breakdown be set, then the transaction will decline:

• Combined DDA / Gen AC failed • Off-line DDA failed • Card on hot list • ICC data missing • SDA failed • Off-line data authentication not performed • Requested service not allowed for card product • Application not yet effective • Expired application • PIN try limit exceeded • Cardholder verification unsuccessful • Card acceptor forced on-line (i.e. suspicious) • Upper consecutive off-line limit exceeded






7.4. Offline Transaction Specifics Offline Transactions are processed when Sentinel:

• Is unable to contact the VeriFone central servers • Receives a Comms Down result • Times out waiting for a response from the acquirer

In these scenarios, the offline transactions are stored in the PED.

If unable to contact the VeriFone central servers, Sentinel will return an offline token in the T-record response if token registration is performed. The EFTSN placed in the receipt is prefixed with OL.

If able to contact the VeriFone central servers but receives a Comms Down result or times out waiting for a response from the acquirer, Sentinel will return an online token in the T-record response if token registration is performed. The EFTSN placed in the receipt is prefixed with OL.

The PED has storage limits depend on the type of PED in use and its capacity. There is storage for over 300 transactions on the PED. When the storage capacity of the PED is reached no further offline transactions can be run. After this transaction limit is reached, no further transactions can be stored on the PED and offline transactions will fail to complete.

When Sentinel next connects to the VeriFone central severs (at the logon or the next transaction any offline transactions present in the PED are transferred to the VeriFone central server.

Offline transactions which are processed when Sentinel is able to contact the VeriFone central servers but the VeriFone central servers not able to reach the Acquirer are stored in the PED.

Sentinel will return an online token in the T-record response if token registration is performed. The EFTSN placed in the receipt is prefixed with OL.

7.5. Offline Hash Generation

Some merchants will store the VeriFone hashed version (SHA-256) of the card number returned via integration when configured to the appropriate Integration Version.

Customer specific hashes, when used, are amalgamated with the generic VeriFone hash by Sentinel and returned to the merchant via integration.

VeriFone’s SHA-256 hashed version of the card number is 32 bytes in length (after base64 decoding). In a scenario when a customer specific hash is also produced, this will be returned within the same hash field of the integration response. The customer specific hash will follow the SHA-256, 32 byte hash, without any separator in place within the field between the two hashes.






Hash representations of card numbers are generated by the PED and returned via integration. When Sentinel is offline, the generic VeriFone (SHA-256) hash is still returned via integration as it is generated of the PED and not by the VeriFone Servers.

7.6. Example EFT Scenarios In the below scenarios, the following floor limits are configured:

• EMV Floor Limit £0.00 • Voice Referral Floor Limit £100.00 • Post Comms floor limit £200.00 • Transaction Value £150.00

Here are four example scenarios to demonstrate the offline processing and floor limits described. In each of the examples below, a token registration has been performed as part of the transaction in order to also provide examples of how tokens are handled online/offline:

a) Sentinel cannot reach VeriFone servers. Swiped Transaction for £150.00

As this is a Swiped Transaction the Voice Referral Floor Limit applies. As the transaction is above the Voice Referral Floor Limit, the transaction is prompted for Voice Referral.

As Sentinel cannot reach the VeriFone server, the T-record returns an offline token.

The SHA-256 hash representation of the card number is returned via integration after being generated by the PED; this process is unaffected by being offline to the VeriFone servers.

The transaction is stored in the PED for later transmission to the Sentinel Server.

b) Sentinel cannot reach VeriFone servers. ICC Transaction for £150.00

As this is an ICC transactions and a Post Comms floor limit has been specified, the Post Comms floor limit applies. As the transaction is below the Post Comms floor limit, the transaction is processed by the Stand-In Authorisation. If the card allows, authorisation of the transaction will be attempted by Sentinel.

As Sentinel cannot reach the VeriFone server, the T-record returns an offline token.

The SHA-256 hash representation of the card number is returned via integration after being generated by the PED; this process is unaffected by being offline to the VeriFone servers.


c) Sentinel can reach VeriFone servers. VeriFone servers cannot reach Acquirer. Swiped Transaction for £150.00

As this is a Swiped Transaction the Voice Referral Floor Limit applies. As the transaction is above the Voice Referral Floor Limit, the transaction is prompted for Voice Referral.

As Sentinel can reach the VeriFone server, the T-record returns an online token.






The SHA-256 hash representation of the card number is returned via integration after being generated by the PED.

The transaction is stored in the PED for later transmission to VeriFone’s central servers.

d) Sentinel can reach VeriFone servers. VeriFone servers cannot reach Acquirer. ICC Transaction for £150.00

As this is an ICC transactions and a Post Comms floor limit has been specified, the Post Comms floor limit applies. As the transaction is below the Post Comms floor limit, the transaction is processed by the Stand-In Authorisation. If the card allows, the transaction will be authorised by Sentinel.

As Sentinel can reach the VeriFone server, the T-record returns an online token.

The SHA-256 hash representation of the card number is returned via integration after being generated by the PED.


e) Sentinel cannot reach the VeriFone servers. CARDWAIT request

No floor limits are applied during the CARDWAIT process; the card presented is read and its details returned to the POS via integration without authorisation being sought from the acquirer.

One of the fields returned within the CARDWAIT response message is the hash representation of the card. The SHA-256 hash representation of the card number is returned via integration after being generated by the PED. This process is unaffected by being offline to the VeriFone servers.






7.7. SVS Offline Functionality When processing an SVS transaction, if Sentinel goes offline then this could be for two reasons:

a) Sentinel is unable to connect to VeriFone’s central servers Sentinel will attempt to connect to the central server 3 times (not configurable) before falling back to Offline mode, and therefore initiating the IVR process In this scenario, an error message of ‘-99,Tranasction Cancelled’ will be returned to the POS

b) Sentinel can connect to VeriFone’s central servers but the SVS Host System is unavailable In this scenario, Sentinel will wait for a response for the period of time defined within the ‘AuthTimeout’ setting within the Program Settings file (by default 60 seconds) before timing out waiting for a response and informing the POS of this timeout transaction outcome. In this scenario, an error message of ‘-181,Host Unavailable’ will be returned to the POS

When an SVS transaction is attempted but a timeout is experienced, the VeriFone central servers will initiate and handle the reversal process with the SVS host; ensuring that any transactions which are not completed are reversed. VeriFone’s central servers have a 45 second timeout period which is not configurable.

Any transactions which fail due to a timeout should be re-processed using the IVR functionality.

7.7.1. SVS Reversal Processing

As aforementioned, VeriFone’s central servers handle the reversal process on behalf of the merchant; attempting to reverse any transactions, which are not completed within the timeout period, with the SVS host.

The process is as follows:

• SVS request message sent from Sentinel and inserted into the relevant database • Database passes SVS request message to the SVS server application within the

VeriFone central infrastructure. A timeout is initiated at this point of 45 seconds • SVS server application communicates with the SVS host to attempt to process the

request o If the SVS server application fails to return a response to the database within the

45 second timeout period, then the transaction is deleted from the database and a reversal request passed to the SVS server application to send to the SVS host. Sentinel is simultaneously informed that the transaction has timed out

• The SVS server application updates the database with the response from the SVS host on receipt of the information

o At this stage of the transaction, the database’s 45 second timeout period is restarted as an update to the transaction has been received

• The database passes the transaction result back to Sentinel via the SVS response message

• Sentinel acknowledges to the database that it has received the transaction result message, which initiates the SVS transaction being confirmed






• On receipt of the confirmation request, the SVS transaction is completed on the database and the SVS transaction removed from the processing queue to ensure that transaction is not reversed by the 45 timeout period expiring

o If the database fails to receive a confirmation request from Sentinel within the 45 second timeout period, then the transaction is deleted from the database and a reversal request passed to the SVS server application to send to the SVS host

When a reversal is attempted, the same number of connection attempts is applicable as with standard processing. The SVS server application will attempt to connect to the SVS host 3 times in order to send the reversal, before returning a result to the VeriFone database.

7.8. Transax Offline Functionality

When processing a Transax transaction, if Sentinel is unable to connect to the VeriFone central servers it will attempt to connect 3 times (not configurable), with a timeout of 60 seconds on each attempt, before falling back to offline processing, via IVR. However, if receiving an error response to the initial Transax Request then Sentinel will not retry to connect.

Should Sentinel be able to connect to the VeriFone central servers but be unable to reach the Transax host then it will retry up to 3 times (not configurable), with the transaction timing out if exceeding 45 seconds.

7.9. Automatic Return Online Functionality When Sentinel returns to the main menu screen; if it is offline it enables an offline timer. An offline timer, when enabled performs a check every 10 minutes to see if it can go back to an online state. If Sentinel is returned to an online state, it will perform an offline transaction submission attempt. If Sentinel is still offline, the timer gets restarted.

The timer gets stopped if Sentinel leaves the main menu screen or if it is processing the timer elapsed event.






APPENDIX

Contact Details

VeriFone 100 Eureka Park

Upper Pemberton Road Ashford, Kent

TN25 4AZ

Main Tel: 08444 828200

Main Fax: 08444 828210

Merchant Helpdesk: 08444 828222

Merchant Helpdesk Fax: 08444 828223

Implementations: 08444 828273

Email: Sales Enquiries [email protected]

Merchant Helpdesk [email protected] (For live queries)

Implementation Enquiries [email protected] (For test queries)

Website: www.VeriFone.com

mailto:[email protected]

mailto:[email protected]

http://www.commidea.com/






Currency Code ISO 4217 Currency Code Num Locations using this currency Afghani AFN 971 Afghanistan Algerian dinar DZD 012 Algeria Argentine peso ARS 032 Argentina Armenian dram AMD 051 Armenia Aruban guilder AWG 533 Aruba Australian dollar AUD 036 Australia, Australian Antarctic Territory, Christmas Island,

Cocos (Keeling) Islands, Heard and McDonald Islands, Kiribati, Nauru, Norfolk Island, Tuvalu

Azerbaijanian manat AZN 944 Azerbaijan Bahamian dollar BSD 044 Bahamas Bahraini dinar BHD 048 Bahrain Baht THB 764 Thailand Balboa PAB 590 Panama Bangladeshi taka BDT 050 Bangladesh Barbados dollar BBD 052 Barbados Belarusian ruble BYR 974 Belarus Belize dollar BZD 084 Belize Bermudian dollar (customarily known as Bermuda dollar)

BMD 060 Bermuda

Bolivian Mvdol (funds code) BOV 984 Bolivia Boliviano BOB 068 Bolivia Brazilian real BRL 986 Brazil Brunei dollar BND 096 Brunei, Singapore Bulgarian lev BGN 975 Bulgaria Burundian franc BIF 108 Burundi Canadian dollar CAD 124 Canada Cape Verde escudo CVE 132 Cape Verde Cayman Islands dollar KYD 136 Cayman Islands Cedi GHS 936 Ghana CFA Franc BCEAO XOF 952 Benin, Burkina Faso, Côte d'Ivoire, Guinea-Bissau, Mali,

Niger, Senegal, Togo CFA franc BEAC XAF 950 Cameroon, Central African Republic, Congo, Chad,

Equatorial Guinea, Gabon CFP franc XPF 953 French Polynesia, New Caledonia, Wallis and Futuna Chilean peso CLP 152 Chile Chinese Yuan CNY 156 China (Mainland) Code reserved for testing purposes

XTS 963

Colombian peso COP 170 Colombia Comoro franc KMF 174 Comoros Convertible marks BAM 977 Bosnia and Herzegovina Cordoba oro NIO 558 Nicaragua Costa Rican colon CRC 188 Costa Rica Croatian kuna HRK 191 Croatia Cuban convertible peso CUC 931 Cuba Cuban peso CUP 192 Cuba Czech Koruna CZK 203 Czech Republic Dalasi GMD 270 Gambia Danish krone DKK 208 Denmark, Faroe Islands, Greenland Denar MKD 807 Macedonia Djibouti franc DJF 262 Djibouti Dobra STD 678 São Tomé and Príncipe Dominican peso DOP 214 Dominican Republic East Caribbean dollar XCD 951 Anguilla, Antigua and Barbuda, Dominica, Grenada,

Montserrat, Saint Kitts and Nevis, Saint Lucia, Saint Vincent and the Grenadines

Egyptian pound EGP 818 Egypt Ethiopian birr ETB 230 Ethiopia Euro EUR 978 Austria, Belgium, Cyprus, Finland, France, Germany,






Greece, Ireland, Italy, Luxembourg, Malta, Netherlands, Portugal, Slovakia, Slovenia, Spain, Andorra, Kosovo, Monaco, Montenegro, San Marino, Vatican

European Composite Unit (EURCO) (bond market unit)

XBA 955

European Monetary Unit (E.M.U.-6) (bond market unit)

XBB 956

European Unit of Account 17 (E.U.A.-17) (bond market unit)

XBD 958

European Unit of Account 9 (E.U.A.-9) (bond market unit)

XBC 957

Falkland Islands pound FKP 238 Falkland Islands Fiji dollar FJD 242 Fiji Forint HUF 348 Hungary Franc Congolais CDF 976 Democratic Republic of Congo Gibraltar pound GIP 292 Gibraltar Gold (one troy ounce) XAU 959 Guarani PYG 600 Paraguay Guinea franc GNF 324 Guinea Guyana dollar GYD 328 Guyana Haiti gourde HTG 332 Haiti Hong Kong dollar HKD 344 Hong Kong Special Administrative Region Hryvnia UAH 980 Ukraine Iceland krona ISK 352 Iceland Indian rupee INR 356 Bhutan, India Iranian rial IRR 364 Iran Iraqi dinar IQD 368 Iraq Israeli new sheqel ILS 376 Israel Jamaican dollar JMD 388 Jamaica Japanese yen JPY 392 Japan Jordanian dinar JOD 400 Jordan Kenyan shilling KES 404 Kenya Kina PGK 598 Papua New Guinea Kip LAK 418 Laos Kroon EEK 233 Estonia Kuwaiti dinar KWD 414 Kuwait Kwacha MWK 454 Malawi Kwacha ZMK 894 Zambia Kwanza AOA 973 Angola Kyat MMK 104 Myanmar Lari GEL 981 Georgia Latvian lats LVL 428 Latvia Lebanese pound LBP 422 Lebanon Lek ALL 008 Albania Lempira HNL 340 Honduras Leone SLL 694 Sierra Leone Lesotho loti LSL 426 Lesotho Liberian dollar LRD 430 Liberia Libyan dinar LYD 434 Libya Lilangeni SZL 748 Swaziland Lithuanian litas LTL 440 Lithuania Malagasy ariary MGA 969 Madagascar Malaysian ringgit MYR 458 Malaysia Manat TMT 934 Turkmenistan Mauritius rupee MUR 480 Mauritius Metical MZN 943 Mozambique Mexican peso MXN 484 Mexico Mexican Unidad de Inversion (UDI) (funds code)

MXV 979 Mexico

Moldovan leu MDL 498 Moldova Moroccan dirham MAD 504 Morocco, Western Sahara






Naira NGN 566 Nigeria Nakfa ERN 232 Eritrea Namibian dollar NAD 516 Namibia Nepalese rupee NPR 524 Nepal Netherlands Antillean guilder ANG 532 Netherlands Antilles New Taiwan dollar TWD 901 Taiwan and other islands that are under the effective

control of the Republic of China (ROC) New Zealand dollar NZD 554 Cook Islands, New Zealand, Niue, Pitcairn, Tokelau Ngultrum BTN 064 Bhutan No currency XXX 999 North Korean won KPW 408 North Korea Norwegian krone NOK 578 Norway, Bouvet Island, Queen Maud Land, Peter I Island Nuevo sol PEN 604 Peru Ouguiya MRO 478 Mauritania Pa'anga TOP 776 Tonga Pakistan rupee PKR 586 Pakistan Palladium (one troy ounce) XPD 964 Pataca MOP 446 Macau Special Administrative Region Peso Uruguayo UYU 858 Uruguay Philippine peso PHP 608 Philippines Platinum (one troy ounce) XPT 962 Pound sterling GBP 826 United Kingdom, Crown Dependencies (the Isle of Man and

the Channel Islands), certain British Overseas Territories (South Georgia and the South Sandwich Islands, British Antarctic Territory and British Indian Ocean Territory)

Pula BWP 072 Botswana Qatari rial QAR 634 Qatar Quetzal GTQ 320 Guatemala Rial Omani OMR 512 Oman Riel KHR 116 Cambodia Romanian new leu RON 946 Romania Rufiyaa MVR 462 Maldives Rupiah IDR 360 Indonesia Russian rouble RUB 643 Russia, Abkhazia, South Ossetia Rwanda franc RWF 646 Rwanda Saint Helena pound SHP 654 Saint Helena Samoan tala WST 882 Samoa Saudi riyal SAR 682 Saudi Arabia Serbian dinar RSD 941 Serbia Seychelles rupee SCR 690 Seychelles Silver (one troy ounce) XAG 961 Singapore dollar SGD 702 Singapore, Brunei Solomon Islands dollar SBD 090 Solomon Islands Som KGS 417 Kyrgyzstan Somali shilling SOS 706 Somalia Somoni TJS 972 Tajikistan South African rand ZAR 710 South Africa South Korean won KRW 410 South Korea Special Drawing Rights XDR 960 International Monetary Fund Sri Lanka rupee LKR 144 Sri Lanka Sudanese pound SDG 938 Sudan Surinam dollar SRD 968 Suriname Swedish krona/kronor SEK 752 Sweden Swiss franc CHF 756 Switzerland, Liechtenstein Syrian pound SYP 760 Syria Tanzanian shilling TZS 834 Tanzania Tenge KZT 398 Kazakhstan Trinidad and Tobago dollar TTD 780 Trinidad and Tobago Tugrik MNT 496 Mongolia Tunisian dinar TND 788 Tunisia Turkish lira TRY 949 Turkey, Northern Cyprus Uganda shilling UGX 800 Uganda






UIC franc (special settlement currency)

XFU Nil International Union of Railways

Unidad de Fomento (funds code)

CLF 990 Chile

Unidad de Valor Real COU 970 Colombia United Arab Emirates dirham AED 784 United Arab Emirates United States dollar (next day) (funds code)

USN 997 United States

United States dollar (same day) (funds code) (one source[who?] claims it is no longer used, but it is still on the ISO 4217-MA list)

USS 998 United States

US dollar USD 840 American Samoa, British Indian Ocean Territory, Ecuador, El Salvador, Guam, Haiti, Marshall Islands, Micronesia, Northern Mariana Islands, Palau, Panama, Puerto Rico, Timor-Leste, Turks and Caicos Islands, United States, Virgin Islands, Bermuda (as well as Bermudian Dollar)

Uzbekistan som UZS 860 Uzbekistan Vatu VUV 548 Vanuatu Venezuelan bolívar fuerte VEF 937 Venezuela Vietnamese đồng VND 704 Vietnam WIR euro (complementary currency)

CHE 947 Switzerland

WIR franc (complementary currency)

CHW 948 Switzerland

Yemeni rial YER 886 Yemen Zimbabwe dollar ZWL 932 Zimbabwe Złoty PLN 985 Poland






Country Codes ISO 3166 Official country names used by the ISO 3166/MA Numeric Alpha-3 Alpha-2 Afghanistan 004 AFG AF Åland Islands 248 ALA AX Albania 008 ALB AL Algeria 012 DZA DZ American Samoa 016 ASM AS Andorra 020 AND AD Angola 024 AGO AO Anguilla 660 AIA AI Antarctica 010 ATA AQ Antigua and Barbuda 028 ATG AG Argentina 032 ARG AR Armenia 051 ARM AM Aruba 533 ABW AW Australia 036 AUS AU Austria 040 AUT AT Azerbaijan 031 AZE AZ Bahamas 044 BHS BS Bahrain 048 BHR BH Bangladesh 050 BGD BD Barbados 052 BRB BB Belarus 112 BLR BY Belgium 056 BEL BE Belize 084 BLZ BZ Benin 204 BEN BJ Bermuda 060 BMU BM Bhutan 064 BTN BT Bolivia 068 BOL BO Bosnia and Herzegovina 070 BIH BA Botswana 072 BWA BW Bouvet Island 074 BVT BV Brazil 076 BRA BR British Indian Ocean Territory 086 IOT IO Brunei Darussalam 096 BRN BN Bulgaria 100 BGR BG Burkina Faso 854 BFA BF Burundi 108 BDI BI Cambodia 116 KHM KH Cameroon 120 CMR CM Canada 124 CAN CA Cape Verde 132 CPV CV Cayman Islands 136 CYM KY Central African Republic 140 CAF CF Chad 148 TCD TD Chile 152 CHL CL China 156 CHN CN Christmas Island 162 CXR CX Cocos (Keeling) Islands 166 CCK CC Colombia 170 COL CO Comoros 174 COM KM Congo 178 COG CG Congo, Democratic Republic of the 180 COD CD Cook Islands 184 COK CK Costa Rica 188 CRI CR Côte d'Ivoire 384 CIV CI Croatia 191 HRV HR Cuba 192 CUB CU Cyprus 196 CYP CY Czech Republic 203 CZE CZ Denmark 208 DNK DK






Djibouti 262 DJI DJ Dominica 212 DMA DM Dominican Republic 214 DOM DO Ecuador 218 ECU EC Egypt 818 EGY EG El Salvador 222 SLV SV Equatorial Guinea 226 GNQ GQ Eritrea 232 ERI ER Estonia 233 EST EE Ethiopia 231 ETH ET Falkland Islands (Malvinas) 238 FLK FK Faroe Islands 234 FRO FO Fiji 242 FJI FJ Finland 246 FIN FI France 250 FRA FR French Guiana 254 GUF GF French Polynesia 258 PYF PF French Southern Territories 260 ATF TF Gabon 266 GAB GA Gambia 270 GMB GM Georgia 268 GEO GE Germany 276 DEU DE Ghana 288 GHA GH Gibraltar 292 GIB GI Greece 300 GRC GR Greenland 304 GRL GL Grenada 308 GRD GD Guadeloupe 312 GLP GP Guam 316 GUM GU Guatemala 320 GTM GT Guernsey 831 GGY GG Guinea 324 GIN GN Guinea-Bissau 624 GNB GW Guyana 328 GUY GY Haiti 332 HTI HT Heard Island and McDonald Islands 334 HMD HM Holy See (Vatican City State) 336 VAT VA Honduras 340 HND HN Hong Kong 344 HKG HK Hungary 348 HUN HU Iceland 352 ISL IS India 356 IND IN Indonesia 360 IDN ID Iran, Islamic Republic of 364 IRN IR Iraq 368 IRQ IQ Ireland 372 IRL IE Isle of Man 833 IMN IM Israel 376 ISR IL Italy 380 ITA IT Jamaica 388 JAM JM Japan 392 JPN JP Jersey 832 JEY JE Jordan 400 JOR JO Kazakhstan 398 KAZ KZ Kenya 404 KEN KE Kiribati 296 KIR KI Korea, Democratic People's Republic of 408 PRK KP Korea, Republic of 410 KOR KR Kuwait 414 KWT KW Kyrgyzstan 417 KGZ KG Lao People's Democratic Republic 418 LAO LA Latvia 428 LVA LV






Lebanon 422 LBN LB Lesotho 426 LSO LS Liberia 430 LBR LR Libyan Arab Jamahiriya 434 LBY LY Liechtenstein 438 LIE LI Lithuania 440 LTU LT Luxembourg 442 LUX LU Macao 446 MAC MO Macedonia, the former Yugoslav Republic of 807 MKD MK Madagascar 450 MDG MG Malawi 454 MWI MW Malaysia 458 MYS MY Maldives 462 MDV MV Mali 466 MLI ML Malta 470 MLT MT Marshall Islands 584 MHL MH Martinique 474 MTQ MQ Mauritania 478 MRT MR Mauritius 480 MUS MU Mayotte 175 MYT YT Mexico 484 MEX MX Micronesia, Federated States of 583 FSM FM Moldova, Republic of 498 MDA MD Monaco 492 MCO MC Mongolia 496 MNG MN Montenegro 499 MNE ME Montserrat 500 MSR MS Morocco 504 MAR MA Mozambique 508 MOZ MZ Myanmar 104 MMR MM Namibia 516 NAM NA Nauru 520 NRU NR Nepal 524 NPL NP Netherlands 528 NLD NL Netherlands Antilles 530 ANT AN New Caledonia 540 NCL NC New Zealand 554 NZL NZ Nicaragua 558 NIC NI Niger 562 NER NE Nigeria 566 NGA NG Niue 570 NIU NU Norfolk Island 574 NFK NF Northern Mariana Islands 580 MNP MP Norway 578 NOR NO Oman 512 OMN OM Pakistan 586 PAK PK Palau 585 PLW PW Palestinian Territory, Occupied 275 PSE PS Panama 591 PAN PA Papua New Guinea 598 PNG PG Paraguay 600 PRY PY Peru 604 PER PE Philippines 608 PHL PH Pitcairn 612 PCN PN Poland 616 POL PL Portugal 620 PRT PT Puerto Rico 630 PRI PR Qatar 634 QAT QA Réunion 638 REU RE Romania 642 ROU RO Russian Federation 643 RUS RU Rwanda 646 RWA RW






Saint Helena 654 SHN SH Saint Kitts and Nevis 659 KNA KN Saint Lucia 662 LCA LC Saint Pierre and Miquelon 666 SPM PM Saint Vincent and the Grenadines 670 VCT VC Samoa 882 WSM WS San Marino 674 SMR SM São Tomé and Príncipe 678 STP ST Saudi Arabia 682 SAU SA Senegal 686 SEN SN Serbia 688 SRB RS Seychelles 690 SYC SC Sierra Leone 694 SLE SL Singapore 702 SGP SG Slovakia 703 SVK SK Slovenia 705 SVN SI Solomon Islands 090 SLB SB Somalia 706 SOM SO South Africa 710 ZAF ZA South Georgia and the South Sandwich Islands 239 SGS GS Spain 724 ESP ES Sri Lanka 144 LKA LK Sudan 736 SDN SD Suriname 740 SUR SR Svalbard and Jan Mayen 744 SJM SJ Swaziland 748 SWZ SZ Sweden 752 SWE SE Switzerland 756 CHE CH Syrian Arab Republic 760 SYR SY Taiwan, Province of China 158 TWN TW Tajikistan 762 TJK TJ Tanzania, United Republic of 834 TZA TZ Thailand 764 THA TH Timor-Leste 626 TLS TL Togo 768 TGO TG Tokelau 772 TKL TK Tonga 776 TON TO Trinidad and Tobago 780 TTO TT Tunisia 788 TUN TN Turkey 792 TUR TR Turkmenistan 795 TKM TM Turks and Caicos Islands 796 TCA TC Tuvalu 798 TUV TV Uganda 800 UGA UG Ukraine 804 UKR UA United Arab Emirates 784 ARE AE United Kingdom 826 GBR GB United States 840 USA US United States Minor Outlying Islands 581 UMI UM Uruguay 858 URY UY Uzbekistan 860 UZB UZ Vanuatu 548 VUT VU Venezuela 862 VEN VE Viet Nam 704 VNM VN Virgin Islands, British 092 VGB VG Virgin Islands, U.S. 850 VIR VI Wallis and Futuna 876 WLF WF Western Sahara 732 ESH EH Yemen 887 YEM YE Zambia 894 ZMB ZM Zimbabwe 716 ZWE ZW






VeriFone Error Codes Error Code

General Description Additional Technical Description

(if required)

Recommended Action

0001 Unspecified error Contact VeriFone 0002 Invalid transaction type An example of this could be a

Refund being passed when the site are not set up to do so. A trace of what was passed will be in the system log.

Use alternative method for transaction type.

0003 Invalid card / invalid Track2 General card error. Track2 must either be ;PAN=YYMMsss……?x or just the PAN.

Re-enter card number or re-swipe card

0004 Card scheme not recognised The card Issuer Identification Number (IIN) has not been located in the IIN table. The IIN is typically the first 4 to 6 digits of the card number.

Prompt for alternate method of payment

0005 Card scheme not accepted The card has been identified, but the card scheme is not accepted at the given site.

Reject Transaction

0006 Invalid card number (lcd) The LUHN check digit is incorrect (the card has been mis-keyed or mis-swiped).


0007 Invalid card number length The length of the PAN is incorrect for the given card scheme.


0008 Invalid card number (pcd) The pen-ultimate check digit is invalid.


0009 Expired card Prompt for alternate method of payment

0010 Card not yet valid Prompt for alternate method of payment

0011 Invalid card service code The Track2 service code is invalid. Prompt for alternate method of payment

0012 File or XML missing or wrong format

A required file or XML is missing or has wrong format.

Contact VeriFone

0013 File permanently locked A file required by the EFT library was still locked after EFT FIO TRIES attempts.

Contact VeriFone

0014 Out of memory The library has failed to allocate sufficient heap.

Contact VeriFone

0015 Account number does not exist

The requested account number does not exist.

Check the account number configuration of the system, ensuring it matches that configured within WinTI

0016 Value exceeds ceiling limit Purchase value exceeds card scheme ceiling limit

Prompt for alternative method of payment. Arrange to increase ceiling limits

0017 Cashback exceeds ceiling limit Cashback value exceeds card scheme ceiling limit

Revise transaction cash-back value

0018 Transaction currency is invalid The transaction currency code is invalid or incorrect for the given site.

0019 Lay aways are not allowed Attempt to lay away invalid / lay aways are not allowed

0020 Lay away already stored Attempt to lay away a transaction where there is already a transaction laid away on that card


0021 EFT system not configured The EFT system has not been configured

0022 Internal error, buffer too small A buffer is too small 0023 Unknown comms device type Invalid / unknown communications

device type Check communications configuration

0024 Configuration file is invalid Configuration file is invalid / bad format

Check system configuration

0025 No valid accounts There are no valid accounts specified in the TillInfo.cfg

Check system configuration

0026 Invalid channel Invalid channel Check>






Error Code


(if required)

Recommended Action

· 2 transactions aren’t being passed down the same channel. · 2 tills aren’t using the same channel number. · WinTI EFTChans within the registry has enough available channels set (Socket mode only).

0027 System error –module not loaded

System error (Track2 check module has not been loaded)

0028 General transaction error Re-enter transaction 0029 Transaction store unavailable Transaction store unavailable Check Live Store.

Check hard disk space. 0030 Unspecified error Unspecified error Check system log for indication of

error. 0031 Unspecified error:2 Transaction cancelled Channel available for next transaction 0032 Library not open EFT library is unavailable 0033 Possible text for error:

<fieldname> (<fieldno>) should be X to Y characters in length. <fieldname> out of range, should be X to Y. <fieldname> out of tolerance, is X, should be X +/- Z. Line discount not available for Cendant cards. Line count (X) doesn’t match header -> CPC lines (Y). Separate post and packing only on Amex cards. Where <fieldname> = part number, part description, commodity code, unit of measure, quantity, net value, VAT amount, gross value, PAN, PO number, customer number, customer name, customer VAT no, destination zip, destination country code, order date, original invoice number, cost centre, invoice net amount, invoice VAT amount, post and packing VAT, invoice gross or transaction total. Invalid CPC data

The error message is made up of a combination of text (1 to 6) with the applicable field name inserted, as applicable. For example: Net value out of tolerance, is 123.45, should be 123.00 +/- 1

0034 Modifier field invalid/missing As the modifier is passed within the T record the host software is likely to be the cause of this

0035 Invalid card / invalid Track 1 Track 1 is invalid Re-swipe card 0036 Invalid card / invalid Track 3 Track 3 is invalid Re-swipe card 0037 Invalid / missing expiry date The expiry date is either invalid or

missing. If key entered, the format should be MMYY

Re-enter expiry date or re-swipe card

0038 Invalid / missing issue number The issue number is either invalid (value or length) or missing

Re-enter issue number or re-swipe card

0039 Invalid / missing start date The start date is either invalid or missing. If key entered, the format should be MMYY.

Re-enter start date or re-swipe card

0040 Purchase/refund value bad or missing

The transaction value is either invalid or missing

Re-enter transaction

0041 Cash-back value bad or missing

The cash-back value is either invalid or missing

Re-enter transaction

0042 Auth code value bad or missing

The authorisation code is either invalid or missing






Error Code


(if required)

Recommended Action

0043 Cheque account number value bad or missing

The cheque account number is either invalid or missing

Re-enter cheque account number

0044 Invalid cheque sort code The cheque sort code is either invalid or missing

Re-enter sort code

0045 Invalid / missing cheque number

Re-enter cheque number

0046 Invalid / missing cheque type Re-enter cheque type 0047 Invalid EFT serial number The EFT serial number is either

invalid or missing in the .Cnf file Re create *.cnf

0048 Unexpected CPC data Purchasing card invoice data has been presented for a non-Purchasing Card (where invoice data is not valid/required)

Re-enter transaction without invoice data or prompt for a valid Purchasing Card

0049 Transaction already confirmed or rejected

Attempt to confirm or reject a transaction, which has already been confirmed or rejected

0050 Copy protection failure Could be a permission problem on the PC

0051 Post confirm reversal not allowed for PWCB or Cash Advance (reserved for future use)

Attempt to perform a post confirm reversal on a PWCB or Cash Advance has been dis-allowed (as post confirm reversals are not supported when cash is involved)

Reverse transaction manually (as cash is involved)

0052 Transaction data supplied in post conf rev not consistent with store (reserved for future use)

The details supplied in the post confirm reversal message is not consistent with the data stored for the transaction to be reversed

0053 Transaction already void Attempt to perform a post transaction reversal has failed because the transaction has already been voided/reversed

0054 Card on hot list The card number is on the locally stored host list (received from the acquirer and/or entered by the customer). The card must be rejected


0055 Attempt to confirm a declined transaction

The format of the confirmation message is invalid (confirming a declining transaction). The confirmation message should contain a command value of 2 (reverse/reject) and not a value of 1 (confirm).

0056 EFT_ERR_BAD_CV2 CV2 is invalid Check CV2 and re-enter 0057 EFT_ERR_BAD_AVS AVS is invalid Check AVS and re-enter 0058 Invalid Merchant Details Merchant Details passed in XML

Gateway are Invalid. Check both the GUID and Passcode information that being passed to the XML Gateway

0059 Invalid Mobile Number Format The Mobile Number format passed is incorrect

Please check and re-enter the mobile number supplied.

0060 Invalid/missing bank account number

The bank account number within the supplied T-Record is incorrect.

Check the bank number being passed and re-enter as necessary.

0062 Token does not exist or invalid token for this merchant system

The Token ID supplied is incorrect or invalid for the merchant system

Check the Token ID is correct and for use with the current merchant system

0064 Unexpected / Invalid Authorisation Response

Unexpected / Invalid Authorisation Response from M-Voucher Host

Please contact VeriFone Support

0065 Invalid voucher target type The Target Voucher Type is invalid (M-Voucher)


0066 Invalid Refund Pin The refund pin entered is invalid Please enter the correct refund pin if continues to fail, please contact VeriFone Support

0067 Report Not Supported The Report ID supplied is either invalid or does not correspond to a report that is supported

Check the Report ID that is being passed

0068 Report Failed Integrated report failed Contact VeriFone






Error Code


(if required)

Recommended Action

0069 Gratuity value exceeded Check Gratuity Value Check Gratuity Value 0070 Invalid Capture Not

Supported Check PAYware Ocius settings Capture Method Not Set correctly

0071 Cashback not allowed by card Card does not allow cashback Use a different card or proceed without cashback

0072 Cash advance not allowed by card

Card does not allow cash advance Use a different card

0073 Max refund value exceeded Refund transaction value is greater than the maximum refund value set on the account

Reduce transaction value

0074 Bill Already Complete The bill being cancelled is already completed and therefore cannot be cancelled.

N\A

0075 No ETU accounts Attempt to process ETU transaction without ETU accounts being present on terminal

Contact VeriFone

0076 Card is online only Attempt to process an online only card whilst offline

Check network or use another card

0077 Cancel Failed - In Payment on xxx.xxx.xxx.xxx

Attempt to cancel a lodged Bill failed, usually locked on a specific terminal

Leave for configured amount of time before retrying cancel routine.

0078 Login failed User ID or PIN is incorrect Check login details and try again 0079 Confirmation Status Unknown An invalid confirmation response

has been received or the confirmation message to be sent was not saved

0080 Bill Reference Already Exists Attempt to lodge a Bill into I-Link that already exists

Clear the original Bill, or re-send this one using an alternative reference.

0081 Print Report Failed The request report failed to generate or print

Check printer settings, network connection and try again.

0082 Network Error Error in Network Check network. 0083 Invalid Record Invalid Record The record received is invalid. 0084 PED User already logged in A Login command has been

received, but a user is already logged in

Log the terminal off first, or simply pass a transaction.

0085 PED User not logged in The terminal needs to be logged in Send a login command to the terminal, or manually login using the on-screen prompts, then re-send the transaction.

0086 Submission of offline transactions failed

The submission of the offline stored transactions have failed.

The transactions will still be stored on the terminal. Re-try, and if still having problems contact The Merchant Helpdesk.

0087 Problem in network There has been a problem in the network.

0088 Voice Referral Timeout The voice referral transaction has taken too long.

Re-try or cancel.

0089 Invalid Account ID Invalid Account ID 0090 Service Not Allowed Service code not supported Use another card, or cancel the

transaction 0091 Card Not Accepted Card type not accepted Use another card, or cancel the

transaction 0092 Unknown Card Unknown card type Use another card, or cancel the

transaction 0093 Not In IIN Range Unknown card type Use another card, or cancel the

transaction 0094 Application Blocked The terminal cannot accept this

card type Use another card, or cancel the transaction

0095 Card Blocked The card has been blocked. Use another card, or cancel the transaction.

0096 Card Error There is a problem with the Card Re-try or use another card. 0097 Authorisation Error The authorisation process has

been interrupted or is not responding.

Check ILink & WinTI are running – or when using ICP, contact VeriFone Merchant Helpdesk.

0098 Unknown Client Unknown Transaction Source

When using transaction processing, if no POS Routing has

Configure POS routing for that Point Of Sale.






Error Code


(if required)

Recommended Action

Unknown Message been configured for the IP Address or File Name where the transaction originates from, ILink does not know where to send the transaction. It therefore rejects it with this message.

0099 Transaction/Bill Cancelled When a transaction has been cancelled by the user, the system or an ICC card, this error message will be sent.

0100 Pin Bypass Failed ICC Card does not allow Pin Bypass.

Use another card.

0101 Invalid Terminal Country Code' The Terminal Country Code passed is invalid

Please check the ISO Country Codes table and make sure the code being passed is correct.

0102 User has no permissions on specified account

Check account permissions in WebCom.


0103 Invalid Currency Code' The Currency Code passed is invalid.

Please check the ISO Currency Codes table and make sure the code being passed is correct.

0104 Invalid EMV Terminal Type' The EMV Terminal Type passed is invalid

Please check the EMV Terminal Type that is being passed is valid.

0105 Unknown Message Type The message type received by server side is not recognised


0106 General Enqueue Error General VeriFone Enqueueing Error


0107 Transaction Confirmation Error The transaction confirmation has errored.

Please retry the confirmation and if continues to fail please contact VeriFone Support

0108 Payer Auth Error The Payer Auth has encountered an error.

Please check the error message response and contact VeriFone support.

0109 Ukash Auth Error The Ukash transaction has encountered an error.

Please check the error message response and Contact VeriFone Support.

0110 Encryption Failure An error has occurred in the data encryption.


0111 Unable to build Auxillary Data Record

The auxillary data record failed to build correctly


0112 Transaction rejection error The attempt to reject the transaction has errored

Please retry the rejection and if continues to fail please contact VeriFone support

0113 Unknown Terminal The terminal\PTID is not recognised


0114 Invalid Download Type The download type is invalid Please contact VeriFone Support 0115 Terminal Registration Failed The attempt to register the terminal

has failed Please retry the registration if it continues to fail, please contact VeriFone Support

0116 Terminal has been deactivated The terminal has been marked as deactivated.


0117 Comms down Acquirer has been blocked in the database as acquirer is not processing any authorisations (comms down)


0118 M-Voucher Service Unavailable

This is when the terminal is in offline mode at the start of a transaction, and cannot connect to the hosted server to allow M-Voucher


0119 Barclays Bonus Service Unavailable

Error response when Comms failure between server application and XLS Host experienced.


0120 Token Server Error The Token Server has encountered an error


0121 Purchase transaction type not The token provided does not allow Please supply another token that






Error Code


(if required)

Recommended Action

allowed on token purchase transactions allows purchase transactions 0122 Refund transaction type not

allowed on token The token provided does not allow refund transactions

Please supply another token that allows refund transactions

0123 Cashback transaction type not allowed on token

The token provided does not allow cashback transactions

Please supply another token that allows cashback transactions

0124 Token expired The token provided has passed its expiry date

Please register a new token

0125 Invalid TokenID The token provided is invalid Please supply another token or contact VeriFone Support

0126 Token has no Txn Type Permissions

The Token Registration has no transaction permissions

Please resubmit the token request with transaction permissions enabled

0127 Invalid Token expiration date The token expiration date provided is invalid

Please resubmit the token request with a valid token expiration date

0128 ProcessingDB Missing or Invalid

The processing database that is passed in the client header is either missing or invalid.

Please check that the message you are sending has the processing database set in the client header and that it is valid (as per the transaction\payer auth request)

0129 Invalid Original Barclays Gift Transaction ID

The Original Gift Transaction ID provided is invalid

Please check the Original Transaction ID and try again.

0130 Invalid Barclays Gift Configuration

Your Barclays Gift Configuration is invalid

Please check the configuration and download to the terminal. If the problem continues please contact support.

0131 Barclays Gift Service Unavailable

The Barclays Gift Service is temporarily unavailable


0132 Merchant Reference Required Your current configuration requires a Merchant Reference to be passed.

Please re-submit the transaction with the Merchant Reference populated.

0133 Account On File Not Allowed Terminal is operating in offline mode Account does not allow Account On file CNP transactions EFT transaction capture method does not support registration of details for Account On File processing

Please check that the terminal is online Please check the configuration of the account Check the transaction details that you have passed.

0134 Card not allowed to be keyed The card scheme doesn't allow processing of keyed card numbers

Use another card, or cancel the transaction

0135 Timeout Waiting for Card A timeout has occurred whilst waiting for the card and Transactions has been cancelled

Reprocess Transaction.

0137 Present Cash Advance Transaction As Purchase

The card presented does not support cash advance and needs to be represented as a purchase txn.

Reprocess Transaction as a purchase

0138 Gratuity Value Incorrect Check Gratuity Value Check Gratuity Value 0139 Transaction Timeout The application has timed out

waiting for a Barclays Gift response Please check whether the gift request has gone through and if necessary please try again.

0140 Schedule Payment registration failed.

The scheduled payment registration has failed.

Please attempt to re-register the scheduled payment or contact VeriFone Support

0141 Ocius migration failed The PAYware Ocius migration failed on the database because the migration has not been setup / enabled

Contact VeriFone to arrange for migration

0142 S Record Timeout Terminal has timeout after 30 seconds from no response from user

Reprocess record if required

0143 Download Failed The software or configuration download on the Vx810 RS solution has failed to complete its

Please retry the download if it continues to fail please contact VeriFone Support






Error Code


(if required)

Recommended Action

download successfully. 0150 Invalid PayPoint Configuration The PayPoint configuration that

you have setup is invalid. Please contact VeriFone Support

0151 No PayPoint Accounts There are no PayPoint accounts available.


0152 PayPoint Service Unavailable The PayPoint service is currently unavailable

Please retry the payment or contact VeriFone support

0153 PayPoint Download Required A PayPoint download is required Please perform a configuration file update to your terminal

0154 PayPoint Account Extraction Failed

PayPoint account file extraction has failed.

Please retry the download if it continues to fail please contact VeriFone Support

0155 PayPoint Transaction Type Not Allowed

The PayPoint transaction type provide is not allowed

Please check the Transaction Type supplied and correct

0156 Invalid PayPoint TopUp Type The PayPoint TopUp type provided is invalid

Please check the TopUp Type supplied and correct

0157 Invalid PayPoint Service Provider

The PayPoint Service Provider provided is invalid

Please check the Service Provider supplied and correct

0158 Invalid PayPoint Scheme The PayPoint Scheme provided is invalid

Please check the Scheme supplied and correct

0159 Invalid PayPoint Scheme Option

The PayPoint Scheme Option provided is invalid

Please check the Scheme Option supplied and correct

0160 Invalid PayPoint Amount The PayPoint Amount provided is invalid

Please check the Amount supplied and correct

0161 No PinPad Available The PinPad is currently unavailable Please check the PinPad is available for use, please contact VeriFone Support if the problem persists.

0185 On Hold Transaction Failed When an unexpected response or error response is returned by the VeriFone hosted infrastructure

Represent the transaction, if error persists then please contact VeriFone support.

0189 Invalid refund password An invalid refund password has been supplied during the transaction, and was rejected by the database


0999 Token Server Error Start date or issue data supplied is incorrect or missing

Please check you are passing the appropriate required fields

1000 Generic Error Generic Capture Error Please contact VeriFone Support 1001 Merchant Supplied Bad Data The information supplied in the

post is incorrect Please check the data that you are sending and retry.

1002 Bad Source URL The source URL is unrecognised Please contact VeriFone Support 1003 Attempting to use a TokenID

and a PAN at the same time A TokenID and PAN were received for the same transaction

Please check the data that is being passed

1004 Curl Error Communication Error Please contact VeriFone Support 1005 Couldn't Extract Error Code

from Response The error code returned could not be extracted


1006 Failed to Retrieve System Config

PayPage has failed to retrieve your System Configuration


1007 Unusual Data Supplied (Possible Attack)

The data that has been supplied is suspicious

Please check the data that you are sending and contact VeriFone support

1008 Failed to Retrieve Session Data

PayPage has failed to retrieve your session data


1009 Failed to Create New Session PayPage has failed to create a new session


1010 Bad SessionID received from end user

The sessionID provided by the front end is incorrect.

Please check the data that you are sending and retry.

1011 Bad PIN received from end user

The PIN provided by the front end is incorrect.

Please check the data that you are sending and retry.

1012 Session Finished The session that you are trying to use has already finished.


1013 Failed to extract PA Data An error has occurred trying to decrypt\extract the Payer Auth data


1014 Session Expired The session that you are trying to use has expired.







Sentinel FAQs

Why do I get an “EFT is not allowed” integration response?

Receiving a -21 response to an integrated transaction request with an authorisation message of “EFT Not Allowed” indicates that when the transaction was started that the PED was deemed not to be available.

Possible Causes Description Steps To Resolve PED is disconnected If the PED is not physically connected

to the PC that is running Sentinel, it will not be able to communicate to the PED and as such not be able to perform EFT transactions

• Ensure that the PED is correctly connected to the PC using the supplied RS232 / USB cable

• Do not use RS232 to USB serial converters

PED is not powered up If the PED is not powered up, the PED cannot perform any processing

• Ensure that the supplied power supply is correctly connected to the RS232 cable

Online PED verification required

If the PED has been power cycled too many times between pairing requests, the PED will require online PED verification. If Sentinel is logged in, this will require the current user to logout to allow for the verification to be performed

• Logout of Sentinel • Re-Login to Sentinel • Enter PED Security PIN if prompted

Low System Resources In order for a PED to remain in an available state, the PED must respond to the polling messages within a given period of time. If the PC is under load, Sentinel may not receive these messages in time and so fall into a PED not connected state

• Ensure that the PC has enough RAM – Minimum requirements for Windows is not enough. Every application that you run requires additional resources on top of the Windows defined minimum value

• Ensure that the PC has enough free disk space – Windows makes use of swap files to boost the amount of RAM available. Limiting this, limits the total amount of RAM (physical + virtual) available

• Ensure that the PC is not running at near 100% CPU usage for long periods of time. If the machine / a process is using near 100% CPU usage, applications could be suffering from the inability to perform any processing

Invalid PED Settings In order to successfully communicate with the PED, Sentinel must be correctly configured to communicate on the correct settings

• Ensure that Sentinel is set to use the correct PED Type

• Ensure that the COM Port settings are correct

COM Port In Use If another application is using the COM port, Sentinel will not be able to access it, and will therefore be unable to communicate to the PED

• Ensure that no other applications are using the specified COM port

User Opted To Continue Without PED

During the Sentinel start-up process, if the PED is deemed as not connected, Sentinel will prompt for the user to connect the PED. If the user chooses to continue without the PED, the PED will not be available for use

• Ensure that the PED is correctly connected and configured

• Restart Sentinel • Do not opt to continue without the PED

PED is invalid Sentinel can only use PEDs that are allowed by the merchant’s system. Connecting any other PED will result in Sentinel either requiring Online Validation or not being allowed

• Ensure that the PED is valid for the given merchant system






Faulty PED If the PED is faulty or not working correctly, unexpected results may be experienced

• Try an alternative PED that is allowed for that merchant system

Why do I get an integration service not allowed?

Receiving a -31 response to an integration record with a message indicating “Service Not Allowed” indicates that when the specified functionality to be performed was requested, Sentinel was not in a position whereby it could process the request.

Possible Causes Description Steps To Resolve Sentinel Is Not Idle The majority of integrated commands

can only be processed when Sentinel is on the idle screen. Integration commands include:- • Transaction • PayPoint Transaction • GR TFS Transaction • Barclays Gift Transaction • M-Voucher Transaction • Flexecash Gift Transaction • Logout • Offline Submission • Report • Update App • Stay Offline • Givex Transaction

• Ensure that the integration command is only sent when Sentinel is idle – Use the Sentinel log file to help identify the issue

Already Processing A Request For Another Client

Sentinel only supports processing a single integrated request at a time. If another client connects to Sentinel and sends a request, Sentinel will reject the request

• Ensure that only one client is connected and sending messages to Sentinel at a given time

Sentinel Is Not Processing A Transaction

If sending Continue Transaction command, and the action does not fall into one of the few exceptions, Sentinel expects a transaction to be in progress. If there is no transaction in progress, the request will be rejected.

• Ensure that the correct Continue Transaction command is being sent and at the right time

Sentinel Is Not Able To Accept Login Request

If Sentinel is not in a position to be able to log in (on the login screen), Sentinel cannot process the login request.

• Ensure that the login request is being sent at the correct time.






System.MissingMethodException in the log file

Normally this indicates that the required signature of an external resource does not match that expected by Sentinel.

Log File Example:

OCIUS(StartPinpadInitialisation)System.MissingMethodException: Method not found: 'Boolean System.Threading.WaitHandle.WaitOne(Int32)'. at VeriFone.VeriFonePED.PinpadEMV.PingProcessing() at VeriFone.VeriFonePED.PinpadEMV.Ping() at OciusPED.OCIUS.InitialisePinpad(Boolean Reconnecting) at OciusPED.OCIUS.StartPinpadInitialisationProcessing()

Possible Causes Description Steps To Resolve .NET Framework is not up-to-date

Sentinel is compiled against specific versions of the .NET framework. As and when patches released by Microsoft are applied, these patches may update the assemblies used within the .NET framework for functionality that Sentinel depends on. If these assemblies are not compatible with those required, Sentinel will not be able to use them.

• Ensure that all available updates for Windows are applied

• Ensure that the correct version of .NET is installed

• Ensure that all released updates to the .NET framework have been installed

What version of .NET is required?

Unless PayPoint is enabled on the merchant system, Sentinel requires .NET 2.0 SP2. If PayPoint is enabled, Sentinel requires .NET 3.5 SP1. Please note, Windows and the .NET framework should be kept fully patched in line with Microsoft’s patch and service releases issued via Windows Update.

No System ID available

What causes “No System ID available - Either PAYware Ocius PED is activated, but the System Config does not exist or contain the System ID, or activation is required, but the License Key does not exist or contain the System ID”?

In order to use Sentinel, it needs to be successfully activated in order to obtain its PTID and system details. All these details are required to perform core processing and therefore are validated during the login process. Without having the system ID available, the login process cannot be performed, and as such it obtains the System ID from the System Config file. If this file does not exist or the value is invalid then if activation is being performed (i.e. this is the first run of Sentinel), the System ID will be obtained from the supplied license key. If activation is not being performed, the license key would not have been loaded and as such the configuration is invalid. The requirement to perform activation is governed by whether Sentinel has a PTID available for use.






To resolve this issue, delete the PTID details stored in the machine’s registry and Sentinel’s generated configuration files (exml files excluding the CK files), so that Sentinel is forced to perform the activation process.

Why did the hosted login process fail?

In order to successfully complete the hosted login process, Sentinel must provide sufficient information to validate the installation and the user’s credentials.

Possible Causes Description Steps To Resolve XML missing or wrong format

This indicates that the login request message does not match the expected format and as such cannot be processed

• Contact Merchant Helpdesk

Invalid Merchant Details This indicates that System ID is invalid • Ensure that the merchant system has been configured

• Check that the configuration details that being used are correct

• Ensure that if activating Sentinel that the correct license key file is being used

• Contact Merchant Helpdesk if any of the details are incorrect

Login Failed The supplied user details are invalid or terminal details are incorrect or any other unexpected error

• Check that the user ID and password details are correct

• Check that the merchant details are correct

• Check that the terminal details are correct including the MAC list

• Contact Merchant Help Desk if any of the details are incorrect

Invalid License The license details supplied are invalid

• Check that the license key file is the correct file

• Check that the merchant details are correct

• Contact Merchant Helpdesk if any of the details are incorrect

License Mismatch The supplied terminal details are invalid for the re-installation of Sentinel under the identified existing installation slot

• Check that the license key details are correct

• Check the installation slot details are valid

Maximum License Install Exceeded

There are no more free installation slots available

• Free up slots that are no longer in use • Order more installation slots from the

account manager Terminal Registration Failed

The hosted server failed to successfully activate the installation slot or the terminal details

• Try the activation process again • Contact Merchant Helpdesk

Unknown Terminal The terminal details supplied are invalid

• Check the terminal details being supplied are correct

• Contact Merchant Help Desk if any of the details are incorrect

Terminal Has Been Deactivated

The terminal has been deactivated • Contact Merchant Help Desk

General Enqueue Error Failed to initialise the configuration / software download preparation process

• Try the login process again • Contact Merchant Help Desk






How do I allow Sentinel to be installed on more machines?

Sentinel is restricted based upon the number of installation slots generated as part of the order process. If you need more installation slots, it will be necessary to follow the defined order process through Halo.

How do I move an Sentinel license to a new machine?

Contact Merchant Helpdesk to release the installation slot. To do this, it is necessary to know the merchant system details and the PTID of the Sentinel install to be moved. Once released, it will be possible to perform the activation process on the new machine.

When does the offline voice referral floor limit take into effect?

The offline voice referral floor limit is only used when a transaction requires a voice referral to be performed due to a comms down scenario. Voice referrals due to instructions received from the acquirer will still require the voice referral process to be followed.

Why is the offline voice referral floor limit process different?

Sentinel’s voice referral floor limit process differs from that deployed with PAYware Ocius for PC. This is because Sentinel’s transaction process is implemented to standardise the transaction process in line with EMV, acquirer and card scheme rules. EMV rules dictate that in the event of a communications failure, ICC transactions should be completed as per standard EMV rules, whereby the transaction is completed informing the ICC that the transaction is subject to Comms Down.

v 810 and vx 820 sentinel -...

Documents