Worldline Payment Interface

Version 2.2.2

Introduction
Communication Layer
1. Android Inter App Communication
  1. Interface Structure
  2. Android Intent implementation
Data Dictionnary

1. Introduction

This page is intended for third-party application providers who want to develop business applications for Worldline Payment Applications. This document only covers use cases for the Worldline Tap on Mobile.

To interact with a payment application, Worldline has defined the W orldline P ayment I nterface, also known as WPI . WPI is designed for easy and fast integration. A 3rd party application is used to extend and control the business flow for the desired use cases. The payment application is only displayed in the event of a transaction.

The transaction flow and screens cannot be changed due to the payment protocol and PCI requirements.

All source code examples are written in Kotlin (Android).

1.1 Supported Transactions Types

At this stage the following transaction types are supported:

Payment
Refund
Reversal/Cancellation

A Reversal transaction can only be used for the last successful purchase transactions (Payment).

A Refund transaction can only be used for successful purchase transactions (Payment) that cannot be Reversed/Cancelled.

1.2 Preconditions

Before you can start the implementation, you must meet the following preconditions:

Development IDE for Android development
Android Toolkit
Worldline Tap on Mobile Sandbox App
Fully available android application project
Your package name has to be whitelisted for Tap on Mobile app

1.3 Versioning

Every WPI version Y.X is backward compatible with all Y versions. A payment solution who has implemented version 1.1 can be used with request in version 1 (1.0) format. A Version 2.2 cannot be used with a request with version 1.1.

Tap on Mobile support:

ID	Tap on Mobile Version	WPI 1.0	WPI 2.0	WPI 2.1	WPI 2.2
1	2.1.25	Ok	N/A
2	2.1.25.1	Ok	N/A
3	2.1.28	Ok	N/A
4	2.1.28.1	Ok	N/A
5	2.1.29	Ok	N/A
6	2.1.30	Ok	N/A	Ok
7	2.1.31	Ok	N/A	Ok
8	2.1.32.X	Ok	N/A	Ok
9	2.1.34.X	Ok	N/A	Ok
10	4.1.39.x	Ok	N/A	Ok	Ok
11	5.3.0	Ok	N/A	Ok	Ok
12	5.4.0	Ok	N/A	Ok	Ok

2. Communication Layer

2.1 Android Inter App Communication

WPI is using Intents in Android that are a means of communicating between components of an Android app, such as between Activities, Services, Broadcast Receivers, and Content Providers. An Intent object is used to describe what an app component should do, including the action to be performed and the data to be used.

Intent usage in Android for application integration can be broadly categorized into two types:

Explicit Intents: These intents are used to launch a specific component within the same app. The target component is specified explicitly in the intent. For example, starting an Activity from another Activity within the same app.
Implicit Intents: These intents do not specify the target component directly. Instead, they declare a general action to be performed and let Android resolve the target component based on the information provided in the intent. For example, sending an email or opening a web page. WPI is the implementation of this type of intent.

Intents can also carry data in the form of key-value pairs, called Extras, which can be used to pass data between components. By using intents, apps can delegate tasks to other components and take advantage of the existing Android framework to perform common actions.

2.1.1 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:

Type	Category	Intent	Purpose
Financial	Display Action	com.worldline.payment.action.PROCESS_TRANSACTION	Process a financial transaction
Information	Background action	com.worldline.payment.action.PROCESS_INFORMATION	Background management of payment solution specific information

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, but sometimes can require user interaction (due to COTS device specification).
- Android intents are used

2.1.2 Android Intent implementation

The start of a payment is based on an intent. Each special transaction type has a set of parameters that are mandatory. To test transactions, you can use the Worldline Tap on Mobile Test App.

val intent = Intent("com.worldline.payment.action.PROCESS_TRANSACTION").apply{flags += Intent.
FLAG_ACTIVITY_REORDER_TO_FRONT}

This intent requires some extras:

Request

Extra	Description	Type	Condition
WPI_SERVICE_TYPE	Specify the subtype of action to be executed	String	Mandatory
WPI_REQUEST	The request contains JSON structured data mandatory for given service type, in some specific cases this field is not given or empty	String	Mandatory
WPI_VERSION	Used WPI version	String	Mandatory
WPI_SESSION_ID	Used as an identifier of a WPI exchange (a request/response) between a client application and a payment application. Is used to recover the status of the exchange in case of an unexpected failure. Is provided by the client and should be part of the response. The session id : · must be unique · must be part of the response · must not be reused for subsequent requests (as soon as the cache is expired this would not be an issue, so it is not necessary to keep track of it but as a general rule a unique random string per request should be used) In the case of an unexpected failure during an exchange, the session id can be used in order for the client to restore its state and sync the exchange status with the payment application.	String	Mandatory

Response

Extra	Description	Type	Condition
WPI_SERVICE_TYPE	Specify the subtype of action to be executed	String	Mandatory
WPI_RESPONSE	The response contains JSON structure data processed for the requested service type	String	Mandatory
WPI_VERSION	Used WPI version	String	Mandatory
WPI_SESSION_ID	Identifier of a WPI exchange provided by the client	String	Mandatory

The transaction request fields and examples per transaction type are explained in the subsequent sections:

/** Code snippet only
* SaleTransactionRequest and SaleTransactionResponse are not provide they are simple POJOs
*
*
*/
class SaleActivity: AppCompatActivity() {
   val launcher = registerForActivityResult(
        ActivityResultContracts.StartActivityForResult()
    ) { result ->
        result.data?.let { handleTransactionResponse(it) }
    }
          
    private fun startTransactionIntent(transactionJson : String, serviceType : String) {
        val intent = Intent("com.worldline.payment.action.PROCESS_TRANSACTION")
        // These extras are mandatory whether the intent comes from the payment
        // application or a 3rd party application.
        intent.putExtra("WPI_SERVICE_TYPE", serviceType )
        intent.putExtra("WPI_REQUEST", transactionJson )
        intent.putExtra("WPI_VERSION", "2.1")
intent.putExtra("WPI_SESSION_ID",currentSession)
  
        launcher.launch(intent)
    }
  
    private fun handleTransactionResponse(intent: Intent) {
        val rawJsonResponse = intent.getStringExtra("WPI_RESPONSE")
        // Handle response
    }
}

As you can see in the above example, the transaction request is sent to the payment application as JSON. The final result of the transaction is returned from the intent started previously and needs to be handled based on the service type. The JSON format is described in chapter 3.

There are some important considerations:

It is strictly advised to store WPI_SESSION_ID within the business application
No new transaction should be initiated before the result of the previous is known
If the previous transaction status is unknown to the cash register, last transaction should be used to get it from Tap on Mobile app

3. Data Dictionnary

This chapter describes the data exchange format, all requests and responses are described here. WPI is using JSON as data exchange.

3.1 Service Type

Service Type	Description
WPI_SVC_PAYMENT	Service type for a purchase
WPI_SVC_CANCEL_PAYMENT	Service type for a reversal of a previous transaction
WPI_SVC_REFUND	Service type for a refund of a previous transaction

3.2 Transaction Data

3.2.1 Purchase

The Service Type for a purchase transaction is WPI_SVC_PAYMENT . At minimum the currency and requestedAmount is needed.

Field Name	Description	Type	Condition
Currency	Currency of the amount. Alpha code value defined in ISO 4217 (e.g. EUR)	String	Mandatory
RequestedAmount	Total payment amount as minor unit. The fractional digits are evaluated based in the currency. For example, 11.91€ must be sent as 1191 and the currency as EUR. (tip amount is excluded)	Integer	Mandatory
tipAmount	The tip amount to be used as minor unit. This amount has the same currency as the transaction amount.	Integer	Optional
Reference	Reference to be send to the payment solution for reconciliation	String	Optional Due to the limitation of acquiring systems, only following characters are supported: ('a'..'z', 'A'..'Z', '0'..'9', hex 40 - hex FF)
ReceiptFormat		Array	Optional

{
 "currency": "EUR",
 "requestedAmount": 1022,
 "reference": "myRef-01"
}

3.2.1.1 TIP handling

TIP functionality has to be enabled in Tap on Mobile portal on every terminal by checking the field “TIP Enabled”
In case of tipAmount in the WPI request is not defined and TIP is enabled => Tap on Mobile app will show the tip entry screens.
In case of tipAmount in the WPI request is defined > 0 and TIP is enabled => Tap on Mobile will take the tip amount from the request and not show the tip entry screen
In case of tipAmount is null or 0 => ToM will not show the tip entry screen and no tip will be processed as part of given transaction

3.2.2 Reversal/Cancellation

The Service Type for a reversal transaction is WPI_SVC_CANCEL_PAYMENT . To reverse a transaction, you need the paymentSolutionReference you retrieve in the response of the transaction that shall be reversed.

Field Name	Type	Condition
PaymentSolutionReference	String	Mandatory
Reference	String	Optional Due to the limitation of acquiring systems, only following characters are supported: ('a'..'z', 'A'..'Z', '0'..'9', hex 40 - hex FF)
receiptFormat	Array	Optional

Field Name

Type

Condition

PaymentSolutionReference

String

Mandatory

Reference

String

Optional

Due to the limitation of acquiring systems, only following characters are supported:

('a'..'z', 'A'..'Z', '0'..'9', hex 40 - hex FF)

receiptFormat

Array

Optional

{
 "paymentSolutionReference": "PaymentSolRef-013543-22234;kjhj3ll3jJHGGSk",
 "reference": "myRef-01"
}

Remark:

It is possible to reverse only last Payment transaction
Reversal does not need a card tapping - the full amount will be reversed to the card that initiated the Transaction

3.2.3 Refund

The Service Type for a refund transaction is WPI_SVC_REFUND . A refund transaction is like a reversal but just for a partial amount. That means the requestedAmount specified needs to be equal or lower than the original one. The paymentSolutionReference is the one of the original (previous) transaction that shall be refunded.

Field Name	Type	Condition
currency	String	Mandatory
requestedAmount	Integer	Mandatory
paymentSolutionReference	String	Mandatory
reference	String	Optional Due to the limitation of acquiring systems, only following characters are supported: ('a'..'z', 'A'..'Z', '0'..'9', hex 40 - hex FF)
receiptFormat	Array	Optional

{
 "currency": "EUR",
 "requestedAmount": "399",
 "paymentSolutionReference": "PaymentSolRef-013543-22234-kjhj3ll3jJHGGSk",
 "reference": "myRef-01"
}

Remarks:

It is possible to refund Payment transaction that is not reversable (all but the last one)
Refund requires card tapping

3.3 For transactions with multiple items or services, it is possible to process only one refund (for total or partial amount) Information

Retrieval of Payment Solution specific information that does not require user interaction. The request does not contain any parameter.

3.3.1 Last Transaction

In case of the last payment 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.

Request:

Extra	Description	Type	Condition
WPI_SERVICE_TYPE	WPI_SVC_LAST_TRANSACTION	String	Mandatory
WPI_VERSION	Used WPI version	String	Mandatory
WPI_SESSION_ID	The session id of the requested session NOT a new session id	String	Mandatory

Response

Extra	Description	Type	Condition
WPI_SERVICE_TYPE	This will be the service type of the recovered transaction not "WPI_SVC_LAST_TRANSACTION"	String	Conditional Mandatory if Session id known by the payment solution and transaction was executed (failure or success)
WPI_RESPONSE	The Financial Payment Response object of the corresponding SESSION_ID	String	Conditional Mandatory if Session id known by the payment solution and transaction was executed (failure or success)
WPI_VERSION	Used WPI version	String	Mandatory
WPI_SESSION_ID	Identifier of a WPI exchange, this session id will be the same as the one sent in the request	String	Mandatory

3.3.1.1 Receipt Format

Value (String)	Purpose	Tap on Mobile app behavior
FORMATTED	Return the receipt in a payment response as String (default)	No confirmation/receipt details screen after completing transaction; FormattedReceipt contains all the data
JSON	Return the receipt in a payment response as JSON	No confirmation/receipt details screen after completing transaction; Receipt field contains json data
EMPTY ARRAY	The payment solution provides the receipt as configured in TMS. Depending on the device this can be printed or QR Code based.	Confirmation/receipt details screen is displayed after completing transaction; no receipt data sent back to ECR application

Value (String)

Purpose

Tap on Mobile app behavior

FORMATTED

Return the receipt in a payment response as String (default)

No confirmation/receipt details screen after completing transaction;

FormattedReceipt contains all the data

JSON

Return the receipt in a payment response as JSON

No confirmation/receipt details screen after completing transaction;

Receipt field contains json data

EMPTY ARRAY

The payment solution provides the receipt as configured in TMS. Depending on the device this can be printed or QR Code based.

Confirmation/receipt details screen is displayed after completing transaction; no receipt data sent back to ECR application

Default is formatted. If an empty array is sent no receipt will be returned nor provided by the payment app.

3.4 Transaction response description

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.

Field name	Description	Type	Condition
Result	Result of the transaction (success or failure)	String	Mandatory
ErrorCondition	Specific error reason (see table below)	String	Mandatory
Remark	Terminal / transaction specific message for detailed error descriptions. Text provided by payment app in English	String	Conditional - only for NOT successful transaction
Action Code		String	Conditional - only for successful transaction
Timestamp	Date and time of the transaction, indicated by the acquirer Format according to ISO 8601	String (ISO 8601)	Conditional - only for successful transaction
Currency	Currency code of the transaction. Alpha code value defined in ISO 4217 e.g. EUR	String	Conditional - only for successful transaction
AuthorizedAmount	Amount of the transaction. The fraction is taken from the currency code. Example: Currency = EUR requestedAmount = 3190 => 31,90 €	String	Conditional - only for successful transaction
BrandName	Brand name of used payment method as described in the 3.4.4	String	Conditional - only for successful transaction in which a payment card was used
CustomerLanguage	Language the payment application shall use. If the language is not supported by the payment application the default language of the terminal will be used. used on all screens towards the cardholder and when formatting the receipt. Language code will be returned for english > en Format according to ISO 630-1 (alpha-2 code)	String
ApplicationIdentifier	Payment card application identifier dependent on the used card e.g. for MasterCard A00000041010	String	Conditional - only for successful transaction in which a payment card was used
ApplicationLabel	Payment card application label, depending on the used card e.g. MasterCard DEBIT	String	Conditional - only for successful transaction in which a payment card was used
Receipt	Details for the Receipt Object are described in the 3.4.5	Object	Conditional: Always present for successful transactions Optional for failed transactions
PaymentSolutionReference	Transaction specific and unique identification. This value is defined by the payment application and contains all necessary data to perform subsequent transactions. This value can differ based on the payment application and can only be used on the same device.	String	Conditional: Always present for successful transactions Optional for failed transactions
Reference	Reference to be send to the payment app for reconciliation	String	Optional - available in case of a reference was provided in the request
acquirerIdentifier	Identifier for the acquirer	String	Conditional: Always present for successful transactions Optional for failed transactions
merchantIdentifier		String	Mandatory
terminalIdentifier		String	Mandatory
authorizationCode	The first 2 digits of this element will correspond to the ISO response code. The structure would be XX ABCDEF where XX is the ISO response code and ABCDEF the acquirer authorisation code for successful transactions	String	Conditional in case transaction was processed online
tipAmount		Integer	Conditional - in case of tip is active and entered by the cardholder during transaction processing or provided in the request
dccUsed
dccOffered
dccAmount
dccCurrency
dccExchangeRate
authorizationMode	Pre-defined values described in 3.4.6 Authorisation mode	String	Conditional - in case of successful transaction
pan	Truncated PAN with last 4 digits	String	Conditional - in case of successful transaction
cardholderVerificationMethod		String	Conditional - in case of successful transaction
cardDataInput		String	Conditional - in case of successful transaction

3.4.1 Result

Result	Description
WPI_RESULT_SUCCESS	In case of successful transaction
WPI_RESULT_FAILURE	In case of failed transaction

3.4.2 Error Conditions

Error Condition	Description
WPI_ERR_COND_NONE	Will always be present if no error occurred
WPI_ERR_COND_SERVICE_NOT_SUPPORTED	The requested service type is not supported by the Payment Application/Service
WPI_ERR_COND_ABORTED	The initiator of the request has sent an abort request, which was accepted and processed
WPI_ERR_COND_BUSY	The Payment Application/Service is busy. Try later
WPI_ERR_COND_CARD_READ_ERR	The payment application was not able to read the card. Either due to inconsistent data or wrong card handling
WPI_ERR_COND_USER_CANCEL	The user has aborted the transaction
WPI_ERR_COND_USER_TIMEOUT	A timeout occurred while waiting for user interaction
WPI_ERR_COND_HOST_REFUSAL	The Acquirer/Issuer refused the transaction
WPI_ERR_COND_NETWORK_ISSUE	Network issue occurred (host not reachable, network down, … )
WPI_ERR_COND_TRANSACTION_TIMEOUT	Timeout occurred during transaction (other than with user interaction)
WPI_ERR_COND_ENCRYPTION_ISSUE	Encryption issue (PAN, PIN …) caused the transaction to be aborted
WPI_ERR_COND_ INVALID_KEY	The secure component of the terminal is missing a key it needs to perform the transaction
WPI_ERR_COND_INVALID_TRANSACTION_REQ	Invalid transaction request received. One of the fields in the transaction request object was invalid
WPI_ERR_COND_INTERNAL	Internal error within payment service
WPI_ERR_COND_INVALID_AMOUNT	Entered invalid amount
WPI_ERR_COND_INVALID_CURRENCY	Transaction started with invalid currency. The currency is a global attribute of the underlying payment service
WPI_ERR_COND_APP_NOT_SUPPORTED	None of the applications on the EMV NFC/IC chip card are accepted or the ISO/PAN on the magnetic stripe track didn’t result in a brand being accepted
WPI_ERR_COND_MISSING_MANDATORY_PARAMETER	A mandatory parameter is missing in the request
WPI_ERR_COND_GENERIC	A generic error that is not specified in detail
WPI_ERR_COND_WPI_VERSION_NOT_SUPPORTED	The request contains a WPI version which is not supported by the payment solution
WPI_ERR_COND_SESSION_ID_ALREADY_IN_USE	In case of the SESSION ID was already used and the payment solution would not be able to identify the last transaction for recovery then this error code is returned
WPI_ERR_COND_INVALID_PASSWORD	For password protected transactions, this error code is returned if the password entered in the payment solution, by the merchant, is incorrect
WPI_ERR_COND_RECEIPT_DELEGATION_NOT_SUPPORTED	If a transaction was started with receipt delegation and receipt delegation is not supported this error code is returned
WPI_ERR_COND_MANUAL_PAN_KEY_ENTRY_NOT_SUPPORTED	In case of manual PAN key entry is not possible but requested
WPI_ERR_COND_TIP_NOT_SUPPORTED_BY_PAYMENT_SOLUTION	If tipAmount is present in the transaction request but not supported by the payment solution
WPI_ERR_COND_TIP_NOT_SUPPORTED_BY_SERVICE_TYPE	If tipAmount is present in the transaction request but not supported for the specific service type
WPI_ERR_COND_TIP_NOT_SUPPORTED_BY_BRAND	If tipAmount is present in the transaction request but not supported by cardholder card brand
WPI_ERR_COND_TIP_AMOUNT_EXCEEDS_MAXIMUM	If tipAmount is higher than the maximum allowed tipAmount configured for the payment solution

3.4.3 Action Codes

Action Codes	Description
WPI_ACTION_CODE_NONE	No additional action to be performed

3.4.4 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.

Brand Name
WPI_BRAND_NAME_ALIPAY
WPI_BRAND_NAME_AMERICAN_EXPRESS
WPI_BRAND_NAME_BANCONTACT
WPI_BRAND_NAME_BLIK
WPI_BRAND_NAME_CARTE_BANCAIRE
WPI_BRAND_NAME_GIROCARD
WPI_BRAND_NAME_LOCAL_CREDIT_CARD
WPI_BRAND_NAME_LOCAL_DEBIT_CARD
WPI_BRAND_NAME_LOCAL_QR_CODE_BRAND
WPI_BRAND_NAME_MAESTRO
WPI_BRAND_NAME_MASTERCARD
WPI_BRAND_NAME_MASTERCARD_DEBIT
WPI_BRAND_NAME_OTHER
WPI_BRAND_NAME_PAYCONIQ
WPI_BRAND_NAME_TWINT
WPI_BRAND_NAME_VISA
WPI_BRAND_NAME_VISA_DEBIT
WPI_BRAND_NAME_VISA_ELECTRON
WPI_BRAND_NAME_VPAY
WPI_BRAND_NAME_WECHAT_PAY

3.4.5 Receipt

Field name	Description	Type
Formatted	Merchant and cardholder receipt are contained in this field. Both receipts are available as text preformatted. The receipt wide is defined by the payment application (often 32 characters) and depends on the printer capabilities or configuration.	JSON object (check example below)
Json	Merchant and cardholder receipt are contained in this field. Both receipts are represented in a JSON format. This is used to create a own format. (warning) An own format should be compliant with the local, payment solution and EMV specification!	JSON object (check example below)

Field name

Description

Type

Formatted

Merchant and cardholder receipt are contained in this field. Both receipts are available as text preformatted. The receipt wide is defined by the payment application (often 32 characters) and depends on the printer capabilities or configuration.

JSON object (check example below)

Json

Merchant and cardholder receipt are contained in this field. Both receipts are represented in a JSON format. This is used to create a own format. (warning) An own format should be compliant with the local, payment solution and EMV specification!

JSON object (check example below)

3.4.6 Authorisation Mode

Authorization Mode	Description
WPI_AUTHORIZATION_MODE_ONLINE	Authorized online

Authorization Mode

Description

WPI_AUTHORIZATION_MODE_ONLINE

Authorized online

3.4.7 Cardholder Verification Method

Cardholder Verification Method (CVM)	Description
WPI_CVM_NO_CVM	No CVM executed
WPI_CVM_PIN_ONLINE	PIN online CVM executed
WPI_CVM_CD_CVM	Consumer Device CVM

3.4.8 Card Data Input

Card Data Input	Description
WPI_CARD_DATA_INPUT_ALTERNATIVE_PAYMENT_METHOD	Card data was provided through an alternative payment method (e.g. QR Code payment)
WPI_CARD_DATA_INPUT_PROXIMITY_ICC	Card data was read via NFC with chip mode
WPI_CARD_DATA_INPUT_PROXIMITY_MAGNETIC_STRIPE	Card data was read via NFC with magnetic stripe mode
WPI_CARD_DATA_INPUT_REFERENCE_BASED	Card data evaluated by the acquiring system from a previous (referenced) transaction

3.5 Sample transaction receipt

Tap on Mobile application has its own transaction receipt handling and it supports:

Sending it via email
Generating QR Code with the link to the digital receipt on the server

However, each response contains a transaction receipt for merchants and cardholders. The below example shows a pretty printed version of the JSON you will receive - for demonstration purpose as usually each receipt content is in one line. 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":{
  "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":{
    "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"
    },
    "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"
    },
    "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"
        }
      }
    }
  }
}

Documentation

Worldline Payment Interface

Table of Contents

1. Introduction

1.1 Supported Transactions Types

1.2 Preconditions

1.3 Versioning

2. Communication Layer

2.1 Android Inter App Communication

2.1.1 Interface Structure

2.1.2 Android Intent implementation

3. Data Dictionnary

3.1 Service Type

3.2 Transaction Data

3.2.1 Purchase

3.2.1.1 TIP handling

3.2.2 Reversal/Cancellation

3.2.3 Refund

3.3 For transactions with multiple items or services, it is possible to process only one refund (for total or partial amount) Information

3.3.1 Last Transaction

3.3.1.1 Receipt Format

3.4 Transaction response description

3.4.1 Result

3.4.2 Error Conditions

3.4.3 Action Codes

3.4.4 Brand Name

3.4.5 Receipt

3.4.6 Authorisation Mode

3.4.7 Cardholder Verification Method

3.4.8 Card Data Input

3.5 Sample transaction receipt