Merchants that process recurring transactions need to be enabled as such via the Admin Portal. In the authorization message that is sent to the Acquirer, as part of the transaction process, there is specific data that indicates that a transaction is recurring, and the merchant has been enabled for recurring transactions. We will have a look at how to enable a merchant for recurring transactions via the Administration Website: Navigation Path: Applications > Update > Provider Specific. Click on the ‘Common Provider’ expansion tab as illustrated. 1. Navigate to the ‘Processing’ parameter and click on the expansion button. me1 [1] 2. Navigate your way to the ‘Cardholder Presence Default’ Parameter. This parameter will be defaulted to ‘Not specified’. me2 [2] 3. Untick the ‘Use Default’ tab. F

Below is the process of how to enable MOTO transactions for a merchant on the Admin Website: Navigation Path: Applications > Update > Provider Specific. Click on the ‘Common Provider’ expansion tab as illustrated. 1. Navigate to the ‘Processing’ parameter and click on the expansion button. moto1 [1] 2. Navigate your way to the ‘Cardholder Presence Default’ Parameter. This parameter will be defaulted to ‘Not specified’. moto2 [2] 3. Untick the ‘Use Default’ tab. From the drop down, select ‘Mail/Telephone Order (single transaction)’. moto3 [3] 4. Lastly, to ensure the change has been saved, click on the ‘Update Parameters’ tab. moto4 [4] [1] /web/image/351226-55085015/moto1.png?access_token=a03576b8-fe21-4b94-b4c7-b2fe65ec31f6 [2] /web/image/351227-0b632be4/moto2.png?access_token=8d6f6399-44

The purpose of this user guide is to assist users in navigating the merchant take-on process by providing step-by-step visual representations on the screen. Accompanied by detailed explanations, these screen representations aim to enhance the user's understanding of the iVeri administration website interface. The guide contains all the essential information for users to successfully onboard a merchant. It also covers typical scenarios that may arise based on the merchant's requirements.

Recurring transactions refer to payments or financial transactions that occur on a regular, predetermined schedule. These transactions are typically set up to recur automatically without the need for manual intervention for each occurrence. The frequency of the transactions is predetermined and agreed upon by the parties involved. Here are some examples of recurring transactions: Gym Memberships: Customers sign up for monthly or annual gym memberships, and the membership fees are automatically charged to their credit cards or bank accounts on a recurring basis. Insurance Premiums: Insurance companies offer various insurance products with recurring premium payments. Policyholders agree to pay a fixed premium amount at regular intervals (e.g., monthly, quarterly, annually) for coverage. Subs

In some instances, based on the merchant’s business needs to accept various payment methods, there may be a requirement to have more than one iVeri solution. The process is simple, as there is no need for a user to replicate the entire take-on process. Below, we will walk through the process of capturing an additional iVeri solution for a merchant using the same User Group ID. 1. From the menu, the user will navigate to: Applications > Create. CAP [1] Click on the Application found under ‘Search Results’. 2. Populate all the mandatory fields in yellow: CAP1 [2] Product TypeID: This crucial parameter is where the user will select from the dropdown, the iVeri solution for the merchant, based on the merchant agreement. Default Provider: The user will select the default provider/s listed here.

MOTO (Mail Order/Telephone Order) are systems that allow businesses to take and manage card transactions remotely. This web-based payment system facilitates payment transactions that can be taken over the telephone or via email or written requests. How MOTO Transactions work: moto [1] Examples of common MOTO transactions It is common to see MOTO systems in businesses that take orders for products or services through emails or by telephone. Some of the more notable examples include: Health & fitness services Repair services Retail outlets Online retailers Travel agencies However, a customer may also request a MOTO payment in the case of them: Making a purchase over the phone or to online retailers. Cannot physically reach the store’s location in time to pay. Ordering from a remote location

Introduction  *** 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 pay

Supported Prompts  * ** The prompts are specific to devices so depending on which devices are attached to the Indigo server will determine which prompts are used. These prompts are, in general, loaded onto the device at initialisation so if this has not been done then prompts will not be supported. There is a hardcoded default prompt so that if the Index used from the list below does not happen to be loaded on the device or does not exist on the device then this prompt will be used as a generic request for data to be entered. Ingenico RA1 Based Devices *** x Prompt Description 1 Amount 2 Please enter new total 3 Total 4 amount again 5 Please enter 6 Add 7 Input 9 Balance 10 Tip 11 Gratuity 12 Service 13 Donation 20 Waiter ID 21 Waiter logon 22 Table number 23 Bill number 24 Location refere

The error codes below can be resolved without returning a device back to Touchpoint Payments Error Code* Error * Solution * 100 Transaction declined by bank / blocked card Try another card 109 Merchant ID / Terminal ID / Serial number mismatch Please validate these settings on the iVeri server 399 Incorrect date and time on POS – Please update POS parameters [ FUNC + 1] 902 Device deactivated on server Please forward serial number to us to activate 921 Invalid data authentication Please insert the card and process PIN based transaction 908 Unknown host Please insert the card and process PIN based transaction 909 Various errors Please try PIN based transaction. If still fails please call Touchpoint to further investigate before shipping back to us No terminal params Please download terminal