Terminal Commerce Applications | Applications | Services | Platform Components | Runtime Model | Elements of a Terminal Commerce Application

Terminal Commerce Applications

Terminal Commerce applications can range from client-heavy applications leveraging HTML, CSS, and JavaScript, to lighter applications without client scripting. Some applications require access to third-party servers to collect and process data, others simply run offline. Some applications exchange data with the payment application, while others run without participating in the transaction.

Regardless of these differences, Terminal Commerce applications are managed uniformly by various components of the Platform: the Runtime environment, payment application, entitlement services, and various portals. At a basic level, all Terminal Commerce applications are launched via triggers; every application has declared trigger intent. On the terminal, the payment application owns the beginning-to-end flow of the interaction. During the flow of a transaction, there are potential non-payment interaction points called triggers. When the payment application reaches an interaction point, it notifies the Runtime to allow a registered Terminal Commerce application to manage the consumer interaction. For example, the interaction could entail gathering consumer loyalty identification and having that data routed back to a third-party developer’s cloud service. Once the Terminal Commerce application has completed its task, control of the transactional flow is given back to the payment application. This type of interaction can occur once or many times during the flow of the transaction on the device. The simplest triggers are ones that allow the application to be launched manually or allow the application to run during idle mode.


Terminal Commerce applications extend the payment flow with additional features and value-added services (VAS). These applications have limited access to system resources and devices and are not allowed to handle sensitive data. Terminal Commerce applications can interact with external servers using HTTP messages. Terminal Commerce applications don’t run concurrently with the payment application, they run only at defined trigger points. When there’s a payment application in process, processing of Terminal Commerce applications pauses between trigger points.

Applications have the following roles:
  • Launch in the context of payment flow
  • Interact with customers via the user interface
  • Interact with external servers using HTTP messages
  • Use the printer
  • Use services provided by the payment applications
  • Return trigger response messages to payment applications
  • Pause processing between trigger points while payment application is processing


Services are similar to applications, but with the following restrictions:
  • Won’t interact with the user
  • Won't have UI layer  

Platform Components 

The Runtime doesn't just abstract the OS differences; more importantly, it establishes a security model which allows installation, upgrading, and uninstallation of Terminal Commerce applications without the burden of a lengthy certification process. The security model relies on three major components:
  1. The installer verifies that the application is “signed” by the estate owner and meant to be deployed on the terminal.
  2. The Runtime controller orchestrates activation, closing, etc. of multiple competing Commerce Applications in independent “sandboxed” environments to prevent leakage of data.
  3. The Runtime controller also provides access to the payment application via a set of standardized APIs.
The Runtime maintains a single, secure communication channel with the Entitlement Services, allowing applications to exchange data back and forth with pre-approved merchant cloud servers.
The payment application is not tied directly to any Terminal Commerce application; it simply implements an API allowing Terminal Commerce applications to interact in a secure fashion with the payment application at pre-defined “trigger points” of the transaction flow. This stable API normalizes the exchange of data and shields commerce applications from non-encrypted payment information.

Runtime Model

Runtime supports the HTML application paradigm: Terminal Commerce applications based on restricted HTML, CSS, and JavaScript pre-processing support. 

Runtime provides a few specific extensions:
  • Additional input types (see types: numeric, mask, signature)
  • Timeouts (see input types: timeout, idletimeout)
  • Keyboard binding (see “accesskey” attribute)
  • Widget functions to navigate focus, scroll document, control video (see “action call”)
  • Page navigation (see “action load” attribute)
  • XML pre-processing for: data placeholders, text catalogs, barcode rendering, screen transitions
Although the Terminal Commerce applications are HTML based, there are some differences in the programming model from traditional web programming due to security requirements on payment terminals:
  • Only authentic and locally installed HTML/CSS documents can be used
  • Navigation to external pages is not allowed
  • There is a separation of static HTML/JS code and data
  • Dynamic data is filled into the HTML page before rendering using XML processing instructions
  • Data will be provided as trigger input data
  • Additional data might be provided by a third-party cloud application
Terminal Commerce applications will be activated by one of the following events:
  • Triggered by a payment application (i.e., at defined trigger points of the payment flow)  
  • Manually triggered from the application desktop
Each invocation of the Terminal Commerce application can provide input data to the activated HTML page. The input data is used to fill input elements with initial values or process conditions on the HTML page. Pre-processing of the HTML page happens before handing over the page to the GUI server. During pre-processing:
  • HTML/JS page can communicate directly to the entitlement services/third-party cloud using XMLHTTPRequest API
  • HTML/JS page can complete or exit pre-processing and continue rendering the page
  • HTML/JS page can exit pre-processing and end the trigger processing
  • HTML/JS page can navigate to another page 
The page will stay active until one of the following events occur:
  • User presses a key or button on the dialog (confirming or canceling an input dialog) that’s associated with returning to the commerce app runner to handle any of the following situations:
    • Load another HTML page
    • Exit the app and end the trigger processing
  • Exit due to dialog timeout 
  • Payment application requests exit from the app
In turn, the Terminal Commerce application will provide a set of output data for a synchronous trigger method. Typically, the application won’t store any data on the terminal, but will return output data and pass it on to the next page if required. 

Elements of a Terminal Commerce Application

Terminal Commerce applications typically consists of the following files: