Amadis
Events
- Frédéric Béland (Unlicensed)
Introduction
Each different request or notification type received by the Retail Module is represented by a unique class, with associated data extracted from the received Nexo message. A distinction is made between Events, which do not have an associated response, and Requests, which require a response.
TOC
- 1.1 Introduction
- 2 TOC
- 2.1 Login
- 2.2 Logout
- 2.3 Disconnection
- 2.4 PaymentRequest
- 2.5 Content
- 2.6 Response
- 2.7 Abort
- 2.8 DisplayRequest
- 2.9 Content
- 2.10 InputRequest
- 2.11 AdminRequest
- 2.12 ErrorReport
- 2.13 Content
Login
A LoginRequest was accepted by the Retail Module
No response
Logout
A LogoutRequest was accepted by the Retail Module
No response
Disconnection
A Disconnection was detected by the Retail Module
The absence of this event is not a guarantee that a connection is still active with the Sale System. The presence of this event is a guarantee that the connection is or was broken.
No response
PaymentRequest
A PaymentRequest was received from the Sale System while the system was available
This Event type requires a response, even if the operation was unsuccessful
Content
A TLV stream containing the Request elements in Arkos-specific format, including (but possibly not exclusively):
BER Tag | Count | Field Name | Format | Nexo Retail Source (under PaymentRequest) | Miscellaneous Information |
|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Â |
|
|
|
|
| Â |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Response
A TLV tree containing the following elements, in raw form:
Field | Type | Usage |
|---|---|---|
PaymentData | DO | The TLV payment response from the Arkos Framework |
MerchantData | DO | Context-specific Merchant Data (TBD) |
Abort
An abort request was received from the sale system
The application has the responsibility to try to abort the current transaction (if one is running), if possible. There is no direct response to this event - the eventual PaymentResponse will contain wether it was Aborted.
In general, it is suggested to manage aborts through the PollingProvider, providing aborts up to card detection.
If this request is received outside of a valid service exchange, or received too late, the Application should signal that the message was completed, using NexoRetailModule.signal(NexoSignal.MessageCompleted); which will send to corresponding notification back to the Sale System.
DisplayRequest
A DisplayRequest was received while the System was available
This is the base display class, and should be cast to one of the derived classes (DisplayRefRequest or DisplayTextRequest)
Content
The following fields and methods:
Field | Type | Usage |
|---|---|---|
displayType | DisplayType (enum) | Signals wether this object is a Reference or Text display request |
No response
InputRequest
TBD
AdminRequest
TBD
ErrorReport
The Nexo Module detects an error. This includes internal errors, data errors and protocol errors.
Content
An UTF-8 String (in binary form) with the error description, which can be logged by the Merchant application or discarded. Retrieve through thebyte[] GetData() method.
// To convert to a Java String
String errorMessage = new String(event.GetData());No response