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
| Table of Contents |
|---|
Login
A LoginRequest was accepted by the Retail Module
...
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.
| Info |
|---|
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 |
DisplayRequest
A DisplayRequest was received while the System was available
Content
A DisplayData object, obtained using DisplayData GetDisplayData() with the 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 | ||
|---|---|---|---|---|
displayID | String | The Display ReferenceID requested by the Sale System (null if unapplicable)displayType | DisplayType (enum) | Signals wether this object is a Reference or Text display request |
No response
InputRequest
TBD
...