Cardinal Posport Indigo Release Notes V 20230323 *** The release notes contained in this document are available in iVeri’ s repository in production and can be installed on any Cardinal and or indigo installation on a case-by-case bases as agreed with Customers and or Integrators. / Whats new  /* Indigo Ingenico * A change is implemented to make Ingenico devices reboot once a day to comply with PCI requirement. The default time is set to be at midnight. PosPort * Device Status is included as part of the data synchronized from Cardinal into MIS allowing for a better filtering in reports generated from MIS. Allowances that make it possible to enable "CashAdvance" in parallel with "Sale" transaction type have been made SMYL Loyalty  * As part of the loyalty offering on the N700 device, enabli

Query Code * ** Function: Query a code that has been created. Query Code Parameters * Request Parameter Description MasterPassAction Mandatory, The action to perform. MasterPassMerchantID Mandatory, The merchant id as captured on MasterPass. MasterPassCode Mandatory, The result code that must be queried Response Parameter Description MasterPassAction The action that was performed MasterPassShortDescription Short decription linked to the code MasterPassCodeExpiryDate Date until the code is valid. This is in epoch time. MasterPassMerchantName The name of the merchant as captured on MasterPass Amount Amount linked to the code. Currency The currency is tied to the merchant setup. MerchantReference Linked to the code. Query Code – REST Sample * Request Response { "Version" :  "2.0" , "Certifica

Generic POS Channel API Developers Guide * **

Transaction Life Cycle * ** The following diagrams describe how related stages can be executed during the life cycle of a transaction. There are three diagrams to illustrate the three possible starting points that a transaction life cycle can start from and, once it has started, what follow-up transactions can be performed on them. The data which links transactions together is the MerchantReference which is generated by the POS Till and/or MerchantTrace which is generated by the Indigo Server and returned in appropriate response messages to the POS Till. There is a subtle distinction between a Refund (command = Credit) and Payment (command = Credit); a Refund is the term used when returning money previously taken from a cardholders account by a Sale (command = Debit). A Payment is not link

Void ***

Payment * **

Reversal of a previously successful Authorisation * **

Appendix B – QA Environment for Development and Certification * ** During the development and certification phases of an integration project the Indigo server will be located within iVeri's QA environment and a Merchant Profile for the Integrator performing the integration must be created on iVeri's QA Gateway as well as on the iVeri QA Indigo Server and the resulting credentials distributed to the Integrator. This must be performed by iVeri Support who can be contacted at assist@iveri.com. Please make sure in all communication with Support that they must deal with QA Indigo and the QA Gateway. Network wise, the Integrator must ensure that the POS/Till system which will be communicating to the Indigo server using the Generic POS Channel protocol has outbound internet access to the iVeri QA

Appendix C – Test Plan * ** The purpose of the following section is to validate the implementation of the Generic POS Channel protocol for the transaction sets chosen by the Integrator. An Integrator may choose to only implement a subset of all the Test Cases (1, 2, 3, 4 and 5) below but, having chosen a Test Case, all sub Test Cases and the transaction types applicable to these Test Case must be performed. By way of example, if an Integrator only wants to perform Debits then only Test Case 3 comprising 3.0, 3.1, 3.2, 3.3 and 3.4 need to be tested and logs for these submitted. In this case logs for 3.0a, 3.1a, 3.1b, 3.2a, 3.3a, 3.3b, and 3.4a would need to be submitted. Integrators should keep logs of all requests sent to the Indigo Server as well as the responses received and the data and

* *Divert is a payment solution that allows merchants to request payment from their cardholders for services rendered. Traditionally, this functionality has only been available by accessing the merchant portal – Backoffice where merchants can populate the cardholder data and the payment amount agreed between the merchant and cardholder. On completion, a payment link via email would be distributed to the intended cardholder. The API implementation carries the same functionality found in Backoffice, the aim of the API is to extend the existing functionality to a wider audience whose requirement may be to automate the process of generating the payment link from the Gateway thus giving control and flexibility to the merchant, making it possible for merchants to integrate the payment requests i