API Differences between triPOS Cloud and triPOS Distributed

Document created by dourada on Nov 23, 2016Last modified by jeff.gross@vantiv.com on May 19, 2017
Version 11Show Document
  • View in full screen mode

By design, the triPOS Cloud API and integration is very similar to triPOS Distributed. Current integrators to triPOS Distributed will find that they will need to make very few changes to integrate to triPOS Cloud. Below is a list of the differences in the API between triPOS Cloud and triPOS Distributed.

 

  1. Credentials in the Header. In triPOS Distributed, the credentials can either be sent in the header of every request, or reside in the triPOS.config file. In triPOS Cloud, the credentials are required to be sent in the header of every request.
  2. HTTPS and HMAC Signing. In triPOS Distributed, the use of HTTPS is optional. In triPOS Cloud, the use of HTTPS is required, and consequently, signing requests with an HMAC signature is no longer necessary.
  3. Transaction Configuration. In triPOS Distributed, several transaction configuration values are set in the triPOS.config file. In triPOS Cloud, these values are sent in through the API. For example, if an ISV supports debit and wants to enable cashback, the debit and cashback values should be sent directly in the sale request.  Configuration parameters supported today via the API with triPOS Distributed are also supported via the API with triPOS Cloud.  Additional triPOS Cloud API configuration parameters will be added in the future.
  4. Configuration Endpoints. The configuration endpoints are different for triPOS Cloud. The application, host, transaction, server, and serial lane endpoints are not necessary. Additionally, when adding an IP lane, triPOS Cloud requires an ISV to send in the activation code shown on the PIN pad.
  5. JSON Only. In triPOS Distributed, the ISV has the choice of whether to use XML or JSON. triPOS Cloud is JSON only.
  6. Request ID. In triPOS Distributed, sending a tp-request-id header, the unique ID for each request, is optional. In triPOS Cloud, the tp-request-id header is required.
  7. Response Logs. In triPOS Distributed, a header value named tp-return-logs could be sent to get return trace logs on the response. In triPOS Cloud, trace logs are not available and this header is ignored.
  8. Terminal ID Configuration.  In triPOS Distributed, the Terminal ID submitted by triPOS to the Express platform is configurable per lane.  In triPOS Cloud, the Terminal ID submitted by triPOS Cloud will match the Terminal ID specified in the call to POST /cloudapi/v1/lanes during the lane pairing process.
  9. Store and Forward.  In triPOS Distributed, Store and Forward functionality is currently available.  In triPOS Cloud, at this time, Store and Forward functionality is not available for testing, but there are plans for that functionality to be available at some point in the future.
  10. EMV Initialization.  In triPOS Distributed, when EMV is enabled, triPOS will initialize the PIN pad for EMV each time it connects to the PIN pad (e.g. during a triPOS service startup/restart, a PIN pad power cycle, or during the loss of the USB/IP connection).  This EMV initialization process may take 1-2 minutes.  In triPOS Cloud, the EMV initialization process takes place during the lane pairing process only (i.e. during a Create Lane request) and takes approximately the same amount of time (1-2 minutes).  So a PIN pad that is already paired with a lane will not go through the EMV initialization process again if the PIN pad itself is simply power cycled.
  11. Mx915 PIN Pad Whitelist.  In triPOS Distributed, whitelist functionality exists for the Verifone Mx915 PIN pad.  In triPOS Cloud, at this time, whitelist functionality does not exist with the Mx915 PIN pad.  This functionality is being reviewed as a potential enhancement at some point in the future.
4 people found this helpful

Attachments

    Outcomes