Worldline Payment Interface

Version 2.2 | Revision #3

Table Of Contents

• 1 Overview

  • 1.1 What's New

  • 1.2 Revision History

• 2 Interface Structure

  • 2.1 Versioning

  • 2.2 Extras

    • 2.2.1 Service Types

• 3 Interface Description

  • 3.1 Financial

    • 3.1.1 Payment

    • 3.1.2 Cancellation

    • 3.1.3 Unreferenced Cancellation

    • 3.1.4 Refund

    • 3.1.5 Pre-authorization

    • 3.1.6 Update Pre-authorization

    • 3.1.7 Payment Completion

    • 3.1.8 Deferred Payment

    • 3.1.9 Payment Instrumentation Recognition

    • 3.1.10 Follow on Credit

    • 3.1.11 Follow on Payment

    • 3.1.12 Phone Authorized

    • 3.1.13 Force Acceptance

  • 3.2 Management

    • 3.2.1 Payment Menu

    • 3.2.2 Day-End

    • 3.2.3 Payment Parameterization

    • 3.2.4 Acquirer Parameterization

    • 3.2.5 Print Receipt

    • 3.2.6 Abort Ongoing Payment

    • 3.2.7 Last Day End information

  • 3.3 Information

    • 3.3.1 Last Transaction

    • 3.3.2 Payment Solution Information

• 4 Data Dictionary

  • 4.1 Request Data

    • 4.1.1 Receipt Format

    • 4.1.2 Recognition Option

    • 4.1.3 Receipt Target

  • 4.2 Response Data

    • 4.2.1 ShopInfo

    • 4.2.2 Result

    • 4.2.3 Error Condition

    • 4.2.4 Action Code

    • 4.2.5 Receipt

    • 4.2.6 Payment Information Item

    • 4.2.7 Supported Technologies

    • 4.2.8 Supported Ticket Format

    • 4.2.9 Acquirer Protocol

    • 4.2.10 Authorization Mode

    • 4.2.11 Brand Name

    • 4.2.12 Card Data Input

    • 4.2.13 Cardholder Verification Method

• 5 Payment Solution Implementation

1 Overview

The Worldline Payment Interface (WPI) is an Android intent-based interface that enables easy and fast integration with payment apps. It is designed to allow additional business applications to execute payments on any Worldline offered SmartPOS device. A SmartPOS device is a payment device that runs Android.

All Worldline Payment Solutions support WPI, which means that business applications that use this interface can run everywhere without any change of code. This makes it easy for developers to build payment apps that are compatible with a wide range of payment devices and payment protocols.

The WPI interface is built on top of the Android Intent mechanism, which allows different parts of an app to communicate with each other in a structured way. By using intents to trigger payment-related actions, the WPI interface simplifies the payment integration process and makes it easier for developers to build business applications on top of Payment Solutions.

1.1 What's New

• Interface Structure

  • Information on requirements for service types support added (Section 2.1.1)

• Financial functional extensions

  • New service types added :

    • Unreferenced Cancellation

    • Phone authorized 

    • Force acceptance

  • Payment request fields added:

    • productSelection

  • Financial response field added:

    • surchargeAmount

    • expiryDate

    • voiceReferralPhoneNumber

    • phoneAuthorized

    • externalTransactionIdentifier

    • forcedAcceptance

    • productSelection

    • token

    • onlineToken

  • Payment request product selection use case

  • Payment Instrumentation Recognition description updated

  • New Error Condtion values added:

    • WPI_ERR_COND_MPKE_NOT_SUPPORTED_BY_SERVICE_TYPE

    • WPI_ERR_COND_INVALID_AUTHORIZATION_CODE

    • WPI_ERR_COND_PRODUCT_NOT_SUPPORTED

    • WPI_ERR_COND_DAY_END_NOT_YET_PERFORMED

    • WPI_ERR_COND_VOICE_REFERRAL_REQUIRED

  • Conditions of presence Financial response updated

  • Clarification on Financial response content added (3.1 Financial response description)

• Management functional extensions:

  • New service type 

    • Last Day End Information 

  • Clarification on receipt format for Management actions added (only FORMATTED supported). Affected sections:

    • 3.2 Management (Description)

    • 3.2.2 Day-End (receiptFormat removed from the request)

    • 3.2.3 Payment Parameterization (receiptFormat removed from the request)

    • 3.2.4 Acquirer Parameterization (receiptFormat removed from the request)

    • 3.2.7 Last Day End information (receiptFormat removed from the request)

• Information functional extensions

  • Response fields added

    • manualPanKeyEntrySupportedServiceTypes

    • supportsReceiptWidth

    • terminalIdentifierLong

    • supportedProducts for Product Selection use case

  • Clarified the session id use in the last transaction response

• Data Dictionary

  • WPI_BRAND_NAME_BLIK value added in Brand Name

  • Clarification on numberofCancellableTransactions value in Payment Information Item added

  • Clarification on customerLanguage value in Request Data and Response Data added

• Payment Solution Implementation

  • Clarification on Payment Solution Reference added to ensure interoperability (Pt.5.2.d)

1.2 Revision History

• Revision #3

  • 3.1 Financial

    • productSelection field type changed from Array to Object

  • 3.1.1 Payment

    • productSelection field type changed from Array to Object

  • 3.1.1.1 Payment with Product Selection

    • Description changed ( productSelection field type changed from Array to Object)

  • 4.1 Request Data

    • customerLanguage field format updated to ISO 639-1

  • 4.2 Response Data

    • customerLanguage field format updated to ISO 639-1

    • supportedLanguages field format updated to ISO 639-1

    • cardholderDefaultLanguage field format updated to ISO 639-1

    • merchantLanguage field format updated to ISO 639-1

  • 4.2.15.1 Values item 

    • Description updated (Reference to ISO 639-1)

• Revision #2

  • 3.1 Financial

    • reference  field restored in Response table

  • 3.2 Management

    • Condition for  receipt  field clarified (from Optional to Conditional)

  • 3.3.2 Payment Solution Information

    • supportsReceiptDelegation corrected to supportReceiptDelegation  to support receipt delegation as per previous WPI version

  • 4.2 Response Data

    • supportsReceiptDelegation corrected to supportReceiptDelegation  to support receipt delegation as per previous WPI version

  • Sections numbering fixed

    • 2.1 Extras to 2.2 Extras (with sub-sections)

• Revision #1

  • Document Creation

2 Interface Structure

The WPI provides a set of intents that developers can use to build apps that work with the interface. The following table lists each intent, along with its purpose:

We have two type of categories for the Interface

• Display Actions : These actions start the payment solution that are processing financial transactions or require user interaction.

  • Android intents are used

• Background Actions : These actions perform background processing that doesn't require user interaction.

  • Messenger service is used

  • The Message.what attribute of the Messenger Service should be set to the code 895349 for any WPI message.

  • The Message.obj should be  a bundle formatted just like the WPI Extras.

  • Those extras are being transported through a different mean but the same structure and rules applies . 

2.1 Versioning

The WPI uses versioning with the format Y.X (e.g., 1.0 , 2.1 ) to track and manage different releases of our software. Additionally, each revision within a minor version is assigned a unique number, such as " 3.2 Revision #9 ."

• Y (Major Version): Signifies a significant milestone with potential breaking changes. Example: a version 2.x request cannot be used with version 1.x . 

• X (Minor Version): Represents a release with new features or improvements that are backward compatible within the same major version. Example: a version 1.1 must remain compatible with the version 1.0 .

• Revision Number: Each revision is assigned a unique number, indicating the specific iteration of a minor version (e.g., " 3.2 Revision #9 "). Revisions mainly include small fixes, updates, and improvements. They address minor bugs or add slight enhancements/clarifications.

2.2 Extras

An extra in Android intents is a way to pass additional data or parameters to another component in order to provide more context or information for the requested action. In WPI we have extras for request and response. The request extras needs to be provided by the Business Application that is using the interface and the response extra is provided by the Payment Solution.

Request

Response

2.2.1 Service Types

Each intent has several service types that specify the request. Payment Solution shall support all mandatory service types as listed below in Condition column.

2.2.1.1 Financial

2.2.1.2 Management 

2.2.1.3 Information

3 Interface Description

Please refer to Data Dictionary section for detailed description of individual fields 

3.1 Financial

Each financial transaction has a minimum set of fields that needs to be there per service type. In the subsequent chapters this is described in detail. 

The response contains the following fields, unless specific service types describe their own response content later in this section.

Response :

3.1.1 Payment

Service Type : WPI_SVC_PAYMENT

Request :

3.1.1.1 Payment with Product Selection

This use case is handled by the nominal payment use case. In case the payment provider brands have products active ( e.g meal vouchers, eco vouchers, consumption voucher, etc) the user (usually Merchant) can select them in the business application and send it using the productSelection  field. This field is an Object containing the product provider and the identifier of the product used by the payment provider. The information about voucher providers and voucher types is provided by the payment solution information. 

3.1.2 Cancellation

The cancellation is also known as reversal. The cancellation can be executed for several service types, the cancellation service type depends on the initial service type and needs to be set and used correctly by the business application.

Service Type : WPI_SVC_CANCEL_PAYMENT, WPI_SVC_CANCEL_PRE_AUTHORIZATION, WPI_SVC_CANCEL_UPDATE_PRE_AUTHORIZATION, WPI_SVC_CANCEL_PAYMENT_COMPLETION

Request :

3.1.3 Unreferenced Cancellation

An unreferenced cancellation, is a card-present transaction, that enables the cancellation of a transaction without requiring the original transaction reference. The payment provider reads the card and presents the user with a list of matching transactions that can be reversed, allowing the user to select from them. If the values provided in mandatory fields (currency,requestedAmount) are not recognized by payment solution backend WPI_ERR_COND_INVALID_TRANSACTION_REQ is returned.

Service Type : WPI_SVC_CANCEL_UNREFERENCED 

Request :

3.1.4 Refund

Service Type : WPI_SVC_REFUND

Request :

3.1.5 Pre-authorization

Service Type : WPI_SVC_PRE_AUTHORIZATION

Request :

3.1.6 Update Pre-authorization

This service is used to increase the pre-authorization amount, which involves specifying the requested amount for the increment. The reference of pre-authorization is provided through the paymentSolutionReference , which will be use to make the update pre-authorization. The requestedAmount is just the amount that shall be incremented, not the total one . 

Service Type : WPI_SVC_UPDATE_PRE_AUTHORIZATION

Request :

3.1.7 Payment Completion

To complete a previous pre-authorization the paymentSolutionReference has to be used. The final amount should be equal to or less than the total pre-authorization amount (this includes all previous Update pre-authorization calls). If you use a higher amount for the completion, the transaction may not be successful because the higher amount was not reserved - we do not recommend to use higher amounts.

Service Type : WPI_SVC_PAYMENT_COMPLETION

Request :

3.1.8 Deferred Payment

Deferred payment for petrol transaction processing refers to a payment arrangement where the actual payment for fuel is delayed or postponed until a later time. The transaction is split into two parts: authorization and completion.

1. Authorization: The first part of the deferred payment process is authorization. When a customer swipes their payment card or provides their payment details at the petrol station, the system checks if the card is valid and has sufficient funds or credit available. This initial authorization ensures that the customer's payment method is valid and can cover the cost of the fuel. However, the actual payment is not processed at this stage.

2. Completion: The second part of the deferred payment process is completion. After the authorization is successful, the petrol station temporarily reserves the funds or credit limit on the customer's card to cover the estimated cost of the fuel. This reserved amount is typically a pre-authorization hold or pending transaction. The petrol station then dispenses the fuel to the customer.

Later, the petrol station completes the transaction by submitting the final payment request to the customer's bank or credit card company. At this stage, the reserved funds are transferred from the customer's account to the petrol station's account, completing the payment process. The exact timing for completing the authorization may vary depending on the specific payment system and agreements between the petrol station and the customer's financial institution.

The delay between the “Authorization Exchange” and the “Completion Exchange” can be quite long (e.g., in case of tank filling). Therefore, to increase the availability of the terminals using the “Deferred Payment” service, the “Multi-Session” concept is usually configured for performing “Parallel Transactions”. The authorization exchange provides the terminal with an authorized amount as upper limit, and the completion exchange notifies the acquirer of the final amount as actually applicable. The “Deferred Payment” is indifferently meant for attended or unattended terminals. 

PSD2 imposes the amount to be present in the request.

3.1.8.1 Authorization

Service Type : WPI_SVC_DEFERRED_PAYMENT_AUTHORIZATION

Request :

3.1.8.2 Completion

Service Type : WPI_SVC_DEFERRED_PAYMENT_COMPLETION

Request :

3.1.9 Payment Instrumentation Recognition

The purpose of the service type is to read the card before actual payment transaction processing is performed (for e.g. to recognize fleet cards) with a single card insertion. This also allows to avoid double tap under the condition the payment instrument is in contactless entry mode. The payment solution needs information about the transaction service type, requested amount, currency and reference that shall be used for the subsequent transaction. There are two possibilities to do a payment instrumentation recognition token retrieval only and card recognition with further payment processing afterwards. The response differs from the standard response as described below. 

Service Type : WPI_SVC_PAYMENT_INSTRUMENT_RECOGNITION

Request :

Response :

3.1.10 Follow on Credit

Follow on Credit is a card not present transaction which is used to perform the credit transaction with the card data of a previous transaction. paymentSolutionReference is used to identify data necessary to perform follow-up transaction.

Service Type : WPI_SVC_FOLLOW_ON_CREDIT

Request :

3.1.11 Follow on Payment

Follow on Payment is a card not present transaction which is used to perform the payment transaction with the card data of a previous transaction. paymentSolutionReference is used to identify data necessary to perform follow-up transaction.

Service Type : WPI_SVC_FOLLOW_ON_PAYMENT

Request :

3.1.12 Phone Authorized

A phone authorized transaction, is a subsequent transaction after there was a refusal with WPI_ERR_COND_VOICE_REFERRAL_REQUIRED error condition returned. Merchant needs to obtain authorization code via Voice Referral procedure performed with phone number provided in voiceReferralPhoneNumber field. 

Service Type : WPI_SVC_PHONE_AUTHORIZED

Request :

3.1.13 Force Acceptance

A forced acceptance transaction, is a transaction where merchant accepts the risk of payment in relation to an offline transaction. 
Service Type : WPI_SVC_FORCE_ACCEPTANCE

Request :

3.2 Management

Management actions has an empty request JSON content, except for services that contain a receipt, like Day-End and the parameterizations. The receipt format supported for management actions is FORMATTED (defined in 4.1.1 Receipt Format). If receiptWidth or receiptDelegation values are defined for a management services that does not have a receipt these   will be ignored by the payment solution. 

The response for every management action contains the following fields

Response :

3.2.1 Payment Menu

This is used to open the payment solution menu to trigger payment solution specific actions.

Service Type : WPI_SVC_PAYMENT_MENU

3.2.2 Day-End

The day-end is used to upload all transactions to the host for the final settlement. As result an receipt is received which contains a transaction summary per brand with no. of transactions and amount since the last day-end (incl. online and offline transactions).

Service Type : WPI_SVC_DAY_END

Request :

Response :

3.2.3 Payment Parameterization

The payment configuration is used to synchronize the payment solution specific parameters with the corresponding management system.

Service Type : WPI_SVC_PAYMENT_PARAMETERIZATION

Request :

3.2.4 Acquirer Parameterization

The Acquirer parameterization is used to synchronize with the acquirer system corresponding to the payment solution. This includes brands, limits and any other parameter that is mandatory to process a financial transaction. Multi-Acquirer solutions will do the parameterization synchronization for all acquirers.

Service Type : WPI_SVC_ACQUIRER_PARAMETERIZATION

Request :

3.2.5 Print Receipt

This function is intended to provide a compliant receipt by the payment solution. A receipt can be provided in case of

• A previous service was successfully executed with a corresponding session ID for this business application

• The SESSION_ID of the print receipt request in the Android Extras has to be the previous request SESSION_ID and not a new one

• The payment solution supports receipt delivery, for example printing or digital receipt based delivery

• Referenced request (by SESSION_ID) has a receipt available

The Android Extras in the response are close to a standard transaction response except for the conditional presence of WPI_RESPONSE. An initial check on this extra property provides information about the existence of the session. If not available the session ID is not existing.

Be aware any payment solution will just store the last SESSION_ID and response per application (package name). This implies that no other WPI requests shall be done before printing the receipt.

Hint: The receipt cannot be provided under the following circumstances:

Service Type : WPI_SVC_PRINT_RECEIPT

Request :

Response: 

3.2.6 Abort Ongoing Payment

Abort the current ongoing financial transaction. If the transaction was successfully aborted or there was no running transaction WPI_RESULT_SUCCESS will be returned in all other cases WPI_RESULT_FAILURE .

Service Type : WPI_SVC_ABORT

3.2.7 Last Day End information

Request the receipt information of the last day end performed by the terminal. No printing needed by the payment application. 

Service Type : WPI_SVC_LAST_DAY_END

Request :

Response :

3.3 Information

Retrieval of Payment Solution specific information that does not require user interaction. There request does not contain any parameter. The response is specific per service type.

3.3.1 Last Transaction

In case of the last transaction response is not known any more it can be requested by this service. It will return the last financial transaction response independent of the result, failed or success. This is a recovery feature as the payment solution will remember the last SESSION_ID as well as corresponding transaction response. The Android Extras are close to a standard transaction response except for the conditional presence of  WPI_SERVICE_TYPE  &  WPI_RESPONSE . An initial check on one of these extra properties can provide information about the existence of the session.

Be aware any payment solution will just store the last response. That implies that no other WPI request shall be done before the recovery. 

Service Type : WPI_SVC_LAST_TRANSACTION

Request :

Response :

3.3.2 Payment Solution Information

The payment should provide all the required information, in case of a lack or issue of configuration / initialization the response should provide the WPI_ERR_COND_NOT_INITIALIZED as an errorCondition .

Service Type : WPI_SVC_PAYMENT_INFORMATION

Response :

4 Data Dictionary

4.1 Request Data

All data has to be provided as JSON and needs to be provided as WPI_REQUEST extra.

4.1.1 Receipt Format

The receipt format defines how to retrieve the receipt. Default is formatted. If an empty array is sent no receipt will be returned. The following values are possible

4.1.2 Recognition Option

4.1.3 Receipt Target

4.2 Response Data

All data has to be provided as JSON and will be provided as WPI_RESPONSE extra.

4.2.1 ShopInfo

4.2.2 Result

4.2.3 Error Condition

4.2.4 Action Code

4.2.5 Receipt

The receipt language is the same as it is for the payment app. As it is written in the JSON specification ( https://www.ietf.org/rfc/rfc4627.txt ) every control character has to be escaped like shown below but on the same line.

FORMATTED format:

formatted: {
	"merchant":"    This is to confirm your transaction\\n
		registered at:\\n
	    ----------------------------------------\\n
				 SPS-Softpos Pilot 02\\n
				  Grzybowska 4/246\\n
				   00-131 Warszawa\\n
		----------------------------------------\\n
		15.02.2023 22:36\\n
		0,03 PLN\\n
		Visa **** **** **** 7984\\n
				Transaction details: \\n 
	    Status:                       AUTHORIZED\\n
		Authorization code:           (0) 741451\\n
		ARQC:                   61BC5EDC34F63979\\n
		AID:                      A0000000031010\\n
		Contactless\\n
		Type:                               Sale\\n
		POS ID:                         APP00002\\n
		MID:                           103810047\\n
		VISA CARD",
	"client":"    This is to confirm your transaction\\n
		registered at:\\n
	    ----------------------------------------\\n
				 SPS-Softpos Pilot 02\\n
				  Grzybowska 4/246\\n
				   00-131 Warszawa\\n
		----------------------------------------\\n
		15.02.2023 22:36\\n
		0,03 PLN\\n
		Visa **** **** **** 7984\\n
				Transaction details: \\n 
	    Status:                       AUTHORIZED\\n
		Authorization code:           (0) 741451\\n
		ARQC:                   61BC5EDC34F63979\\n
		AID:                      A0000000031010\\n
		Contactless\\n
		Type:                               Sale\\n
		POS ID:                         APP00002\\n
		MID:                           103810047\\n
		VISA CARD"
	}
}

JSON Format:

"json":{
	"receiptTargets":{
		"merchant":{
			"description": "List of field names of the receipt to be included for the merchant receipt"
			"type":"array",
			"items":{
				"type":"string"
			}
		},
		"client":{
			"description": "List of field names of the receipt to be included for the client receipt"
			"type":"array",
			"items":{
				"type":"string"
			}
		}
	},
	"duplicate":{
		"type":"boolean"
	},
	"shopInfo":{
		"name":{
			"type":"string"
		},
		"address":{
			"type":"string"
		},
		"zipCode":{
			"type":"string"
		},
		"city":{
			"type":"string"
		},
		"country":{
			"type":"string"
		},
		"logo":{
			"type":"string" // Content provider uri to the logo file
		}
	},
	"terminalIdentifier":{
		"type":"string"
	},
	"period":{
		"type":"string"
	},
	"transactionIdentifier":{
		"type":"string"
	},
	"currency":{
		"type":"string"
	},
	"amount":{
		"type":"integer"
	},
	"cashbackAmount":{
		"type":"integer"
	}
	"tipAmount":{
		"type":"integer"
	},
    "token":{
		"type":"string"
	},
	"par":{
		"type":"string"
	},
	"brandName":{
		"type":"string"
	},
	"applicationIdentifier":{
		"type":"string"
	},
	"issuerName":{
		"type":"string"
	},
	"pan":{
		"type":"string"
	},
	"maskedPan":{
		"type":"string"
	},
	"cardSequence":{
		"type":"string"
	},
	"cardExpiration":{
		"type":"string"
	},
	"serviceName":{
		"type":"string"
	},
	"timestamp":{
		"type":"string"
	},
	"authorizationCode":{
		"type":"string"
	},
	"reference":{
		"type":"string"
	},
	"acquirerIdentifier":{
		"type":"string"
	},
	"entryMode":{
		"type":"string"
	},
	"cardDataInput":{
		"type":"string"
	},
	"cardholderVerificationMethod":{
		"type":"string"
	},
  "legalIdentificationRequired":{
		"type":"boolean"
	},
	"cardBalance":{
		"old":{
			"type":"string"
		},
		"new":{
			"type":"string"
		},
		"cardholderText":{
			"type":"string"
		}
	},
	"paymentSolutionReference":{
		"type":"string"
	},
	"operatorIdentifier":{
		"type":"string"
	},
	"cardholderReceiptText":{
		"type":"string"
	},
	"acquirerReceiptText":{
		"type":"string"
	},
	"footerLines":{
		"type":"array",
		"items":{
			"line":{
				"type":"string"
			}
		}
	},
	"additionalData":{
		"type":"array",
		"items":{
			"key":{
				"type":"string"
			},
			"value":{
				"type":"dynamic"
			}
		}
	}
}

4.2.6 Payment Information Item

4.2.7 Supported Technologies

4.2.8 Supported Ticket Format

The supported ticket formats are defined in  4.1.1 Receipt Format

4.2.9 Acquirer Protocol

4.2.10 Authorization Mode

4.2.11 Brand Name

Mapping should be based on Payment Application configuration returned by Acquirer. If not possible to find the right match (for e.g. brand is not specified or Payment Solution does not know what brand was used) WPI_BRAND_NAME_OTHER value shall be returned. In case of local brands, WPI_BRAND_NAME_LOCAL_DEBIT_CARD or WPI_BRAND_NAME_LOCAL_CREDIT_CARD shall be returned.

4.2.12 Card Data Input

4.2.13 Cardholder Verification Method

5 Payment Solution Implementation

1. Mandatory Attributes and Result Structure

   1. The technical design is based on defining only the mandatory attributes in the request needed to meet every requested business use case aiming to be payment protocol agnostic .

   2. The payment solution shall support every combination of attributes defined in the request.

   3. The result structure contains every possible attribute to be returned to meet every use case.

2. Payment Solution Reference

   1. The payment solution reference must be designed in a unique way so that all follow on transactions can be handled with this. For example if you do a pre-authorization, it needs to contain all payment-specific fields to do all follow-on transactions like cancel pre-authorization, completion, and so on. WPI supports the so-called reference, for more details check Data Dictionary 4.1 Request Data, this field is also known as a merchant reference and used for reconciliation.

   2. The payment solution shall print the paymentSolutionReference on cardholder receipt in plain text or as QR Code:

      1. compliant with ISO/IEC 18004:2015 (or higher) standard.

      2. highest (H) error correction level must be ensured.

      3. QR Code version should be selected according to the length of data that given Payment Solution will return.

      4. QR Code content should be limited to paymentSolutionReference value with no additional data (i.e. raw data).

   3. The payment solution reference shall be as short as possible and easy to type manually within another Android application.

   4. The payment solution reference should remain interoperable among all payment solutions for given payment protocol

3. Remark and Error Handling

   1. The payment solution shall provide a remark that is understandable by a third-party integrator and only in case of an error condition not equal to WPI_ERR_COND_NONE .

   2. The payment solution shall send back the errorCondition WPI_ERR_COND_BUSY in case of a transaction currently in progress.

4. Payment Instrumentation Recognition Request

   1. In case of a Payment Instrumentation Recognition Request, the terminal shall:

      1. perform the card withdrawal in case of no amount & currency is present.

      2. not wait for another action in case of no amount & currency is present.

      3. return a token for the card PAN or the NFC UID (in case of NFC non-payment related cards) that was read. The token should be a hash which is generated by the Payment Solution and can be reproduced at least on the same device.

5. Tip processing

   1. In case of tipAmount in the WPI request is not defined the Payment Solution has to show the tip entry screens.

   2. In case of tipAmount in the WPI request is defined >= 0 the Payment Solution will take the tip amount from the request and not show the tip entry screen

   3. In case of tipAmount is null or 0 no tip will be processed as part of given transaction

6. Other Requirements

   1. The payment solution must store the SESSION_ID for the last transaction as well as the last transaction object of each business application. Due to this, a recovery procedure can be implemented with the last transaction request.

   2. For compatibility reasons and a certain grace period, every payment application shall support the last two major versions starting with WPI 2.0

   3. Password-protected transaction types such as refund, credit, and follow-on credit must be password protected. In case of a standalone configuration of the payment solution, password entry and validation must be done by the payment solution.

   4. The payment solution shall always take care off the receipt handling - depending on the TMS configuration. Business applications can override (deactivate) the default behavior by setting the receiptDelegation to false .