Child pages
  • Westpay 2.x integration guide
Skip to end of metadata
Go to start of metadata

Version Date Comment
Current Version (v. 6) Feb 25, 2020 10:14 Tomas Nilsson
v. 5 Jun 27, 2018 08:09 Mattias Lantz
v. 4 Jun 21, 2018 09:46 Mattias Lantz
v. 3 Jun 20, 2018 16:52 Mattias Lantz
v. 2 May 17, 2018 16:46 Mattias Lantz
v. 1 May 15, 2018 11:45 Mattias Lantz



The West International XAC payment terminal provides the electronic payment functionality in an integrated point of sale system. This document provides information on how to integrate the terminal with the ECR device and to provide the network connection required by the payment terminal.
This document also defines the obligations on the ECR/network infrastructure needed to maintain the security of the payment system. The terminal expects this to be in place to comply with the PCI security standards (Ref [1]).

Reference Documents

  1. Payment Card Industry (PCI), Payment Application Data Security Standard, Requirements and Security Assessment ProceduresVersion 2.0, Date October 2010Filename: pa-dss_v2.pdf
  2. BABS and CEKAB Software & Parameter DownloadVersion 3.1, Date 5th May 2011Filename: PPL-specification+3+1_20110505.pdf
  3. SPDH Terminal Interface For POS-transactionsVersion 3.1, Date 24th September 2009Filename: SPDH Terminal interface_v3 1_090924.pdf
  4. Design Document ECR Interface Module EPASVersion A_01 or later.BitWise Document Reference – OWDSN004_A04
  5. Design Document ECR Interface Module iPOSVersion A_01 or later.BitWise Document Reference – OWDSN004_A04
  6. Babs & CEKAB – Security Requirements for and EFTPOS TerminalVersion 3.0


Objective and Scope

The objective of this document is to provide the ECR developers and system integrators with the information that need to successfully incorporate the XAC payment terminal into their system.


This document should be read by anyone who is involved in the development of the ECR to payment terminal interface and / or involved in the integration of the point of sale system.

Significant Assumptions



CVV2 Card Verification Value (also known as the card security code, CVV2, CID, CAD, CVC2).
DHCP Dynamic Host Configuration Protocol. The network protocol used to assign a network address and parameters to a device when it starts up.
ECR Electronic Cash Register. In this application it is the device that connects to the payment terminal to drive the transaction process.
FTP File Transfer Protocol. An industry standard method of transferring files between computers.
KCV Key Check Value. When a security key is decrypted and loaded into the secure processor this provides a check that the correct key has been stored. If the encrypted key had been tampered with or a different transport key used then the KCV would not match and the key load is aborted.
MAC Message Authentication Code. A cryptographic signature appended to a message to ensure that the message has not been changed since it was created. This requires that the send and receiver both know the same secret key.
NFC Near Field Communications. A radio communications technology that allows very short range (a few centimetres) bi-directional data communications. This technology is gaining some use in providing communication between a payment card and the terminal.
PCI Payment Card Industry.
PCI DSS PCI Data Security Standard.
PPL Program and Parameter Loading protocol. A BABS defined mechanism for load keys and configuration information into payment terminals (Ref [2]).
RFID Radio Frequency Identification. A short range radio communication that allows a device to wirelessly send an identification number to a receiver.
SPDH Standard Pos Device Handler protocol. The protocol used between the payment terminal and the transaction host (Ref [3]).
TCP/IP Industry standard networking protocol.
EPAS Epas Retailorg ECR protocol related to the SEPA framework.
iPOS ECR protocol developed in the Nordic region for the Nordic market.

ECR Operator Policy

Mikael to provide. Not sure where this should go in this document. Maybe it is first or maybe last, maybe it is part of the next section…..

ECR Development

To successfully integrate the payment terminal into your payment system it must be interfaced to the ECR device. How this is achieved will depend on the ECR vendor, ECR hardware and its application development system. If the ECR meets the defined communications interface and the other requirements defined in this document then a successful integration is possible.

ECR Protocol

The software is currently delivered with two modules for the ECR connection and depending on who has the SACI between the terminal and the ECR, any of the currently supported interfaces can be used.

EPASRetail Org

This communication protocol between the ECR device and payment terminal is based on the TCP/IP and XML. The messages and fields supported are defined Ref [4]. Readers developing the payment terminal interface for the ECR must refer to this document for the protocol details. EPAS supports Ethernet connection only.

iPos (integrated Point Of Sale)

iPos is a protocol developed with the purpose of standardising the interface between a card terminal and an ECR in an integrated environment with the intention to make integration easier on all parts. The messages and fields supported are defined Ref [5]. Readers developing the payment terminal interface for the ECR must refer to this document for the protocol details.Our iPos integration is purely based on RS232.

ECR Simulator (EPAS only)

When developing a new interface it is often useful to have an example to work from. The ECR simulator development tool may be used to connect to the payment terminal from a PC and run transactions. By monitoring the network between the simulator and payment terminal the exact content of the messages can be seen.

Message Validation

The ECR simulator package also provides an XML schema definition file. Developers working on interfacing an ECR to the payment terminal should be use this file to verify the messages they are creating. This will provide an early indication if the messages conform to the correct structure.
How the validation is performed will depend on the ECR development environment, but the normal process is to perform a validating read of the generated data. Some XML libraries have a separate validation function that may be called to validate the built request message.
The XML schema file is named: EpasToPOIMessages.xsd and can be found as part of the ECR Simulator (Product code OWR) deliverable.

Setting-up the Payment Terminal

Before a new terminal can be used it must be configured with the basic communication parameters. These parameters are set via a series of Management Functions. In most cases a terminal delivered 'out of the box' will need to have its network parameters configured before it can be used.
Once a terminal has been configured and connected to the network the ECR device will log-on and provide details of the configuration host from where the terminal will load its operational security keys and application parameters.

Entering the Management Functions

The management functions can be accessed any time the terminal is not processing a transaction. The terminal does not have to be logged on to the ECR to access the Management Functions.
Power the terminal on and wait for the 'Terminal closed' screen to appear. The management functions are entered using the 147369 key sequence. To help prevent fraudulent use there is no feedback to the operator while this is being entered. On successfully entering the sequence the user is presented with a menu of available functions. If the wrong key sequence was entered simply start the number sequence again.
Use the on-screen left and right arrows to navigate to the different menu pages. To enter the desired function press the number associated with that entry. If no selection is made within 30 seconds the terminal will revert back to the idle screen.
Important functions are protected with one of two passwords. The normal password is the current Merchant Password as set from the PPL file and/or subsequently modified by the user. If the terminal has never been configured a default password of 123456 is set.
Some functions use the 'Factory Password'. These functions are for use by West International and the factory password is not normally supplied to the system integrator or end user.

Software Identification

During development and when diagnosing faults it is important to know the version of the software running in the terminal. There are various ways of checking the version of the software running on the terminal.

Start-up Splash Screen

When the terminal is first powered up a splash screen is displayed for a few seconds. This will show the application name and version. An example of this screen is shown in Figure 1.
XAC PA v1.6.0.14

Figure 1 - Example Application Version Splash Screen

Reporting via Management Function (EPAS only)

The terminal supports an ECR accessible management function that reports the software version back to the ECR. See Ref [4], section 2.7.8 and use the 'PrintTerminalConfig' function.

Application Filename

During development and when new versions of the application are provided, these are contained in a file. The file extension will show how the data is stored but the name of the file incorporates the version number.
The file name is constructed as follows:


Figure 2 - Filename Example
The product code for the XACT payment application is always OW1. The major and minor version numbers identify the software release. During development where multiple software builds may be created the build number is used to uniquely identify each one.
The major version, minor version and build numbers map directly on to the first, second and forth numbers in the software version shown on the splash screen (section 4.2.1). On the splash screen the third number is always zero.
This format of the filename is also used to name the directory that the software is stored in on the terminal. This ensures that when multiple versions of the software installed on the terminal their files can be kept separate.

Network Configuration (EPAS Only)

Before the terminal can successfully connect to the network (which is required for communication with the ECR and to download its configuration) it must have the network parameters configured.
Before continuing the configuration, ensure that you know the details of the network parameters to be used. If there are any doubts check with your own IT department.

Enabling DHCP

First select the 'Kommunikationsinställningar' (Terminal comms) management function. The next screen shows 'Aktivera DHCP?' (Enable DHCP). On this screen press the 'Ja' (Yes) or 'Nej' (No) as required.
If DHCP is not selected the operator must manually configure the TCP/IP Address and network parameters (see 4.3.2).

Setting the TCP/IP Address Parameters

After disabling the DHCP the user is presented with a sub-menu giving options to enter the network parameters (IP Address, Subnet mask, and Gateway). Select each of these in turn and enter the address information.
The address is entered from the keyboard, network address fields needing less than 3 digits should be left filled with zeros. A single digit may be corrected by pressing the backspace (yellow) key. The whole process may be cancelled by pressing the cancel (red) key. When complete, use the enter (green) key to confirm the new value.

Setting the ECR Network Listening Port

This parameter defines which port the payment terminal will listen on for the ECR device. This defaults to 3000 but make be set to any value in the range 1025 to 65535.

Obligations on the Retailer

To avoid unnecessary restrictions, the payment terminal will accept any device meeting the defined ECR protocol. To prevent unauthorised access to the payment terminal it is strongly recommended that the retailer's network firewall be configured to block external devices trying to connect to the payment terminal and in particular the ECR listening port.

Serial communication (iPOS only)

The terminal is when connected through the iPOS ECR module connected through a serial interface (RS232) and operates at 115200 baud with no parity, 8 bits and 1 stop bit. No flow control is used.

Communication DLL (iPOS only)

When being run with the iPOS ECR interface, communication with the terminal is done through a DLL. This DLL (PM1.dll) is the transport layer for communication over the RS232 link to the terminal. The protocol used is defined in Ref [5].

Other Management Functions

Self Test

The self test management function presents a set of hardware tests that allow the user to verify the operation of the terminal hardware.
On entry to this function, the user is presented with a list of the available tests. Select the required test(s) and press the on-screen Run button. The user must then follow the on-screen instructions for each test. At the end of the text press the on-screen Exit button to return to the payment application.

Change Merchant Password

By default the Merchant Password is set within the PPL MASPAR file (Tag 0x9F31, User_Password). This will be set the same for all the terminals sharing the same MASPAR file.
The operator may change the Merchant Password for the current terminal by using this management function.
On selecting the function the user is prompted for the current merchant password. If this is accepted the user is asked to enter and then confirm a new password.

Revert to Previous Software Version

The payment terminal can store two versions of the payment application. After being reset the terminal will always attempt to run the latest downloaded application. If there is a problem with the new application, the normal procedure will be to download a (newer) corrected application. In the rare event that the new application cannot communication or download a new application then this command may be used to remove the latest version of the application.
After this management function has been executed the operator must power off and power on the payment terminal to complete the process. After power on the payment terminal will be running the previously downloaded version of the application.
To remove the latest version of the application, select 'Revert software' from the management functions menu. When prompted enter the current merchant password. If the password is accepted, the terminal will reset and power up in the previous version of the application. In the process the 'latest version' of the application is deleted.
Note that 'the latest' version is determined by the version timestamp contained within the PPL DCAPP file header. The version of the software is not checked, so it is possible to rewind a change by downloading and earlier version of the payment application provided this is wrapped into a new PPL DCAPP file with a newer version timestamp.

Return to Factory Settings

Terminals in the field (or during development) can be loaded with various applications and configuration files. This management function allows all the applications and application data to be cleared out. Typically this will be used during development or when a field terminal is being taken out of service.
When selecting the "Set debug level" (Factory default) menu option, the user will be prompted for the factory password. Enter the password and then power the terminal off and back on to complete the process.
Note that this command does not delete the security keys from the secure processor. These are still available and should be used to support the security checks on loading the new application.

System Requirements

The payment application is handling sensitive data (principally the card details) that must be kept secure at all times. The security requirements are defined by PCI (Ref [1]). While most of the responsibility for the data security is handled by the payment terminal, there are some aspects that the ECR and communication networks must comply with. This section defines those requirements.

Data Handling

What to Store

The payment terminal does not transmit any PCI sensitive data to the ECR device. However it is good practice for the ECR developer to minimise the amount of information and the length time that it is stored. If there is no genuine reason for needing this information at a later time then there is no need to store it.

Cryptographic Storage

There are no requirements for the ECR to store any cryptographic key relating to the payment terminal or communication with the payment terminal.

Communications Gateway

The ECR device may be operating as a communications gateway for the payment terminal. There is no requirement to store any of the messages passing between the payment terminal and an external host. If a message fails to make it to its destination the payment terminal will take appropriate corrective action.

Log File Handling

It is a requirement of PA-DSS that the payment terminal maintains an event log file. To allow this file to be processes, infrastructure facilities must exist for this log file to be delivered to a central log file server.

Types of Log File

The payment terminal maintains two types of log data. These appear to the user as the Event Log and the Diagnostic Log.
The Event Log contains the basic information to show the actions that have been performed on the terminal. This log contains at least the minimum information required by PA-DSS(see 5.2.3).
The diagnostic log contains a superset of the information in the event log and is aimed at developers. The level of detail included may be varied via the ECR controlled management function (see 5.2.2).

EPAS Application Logging Levels

There are four levels of logging provided within the application. The logging level is controlled from the ECR. Regardless of the logging level set, the items logged meet the minimum events required by PA-DSS (see section 5.2.4).

iPOS Application Logging Levels

In the iPos version of the terminal there are three levels of logging available. Logging level is set from the SACI with the command OP_TRACE.
L = Status + Error,
M = Status + Error + Warning,
H = Status + Error + Warning + Debug

Logged Information

The following information is collected for each event.

  • Type of the event
  • Date and Time
  • Source of the event (name of the program or module)
  • Details of the event including the pass/fail status (e.g. for logon attempts this needs to record both successful and unsuccessful attempts).

Unavailable Information

The PA-DSS specification expects that the current user information also be logged for each event. The XAC payment application has no concept of a user and does not authenticate the individual users. This information is therefore not present in the logs.
The outcome of all requests to enter a password (e.g. for entry to the management functions) are recorded in the event log file.

Excluded Information

To comply with the PA-DSS requirements, the information logged excludes the card sensitive data. PANs are only be logged in the truncated form (as would appear on a receipt). The CVV2 and card expiry date information will never be logged.

Always Logged Events

These events are always logged into the Event Log regardless of the currently set Logging Level. These events are recorded even if the operation did not succeed.

  • Logon attempts (in our case from the ECR and to the SPDH host).
  • All actions (this shall include all requests from the ECR, financial transactions, management functions, logon etc).
  • Changes to the terminal settings including the logging levels.
  • Access to management functions (record when any of the management functions are executed, or attempted to be executed and failed password checks).
  • Upgrades to PPL Configuration Files, Security Key files and software.

Obligations on ECR

The PA-DSS security specification requires that the payment terminal log files are collected and placed on a central server. At the end of each transaction the incremental details of the last transaction are supplied to the ECR device. The ECR is responsible for managing this data and delivering it to the central server.

Event Log Transfer EPAS

The event log information is automatically passed to the ECR at the end of a transaction within an Event Notification Message.
The ECR Device shall extract the event log data from the EventDetails element. The data should be appended to any earlier data and/or delivered to the central log server. This delivery must include the identity of the terminal that supplied the data (available in the Event Notification Message header).

Event Log transfer iPos

The event log information is automatically passed to the ECR at the end of a transaction within an SR_MESSAGE. There is also an alternative to use the OP_LOG command to extract the complete log file from the terminal.

Disable automatic log transfer

There is a possibility to disable the automatic transfer of log files sent from the terminal as described in This could be useful if the integrator uses OP_LOG to extract logs between transactions. We do however strongly encourage that this function is left activated since there are demands within PA-DSS that logs are sent from the terminal to the ECR on an event basis.
If this feature is disabled, the full responsibility in terms of PCI lays on the one who turned the function off.

Diagnostic Log File Transfer

Making the ECR capable of extracting the diagnostic log is not mandatory but is strongly recommended. This is especially useful during development when abnormal behaviour may get the terminal into an unknown state. The additional diagnostic information in the log file will help understand why the terminal did not respond as expected.

EPAS Specific

To collect the log files the ECR must therefore support an FTP server.

The Diagnostic Log file is requested by the ECR using one of the management functions. See Ref [4], section 2.7.8 and use the 'ExtractLogFiles' function. The diagnostic log is delivered via FTP to the ECR device. This is the device with the same IP address as made the request. It is assumed there is a FTP server on TCP/IP port 21. The payment terminal will log on with a user name matching the terminal's logical identity (and no password). This user must have write access to their home directory.
The log file names are made up of the terminal number, date and time to provide a unique name. This ensures that log files from different terminals will all have a unique name, allowing the files to be placed on a central server by the ECR and ensuring subsequent transfers do not overwrite an earlier one.

Log File Format

Both the event log and diagnostic log share a similar file format. The log files consist of one entry per line. Each line contains a header part followed by free format text giving the details of the event.
The event log is delivered as raw text and the diagnostic log is delivered as html. When the diagnostic log is view with an HTML browser the different records are colour coded. The event types are shown here in their respective display colours: Debug, Spam, Warning, Error and Status.
The header contains three fields separated by spaces. These are:

  • Date and time
  • The level (or type of message)
  • The source module within the payment terminal.

The three header fields are enclosed in square brackets.

An example diagnostic log file is shown in Figure 3. This shows a login from the ECR where the terminal prints its settings to the log file.
[2015-08-20T09:42:38 12345678 806AA000A1 Status] Commencing ECR Login
[2015-08-20T09:42:38 12345678 806AA000A1 Debug] Event Notify : Event Notification: BeginMaintenance
[2015-08-20T09:42:38 12345678 806AA000A1 Status] WestInt PA
[2015-08-20T09:42:38 12345678 806AA000A1 Status] Version: 0.0.0
[2015-08-20T09:42:38 12345678 806AA000A1 Status] Mode: EPAS
[2015-08-20T09:42:38 12345678 806AA000A1 Status] 
[2015-08-20T09:42:38 12345678 806AA000A1 Status] --------------------------
[2015-08-20T09:42:38 12345678 806AA000A1 Status] Host
[2015-08-20T09:42:38 12345678 806AA000A1 Status] ----
[2015-08-20T09:42:38 12345678 806AA000A1 Status] IP:
[2015-08-20T09:42:38 12345678 806AA000A1 Status] Port: 8007
[2015-08-20T09:42:38 12345678 806AA000A1 Status] --------------------------
[2015-08-20T09:42:38 12345678 806AA000A1 Status] Configuration
[2015-08-20T09:42:38 12345678 806AA000A1 Status] -------------
[2015-08-20T09:42:38 12345678 806AA000A1 Status] IP:
[2015-08-20T09:42:38 12345678 806AA000A1 Status] Port: 21
[2015-08-20T09:42:38 12345678 806AA000A1 Status] --------------------------
[2015-08-20T09:42:38 12345678 806AA000A1 Status] 
[2015-08-20T09:42:38 12345678 806AA000A1 Status] --------------------------
[2015-08-20T09:42:38 12345678 806AA000A1 Status] Terminal Network Adapters
[2015-08-20T09:42:38 12345678 806AA000A1 Status] --------------------------
[2015-08-20T09:42:38 12345678 806AA000A1 Status] AX887721
[2015-08-20T09:42:38 12345678 806AA000A1 Status] DHCP: True
[2015-08-20T09:42:38 12345678 806AA000A1 Status] IP:
[2015-08-20T09:42:38 12345678 806AA000A1 Status] SubNet:
[2015-08-20T09:42:38 12345678 806AA000A1 Status] Gateway:
[2015-08-20T09:42:38 12345678 806AA000A1 Status] --------------------------
[2015-08-20T09:42:38 12345678 806AA000A1 Status] Version Details
[2015-08-20T09:42:38 12345678 806AA000A1 Status] ---------------
[2015-08-20T09:42:38 12345678 806AA000A1 Status] H/W: 353042
[2015-08-20T09:42:38 12345678 806AA000A1 Status] F/W: 2861413
[2015-08-20T09:42:38 12345678 806AA000A1 Status] O/S: 14011301
[2015-08-20T09:42:38 12345678 806AA000A1 Status] S/N: 806AA000A1
[2015-08-20T09:42:38 12345678 806AA000A1 Status] PED: WST800
[2015-08-20T09:42:38 12345678 806AA000A1 Status] --------------------------
[2015-08-20T09:42:38 12345678 806AA000A1 Status] Parameter Files
[2015-08-20T09:42:38 12345678 806AA000A1 Status] ---------------
[2015-08-20T09:42:38 12345678 806AA000A1 Status] DCAPP___000000000000
[2015-08-20T09:42:38 12345678 806AA000A1 Status] MASPAR__150813115028
[2015-08-20T09:42:38 12345678 806AA000A1 Status] BINPAR__150813115028
[2015-08-20T09:42:38 12345678 806AA000A1 Status] CAPUB___150813115028
[2015-08-20T09:42:38 12345678 806AA000A1 Status] DCPAR___150813115028

Further down the file we can find some debug information when a transaction is run:
[2015-08-20T09:47:33 12345678 806AA000A1 Status] SPDH Logon: Success
[2015-08-20T09:47:33 12345678 806AA000A1 Debug] ECR response: Admin Response Result: True
[2015-08-20T09:47:33 12345678 806AA000A1 Debug] Admin Response Result: True
[2015-08-20T09:47:35 12345678 806AA000A1 Spam] [EMV] EmvSetIcsValue returned OK
[2015-08-20T09:47:35 12345678 806AA000A1 Debug] InternalShowStandardScreen SCR100_IdleScreen
[2015-08-20T09:47:35 12345678 806AA000A1 Debug] Display Request 0: Display Request: Välkommen 
[2015-08-20T09:52:13 12345678 806AA000A1 Debug] ECR message: Payment Request 8073: Payment Request: Amount 50.00 Cashback: 0.00 ID: 2275, Time: 8/20/2015 7:52:12 AM, Type: Normal
[2015-08-20T09:52:13 12345678 806AA000A1 Status] Commencing Purchase Transaction
[2015-08-20T09:52:13 12345678 806AA000A1 Debug] Card state: DeviceNotOpen -> CardAbsent
[2015-08-20T09:52:13 12345678 806AA000A1 Debug] InternalShowStandardScreen SCR612_WaitingForCard
[2015-08-20T09:52:13 12345678 806AA000A1 Debug] Display Request 8073: Display Request: Ny kund Väntar på kort 
[2015-08-20T09:52:19 12345678 806AA000A1 Debug] InternalShowStandardScreen SCR101_PleaseWait
[2015-08-20T09:52:19 12345678 806AA000A1 Debug] Display Request 8073: Display Request: Vänligen vänta 
[2015-08-20T09:52:19 12345678 806AA000A1 Debug] TxnData.CardChecks CardShouldBeInserted
[2015-08-20T09:52:19 12345678 806AA000A1 Debug] InternalShowStandardScreen SCR6221_ChipCardShouldBeUsed
[2015-08-20T09:52:19 12345678 806AA000A1 Debug] Display Request 8073: Display Request: Kort har chip Forcera mag? 
[2015-08-20T09:52:22 12345678 806AA000A1 Debug] Event Notify : Event Notification: CardAccepted
[2015-08-20T09:52:22 12345678 806AA000A1 Debug] TxnData.CardChecks PINRequired
[2015-08-20T09:52:22 12345678 806AA000A1 Debug] InternalShowStandardScreen SCR652_EnterPINWithOverride
[2015-08-20T09:52:22 12345678 806AA000A1 Debug] Display Request 8073: Display Request: MasterCard Be kund ange kod Signatur möjligt 
[2015-08-20T09:52:22 12345678 806AA000A1 Debug] KSN still fresh, not incrementing.
[2015-08-20T09:52:26 12345678 806AA000A1 Debug] InternalShowStandardScreen SCR101_PleaseWait
[2015-08-20T09:52:26 12345678 806AA000A1 Debug] Display Request 8073: Display Request: Vänligen vänta 
[2015-08-20T09:52:26 12345678 806AA000A1 Debug] TxnData.CardChecks ChecksComplete
[2015-08-20T09:52:27 12345678 806AA000A1 Spam] Message received OK
[2015-08-20T09:52:27 12345678 806AA000A1 Spam] Handling fid 9
[2015-08-20T09:52:27 12345678 806AA000A1 Spam] Subfid A
[2015-08-20T09:52:27 12345678 806AA000A1 Spam] Handling fid F
[2015-08-20T09:52:27 12345678 806AA000A1 Spam] Handling fid G
[2015-08-20T09:52:28 12345678 806AA000A1 Debug] FinishTransaction
[2015-08-20T09:52:28 12345678 806AA000A1 Debug] [SCR] PowerOff returned OK
[2015-08-20T09:52:28 12345678 806AA000A1 Debug] Print Receipt 8073: Print Request
[2015-08-20T09:52:28 12345678 806AA000A1 Debug] InternalShowStandardScreen SCR662_GrpA_ApprovedSignatureTransaction
[2015-08-20T09:52:28 12345678 806AA000A1 Debug] Display Request 8073: Display Request: Köp godkänt Kontrollera signatur 
[2015-08-20T09:52:47 12345678 806AA000A1 Debug] InternalShowStandardScreen SCR6618_PurchaseApproved
[2015-08-20T09:52:47 12345678 806AA000A1 Debug] Print Receipt 8073: Print Request
[2015-08-20T09:52:47 12345678 806AA000A1 Debug] InternalShowStandardScreen SCR6618_PurchaseApproved
[2015-08-20T09:52:47 12345678 806AA000A1 Debug] Display Request 8073: Display Request: Köp godkänt 
[2015-08-20T09:52:47 12345678 806AA000A1 Debug] ECR response: Payment Response Result: True
[2015-08-20T09:52:47 12345678 806AA000A1 Debug] Payment Response Result: True
[2015-08-20T09:52:47 12345678 806AA000A1 Status] Completing PurchaseRequest : Approved, code=11111111
[2015-08-20T09:52:47 12345678 806AA000A1 Status] Response Code: 7 Ret. Ref. No: 000067800010
[2015-08-20T09:52:47 12345678 806AA000A1 Debug] Event Notify : Event Notification: EventLog
[2015-08-20T09:52:47 12345678 806AA000A1 Debug] Physical memory available: 12796 Kb, used: 22844 Kb (Managed = 1358 Kb, Unmanaged = 21486 Kb
[2015-08-20T09:52:47 12345678 806AA000A1 Spam] [EMV] EmvSetIcsValue returned OK
[2015-08-20T09:52:51 12345678 806AA000A1 Spam] [EMV] EmvSetIcsValue returned OK
[2015-08-20T09:52:51 12345678 806AA000A1 Debug] InternalShowStandardScreen SCR100_IdleScreen

Figure 3 - Example Diagnostic Log File
The event log comprises the subset of items in the diagnostic log with an event type of 'Status' or 'Error'.

ECR Payment Card Entry

The communications link between the ECR device and payment terminal is not secured and no PCI sensitive data is transported across this link. This limits the types of card data received by the payment terminal from the ECR that can be processed.

Acceptable Card Types

In general the bonus and payment cards are swiped/inserted in the payment terminal. For non-PCI payment cards it is possible that the card information be entered on the ECR device and sent to the payment terminal for processing.
In this context non-PCI payment cards include bonus or loyalty cards and payment cards that have the National Card flag set (see PPL Ref [2], BINPAR Bitfields 2, National Card bit). Cards with a PAN number referencing a BINROW configured in the payment terminal that does not meet these criteria will be rejected by the payment terminal.

ECR Data Entry

It is up to the ECR implementer to decide how the operator inputs the card data, it may be swiped, RFID/NFC or keyed.

Payment Request

If the card details are entered on the ECR device then they are supplied to the payment terminal in the Payment Request message. The information is provided in the CardData element; see Ref [4] section

Network Security

The only device expected to connect to the payment terminal is the controlling ECR device. In practice this will be physically located to close to the payment terminal and share the same network subnet.
For maximum network security it is recommended that the sub-net firewall shall block all attempts for an external device to attempt to access the payment terminal.

The payment terminal will make outgoing connections to the SPDH and PPL hosts. If these hosts are located outside the firewall, the firewall must be configured to allow these connections. Check with the host providers the addresses and port numbers being used.

Wireless Networks

The payment terminal does not support a wireless network connection. However, the PCI DSS specification mandates:

    1. That traffic from any wireless network is protected with a firewall.
    2. Wireless devices shall have their security keys, access codes and identification strings changed from the factory defaults.
    3. The level of encryption use must be stronger than WEP.

The reader is recommended to refer to the PCI Specification (Ref [1]) for more details.

Remote Terminal Management and Configuration Update

With the exception of the PPL configuration files, the payment terminal does not support any form of remote access or configuration. It is not possible to remotely log on to the terminal (e.g. for diagnostic or administrative purposes).
Any configuration changes are performed directly via the keyboard and built in management functions or using the PPL configuration files. These files are all protected by both data content and file cryptographic MAC. The terminal will validate the MAC before processing the data contained in the file.
Details of the protection and content of these files may be found in Ref [2]. The PPL files are also used to transfer any application upgrades to the terminal.

Software Security

To ensure that the application running in the terminal has not been tampered with since it was created a chain of authentication back to the software build is needed. This is shown diagrammatically in Figure 4.

Figure 4 - End to End Software Integrity Checking
Between XAC and Westpay the software deliveries are signed with an MD5 signature. To ensure that integrity of the MD5 signature it is transferred via a different route to that of the software. ???Typically the software is delivered via and FTP server while the MD5 signatures are sent via e-mail???

Signature Verification

Westpay verify the MD5 signatures of the XAC libraries before they are built into the payment application. If any of the signatures do not match the build is aborted. (Blue MD5 signature in Figure 4).
The Westpay build process generates an MD5 checksum of the payment application. This shall be verified by Westpay within the secure room and only if found to match will the software be signed with the live application signing key. (Green MD5 signature).
The software signature added in the Westpay secure room is a cryptographic signature that is attached to the application (Dark orange arrow). This signature is verified by the XAC platform software each time the application is started.
The PPL configuration protocol uses additional MAC checksum on the file content and the overall file as the file is distributed. These provide additional security to ensure that the correct files is delivered by the configuration server to the terminal. Note that the PPL MACs are based on cryptographic keys managed by the payment service provider. This differs from the software signature where the key is managed by Westpay. Further details of the file formats can be found in Ref [2].

Software Updates

The payment terminal does not support the concept of patching an existing software release. If a change is needed to the application (regardless of how small) the whole of the application must be rebuilt and released.
A field software upgrade is performed using the PPL DCAPP file.
To create a single downloadable file the XAC software signing tool is used. This tool performs two functions, it signs the software and it packs it into a single file. It is the output file that is then transported via the PPL DCAPP file to the terminal. This signing operation must be performed in the Westpay secure room???

Protection for Failed Software Upgrades

There is a small and very unlikely risk that the new application does not start correctly so the bootloader will monitor the startup process. After three failed attempts to start the application the boot loader will disable the new application and revert to the previous version. Note that it can take one minute for the bootloader to recognise that the application has not started. There if, after a download the terminal does not start correctly the user must wait a full minute before resetting the terminal and trying again. This will need to be repeated 3 times before it reverts to the earlier software.
If the application successfully starts but cannot communicate with the communications network or there is some other problem it is possible to remove the latest version of the application manually via the management functions. This should only be performed on instruction from you help desk."

Communication Protocols

The payment application requires three distinct communication protocols to operate. These are all based on the TCP/IP network protocols. No other network protocols or data communications are supported.

ECR Interface

The ECR communicates with the payment terminal using the EPAS protocol. OPI??? The messages and data fields supported are those relevant to this application. A few extensions have been provided to support additional features (e.g. ECR device is formatting the receipt printing). The message data fields are defined in Ref [4].
The messages are defined in XML and contain a simple length indicator in a header. The length indicator allows the receiver to determine how long the following message is. The receiver must wait for the complete message to be received before processing it.
The payment terminal acts as a server for this communication channel. It will wait for the ECR device to establish the connection. Only a single ECR device may be connected at any one time.
It is assumed that the ECR connection is performed over a private network. Any ECR device conforming to the ECR protocol may connect to the terminal.
This link does not use encryption and no PCI sensitive data is sent over the link. Any card PAN information (e.g. being sent as part of the receipt data) will be sent with the middle digits obscured. Bonus (loyalty) card data which is outside the PCI definition of sensitive data may be sent across this link for the ECR device or payment terminal to process.

Transaction Host

The payment terminal communication to the transaction host follows the SPDH specification (Ref [3]). The ACISTD low level protocol (Ref [3], section Appendix A) is included over the TCP/IP stream.
The SPDH messages use encryption at the application level for any sensitive data and all messages contain a MAC to prevent changes being made to the message. These measures ensure both the safety of the sensitive data against eavesdropping and allow the receiver to authenticate the message sender.
The payment terminal acts as the TCP/IP client and establishes the connection to the transaction host. There is no pre-defined TCP/IP port used for this communication and the terminal will attempt to connect on whatever port number it is provided with.
Provided there appears to be a valid TCP/IP path between the payment terminal and the transaction host, it is up to the integrator how the messages are routed. This includes different combinations public, private or VPN networks with gateways and firewalls between them.

Configuration Host

The terminal's payment application configuration information is provided in a set of PPL configuration files. The format, including the content and file MAC requirements are defined in Ref [2], including the format of the files used for key loading.
When one or more new configuration files are required the payment terminal first establishes a FTP client connection to the PPL server and then requests (FTP Get) the files to be transferred to the terminal.
Before the files are processed the content and file MACs are checked The CAPUB file has a third MAC that is also verified by the terminal before the public key information it contains is processed.. This performs two functions, it authenticates that the files came from a known source (the provider and terminal must both know the same security key to generate the MAC) and that the data has not been tampered with while it was transported to the terminal.
The key load files use a different file format and rely on the key's KCV to authenticate the data. Details are in Ref [2].
There is no pre-defined TCP/IP port used for this communication and the terminal will attempt to connect on whatever port number it is provided with.
Provided there appears to be a valid TCP/IP path between the payment terminal and the configuration host, it is up to the integrator how the messages are routed. This includes different combinations public, private or VPN networks with gateways and firewalls between them.


  • No labels