EPAS

Last updated: 2026-06-05

Revision History

Date	Author	Notes
06/06/26	Westpay	Migrated the EPAS documentation to the new portal format and consolidated protocol guidance, examples, and flows.
18/11/20	Colin MacDonald	Added revision history for change tracking
18/11/20	Johan Ekberg	Added `ExtAuth` element to receipt data to indicate that an external payment process was used
18/2/21	Per Erik Stendahl	Added the `MarkUpDescription` field in the DCC information
1/6/21	Per Erik Stendahl	Added the `ExtraPOIID` element to the `LoginRequest` message
16/2/22	Markus Jagerskogh	Added the attributes `Method` and `ReferenceNumber` to `PaymentData` and `AlternativePaymentMethod` to receipt data

Introduction

This page describes the EPAS protocol implementation in the Westpay payment application.

The EPAS protocol is one method of controlling a payment terminal from an Electronic Cash Register (ECR). The protocol is intentionally broad, and much of the full EPAS specification is not needed for this integration model. At the same time, there are gaps in the base protocol that require Westpay-specific adaptations.

The purpose of this page is to show which EPAS messages are used, which parts of those messages are relevant, and which messages or fields have been customised to fit the payment application.

This page refers conceptually to two specifications:

EPAS Org, Sale to POI Protocol Specifications Version 1.0, dated 10 October 2010
BABS and CEKAB Cardholder and Operator Interface Version 4.02, dated 25 August 2009

The EPAS specification is the primary source for protocol behaviour. The BABS and CEKAB material is relevant for standardised screen layouts and display messaging.

Protocol Overview

The interface between the payment application and the ECR provides a range of functionality including:

ECR login
Starting a transaction
Handling message display on the ECR
Printing receipts on the ECR
Performing administrative functions

In an EPAS environment the ECR is the retailer's interface to the complete sales system, while the payment terminal is the customer's interface. During a customer transaction, the retailer must therefore be able to control and instruct the terminal through the ECR display and keyboard.

Message Transport And Encoding

All EPAS messages are XML encoded. XML schema files are used by the payment application to validate inbound messages in real time. The schema files are based on the EPAS message schemas but are extended to include the additional messages and fields used by this implementation. Messages that fail schema validation are not processed.

TCP/IP Network Connection

When operating over a TCP/IP network connection, all messages are preceded by a four-byte length field as described in the EPAS specification.

You can find the terminal IP by pressing 1 4 7 3 6 9 from the terminals closed screen, then opening the Status menu and browsing until the terminal IP is shown.

Default Communication Port

The default communication port for EPAS implementations is 3000.

Keepalive

Once connected, the ECR must send something to the terminal at regular intervals. Otherwise, the terminal will assume that the ECR has gone offline or lost connection and will terminate any ongoing service.

If the ECR has no application data to send, it can send an empty packet consisting of four zero bytes. Since the first four bytes of an EPAS message indicate the message size, this is effectively an empty message.

The ECR should aim to send something every two seconds.

The normal approach is to keep a two-second timer. Whenever something is sent to the terminal, the timer is reset. Whenever the timer fires, an empty message can be sent and the timer is reset again.

Message Header

The EPAS specification defines a header for each message type. The header can contain the following fields:

Component	Description
`ProtocolVersion`	Version of the EPAS Sale-to-POI protocol. Mandatory for a login request and absent for other messages.
`MessageClass`	Message class.
`MessageCategory`	Category of message.
`MessageType`	Request, response, or notification type.
`ServiceID`	Service ID used to identify a request and response dialogue.
`DeviceID`	Device-class identifier used to match a request and response pair.
`WorkstationID`	Identifies the terminal from the EPAS protocol perspective. Once established, messages with a different workstation ID are ignored.
`POIID`	Identifies the terminal in the wider payment processing system. This terminal ID is used in PPL configuration and SPDH authorisation requests.

For compactness, the message header is not repeated inside the message tables below.

Message Contents

This section describes the EPAS messages that are supported. Each message is described using the conventions below.

Field Repetitions

The column marked Mult. describes the minimum and maximum occurrences of a particular element or field.

Mult.	Meaning
`[1..1]`	Mandatory exactly once
`[0..1]`	Optional, at most once
`[0..n]`	Optional, repeatable

Field Rule

The column marked Rule indicates any special conditions that apply to the field.

Field Usage

The column marked Usage is interpreted differently depending on message direction.

On messages originating from the ECR:

Yes means the payment application uses the element or attribute if it is present
No means the element or attribute may occur but is ignored

On messages originating from the terminal:

Yes means the payment application populates the element or attribute
No means the element or attribute is either omitted or present without valid data

If an element is marked Yes, its children and attributes are assumed to be Yes unless stated otherwise. The same applies for No.

Mandatory Elements

Messages from the ECR to the terminal are validated against the EPAS XML schema. That means elements that are mandatory in the schema must still be present even if they are not functionally used by Westpay.

If a data element is not used, its contents are ignored as long as the schema requirements are met.

Variations From The EPAS Specification

This implementation adds selected fields that are not part of the base EPAS specification and also intentionally ignores some standard fields.

Login Message

The Login request enables transaction processing and provides the key runtime configuration for the terminal, including POIID, transaction host, and configuration host.

Login Request Message

Component	Mult.	Rule	Usage
`LoginRequest`	`[1..1]`
`DateTime`	`[1..1]`		Yes
`SalesSoftware`	`[1..1]`		No
`ManufacturerID`	`[1..1]`
`ApplicationName`	`[1..1]`
`SoftwareVersion`	`[1..1]`
`CertificationCode`	`[1..1]`
`SaleTerminalData`	`[0..1]`	Present if login involves a Sale Terminal	No
`TerminalEnvironment`	`[1..1]`
`SaleCapabilities`	`[1..1]`
`SaleProfile`	`[0..1]`	If at least one child is present
`GenericProfile`	`[0..1]`	Default `Standard`
`ServiceProfiles`	`[0..1]`	If a service profile could be requested
`TotalsGroupID`	`[0..1]`	Default for all transactions if present
`TrainingModeFlag`	`[0..1]`	Default `False`	No
`OperatorLanguage`	`[1..1]`	Default value for device displays	Yes
`OperatorID`	`[0..1]`	Sent when operator identity is needed	Yes
`ShiftNumber`	`[0..1]`	Same conditions as `OperatorID`	No
`POISerialNumber`	`[0..1]`	If login involves a POI terminal and not the first login	No
`ConfigData`	`[0..1]`		Yes
`TxnHostAddress`	`[1..1]`	Hostname or dotted IP, optional port
`ConfigHostAddress`	`[1..1]`	Hostname or dotted IP, optional port
`ConfigFile`	`[1..1]`	Not currently used
`StorePay`	`[0..1]`	Svea StorePay or WebPay credentials	Yes
`ID`	`[1..1]`	Svea web API login ID
`Password`	`[1..1]`	Svea web API password
`ExtraPOIID`	`[0..1]`	Alternative TSP IDs, separated by spaces	Yes

Login Request Notes

Field	Notes
`OperatorLanguage`	Used as the default language for device displays.
`ConfigData.TxnHostAddress`	Can be a hostname or dotted IP address, optionally with port.
`ConfigData.ConfigHostAddress`	Can be a hostname or dotted IP address, optionally with port.
`StorePay`	Used for Svea StorePay or WebPay credentials.
`ExtraPOIID`	Used for alternative TSP IDs in multi-TID scenarios.

Login Request Example

This example shows a login request carrying cashier identity, language, serial number, and configuration hosts.

xml
<?xml version="1.0" encoding="UTF-8"?>
<SaleToPOIRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="EpasSaleToPOIMessages.xsd">
  <MessageHeader ProtocolVersion="1.0" MessageClass="Service" MessageCategory="Login" MessageType="Request" ServiceID="" WorkstationID="" POIID=""/>
  <LoginRequest OperatorLanguage="sp" OperatorID="Cashier16" ShiftNumber="2" POISerialNumber="78910AA46010005">
    <DateTime></DateTime>
    <SaleSoftware ManufacturerID="PointOfSaleCo" ApplicationName="SaleSys" SoftwareVersion="01.98.01" CertificationCode="ECTS2PS001"/>
    <SaleTerminalData />
    <ConfigData>
      <TxnHostAddress></TxnHostAddress>
      <ConfigHostAddress></ConfigHostAddress>
      <ConfigFile></ConfigFile>
    </ConfigData>
  </LoginRequest>
</SaleToPOIRequest>

Login Response Message

Component	Mult.	Rule	Usage
`LoginResponse`	`[1..1]`
`Response`	`[1..1]`		Yes
`Result`	`[1..1]`	`Success` or `Failure`
`ErrorCondition`	`[0..1]`	Error classification in failure case
`AdditionalResponse`	`[0..1]`	Problem description in failure case
`POISystemData`	`[0..1]`	If `Response.Result` is `Success`	Yes
`DateTime`	`[1..1]`	Current date and time on terminal	Yes
`POISoftware`	`[1..1]`		Yes
`ManufacturerID`	`[1..1]`	Empty
`ApplicationName`	`[1..1]`	Empty
`SoftwareVersion`	`[1..1]`	Payment application version
`CertificationCode`	`[1..1]`	Empty
`POITerminalData`	`[0..1]`	Present if login involves a POI Terminal	Yes
`TerminalEnvironment`	`[1..1]`	`Attended`
`POICapabilities`	`[1..1]`	`CustomerDisplay CustomerError CustomerInput MagStripe ICC`
`POIProfile`	`[0..1]`	If at least one child is present	No
`GenericProfile`	`[0..1]`	Default `Standard`
`ServiceProfiles`	`[0..1]`	If a service profile could be requested
`POISerialNumber`	`[1..1]`	Terminal serial number
`POIStatus`	`[0..1]`	If `Response.Result` is `Success`	No
`GlobalStatus`	`[1..1]`
`SecurityOKFlag`	`[0..1]`	If security module present
`PEDOKFlag`	`[0..1]`	If PED present
`CardReaderOKFlag`	`[0..1]`	If card reader present
`PrinterOKFlag`	`[0..1]`	If printer present
`CommunicationOKFlag`	`[0..1]`	If communication infrastructure present
`FraudPreventionFlag`	`[0..1]`	Default `False`

Login Response Example

xml
<SaleToPOIResponse>
  <MessageHeader ProtocolVersion="1.0" MessageClass="Service" MessageCategory="Login" MessageType="Response" ServiceID="2251" WorkstationID="" POIID="52400004" />
  <LoginResponse>
    <Response Result="Success" />
    <POISystemData>
      <DateTime>2015-11-18T16:21:07.0+00:00</DateTime>
      <POISoftware ManufacturerID="" ApplicationName="" SoftwareVersion="0.0.0" CertificationCode="" />
      <POITerminalData TerminalEnvironment="Attended" POISerialNumber="D0029">
        <POICapabilities>CustomerDisplay CustomerError CustomerInput MagStripe ICC</POICapabilities>
      </POITerminalData>
    </POISystemData>
  </LoginResponse>
</SaleToPOIResponse>

Logout Message

Logout is used when login context changes or when the ECR wants the terminal to return to idle mode.

Logout Request Message

Component	Mult.	Rule	Usage
`LogoutRequest`	`[1..1]`	No children or attributes

Logout Response Message

Component	Mult.	Rule	Usage
`LogoutResponse`	`[1..1]`
`Response`	`[1..1]`		Yes
`Result`	`[1..1]`	`Success` or `Failure`
`ErrorCondition`	`[0..1]`	Error classification in failure case
`AdditionalResponse`	`[0..1]`	Problem description in failure case

Logout Request Example

xml
<SaleToPOIRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="EpasSaleToPOIMessages.xsd">
  <MessageHeader ProtocolVersion="1.0" MessageClass="Service" MessageCategory="Logout" MessageType="Request" ServiceID="1" WorkstationID="" POIID=""/>
  <LogoutRequest/>
</SaleToPOIRequest>

Logout Response Example

xml
<SaleToPOIResponse>
  <MessageHeader ProtocolVersion="1.0" MessageClass="Service" MessageCategory="Logout" MessageType="Response" ServiceID="2252" WorkstationID="" POIID="52400004" />
  <LogoutResponse>
    <Response Result="Success" />
  </LogoutResponse>
</SaleToPOIResponse>

Admin Message

Admin requests trigger terminal-level administrative operations that are not tied to an active transaction.

Admin Request Message

Component	Mult.	Rule	Usage
`AdminRequest`	`[1..1]`
`ServiceIdentification`	`[0..1]`	Required service name	Yes
`OperatorID`	`[0..1]`	Used for `HostLogin` when merchants share a terminal	Yes

ServiceIdentification Values

Value	Function
`ResetMerchantPassword`	Resets the merchant password.
`PrintLastEMVTransaction`	Prints EMV data from the last transaction.
`PrintTerminalConfig`	Prints terminal configuration details.
`ExtractLogFiles`	Sends the current trace log to the ECR over FTP on port 21.
`LogLevel_0` to `LogLevel_4`	Changes terminal logging verbosity.
`UpdateParameters`	Requests parameter download and install from the PPL server.
`HostLogin`	Performs a SPDH host login transaction.
`ExtractTransactions`	Requests a summary of recent transactions.

Admin Response Message

Component	Mult.	Rule	Usage
`AdminResponse`	`[1..1]`
`Response`	`[1..1]`
`Result`	`[1..1]`	`Success` or `Failure`	Yes
`ErrorCondition`	`[0..1]`	Error classification in failure case	Yes
`AdditionalResponse`	`[0..1]`	Problem description in failure case	Yes
`AdditionalData`	`[0..1]`	Additional data depending on request	Yes

Admin Request Examples

xml
<SaleToPOIRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="EpasSaleToPOIMessages.xsd">
  <MessageHeader MessageClass="Service" MessageCategory="Admin" MessageType="Request" ServiceID="1" WorkstationID="" POIID=""/>
  <AdminRequest>
    <ServiceIdentification>PrintLastEMV</ServiceIdentification>
    <OperatorID/>
  </AdminRequest>
</SaleToPOIRequest>

xml
<SaleToPOIRequest>
  <MessageHeader MessageClass="Service" MessageCategory="Admin" MessageType="Request" ServiceID="2254" WorkstationID="" POIID="52400004" />
  <AdminRequest>
    <ServiceIdentification>HostLogin</ServiceIdentification>
  </AdminRequest>
</SaleToPOIRequest>

xml
<SaleToPOIRequest>
  <MessageHeader MessageClass="Service" MessageCategory="Admin" MessageType="Request" ServiceID="2254" WorkstationID="" POIID="52400004" />
  <AdminRequest>
    <ServiceIdentification>UpdateParameters</ServiceIdentification>
  </AdminRequest>
</SaleToPOIRequest>

Admin Response Example

xml
<SaleToPOIResponse>
  <MessageHeader ProtocolVersion="1.0" MessageClass="Service" MessageCategory="Admin" MessageType="Response" ServiceID="2254" WorkstationID="" POIID="52400004" />
  <AdminResponse>
    <Response Result="Success" />
  </AdminResponse>
</SaleToPOIResponse>

Admin Function - ExtractTransactions

The EPAS AdminRequest message is also used for selected out-of-protocol requests from the ECR to the payment application. One of them is ExtractTransactions, which returns a summary of recent financial transactions.

In this context, a transaction means a financial transaction that was either sent online or added to the Store & Forward queue for later online submission. Administrative transactions are not recorded.

The payment application does not store all transactions indefinitely. At the time of writing, roughly 30 days of transactions are retained in the local database.

ExtractTransactions Request

The normal EPAS AdminRequest does not allow extra parameters, but for ExtractTransactions it is useful to specify a date range. This is done by adding the attributes StartDate and EndDate to the ServiceIdentification element.

The dates are formatted as yyyyMMddHHmmss.

ExtractTransactions Request Example

xml
<?xml version="1.0" encoding="UTF-8"?>
<SaleToPOIRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="EpasSaleToPOIMessages.xsd">
  <MessageHeader MessageClass="Service" MessageCategory="Admin" MessageType="Request" ServiceID="2795" WorkstationID="" POIID="52400004" />
  <AdminRequest>
    <ServiceIdentification StartDate="20160403170641" EndDate="20160413180641">ExtractTransactions</ServiceIdentification>
  </AdminRequest>
</SaleToPOIRequest>

ExtractTransactions Response

The response uses the non-standard AdditionalData element inside AdminResponse. In this flow, AdditionalData contains a Transactions element, which in turn contains zero or more Transaction elements represented through attributes.

If no transactions exist for the requested period, or if EndDate is earlier than StartDate, the Transactions element is returned empty.

If StartDate or EndDate is missing or cannot be parsed, the terminal returns a standard EPAS error response.

Attribute	Meaning
`transdate`	Transaction date and time in `yyyyMMddHHmmss` format
`type`	Transaction type such as `Purchase`, `Refund`, `Cash advance`, or `Other`. Reversal transactions are identified with values such as `Purchase reversal`.
`amount`	Total transaction value in sub-units of the operating currency. For example, `320.00 SEK` is returned as `32000`.
`extra`	Extra or tip amount in sub-units of the operating currency. This amount is included in `amount`.
`cashback`	Cashback amount in sub-units of the operating currency. This amount is included in `amount`.
`reference`	Retrieval reference number for the transaction. Reversals reuse the same reference number as the original transaction.
`authcode`	Transaction authorisation code. Codes beginning with `L` are locally authorised.
`hostresponse`	Authorisation-host response value. This is `0` for locally authorised transactions.
`institution`	Card-provider institution from terminal configuration
`batch`	Transaction batch number. Batch-closure transactions are not recorded, but a changed batch value indicates that a batch boundary has passed.
`cardname`	Card name from terminal configuration or card data

ExtractTransactions Response Example

xml
<?xml version="1.0" encoding="utf-8"?>
<SaleToPOIResponse>
  <MessageHeader ProtocolVersion="1.0" MessageClass="Service" MessageCategory="Admin" MessageType="Response" ServiceID="2791" WorkstationID="" POIID="52400004" />
  <AdminResponse>
    <Response Result="Success" />
    <AdditionalData>
      <Transactions>
        <Transaction transdate="20160407115756" type="Purchase" amount="12500" extra="0" cashback="0" reference="000000402012" authcode="832322 B" hostresponse="1" institution="SWE" batch="146" cardname="MAESTRO" />
        <Transaction transdate="20160408174406" type="Purchase" amount="12500" extra="0" cashback="0" reference="000000402013" authcode="244642 B" hostresponse="1" institution="SWE" batch="146" cardname="MAESTRO" />
        <Transaction transdate="20160413171904" type="Purchase" amount="12500" extra="0" cashback="0" reference="000000402014" authcode="931131 B" hostresponse="1" institution="SWE" batch="146" cardname="MAESTRO" />
        <Transaction transdate="20160413171921" type="Refund" amount="12500" extra="0" cashback="0" reference="000000402015" authcode="L00188" hostresponse="0" institution="SWE" batch="146" cardname="MAESTRO" />
        <Transaction transdate="20160413171951" type="Purchase" amount="40000" extra="0" cashback="0" reference="000000402016" authcode="308825 B" hostresponse="1" institution="SWE" batch="146" cardname="VISA" />
        <Transaction transdate="20160413172001" type="Purchase reversal" amount="40000" extra="0" cashback="0" reference="000000402016" authcode="308825 B" hostresponse="" institution="SWE" batch="146" cardname="VISA" />
        <Transaction transdate="20160413172318" type="Purchase" amount="40000" extra="0" cashback="0" reference="000000402017" authcode="745320 B" hostresponse="1" institution="SWE" batch="146" cardname="VISA" />
        <Transaction transdate="20160413174149" type="Purchase" amount="99900" extra="11100" cashback="11100" reference="000000402018" authcode="117149 B" hostresponse="1" institution="SWE" batch="146" cardname="VISA" />
        <Transaction transdate="20160413174212" type="Purchase" amount="66600" extra="11100" cashback="22200" reference="000000402019" authcode="626301 B" hostresponse="1" institution="SWE" batch="146" cardname="VISA" />
        <Transaction transdate="20160413174846" type="Cash advance" amount="30000" extra="0" cashback="0" reference="000000402020" authcode="687173 B" hostresponse="1" institution="SWE" batch="146" cardname="VISA" />
      </Transactions>
    </AdditionalData>
  </AdminResponse>
</SaleToPOIResponse>

Enable Service Message

Enable Service lets the ECR open or close the card readers outside an active payment, for example in swipe-ahead or early-card scenarios.

Enable Service Request Message

Component	Mult.	Rule	Usage
`EnableService`	`[1..1]`
`TransactionAction`	`[1..1]`	`StartTransaction` or `AbortTransaction`	Yes
`ServicesEnabled`	`[0..1]`		No
`DisplayOutput`	`[0..1]`	Display abort or state message to customer	No
`Device`	`[1..1]`	`CustomerDisplay`
`InfoQualify`	`[1..1]`	`Error`
`OutputContent`	`[1..1]`
`OutputFormat`	`[1..1]`
`PredefinedContent`	`[0..1]`	Same as Display
`ReferenceID`	`[1..1]`
`Language`	`[0..1]`	Same as Display
`OutputText`	`[0..n]`	Same as Display
`Text`	`[1..1]`
`CharacterSet`	`[0..1]`	Same as Display
`Font`	`[0..1]`	Same as Display
`StartRow`	`[0..1]`	Same as Display
`StartColumn`	`[0..1]`	Same as Display
`Color`	`[0..1]`	Same as Display
`CharacterWidth`	`[0..1]`	Same as Display
`CharacterHeight`	`[0..1]`	Same as Display
`CharacterStyle`	`[0..1]`	Same as Display
`Alignment`	`[0..1]`	Same as Display
`OutputXHTML`	`[0..1]`	Same as Display
`OutputSignature`	`[0..1]`	If text must be protected

TransactionAction Values

Value	Meaning
`StartTransaction`	Opens the card readers and begins card acquisition ahead of the transaction.
`AbortTransaction`	Closes the readers and stops card processing.

Enable Service Response Message

Component	Mult.	Rule	Usage
`EnableService`	`[1..1]`		Yes
`Response`	`[1..1]`
`Result`	`[1..1]`	`Success` or `Failure`
`ErrorCondition`	`[0..1]`	Error classification in failure case
`AdditionalResponse`	`[0..1]`	Problem description in failure case

Enable Service Request Example

xml
<SaleToPOIRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="EpasSaleToPOIMessages.xsd">
  <MessageHeader MessageClass="Service" MessageCategory="EnableService" MessageType="Request" ServiceID="1" WorkstationID="" POIID=""/>
  <EnableServiceRequest TransactionAction="StartTransaction" />
</SaleToPOIRequest>

Enable Service Response Example

xml
<SaleToPOIResponse>
  <MessageHeader ProtocolVersion="1.0" MessageClass="Service" MessageCategory="EnableService" MessageType="Response" ServiceID="2255" WorkstationID="" POIID="52400004" />
  <EnableServiceResponse>
    <Response Result="Success" />
  </EnableServiceResponse>
</SaleToPOIResponse>

Payment Message

Payment is the core transactional message. A request can include the amount immediately or defer it for early-PIN or swipe-ahead flows.

Payment Request Message

Component	Mult.	Rule	Usage
`PaymentRequest`	`[1..1]`
`SaleData`	`[1..1]`		Yes
`OperatorID`	`[0..1]`	If different from Login	No
`OperatorLanguage`	`[0..1]`	If different from Login	No
`ShiftNumber`	`[0..1]`	If different from Login	No
`SaleTransactionID`	`[1..1]`		Yes
`TransactionID`	`[1..1]`
`TimeStamp`	`[1..1]`
`SaleReferenceID`	`[0..1]`	If payment reservation	No
`SaleTerminalData`	`[0..1]`	If not empty	No
`TerminalEnvironment`	`[0..1]`	If modified since Login
`SaleCapabilities`	`[0..1]`	If modified since Login
`TotalsGroupID`	`[0..1]`	If modified or newly used
`SaleToPOIData`	`[0..1]`	Stored with transaction	No
`SaleToAcquirerData`	`[0..1]`	Sent to acquirer if present	No
`SaleToIssuerData`	`[0..1]`	Sent to acquirer if present	No
`StatementReference`	`[0..1]`	Printed on bank statement	No
`PaymentTransaction`	`[1..1]`
`AmountsReq`	`[1..1]`
`Currency`	`[1..1]`		Yes
`RequestedAmount`	`[0..1]`		Yes
`CashBackAmount`	`[0..1]`	If cashback requested	Yes
`TipAmount`	`[0..1]`	`0` disables tipping for transaction	No
`PaidAmount`	`[0..1]`	If `SplitPaymentFlag` is true	No
`MinimumAmountToDeliver`	`[0..1]`	Reservation or minimum amount case	No
`MaximumCashBackAmount`	`[0..1]`	Max cashback allowed	No
`MinimumSplitAmount`	`[0..1]`	Minimum split amount	No
`OriginalTransaction`	`[0..1]`	For refund or reservation updates	No
`POITransactionID`	`[0..1]`	If `SaleReferenceID` is insufficient
`TransactionID`	`[1..1]`
`TimeStamp`	`[1..1]`
`POIID`	`[0..1]`	If original transaction is from another POI	No
`ReuseCardDataFlag`	`[0..1]`	Default `True`	No
`ApprovalCode`	`[0..1]`	If referral	No
`TransactionConditions`	`[0..1]`	If one child is present	Yes
`AllowedPaymentBrand`	`[0..n]`	Restrict brand if present	No
`AllowedLoyaltyBrand`	`[0..n]`	Restrict brand if present	No
`LoyaltyHandling`	`[0..1]`	Default `Allowed`	No
`CustomerLanguage`	`[0..1]`	If customer selected language in ECR	No
`ForceOnlineFlag`	`[0..1]`	Default `False`	No
`ForceEntryMethod`	`[0..n]`	Restrict entry mode	No
`MerchantCategoryCode`	`[0..1]`	Specific MCC required	No
`AllowChipXpress`	`[0..1]`	Default `true`; `false` disables feature	Yes
`WaitCardRemoval`	`[0..1]`	Default `true`; `false` completes before card removal	Yes
`DisableTip`	`[0..1]`	Default `false`; `true` disables tip entry	Yes
`DisableBankAxept`	`[0..1]`	Default `false`; `true` disables special handling	Yes
`SaleItem`	`[0..n]`	If purchased products are needed	Yes
`ItemID`	`[1..1]`	Required by schema when `SaleItem` is present	Yes
`ProductCode`	`[1..1]`	Product group or code	Yes
`EanUpc`	`[0..1]`	If host protocol supports it	No
`UnitOfMeasure`	`[0..1]`		No
`Quantity`	`[0..1]`	If host protocol supports it	No
`UnitPrice`	`[0..1]`		No
`ItemAmount`	`[1..1]`	Required by schema when `SaleItem` is present	Yes
`TaxCode`	`[0..1]`	If host protocol supports it	No
`SaleChannel`	`[0..1]`	If host protocol supports it	No
`AdditionalProductInfo`	`[0..1]`	If host protocol supports it	No
`PaymentData`	`[0..1]`	If one child is present	Yes
`PaymentType`	`[0..1]`	Default `Normal`	Yes
`Method`	`[0..1]`	Alternative payment method: `Swish`, `Vipps`, `Klarna`	Yes
`ReferenceNumber`	`[0..1]`	Required for reversal of alternative payment method	Yes
`SplitPaymentFlag`	`[0..1]`	Default `False`	No
`RequestedReservationTimePeriod`	`[0..1]`	Reservation period requested	No
`CardAcquisitionReference`	`[0..1]`	If card data comes from prior acquisition	No
`TransactionID`	`[1..1]`		No
`TimeStamp`	`[1..1]`		No
`PaymentInstrumentData`	`[0..1]`	If Sale System read payment instrument	Yes
`PaymentInstrumentType`	`[1..1]`	Only `Card` accepted	Yes
`CardData`	`[0..1]`	If `PaymentInstrumentType` is `Card`	Yes
`EntryMethod`	`[1..1]`	`Magstripe` or `Manual`	Yes
`SensitiveCardData`	`[0..1]`	Unprotected or enveloped structure	Yes
`PAN`	`[0..1]`	If entry is file, keyed, or manual	Yes
`CardSeqNumb`	`[0..1]`	If available on card	No
`ExpirationDate`	`[0..1]`	If available on card	Yes
`TrackData`	`[0..3]`	If entry is MagStripe or RFID	Yes
`TrackNumb`	`[0..1]`	Default `2`	No
`TrackFormat`	`[0..1]`	Default `ISO`	No
`TrackValue`	`[1..1]`		Yes
`LoyaltyData`	`[0..n]`	Loyalty cards used with payment	No
`CardAcquisitionReference`	`[0..1]`
`TransactionID`	`[1..1]`
`TimeStamp`	`[1..1]`
`LoyaltyAccountID`	`[0..1]`
`EntryMethod`	`[1..1]`
`IdentificationType`	`[1..1]`
`LoyaltyID`	`[1..1]`
`LoyaltyAmount`	`[0..1]`	Additional loyalty award
`LoyaltyUnit`	`[0..1]`
`Currency`	`[0..1]`
`AmountValue`	`[1..1]`

Payment Request Notes

Field	Notes
`PaymentData.PaymentType`	Default is `Normal`. Westpay also supports `Refund` and `CashAdvance`.
`PaymentData.Method`	Used to force a specific alternative payment method such as `Swish`, `Vipps`, or `Klarna`.
`PaymentData.ReferenceNumber`	Required for reversal of an alternative payment method transaction.
`TransactionConditions.AllowChipXpress`	Set `false` to disable ChipXpress.
`TransactionConditions.WaitCardRemoval`	Set `false` to return the payment response before card removal.
`TransactionConditions.DisableTip`	Set `true` to disable tip entry.
`TransactionConditions.DisableBankAxept`	Set `true` to disable BankAxept special handling.

Payment Request Examples

These examples show three useful request variants that complement the field tables:

Standard payment or refund shape with AmountsReq, TransactionConditions, and SaleItem.
Manually keyed card data using PaymentInstrumentData.
Track-data based card submission using SensitiveCardData.TrackData.

xml
<SaleToPOIRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="EpasSaleToPOIMessages.xsd">
  <MessageHeader MessageClass="Service" MessageCategory="Payment" MessageType="Request" ServiceID="" WorkstationID="" POIID=""/>
  <PaymentRequest>
    <SaleData OperatorID="">
      <SaleTransactionID TransactionID="" TimeStamp=""/>
    </SaleData>
    <PaymentTransaction>
      <AmountsReq Currency="SEK" RequestedAmount="0.00" CashBackAmount="0.00"/>
      <TransactionConditions AllowChipXpress="true" WaitCardRemoval="true" DisableTip="false" DisableBankAxept="false"/>
      <SaleItem ItemID="1" ProductCode="000" ItemAmount="0"/>
    </PaymentTransaction>
    <PaymentData PaymentType="Refund"/>
  </PaymentRequest>
</SaleToPOIRequest>

xml
<PaymentData>
  <PaymentInstrumentData PaymentInstrumentType="Card">
    <CardData EntryMethod="Manual">
      <SensitiveCardData PAN="" CardSeqNumb="" ExpirationDate=""/>
    </CardData>
  </PaymentInstrumentData>
</PaymentData>

xml
<PaymentData>
  <PaymentInstrumentData PaymentInstrumentType="Card">
    <CardData EntryMethod="Magstripe">
      <SensitiveCardData>
        <TrackData TrackValue=""/>
      </SensitiveCardData>
    </CardData>
  </PaymentInstrumentData>
</PaymentData>

Payment Response Message

Component	Mult.	Rule	Usage
`PaymentResponse`	`[1..1]`
`Response`	`[1..1]`
`Result`	`[1..1]`	`Success` or `Failure`	Yes
`ErrorCondition`	`[0..1]`	Error classification in failure case	Yes
`AdditionalResponse`	`[0..1]`	Problem description in failure case	Yes
`POIData`	`[1..1]`
`POITransactionID`	`[1..1]`
`TransactionID`	`[1..1]`		Yes
`TimeStamp`	`[1..1]`		Yes
`BatchID`	`[0..1]`	If result is `Success` or `Partial`	No
`PaymentResult`	`[0..1]`	If one child is present	Yes
`PaymentType`	`[0..1]`	Copy, default `Normal`	Yes
`PaymentInstrumentData`	`[0..1]`	If a payment instrument is analysed	No
`AmountsResp`	`[0..1]`	If result is `Success` or `Partial`
`AuthorizedAmount`	`[1..1]`		Yes
`TotalRebatesAmount`	`[0..1]`	If rebate exists	No
`TotalFeesAmount`	`[0..1]`	If fees were charged	No
`CashBackAmount`	`[0..1]`	If cashback service was performed	No
`TipAmount`	`[0..1]`	If payment with tip was requested	No
`CurrencyConversion`	`[0..n]`	If Sale needs conversion info	No
`ConvertedAmount`	`[1..1]`
`AmountValue`	`[1..1]`
`Currency`	`[1..1]`
`ForeignAmount`	`[0..1]`	If pre-conversion amount is required
`Declaration`	`[0..1]`	If customer declaration is needed
`MerchantOverrideFlag`	`[0..1]`	Default `False`	No
`AllowedReservationTimePeriod`	`[0..1]`	Reservation-related success case	No
`AllowedProduct`	`[0..n]`	If `PaymentRestriction` occurred	No
`PaymentAcquirerData`	`[0..1]`	If card PAN is readable	No
`LoyaltyResult`	`[0..n]`	Loyalty cards used with payment transaction	No

Payment Response Example

This response shows the minimal successful payment response shape used in the tests.

xml
<SaleToPOIResponse>
  <MessageHeader ProtocolVersion="1.0" MessageClass="Service" MessageCategory="Payment" MessageType="Response" ServiceID="1" WorkstationID="1" POIID="80000001" />
  <PaymentResponse>
    <Response Result="Success" />
    <POIData>
      <POITransactionID TransactionID="1234567891234" TimeStamp="2023-02-01T15:37:45.0+00:00" />
    </POIData>
    <PaymentResult PaymentType="Normal">
      <AmountsResp AuthorizedAmount="550.25" />
    </PaymentResult>
  </PaymentResponse>
</SaleToPOIResponse>

Loyalty Message

Loyalty messages are used when the terminal identifies a loyalty card and needs the ECR to participate in the flow.

Loyalty Request Message

Component	Mult.	Rule	Usage
`LoyaltyRequest`	`[1..1]`
`SaleData`	`[1..1]`	Same shape as `PaymentRequest.SaleData`
`OperatorID`	`[0..1]`		No
`OperatorLanguage`	`[0..1]`		No
`ShiftNumber`	`[0..1]`		No
`SaleTransactionID`	`[1..1]`		Yes
`TransactionID`	`[1..1]`	Included but not set
`TimeStamp`	`[1..1]`	Included but not set
`LoyaltyTransaction`	`[1..1]`
`LoyaltyTransactionType`	`[1..1]`	Uses same transaction types as payment	Yes
`Currency`	`[0..1]`	If `TotalAmount` is present and differs from default	Yes
`TotalAmount`	`[0..1]`	If loyalty transaction is linked to payment	Yes
`OriginalTransaction`	`[0..1]`	Refund-related loyalty transaction types	No
`TransactionConditions`	`[0..1]`	If one child is present	No
`SaleItem`	`[0..n]`	If relevant to loyalty transaction	No
`LoyaltyData`	`[0..n]`	If content is not empty	Yes
`CardAcquisitionReference`	`[0..1]`	If loyalty account came from previous acquisition	No
`LoyaltyAccountID`	`[0..1]`	If Sale System identifies loyalty account	Yes
`EntryMethod`	`[1..1]`
`IdentificationType`	`[1..1]`	Always `PAN`
`LoyaltyID`	`[1..1]`	Loyalty card number or ID
`LoyaltyAmount`	`[0..1]`	If not computed from `TotalAmount`	No

Loyalty Response Message

Component	Mult.	Rule	Usage
`LoyaltyResponse`	`[1..1]`
`Response`	`[1..1]`		Yes
`Result`	`[1..1]`	`Success` or `Failure`
`ErrorCondition`	`[0..1]`	Error classification in failure case
`AdditionalResponse`	`[0..1]`	Problem description in failure case
`POIData`	`[1..1]`		No
`POITransactionID`	`[1..1]`
`TransactionID`	`[1..1]`
`TimeStamp`	`[1..1]`
`BatchID`	`[1..1]`
`LoyaltyResult`	`[0..n]`	See Payment response structure	No

Loyalty Response Examples

Two common response shapes exist in the test data: one carrying both DeviceID and ServiceID, and one using the NSID-oriented header variant.

xml
<SaleToPOIResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="EpasSaleToPOIMessages.xsd">
  <MessageHeader MessageClass="Service" MessageCategory="Loyalty" MessageType="Response" DeviceID="1" ServiceID="1" WorkstationID="" POIID=""/>
  <LoyaltyResponse>
    <Response Result="Success"/>
    <POIData BatchID="">
      <POITransactionID TransactionID="" TimeStamp="2023-02-01T15:37:00.0+00:00"/>
    </POIData>
  </LoyaltyResponse>
</SaleToPOIResponse>

xml
<SaleToPOIResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="EpasSaleToPOIMessages.xsd">
  <MessageHeader MessageClass="Service" MessageCategory="Loyalty" MessageType="Response" DeviceID="2" WorkstationID="" POIID=""/>
  <LoyaltyResponse>
    <Response Result="Success"/>
    <POIData BatchID="">
      <POITransactionID TransactionID="" TimeStamp="2023-02-01T15:37:00.0+00:00"/>
    </POIData>
  </LoyaltyResponse>
</SaleToPOIResponse>

Additional Supported Messages

The source specification also defines the following message groups:

Reversal for reversing a prior payment
GetLastTransaction for retrieving the latest transaction summary
Display for terminal-to-ECR or ECR-to-terminal display instructions
InputResponse for cashier or customer input results
PrintRequest in both directions
AbortRequest for cancelling an ongoing service
EventNotification for status, card, reject, and event-log notifications
GetTotals for non-closing totals retrieval

Abort Request Example

xml
<SaleToPOIRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="EpasSaleToPOIMessages.xsd">
  <MessageHeader MessageClass="Service" MessageCategory="Abort" MessageType="Request" ServiceID="" WorkstationID="" POIID=""/>
  <AbortRequest>
    <MessageReference MessageCategory="Payment" ServiceID=""/>
    <AbortReason>
    </AbortReason>
  </AbortRequest>
</SaleToPOIRequest>

Abort request with explicit reason:

xml
<SaleToPOIRequest>
  <MessageHeader MessageClass="Service" MessageCategory="Abort" MessageType="Request" ServiceID="106" WorkstationID="" POIID="52400004" />
  <AbortRequest>
    <MessageReference MessageCategory="Payment" ServiceID="105" />
    <AbortReason>Abort button clicked</AbortReason>
  </AbortRequest>
</SaleToPOIRequest>

Reversal Request Message

Component	Mult.	Rule	Usage
`ReversalRequest`	`[1..1]`
`OriginalPOITransaction`	`[1..1]`		Yes
`POITransactionID`	`[1..1]`
`TransactionID`	`[1..1]`		Yes
`TimeStamp`	`[1..1]`		Yes
`ReuseCardDataFlag`	`[0..1]`	Default `True`	No
`ReversalReason`	`[0..1]`		Yes

Reversal Response Message

Component	Mult.	Rule	Usage
`ReversalResponse`	`[1..1]`
`Response`	`[1..1]`		Yes
`Result`	`[1..1]`	`Success` or `Failure`
`ErrorCondition`	`[0..1]`	Error classification in failure case
`AdditionalResponse`	`[0..1]`	Problem description in failure case
`POIData`	`[0..1]`		Yes
`POITransactionID`	`[1..1]`
`TransactionID`	`[1..1]`		Yes
`TimeStamp`	`[1..1]`		Yes
`ReversalResult`	`[0..1]`		Yes
`TotalAuthorizedAmount`	`[0..1]`		Yes
`CustomerOrderID`	`[0..1]`		Yes

Reversal Request Example

This example shows the request shape used when a prior POI transaction is referenced for reversal.

xml
<SaleToPOIRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="EpasSaleToPOIMessages.xsd">
  <MessageHeader MessageClass="Service" MessageCategory="Reversal" MessageType="Request" ServiceID="" WorkstationID="" POIID=""/>
  <ReversalRequest ReversalReason="">
    <OriginalTransaction WorkstationID="" POIID="">
      <POITransactionID TransactionID="" TimeStamp=""/>
    </OriginalTransaction>
    <OperatorID></OperatorID>
  </ReversalRequest>
</SaleToPOIRequest>

Reversal Response Example

xml
<SaleToPOIResponse>
  <MessageHeader ProtocolVersion="1.0" MessageClass="Service" MessageCategory="Reversal" MessageType="Response" ServiceID="77" WorkstationID="" POIID="52400004" />
  <ReversalResponse>
    <Response Result="Success" />
    <POIData>
      <POITransactionID TransactionID="" TimeStamp="0001-01-01T00:00:00.0+00:00" />
    </POIData>
  </ReversalResponse>
</SaleToPOIResponse>

GetLastTransaction Message

GetLastTransaction is used to retrieve a summary of the latest transaction known to the terminal.

GetLastTransaction Request Message

Component	Mult.	Rule	Usage
`GetLastTransactionRequest`	`[1..1]`	No children or attributes	Yes

GetLastTransaction Response Message

Component	Mult.	Rule	Usage
`GetLastTransactionResponse`	`[1..1]`
`Response`	`[1..1]`		Yes
`Result`	`[1..1]`	`Success` or `Failure`
`ErrorCondition`	`[0..1]`	Error classification in failure case
`AdditionalResponse`	`[0..1]`	Problem description in failure case
`POIData`	`[1..1]`		Yes
`POITransactionID`	`[1..1]`
`TransactionID`	`[1..1]`		Yes
`TimeStamp`	`[1..1]`		Yes
`BatchID`	`[0..1]`		No
`PaymentResult`	`[0..1]`		Yes
`AmountsResp`	`[0..1]`		Yes
`AuthorizedAmount`	`[1..1]`		Yes
`CashBackAmount`	`[0..1]`		Yes
`TipAmount`	`[0..1]`		Yes
`PaymentType`	`[0..1]`		Yes
`OnlineFlag`	`[0..1]`		Yes
`AuthenticationMethod`	`[0..1]`		Yes
`CapturedSignatureFlag`	`[0..1]`		Yes
`ValidityDate`	`[0..1]`		Yes
`PaymentInstrumentData`	`[0..1]`		Yes
`PaymentInstrumentType`	`[1..1]`
`CardData`	`[0..1]`
`PaymentBrand`	`[0..1]`		Yes
`MaskedPAN`	`[0..1]`		Yes
`EntryMethod`	`[1..1]`		Yes
`CardCountryCode`	`[0..1]`		Yes
`PaymentToken`	`[0..1]`		Yes
`PaymentAccountRef`	`[0..1]`		Yes
`CurrencyConversion`	`[0..n]`		Yes
`ConvertedAmount`	`[1..1]`
`AmountValue`	`[1..1]`		Yes
`Currency`	`[1..1]`		Yes
`ForeignAmount`	`[0..1]`		Yes
`MarkupDescription`	`[0..1]`		Yes
`Declaration`	`[0..1]`		Yes
`PaymentAcquirerData`	`[0..1]`		Yes
`AcquirerID`	`[0..1]`		Yes
`AcquirerPOIID`	`[1..1]`		Yes
`AcquirerTransactionID`	`[0..1]`		Yes
`TransactionID`	`[1..1]`		Yes
`TimeStamp`	`[1..1]`		Yes
`ApprovalCode`	`[0..1]`		Yes
`ResponseCode`	`[0..1]`		Yes
`MerchantReference`	`[0..1]`		Yes
`RetrievalReferenceNumber`	`[0..1]`		Yes
`MerchantOverrideFlag`	`[0..1]`		Yes
`LoyaltyBrand`	`[0..1]`		Yes
`LoyaltyResult`	`[0..1]`		Yes
`PrePaidData`	`[0..1]`		Yes
`Instalment`	`[0..1]`		Yes
`PaymentReceipt`	`[0..1]`		Yes
`AlternativePaymentMethod`	`[0..1]`		Yes
`ExtAuth`	`[0..1]`		Yes

GetLastTransaction Request Example

xml
<SaleToPOIRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="EpasSaleToPOIMessages.xsd">
  <MessageHeader MessageClass="Service" MessageCategory="GetLastTransaction" MessageType="Request" ServiceID="1" WorkstationID="" POIID="80000001"/>
  <GetLastTransactionRequest/>
</SaleToPOIRequest>

GetLastTransaction Response Example

The automated tests contain verified response payloads for several outcomes:

Successful card payment response
Successful Swish payment response
Failure response

Representative card-payment response:

xml
<SaleToPOIResponse>
  <MessageHeader ProtocolVersion="1.0" MessageClass="Service" MessageCategory="GetLastTransaction" MessageType="Response" ServiceID="1" WorkstationID="" POIID="80000001" />
  <GetLastTransactionResponse OperatorId="cashier-16">
    <Response Result="Success" />
    <MerchantData Name="Westpay AB" Address="Kanalvägen 12" City="Upplands Väsby" ZipCode="12345" PhoneNumber="08123456789" OrganisationNumber="123456-7890" HelplineNumber="020222222" BankAgentName="BAN" AcquirerReference="" />
    <Transaction Type="Debit" Status="AUTHORISED" TransactionID="8000000112345" BatchNumber="1" TimeStamp="2023-02-01T15:37:45.0+00:00" PaymentType="Normal" AuthorizedAmount="550.55" CashBackAmount="200.00" VATAmount="125.00" GratuityAmount="10.11" CashAdvanceChargeAmount="40.00" CurrencyCode="SEK" PaymentCode="888888" PaymentMethod="Card" />
    <Card MerchantPAN="123456******7890" CustomerPAN="************7890" Name="Not a Mastercard" CreditDebit="CREDIT">
      <Auth Responder="0" Channel="1" ResponseCode="001" ApprovalCode="895634" PosEntryMode="C" FinancialInstitution="ELV" IdMethod="A" VerifiedByDevice="False" />
      <EMV AID="A0000000041010" TVR="8010000000" TSI="E800" ResponseCode="00" PANSeqNo="73" />
    </Card>
  </GetLastTransactionResponse>
</SaleToPOIResponse>

Swish-focused response variant:

xml
<SaleToPOIResponse>
  <MessageHeader ProtocolVersion="1.0" MessageClass="Service" MessageCategory="GetLastTransaction" MessageType="Response" ServiceID="1" WorkstationID="" POIID="80000001" />
  <GetLastTransactionResponse OperatorId="cashier-16">
    <Response Result="Success" />
    <Transaction Type="Unknown" Status="AUTHORISED" TransactionID="8000000112345" BatchNumber="" TimeStamp="2023-02-01T15:37:45.0+00:00" PaymentType="Normal" AuthorizedAmount="550.55" CashBackAmount="0.00" VATAmount="0.00" GratuityAmount="0.00" CashAdvanceChargeAmount="0.00" CurrencyCode="SEK" PaymentMethod="Card" />
    <MerchantReceipt>...Swish...</MerchantReceipt>
    <CustomerReceipt>...Swish...</CustomerReceipt>
  </GetLastTransactionResponse>
</SaleToPOIResponse>

Failure variant:

xml
<SaleToPOIResponse>
  <MessageHeader ProtocolVersion="1.0" MessageClass="Service" MessageCategory="GetLastTransaction" MessageType="Response" ServiceID="1" WorkstationID="" POIID="80000001" />
  <GetLastTransactionResponse>
    <Response Result="Failure" ErrorCondition="None">
      <AdditionalResponse />
    </Response>
    <Transaction Type="Debit" Status="CANCELLED" TransactionID="8000000112345" BatchNumber="1" TimeStamp="2023-02-01T15:37:45.0+00:00" PaymentType="Normal" AuthorizedAmount="550.55" CashBackAmount="200.00" VATAmount="125.00" GratuityAmount="10.11" CashAdvanceChargeAmount="40.00" CurrencyCode="SEK" PaymentCode="888888" PaymentMethod="Card" />
    <Card MerchantPAN="" CustomerPAN="************7890" Name="Not a Mastercard" CreditDebit="CREDIT">
      <Auth Responder="0" Channel="1" ResponseCode="001" ApprovalCode="895634" PosEntryMode="C" FinancialInstitution="ELV" IdMethod="A" VerifiedByDevice="False" />
      <EMV AID="A0000000041010" TVR="8010000000" TSI="E800" ResponseCode="00" PANSeqNo="73" />
    </Card>
  </GetLastTransactionResponse>
</SaleToPOIResponse>

Display Message

Display messages are used both for cashier-facing terminal progress and for the limited ECR-to-terminal QR or barcode scenario.

Display Request Message from Payment Application

When the terminal sends display requests, they are used both to inform the cashier about transaction progress and, in some cases, to request input back from the ECR. Display response messages are ignored; if a response is needed it is carried through the optional Input structure associated with the display flow.

Component	Mult.	Usage
`DisplayRequest`	`[1..1]`
`DisplayOutput`	`[0..n]`	Yes
`Device`	`[1..1]`	Yes
`InfoQualify`	`[1..1]`	Yes
`MenuEntry`	`[0..n]`	Yes
`OutputFormat`	`[1..1]`
`OutputText`	`[0..n]`	Yes
`Text`	`[1..1]`	Yes
`CharacterSet`	`[0..1]`	No
`Font`	`[0..1]`	No
`StartRow`	`[0..1]`	No
`StartColumn`	`[0..1]`	No
`Color`	`[0..1]`	No
`CharacterWidth`	`[0..1]`	No
`CharacterHeight`	`[0..1]`	No
`CharacterStyle`	`[0..1]`	No
`Alignment`	`[0..1]`	No
`MenuEntryTag`	`[0..1]`	Yes
`OutputBarcode`	`[0..1]`	Yes
`BarcodeType`	`[0..1]`
`BarcodeValue`	`[1..1]`
`OutputXHTML`	`[0..1]`	Yes
`OutputSignature`	`[0..1]`	No

Prompt ID

PromptId identifies the cashier prompt currently being shown and determines what kind of InputResponse may be sent back.

Custom Prompt IDs

The implementation extends the prompt range with Westpay-specific values. One notable example is 653, which behaves like 652 but without allowing a signature override.

ECR Input

The optional Input component inside a DisplayRequest tells the ECR that a response may or must be sent back to the terminal using InputResponse.

Responses to Input Components in Display Requests

Prompt ID	Purpose	Response
`105`	Gratuity amount prompt	Optional `skip`
`641`	Credit or debit selection	`credit` or `debit`
`642`	Payment code required	Text string
`645`	VAT amount correction	Decimal string
`646`	CV2 required	Digit string
`649`	Imprint card confirmation	`continue`
`652`	PIN entry with optional signature override	Optional `sign`
`653`	PIN entry without signature override	No response option
`662`	Signature verification	`yes` or `no`
`664`	Voice referral authorisation code	Text string
`676`	Parameter download reminder	`yes` or `no`
`6221`	Force magnetic-stripe fallback	Optional `force`
`6410`	VAT amount confirmation	Decimal string
`6619`	Re-entry of voice referral code	Text string

Display Request Message from ECR

Component	Mult.	Rule	Usage
`DisplayRequest`	`[1..1]`
`DisplayOutput`	`[0..n]`		No
`Device`	`[1..1]`
`InfoQualify`	`[1..1]`
`OutputContent`	`[1..1]`
`OutputFormat`	`[1..1]`
`OutputText`	`[0..n]`
`Text`	`[1..1]`
`CharacterSet`	`[0..1]`	Same as terminal display message
`Font`	`[0..1]`	Same as terminal display message
`StartRow`	`[0..1]`	Same as terminal display message
`StartColumn`	`[0..1]`	Same as terminal display message
`Color`	`[0..1]`	Same as terminal display message
`CharacterWidth`	`[0..1]`	Same as terminal display message
`CharacterHeight`	`[0..1]`	Same as terminal display message
`CharacterStyle`	`[0..1]`	Same as terminal display message
`Alignment`	`[0..1]`	Same as terminal display message
`EndOfLineFlag`	`[0..1]`	Same as terminal display message
`OutputXHTML`	`[0..1]`
`OutputSignature`	`[0..1]`	If text must be protected

Display Request Examples

xml
<SaleToPOIRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="EpasSaleToPOIMessages.xsd">
  <MessageHeader MessageClass="Device" MessageCategory="Display" MessageType="Request" ServiceID="" WorkstationID="" POIID=""/>
  <DisplayRequest>
    <DisplayOutput Device="CustomerDisplay" InfoQualify="Display" ResponseRequiredFlag="true">
      <OutputContent OutputFormat="BarCode">
      </OutputContent>
    </DisplayOutput>
  </DisplayRequest>
</SaleToPOIRequest>

Cashier display with plain text:

xml
<SaleToPOIRequest>
  <MessageHeader ProtocolVersion="1.0" MessageClass="Device" MessageCategory="Display" MessageType="Request" ServiceID="4784" DeviceID="5" WorkstationID="" POIID="52400004" />
  <DisplayRequest>
    <DisplayOutput ResponseRequiredFlag="false" Device="CashierDisplay" InfoQualify="POIReplication">
      <OutputContent OutputFormat="Text">
        <OutputText>Invalid logon</OutputText>
        <OutputText>Call helpdesk Support</OutputText>
      </OutputContent>
    </DisplayOutput>
    <PromptId>682</PromptId>
  </DisplayRequest>
</SaleToPOIRequest>

Cashier display with option list:

xml
<SaleToPOIRequest>
  <MessageHeader ProtocolVersion="1.0" MessageClass="Device" MessageCategory="Display" MessageType="Request" ServiceID="4788" DeviceID="12" WorkstationID="" POIID="52400004" />
  <DisplayRequest>
    <DisplayOutput ResponseRequiredFlag="false" Device="CashierDisplay" InfoQualify="POIReplication">
      <OutputContent OutputFormat="Text">
        <OutputText>New customer</OutputText>
        <OutputText>Waiting for card</OutputText>
      </OutputContent>
    </DisplayOutput>
    <PromptId>612</PromptId>
    <Input Type="OptionList">
      <Option>Swedish</Option>
      <Option>English</Option>
      <Option>Norwegian</Option>
    </Input>
  </DisplayRequest>
</SaleToPOIRequest>

Cashier display with required confirmation:

xml
<SaleToPOIRequest>
  <MessageHeader ProtocolVersion="1.0" MessageClass="Device" MessageCategory="Display" MessageType="Request" ServiceID="4791" DeviceID="19" WorkstationID="" POIID="52400004" />
  <DisplayRequest>
    <DisplayOutput ResponseRequiredFlag="false" Device="CashierDisplay" InfoQualify="POIReplication">
      <OutputContent OutputFormat="Text">
        <OutputText>1 000,00 SEK</OutputText>
        <OutputText>VISA</OutputText>
        <OutputText>Verify signature</OutputText>
      </OutputContent>
    </DisplayOutput>
    <PromptId>662</PromptId>
    <Input Type="OptionList" Required="Yes">
      <Option>yes</Option>
      <Option>no</Option>
    </Input>
  </DisplayRequest>
</SaleToPOIRequest>

Input Response

InputResponse is used for cashier prompt answers and for amount-supply flows such as early PIN entry and swipe-ahead.

Input Response Message

The terminal application does not support the EPAS InputRequest message. Instead, if the terminal needs a response from the ECR then that prompt is carried in the optional Input element of the DisplayRequest that asked for the information.

Cashier responses are sent back to the payment terminal using InputResponse.

InputResponse is also used to provide transaction amounts in flows where the original PaymentRequest was sent without amount information, for example swipe-ahead scenarios.

An InputResponse may therefore be sent without any preceding InputRequest, because InputRequest itself is not part of this implementation.

Component	Mult.	Rule	Usage
`InputResponse`	`[1..1]`
`OutputResult`	`[0..1]`	If the triggering request included `DisplayOutput`	No
`Device`	`[1..1]`	Copy from request
`InfoQualify`	`[1..1]`	Copy from request
`Response`	`[1..1]`
`Result`	`[1..1]`	`Success` or `Failure`
`ErrorCondition`	`[0..1]`	Failure classification
`AdditionalResponse`	`[0..1]`	Failure description
`InputResult`	`[1..1]`		Yes
`Device`	`[1..1]`	`CashierInput` or `CustomerInput`; only `CashierInput` is supported	Yes
`InfoQualify`	`[1..1]`	`Input` or `CustomerAssistance`	Yes
`Response`	`[1..1]`		Yes
`Result`	`[1..1]`	`Success` or `Failure`
`ErrorCondition`	`[0..1]`	Failure classification
`AdditionalResponse`	`[0..1]`	Failure description
`Input`	`[0..1]`	If `Response.Result = Success` and `AmountsReq` is not omitted by design	Yes
`InputCommand`	`[1..1]`	`TransactionAmount`, `NonPciCardData`, or a prompt ID echoed from a previous `DisplayRequest`	Yes
`TextInput`	`[0..1]`	Mandatory when `InputCommand` is a prompt ID	Yes
`AmountsReq`	`[0..1]`	Required when `InputCommand = TransactionAmount`	Yes
`RequestedAmount`	`[0..1]`	Must be non-zero
`CashBackAmount`	`[0..1]`	Only required when non-zero
`TipAmount`	`[0..1]`	If present with value `0`, tipping is disabled
`VatAmount`	`[0..1]`	VAT amount
`NonPciCardData`	`[0..1]`	Required when `InputCommand = NonPciCardData`
`Number`	`[1..1]`	Card number
`Expiry`	`[1..1]`	Card expiry date in `MMYY` format

Input Response Example

This example shows a cashier-input response carrying non-PCI card data.

xml
<SaleToPOIResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <MessageHeader MessageClass="Device" MessageCategory="Input" MessageType="Response" ServiceID="1" DeviceID="4" WorkstationID="" POIID=""/>
  <InputResponse>
    <InputResult Device="CashierInput" InfoQualify="Input">
      <Response Result="Success"/>
      <Input InputCommand="NonPciCardData">
        <NonPciCardData Number="" Expiry="" />
      </Input>
    </InputResult>
  </InputResponse>
</SaleToPOIResponse>

InputCommand Field

There are three supported forms of InputResponse, controlled by the InputCommand attribute.

`TransactionAmount`

This form is used to supply amount details for a swipe-ahead transaction that has already started. In this case the terminal was launched with zero amounts and waits for the ECR to send the amount data later through InputResponse.

In this form, AmountsReq must be included.

`NonPciCardData`

The ECR can provide card data for a non-PCI card through InputResponse instead of having the cardholder present the card on the terminal.

In this form, the card number is sent in Number and expiry in Expiry.

Prompt ID

If InputCommand contains the numeric prompt ID from a previous DisplayRequest, then the value in TextInput is interpreted as the ECR's answer to that cashier prompt.

Input Response Examples

Example response to choose signature verification:

xml
<SaleToPOIResponse>
  <MessageHeader MessageClass="Device" MessageCategory="Input" MessageType="Response" ServiceID="4792" DeviceID="1" WorkstationID="" POIID="52400004" />
  <InputResponse>
    <InputResult Device="CashierInput" InfoQualify="Input">
      <Response Result="Success" />
      <Input InputCommand="652">
        <TextInput>sign</TextInput>
      </Input>
    </InputResult>
  </InputResponse>
</SaleToPOIResponse>

Example response to signature verification:

xml
<SaleToPOIResponse>
  <MessageHeader MessageClass="Device" MessageCategory="Input" MessageType="Response" ServiceID="4793" DeviceID="2" WorkstationID="" POIID="52400004" />
  <InputResponse>
    <InputResult Device="CashierInput" InfoQualify="Input">
      <Response Result="Success" />
      <Input InputCommand="662">
        <TextInput>yes</TextInput>
      </Input>
    </InputResult>
  </InputResponse>
</SaleToPOIResponse>

Amount-entry variant:

xml
<SaleToPOIResponse>
  <MessageHeader MessageClass="Device" MessageCategory="Input" MessageType="Response" ServiceID="4797" DeviceID="4" WorkstationID="" POIID="52400004" />
  <InputResponse>
    <InputResult Device="CashierInput" InfoQualify="Input">
      <Response Result="Success" />
      <Input InputCommand="TransactionAmount">
        <AmountsReq Currency="SEK" RequestedAmount="850" CashBackAmount="100" VatAmount="0.00" />
      </Input>
    </InputResult>
  </InputResponse>
</SaleToPOIResponse>

Non-PCI card presentation:

xml
<SaleToPOIResponse>
  <MessageHeader MessageClass="Device" MessageCategory="Input" MessageType="Response" ServiceID="4799" DeviceID="4" WorkstationID="" POIID="52400004" />
  <InputResponse>
    <InputResult Device="CashierInput" InfoQualify="Input">
      <Response Result="Success" />
      <Input InputCommand="NonPciCardData">
        <NonPciCardData Number="9752276400000003" Expiry="0821" />
      </Input>
    </InputResult>
  </InputResponse>
</SaleToPOIResponse>

Failure variant:

xml
<SaleToPOIResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="EpasSaleToPOIMessages.xsd">
  <MessageHeader MessageClass="Device" MessageCategory="Input" MessageType="Response" ServiceID="1" DeviceID="1" WorkstationID="" POIID=""/>
  <InputResponse>
    <InputResult Device="CashierInput" InfoQualify="Input">
      <Response Result="Failure" ErrorCondition="UnavailableService" />
      <Input InputCommand="">
        <TextInput></TextInput>
      </Input>
    </InputResult>
  </InputResponse>
</SaleToPOIResponse>

Print Request - Terminal To ECR

Print Request Message from Payment Application to ECR

The terminal sends PrintRequest to ask the ECR to print receipts, error messages, and reports.

The base EPAS model represents printed output as a sequence of text elements with rendering attributes. In practice this pushes receipt layout responsibility into the payment application, even though the application does not know what printer model, paper size, or rendering constraints exist on the ECR side.

This implementation therefore extends the practical use of PrintRequest by providing receipt data as separate business fields, allowing the ECR to format the final receipt according to its own layout rules.

When receipt data is included, the message may also contain a pre-formatted textual receipt. That text should be treated as debug or test output only, and integrators should prefer the structured receipt elements when building production receipts.

The terminal does not expect, and will not wait for, a PrintResponse.

Component	Mult.	Rule	Usage
`PrintRequest`	`[1..1]`		Yes
`PrintOutput`	`[1..1]`		Yes
`DocumentQualifier`	`[1..1]`		Yes
`ResponseMode`	`[1..1]`	`NotRequired`, `Immediate`, or `PrintEnd`	Yes
`IntegratedPrintFlag`	`[0..1]`	Default `False`	No
`RequiredSignatureFlag`	`[0..1]`	Included only if signature is required	No
`OutputContent`	`[1..1]`		Yes
`OutputFormat`	`[1..1]`	Use `Bitmap` for image printing	Yes
`PredefinedContent`	`[0..1]`	Same as Display	No
`ReferenceID`	`[1..1]`	Same as Display
`Language`	`[0..1]`	Same as Display
`OutputText`	`[0..n]`	Debug or test receipt text	No
`Text`	`[1..1]`	Pre-formatted debug or test receipt
`CharacterSet`	`[0..1]`	Same as Display
`Font`	`[0..1]`	Same as Display
`StartColumn`	`[0..1]`	Same as Display
`Color`	`[0..1]`	Same as Display
`CharacterWidth`	`[0..1]`	Same as Display
`CharacterHeight`	`[0..1]`	Same as Display
`CharacterStyle`	`[0..1]`	Same as Display
`Alignment`	`[0..1]`	Same as Display
`EndOfLineFlag`	`[0..1]`	Same as Display
`OutputXHTML`	`[0..1]`	Same as Display
`OutputBarcode`	`[0..1]`	Same as Display
`BarcodeType`	`[0..1]`	Same as Display
`BarcodeValue`	`[1..1]`	Same as Display
`OutputSignature`	`[0..1]`		No

Print Request Example

This request shows a structured receipt payload with both OutputText and ReceiptData.

xml
<SaleToPOIRequest>
  <MessageHeader ProtocolVersion="1.0" MessageClass="Device" MessageCategory="Print" MessageType="Request" ServiceID="1" DeviceID="1" WorkstationID="" POIID="" />
  <PrintRequest>
    <PrintOutput DocumentQualifier="CustomerReceipt" ResponseMode="NotRequired">
      <OutputContent OutputFormat="Text">
        <OutputText>Westpay AB Receipt ...</OutputText>
      </OutputContent>
    </PrintOutput>
    <ReceiptData>
      <ReceiptHeader>Westpay AB Receipt</ReceiptHeader>
      <MerchantData Name="Westpay AB" Address="Kanalvägen 12" City="Upplands Väsby" ZipCode="12345" PhoneNumber="08123456789" OrganisationNumber="123456-7890" HelplineNumber="020222222" />
      <BankAgentName>BAN</BankAgentName>
      <TransactionData Type="Debit" DateTime="2023-02-01T15:37:00.0+00:00" CurrencyCode="SEK" CurrencyNum="SEK" Amount="550.99" CashBack="200.00" Gratuity="10.11" Vat="125.00" CashAdvanceCharge="0.00" Total="761.10" ReferenceNumber="800000011234" />
      <CardData MaskedPan="************7890" Name="Not a Mastercard" CreditDebit="CREDIT" PaymentCode="888888" />
    </ReceiptData>
  </PrintRequest>
</SaleToPOIRequest>

Additional receipt scenarios may include signature authorisation receipts, alternative-payment receipts, and DCC receipts. The payload shape remains the same, while ReceiptData and optional receipt text vary by transaction type.

Print Request Examples

Normal Purchase Approval Example

This variant represents a standard approved card purchase receipt with merchant details, authorisation data, card data, and EMV data.

Signature Authorisation Example

This variant represents a cashier-facing receipt with explicit signature lines and masked PAN data for manual signature verification.

Alternative Payment Purchase Approval Example

This variant represents a successful alternative payment transaction, for example Swish, where receipt data carries AlternativePaymentMethod.

DCC Example

This variant includes dynamic currency conversion fields such as exchange rate, markup description, and foreign amount presentation. The source material explicitly marks the sample values as hard-coded test data.

Print Request - ECR To Terminal

Print Request Message from ECR to Terminal

The ECR can also send PrintRequest to the terminal, but this is a narrow and configuration-dependent feature.

Only monochrome Windows bitmap (.BMP) images are supported, and the image must not be wider than 384 pixels.

The bitmap data is prepared by compressing the bitmap file using gzip and then base64-encoding the compressed bytes before placing the result in Bitmap.ImageData.

Example C# preparation flow:

csharp
byte[] compressed = null;
string base64String = null;

using (Stream fs = File.OpenRead(filename))
using (MemoryStream ms = new MemoryStream())
using (GZipStream gz = new GZipStream(ms, CompressionMode.Compress))
{
    int bytesRead;
    byte[] buffer = new byte[1000];

    while ((bytesRead = fs.Read(buffer, 0, buffer.Length)) > 0)
    {
        gz.Write(buffer, 0, bytesRead);
    }

    compressed = ms.ToArray();
    base64String = Convert.ToBase64String(compressed, 0, compressed.Length);
}

Component	Mult.	Rule	Usage
`PrintRequest`	`[1..1]`		Yes
`PrintOutput`	`[1..1]`		Yes
`DocumentQualifier`	`[1..1]`	Not used	Yes
`ResponseMode`	`[1..1]`	`NotRequired`, `Immediate`, or `PrintEnd`	Yes
`IntegratedPrintFlag`	`[0..1]`	Default `False`; not allowed unless qualifier is `CashierReceipt` or `CustomerReceipt`	No
`RequiredSignatureFlag`	`[0..1]`	Included only if signature is required	No
`OutputContent`	`[1..1]`		Yes
`OutputFormat`	`[1..1]`	Use `Bitmap`	Yes
`Bitmap`	`[0..1]`		Yes
`ImageData`	`[1..1]`	Base64-encoded gzip-compressed monochrome Windows bitmap data

Print Request Example from ECR to Terminal

xml
<SaleToPOIRequest>
  <MessageHeader MessageClass="Device" MessageCategory="Print" MessageType="Request" DeviceID="4" WorkstationID="" POIID="10.0.1.156:8002" />
  <PrintRequest>
    <PrintOutput DocumentQualifier="CustomerReceipt" ResponseMode="PrintEnd">
      <OutputContent OutputFormat="Bitmap">
        <Bitmap ImageData="H4sIAAAAAAAEAO29B2AcSZYlJi9tynt/SvV......." />
      </OutputContent>
    </PrintOutput>
  </PrintRequest>
</SaleToPOIRequest>

Print Response Message

Component	Mult.	Rule	Usage
`PrintResponse`	`[1..1]`		Yes
`DocumentQualifier`	`[1..1]`	Typically `CustomerReceipt`
`Response`	`[1..1]`	Result of the print request
`Result`	`[1..1]`	`Success` or `Failure`
`ErrorCondition`	`[0..1]`	Failure classification
`AdditionalResponse`	`[0..1]`	Failure description

Print Response Example

This response shows the simple acknowledgement shape returned for a successful print completion.

xml
<SaleToPOIResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="EpasSaleToPOIMessages.xsd">
  <MessageHeader MessageClass="Device" MessageCategory="Print" MessageType="Response" ServiceID="1" DeviceID="1" WorkstationID="" POIID=""/>
  <PrintResponse DocumentQualifier="Document">
    <Response Result="Success"/>
  </PrintResponse>
</SaleToPOIResponse>

Abort Message

AbortRequest is used when the ECR wants to cancel an ongoing service, typically an active payment flow.

Abort Request Message

Component	Mult.	Rule	Usage
`AbortRequest`	`[1..1]`		Yes
`MessageReference`	`[1..1]`	Identifies the message category and service to abort	Yes
`MessageCategory`	`[1..1]`	Typically `Payment`	Yes
`ServiceID`	`[1..1]`	Service ID of the active flow	Yes
`AbortReason`	`[0..1]`	Optional textual reason	Yes

Event Notification

The EventNotification message largely follows the EPAS specification, but extends the list of events that can be notified.

The following values are used in the EventToNotify element:

BeginMaintenance
EndMaintenance
Shutdown
CardInserted
CardRemoved
CardAccepted
Completed
EventLog
Reject

CardAccepted

This event notification is sent when a card is recognised as a valid payment card, meaning it has a matching BIN row and is considered acceptable by the application. In a swipe-ahead scenario there may be multiple CardAccepted notifications if the cardholder inserts multiple cards.

EventLog

This event notification carries the section of event log that has built up since the last time the notification was sent. In practice this means it sends incremental event-log additions to the ECR.

This notification is sent immediately after a LoginResponse, ReversalResponse, and PaymentResponse.

Event Notification Message

EventNotification is sent asynchronously from the terminal to the ECR for maintenance state, card events, rejection or completion events, and incremental event-log delivery.

Event Notification Example

The event-notification tests are useful when documenting terminal-to-ECR card events.

xml
<SaleToPOIRequest>
  <MessageHeader ProtocolVersion="1.0" MessageClass="Event" MessageCategory="Event" MessageType="Notification" DeviceID="device-id" WorkstationID="ABC" POIID="80000001" />
  <EventNotification TimeStamp="2023-01-25T12:34:56.0+00:00" EventToNotify="CardAccepted">
    <EventDetails>123456******6789</EventDetails>
    <CNA>0102030405060708090A0B0C0D0E0F10</CNA>
  </EventNotification>
</SaleToPOIRequest>

Variant with both CNA and CNA2:

xml
<SaleToPOIRequest>
  <MessageHeader ProtocolVersion="1.0" MessageClass="Event" MessageCategory="Event" MessageType="Notification" DeviceID="device-id" WorkstationID="ABC" POIID="80000001" />
  <EventNotification TimeStamp="2023-01-25T12:34:56.0+00:00" EventToNotify="CardAccepted">
    <EventDetails>123456******6789</EventDetails>
    <CNA>0102030405060708090A0B0C0D0E0F10</CNA>
    <CNA2>AABBCC</CNA2>
  </EventNotification>
</SaleToPOIRequest>

Maintenance notification:

xml
<SaleToPOIRequest>
  <MessageHeader ProtocolVersion="1.0" MessageClass="Event" MessageCategory="Event" MessageType="Notification" DeviceID="3" WorkstationID="" POIID="52400004" />
  <EventNotification TimeStamp="2017-07-25T10:15:22.0+00:00" EventToNotify="BeginMaintenance">
    <EventDetails>POI Maintenance: Updating and loading parameters</EventDetails>
  </EventNotification>
</SaleToPOIRequest>

Event Notification With Log Extract

Event-log notification:

xml
<SaleToPOIRequest>
  <MessageHeader ProtocolVersion="1.0" MessageClass="Event" MessageCategory="Event" MessageType="Notification" DeviceID="21" WorkstationID="" POIID="52400004" />
  <EventNotification TimeStamp="2017-07-25T12:40:49.0+00:00" EventToNotify="EventLog">
    <EventDetails>[2017-07-25T12:39:15 52400004 D0029 Status] Request denied: Close batch is overdue</EventDetails>
  </EventNotification>
</SaleToPOIRequest>

GetTotals Message

GetTotals provides reporting information similar to older reconciliation flows, but without closing the batch.

Get Totals Request Message

Component	Mult.	Usage
`GetTotalsRequest`	`[1..1]`
`TotalDetails`	`[0..1]`	No
`TotalFilter`	`[0..1]`	No

GetTotals Request Message Example

xml
<SaleToPOIRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="EpasSaleToPOIMessages.xsd">
  <MessageHeader MessageClass="Service" MessageCategory="GetTotals" MessageType="Request" ServiceID="1" WorkstationID="" POIID=""/>
  <GetTotalsRequest>
    <TotalDetails />
    <TotalFilter ShiftNumber=""/>
  </GetTotalsRequest>
</SaleToPOIRequest>

GetTotals Response Message

Component	Mult.	Rule
`GetTotalsResponse`	`[1..1]`
`BatchID`	`[0..1]`	Identifies the totals period
`GratuityAmount`	`[0..1]`	Total gratuity amount
`Gratuity`	`[1..1]`	Total gratuity value
`Response`	`[1..1]`	Result of the `GetTotals` request
`Result`	`[1..1]`	`Success` or `Failure`
`ErrorCondition`	`[0..1]`	Failure classification
`AdditionalResponse`	`[0..1]`	Failure description
`TransactionTotals`	`[0..n]`	Totals grouped by brand, operator, shift, or currency depending on response
`CardBrand`	`[0..1]`	Card brand for the total group
`PaymentCurrency`	`[0..1]`	Currency code
`TotalsGroupID`	`[0..1]`	Totals-group identifier
`PaymentTotals`	`[0..10]`	Per-transaction-type totals
`TransactionType`	`[1..1]`	Debit, credit, or other reporting type
`TransactionCount`	`[1..1]`	Number of transactions
`TransactionAmount`	`[1..1]`	Total value for the type

GetTotals Response Message Example

This example shows a successful totals response with gratuity data and grouped payment totals.

xml
<SaleToPOIResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="EpasSaleToPOIMessages.xsd">
  <MessageHeader MessageClass="Service" MessageCategory="GetTotals" MessageType="Response" ServiceID="619" WorkstationID="SaleServer" POIID="POIServer"/>
  <GetTotalsResponse BatchID="8927">
    <Response Result="Success"/>
    <GratuityAmount Gratuity="20.00"/>
    <TransactionTotals CardBrand="CardPlus" AcquirerID="876355543" ReconciliationID="98535" WorkstationID="SaleTermA" OperatorID="213" ShiftNumber="1" PaymentCurrency="EUR">
      <PaymentTotals TransactionType="Debit" TransactionCount="61" TransactionAmount="4253.19"/>
      <PaymentTotals TransactionType="Credit" TransactionCount="1" TransactionAmount="27.01"/>
    </TransactionTotals>
  </GetTotalsResponse>
</SaleToPOIResponse>

Reporting Request Examples

Get totals request:

xml
<SaleToPOIRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="EpasSaleToPOIMessages.xsd">
  <MessageHeader MessageClass="Service" MessageCategory="GetTotals" MessageType="Request" ServiceID="1" WorkstationID="" POIID=""/>
  <GetTotalsRequest>
    <TotalDetails />
    <TotalFilter ShiftNumber=""/>
  </GetTotalsRequest>
</SaleToPOIRequest>

Get totals response:

xml
<SaleToPOIResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="EpasSaleToPOIMessages.xsd">
  <MessageHeader MessageClass="Service" MessageCategory="GetTotals" MessageType="Response" ServiceID="619" WorkstationID="SaleServer" POIID="POIServer"/>
  <GetTotalsResponse BatchID="8927">
    <Response Result="Success"/>
    <GratuityAmount Gratuity="20.00"/>
    <TransactionTotals CardBrand="CardPlus" AcquirerID="876355543" ReconciliationID="98535" WorkstationID="SaleTermA" OperatorID="213" ShiftNumber="1" PaymentCurrency="EUR">
      <PaymentTotals TransactionType="Debit" TransactionCount="61" TransactionAmount="4253.19"/>
      <PaymentTotals TransactionType="Credit" TransactionCount="1" TransactionAmount="27.01"/>
    </TransactionTotals>
  </GetTotalsResponse>
</SaleToPOIResponse>

Transaction Flows

This section complements the message reference above by showing how multiple messages are combined into complete operational sequences.

Start-up and Login

The ECR establishes the transport connection.
The ECR starts keepalive traffic if no application data is flowing.
The ECR sends LoginRequest.
The terminal returns LoginResponse.
The terminal may then send EventNotification, for example with EventLog.

Payment Transaction (Example)

The ECR sends PaymentRequest with amount data.
The terminal sends one or more DisplayRequest messages to mirror customer or terminal progress to the cashier.
The terminal may send PrintRequest for merchant or customer receipt output.
The terminal returns PaymentResponse.
The terminal may then send EventNotification with incremental event-log content.

Payment Without Amount, Early PIN Entry (Example)

The ECR starts the transaction with PaymentRequest but without final amount information.
The terminal can begin card handling and PIN-related interaction early.
When the amount is known, the ECR supplies it through InputResponse with InputCommand="TransactionAmount".
The terminal continues authorisation and returns PaymentResponse.

Payment With Swipe Ahead (Example)

The ECR enables early card acquisition or starts a payment flow before final amounts are known.
The customer presents the card before the sale is fully finalised.
The terminal may emit CardAccepted notifications during this phase.
The ECR later supplies the final amount through InputResponse.
The terminal completes the transaction and returns PaymentResponse.

GetLastTransaction

The ECR sends GetLastTransactionRequest.
The terminal returns GetLastTransactionResponse.
The ECR uses the response for receipt reconstruction, operator support, or post-transaction diagnostics.

Multi TID

Multi terminal ID (Multi TID) is a way to share one terminal between multiple merchants. The feature is only available for integrated terminals and should not be confused with a multi-user terminal solution.

To use this functionality, the integrator must support the additional ExtraPOIID element in the login request and Westpay must enable the feature on the primary terminal ID.

How It Works

When enabled, the terminal accepts up to ten additional terminal IDs in the ExtraPOIID element, separated by spaces.

During host logon, the terminal downloads parameters for all supplied terminal IDs directly. This allows seamless switching between IDs during transactions, but makes host logon take longer.

After login, the ECR chooses which of the supplied terminal IDs should be used for each transaction by setting POIID in the request header.

Limitations

There are a few important limitations to be aware of.

Parameters

Some parameters are unique per terminal ID, while others are shared between the primary and secondary IDs.

Parameter / Setting	Description	Shared or Unique	Owner
`MASPAR`	Merchant information	Unique
`DCPAR`	Transaction settings, limits, and related configuration	Unique
`BINPAR`	Card acceptance settings	Unique
`CAPUB`	Transaction keys	Shared	Primary
`DCAPP`	Terminal updates	Shared	Primary
`CTLSPAR`	Contactless settings	Shared	Primary
`Languages`	Languages spoken by the terminal	Shared	Primary
`Logotype`	Logotype shown by the terminal	Shared	Primary
`EOD time`	Time of day when batch closure occurs	Shared	Primary
`APM`	Alternative payment methods	Unique

This means:

primary and secondary IDs must belong to merchants in the same country because they share transaction keys
the solution cannot be used for cross-border sales enablement
triggers and terminal updates are only enabled on the primary terminal ID
available languages are controlled by the primary terminal ID
any configured logotype is visible for all terminal IDs
alternative payment methods such as Swish, Klarna, and Vipps are configured per terminal ID and presented dynamically

Transaction Requests

Multi TID is only supported for standard PaymentRequest flows. It is not supported in EnableService or pre-tap flows.

Requirements for Integrators

Update Login Request

The integrator must support the additional ExtraPOIID element in the login request.

Example header and extra IDs:

xml
<MessageHeader POIID="52400004" />
<ExtraPOIID>52400005 52400006 52400007 52400008</ExtraPOIID>

Example login request:

xml
<SaleToPOIRequest>
  <MessageHeader ProtocolVersion="1.0" MessageClass="Service" MessageCategory="Login" MessageType="Request" ServiceID="2251" WorkstationID="" POIID="52400004" />
  <LoginRequest OperatorLanguage="en" OperatorID="Cashier16" ShiftNumber="2" POISerialNumber="">
    <DateTime>2023-02-13T09:21:07.1480037+00:00</DateTime>
    <ExtraPOIID>52400005 52400006 52400007 52400008</ExtraPOIID>
    <SaleSoftware ManufacturerID="" ApplicationName="" SoftwareVersion="" CertificationCode="" />
    <ConfigData>
      <TxnHostAddress>185.27.171.42:55144</TxnHostAddress>
      <ConfigHostAddress>185.27.171.42:55133</ConfigHostAddress>
      <ConfigFile />
    </ConfigData>
  </LoginRequest>
</SaleToPOIRequest>

Update Payment Request

During each transaction request, the integrator must set POIID in the message header to the terminal ID that should be used for that specific transaction.

Example:

xml
<MessageHeader POIID="52400004" />

Full payment example:

xml
<SaleToPOIRequest>
  <MessageHeader MessageClass="Service" MessageCategory="Payment" MessageType="Request" ServiceID="4779" WorkstationID="" POIID="52400004" />
  <PaymentRequest>
    <SaleData>
      <SaleTransactionID TransactionID="2587" TimeStamp="2017-07-05T17:04:50.0539062+01:00" />
    </SaleData>
    <PaymentTransaction>
      <AmountsReq Currency="SEK" RequestedAmount="1000" CashBackAmount="0" TipAmount="0.00" />
      <TransactionConditions LoyaltyHandling="Forbidden" />
    </PaymentTransaction>
    <PaymentData PaymentType="Normal">
    </PaymentData>
  </PaymentRequest>
</SaleToPOIRequest>

Reporting

The integrator is responsible for tracking and separating transactions into multiple transaction reports when multiple terminal IDs are used.

Implementation Notes

Messages from the ECR are schema-validated before processing.
Fields marked as mandatory by the EPAS schema must still be present even when Westpay does not use them functionally.
The source specification extends standard EPAS in selected places, including fields such as ExtraPOIID, Method, ReferenceNumber, AlternativePaymentMethod, ExtAuth, and MarkupDescription.
Event notifications are used for maintenance state, card events, completion, reject, and incremental event-log delivery.
Reconciliation is marked obsolete from version 1.22.3; GetTotals is the non-closing reporting alternative.