* *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.

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

Subsequent Transactions implementation * ** On the request to the Gateway, the merchant developer has to pass all the required variables that pertain to a subsequent transaction so as to make sure that the iVeri Gateway handles the request appropriately. Variables that should be present in the request to the iVeri Gateway are as follows: The Lite_PanFormat must be set to TransactionIndex  Set the Lite_TransactionIndex to the actual TransactionIndex value e.g {000000-000000- 000-0000 0000000}  Set the Ecom_Payment_Card_Number to the Dotted PAN value Note:* These variables are defined in 8.2 iVeri specification. In addition to these the merchant will still need to pass all the other required variables.

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 Reconciliation  Reports Blacklisting of cards Customise payment request page with Merchant’s Corporate Identity. Create Transaction Requests Process Subsequent Transactions (Refunds)

Initial Transaction * ** When a merchant sends a transaction request(POST) to the iVeri Gateway, the response returned to the merchant generally contains a number of variables, some of which are important when performing subsequent transactions, in order for the merchant to implement subsequent transactions the following variables must be stored on the merchants database. Lite_TransactionIndex Ecom_Payment_Card_Number  Ecom_Payment_Card_ExpDate_Month  Ecom_Payment_Card_ExpDate_Year

V4.139 7/2/2024 ** Release Notes Overview The release notes provided in V1 of this document serve as an initial preview of the changes expected in the upcoming production release scheduled for November 12th, 2023, on the Hosted Gateway. The definitive release notes for deployment in production will be included in V2 of this document. Summary The Gateway release notes will contain information related to the new iVeri software release. The release notes will include the impact of software release to the intended target audience. The release notes will adopt the format outlined below, as applicable: Compliance - Refers to the adherence of the software to specific industry standards, regulations, or internal policies. This includes ensuring that the software meets legal and regulatory requirem

Transaction integrity can be seen as ensuring that all players within an individual iVeri transaction agree on its outcome. When a Card Holder gets his statement from his Issuer, it must correspond to his instruction to the merchant for a corresponding transaction. When transaction integrity is compromised either willfully (fraud) or unintentionally, it can result in a disputed transaction with legal impacts. Individual transactions *** Void* A Void of a previous transaction request is a command to ignore (i.e. cancel the effects of) a previous (recently submitted) transaction request. When a merchant receives a successful response for a transaction request, and thereafter “something goes wrong”, then the Merchant has the option to “void” the transaction. Examples of “something goes wrong”

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. Initial Transaction ** When a merchant sends a transaction request(POST) to the iVeri Gateway, the response retur

Transactions ** Create Transaction Request * Purpose  /* - This function allows you to create a request for payment to be sent to cardholder Action: */ To create a transaction request, start by navigating to the DiVert tab on the homepage. Then, select Transactions and click on Create Transaction Request. image%20%282%29 [2] Action:* Here, choose the Live application ID. Once selected, you’ll be redirected to the Create Transaction Request form, where you can enter all the transaction details. image%20%283%29 [3] Create%20a%20Transaction%20Request%20-%203 [4] Let’s go through the details you’ll need to enter when creating a transaction request: Cardholder Name*: Enter the cardholder’s name exactly as it appears on the card. Cardholder Email*: Input the cardholder’s email address. This is