Core Functions in Backoffice

The merchant portal Backoffice allows for the following core functions Management of User Creation of users Transaction Types allowed per user created Backoffice functionality views allowed Applications permitted on a user created Transaction Reports & Listing & Lookups Recon Reports Blacklisting of cards Customise payment request page with Merchant’s Corporate Identity. Create Transaction Requests Process Subsequent Transactions (Refunds)

Subsequent Transactions* ** When TransactionIndex is used on subsequent transactions, regular customers do not have to re-supply the card data details however this ONLY works if the merchant developer has made provisions for the following: Ability for the merchant to identify the customer, usually by means of user sign-in  The merchant has successfully processed a transaction on the customers card at some point in time using the iVeri Gateway  That the customer's profile is mapped to the correct Tokenised card details (TransactionIndex, Expiry date etc) returned on the initial or previously processed transaction Once the above provisions are made, the merchant developer would be able to display to the cardholder a masked/dotted card number and the expiry date of the card. The cardholder wo

* Parameters * ** The following parameters are expected in the form submitted to the Gateway at step 3 of the iVeri Lite None [1] process flow and/or returned by the Gateway in the response at step 6 to the cardholder via the merchant's website. Note: Not all of the fields in this specification are mandatory.The list of parameters below has been split to reflect mandatory and optional data. You can simulate a test form post, using data corresponding to your request, on None [2] this link *Mandatory Parameters:* * Name * *General Description* *Length* * Notes * Lite_Merchant_ApplicationId iVeri Application id 36 Allocated to the Merchant during registration Lite_Order_Amount Amount to authorize 10 The total amount for the order including tax in cents. This must be equal to the sum of the

Transaction -View – Authorisations ** * Purpose * - To view the transactions for which you originally only obtained an Authorisation. This allows you to now use that Authorisation code to Debit the cardholder by doing a Subsequent Transaction [1]   to debit the cardholder and obtain the money in your bank account. * Action: * In the menu bar, Select Lite, Transactions, View Authorisation. Click on the Application ID you wish to view Authorisations. Select the Date or Date range and click on Search. A list of transactions will be displayed *Choose a date *and select *Search* * Action: * This will give you the below screen reflecting the details of the Authorisation for either viewing of the details or you can print this page for use at a later stage. [1] /knowsystem/subsequent-transactions-

BackOffice User Guide

BackOffice User Guide * ** This document details the functionality available in Backoffice for merchants. The merchant interface (URL) to be accessed depends on the acquirer in which the merchant has an agreement with.

Tokenisation: Transactionindex On Subsequent Transactions

* *This section explains how to implement a follow up/subsequent transaction using the TransactionIndex returned from an initial/previous transaction processed successfully. Merchants that wish to accept payments from regular customers without worrying about PCI DSS burdens of storing or retaining the card number have an option of submitting a unique identifier associated with the customers card number from a previously successfully processed transaction. In iVeri's realm, the identifier which the merchant can pass on subsequent transactions is called the “TransactionIndex”. This variable is an iVeri Gateway generated identifier commonly found in Gateway responses to the merchant.

*Transaction – Subsequent Transaction* ** * Purpose * - Subsequent transactions allow a user with the correct permissions to further action a transaction that has been successfully processed. For example, a user can change the transaction type from an Authorisation to a Sale or from a Sale to a Refund. Action: * From the menu, select *Lite - Transactions - Subsequent Transactions.* * 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 tran

* View – Transactions History * ** * Purpose *- To view a list of all transactions performed for a selected Date or Period. * Action: * In the menu bar, Mouse over mPress, 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. Once edit is selected click on submit to continue th

* General Requirements * ** iVeri Lite implementation consists of doing a submission of a form post to the Gateway endpoint while including all required/mandatory parameters. Applicable Parameters to be passed in the request are common to all the integration methods supported on iVeri Lite, and elaborated in this documentation. The list of applicable parameters can be found None [1] here [1] /knowsystem/parameters-14

Introduction to Enterprise

Enterprise Introduction  *** The iVeri range of payment solutions, developed by iVeri Payment Technologies (Pty) Ltd provides proven credit card payment solutions for businesses that have online or physical presence. The use of Enterprise API's is ideal for merchants that want complete control & flexibility of the payment page and transaction mechanisms supported. Enterprise API’s currently support the following Webservices REST SOAP /Merchant Requirements/* Merchants are required to enter into a “Agreement” with an authorised Acquiring Institution. Once there is a merchant agreement in place, a merchant profile can be created With Enterprise calls to the Gateway, the presence of a certificate ID is required, with the actual physical certificate available as optional means to authenticate