Transaction History * ** / Purpose /*-To obtain a list of transactions for a selected calendar period reflecting all the result details for each in XML format. / Action: */ Click on View then Transaction History / Action: /* To view Transaction history, .click on the appropriate Application ID, Live or Test / Action: /* Make your selection of period/time in the above form by manually changing the default dates or using the calendar icons next to each date. Also select file format i.e. XML or CSV. Once done click on Download. Your file will be open or downloaded to selected folder

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

Transaction Lookup * ** / Purpose /* - To lookup the details of a single transaction based on specific search criteria. / Action: /* Click on View then Transaction Lookup / Action: /* Click on the Application ID on which you want to do the lookup e.g., Live or Test / Action: /* Select the Date on which the transaction took place by changing the default date or by clicking on the calendar icon next to the date. If you are not 100% sure of the date, you are able to search in a range of up to + or – 2 days of the date you have selected by changing the 0 default to 1 or 2 in the +/- Days drop down next to the date. You then need to enter either the Transaction Index or the Merchant Reference number. If you do not have either of these numbers you are able to enter either the full credit card nu

The examples apply when using the web service interface to perform various transactions. The examples serve to showcase a set of parameters that are largely used when performing transactions using the schema definition available in the SOAP interface which are also commonly used on the REST API. The functionality and related parameter definitions, elements supported are standard in the SOAP schema and REST API Further insights on the transaction types and their meanings, refer to the “Commands” and “Actions” sections and these have to be used in conjunction with the input parameters per actions. For the corresponding transaction flows per transactions type refer to transaction sequence The examples cover the following messages: The transaction Request and Response cover the following: The

* Result Status * * Result Code * * Result Description * * Only relevant when * 0 (OK) 0 N/A (Approved) -1 (Not OK) 1 Timeout waiting for response -1 (Not OK) 2 Gateway unreachable -1 (Not OK) 3 Hot card -1 (Not OK) 4 Denied -1 (Not OK) 5 Please call -1 (Not OK) 6 Card Address failure 1 (Warning) 6 Warning: Approved but Card Address failure -1 (Not OK) 7 Card Security Code failure 1 (Warning) 7 Warning: Approved but Card Security Code failure -1 (Not OK) 8 Card Type not accepted -1 (Not OK) 9 Unable to process the transaction -1 (Not OK) 10 Card blocked -1 (Not OK) 11 Invalid amount -1 (Not OK) 12 Invalid budget period -1 (Not OK) 13 Void unsuccessful Command Void -1 (Not OK) 14 Invalid card number -1 (Not OK) 15 Invalid track2 -1 (Not OK) 16 Invalid card date (Expiry Date or Card period)

**

Transaction – Subsequent Transaction * ** Purpose * - To take further action on a transaction which has already been successfully processed. You can convert an Authorisation to a Sale or process a sale Refund. Action: * Click on the appropriate Application ID in which you can view transactions that have been processed. Once the transactions details are displayed you, perform refunds, or do a debit Action: * Select the Date on which the original transaction took place from the drop down menu or select a period if you are not sure of the exact date and click on Search. This will bring up a summary list of all the transactions which match your search selection. Action:  * Scroll through the summary list until you find the transaction you want to take the action on. To make sure that it is the

Transactions – View- Transaction History* Purpose * - To view a list of all transactions performed for a selected Date or Period. Action: * In the menu bar, Select Enterprise, Transactions, View, Transaction History. Click on the Application ID you wish to view Transactions. If you only have one Application ID, this page will NOT be displayed, and you will be automatically taken to the Choose Date/Period page. Select the Date or Date range and click on Search. This will bring up the list of ALL transactions performed for your selection. Choose a specific Application ID Choose a date range to start your Search Action: * Allows you to get details pertaining to a specific transaction – available when clicking on the actual transaction detail.

Updating Cipher Suites for Web Application Firewall (WAF) Security ** Release Description:* Updating Cipher Suites for Web Application Firewall (WAF) Security Category: *Compliance Target Audience: * Implementation date: 20/01/2025* Ciphers:  * The primary purpose of ciphers is to ensure confidentiality, integrity, and authenticity of data during transmission. Using strong ciphers as outlined by PCI DSS is crucial for protecting sensitive cardholder data and ensuring compliance with industry standards, ultimately helping to safeguard against data breaches and cyber-attacks. Strong Ciphers: * Strong ciphers provide high levels of security, making it extremely difficult for unauthorized parties to decipher the encrypted data without the correct decryption key. Importance of Strong Ciphers:*

User ** This is a generic configuration across all products. I have included additional screens and explanations for Reports that a user can request to be e-mailed. / Purpose: /* The Administrator is able to set permissions per User profile created for automated reports / recon files to be e-mailed to a user. From the Dashboard, navigate to the menu and select the ‘User’ tab. Here, the user will choose the profile for which permissions need to be set. From the User Profile, Navigate to and select the ‘Service Parameters’ tab. From the Service Parameters screen, the user will navigate to the ‘Reports/Files to be emailed’ parameter. Here the user can select one or all of the Reports/Files to be Emailed to the user. To select all of the reports to be e-mailed for a user, hold the ‘CTRL’ butto