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

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

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.

Then merchant token generation is a security measure introduced to hash merchant and transaction specific data elements, using SHA256 hashing algorithm. An effort which reduces the risk of data being exposed or intercepted by 3rd parties during the submission of transaction requests to the gateway.

Prerequisites * ** The below parameters must be set in the merchant Backoffice Enable Token Verification to “Yes” (By default this parameter is set to “No”)  Populate the Lite Shared Secret key parameter. Maximum length 32 characters (alpha-numeric)

Requirements * ** Merchants must generate the token on their web server and pass the generated token to the transaction request. The generated token must encompass the following data elements: Lite_Order_Amount: Total amount of the order as specified in 8.2 Lite_Merchant_ApplicationId – The merchants app ID as specified in 8.2 Ecom_BillTo_Online_Email – Email of the cardholder as specified in 8.2  TimeStamp – The timestamp when the token is generated

Token Verification Logic in the Hosted Payment Page * ** If Enable Token Verification has been set to YES and Lite Shared Secret has not been set an exception will be thrown when submitting a transaction request If Enable Token Verification has been set to YES and Lite_Transaction_Token has not been set an exception will be thrown when submitting a transaction request  If Enable Token Verification has been set to YES and the Lite_Transaction_Token does not match the calculated token an exception will be thrown

* Merchant Hash Token Generation * ** /* *secretKey - Lite Shared Secret *resource - /Lite/Authorise.aspx *applicationId - Lite Application Id *amount - Lite Order Amount *emailAddress - Ecom BillTo Online Email */ public static string GenerateTransactionToken(string secretKey, string resource, string applicationId, string amount, string emailAddress) { string time = Convert.ToString(UnixTimeStampUTC()); string token = secretKey + time + resource + applicationId + amount + emailAddress; return String.Concat("x:", time, ":" + GetHashSha256(token)); } public static Int32 UnixTimeStampUTC() { Int32 unixTimeStamp; DateTime currentTime = DateTime.Now; DateTime zuluTime = currentTime.ToUniversalTime(); DateTime unixEpoch = new DateTime(1970, 1, 1); unixTimeStamp = (Int32)(zuluTime.Subtract(unixE

* *Visa Check-Out is a digital representation of a cardholders Visa Card. Cardholders can register their debit or credit cards by downloading the Visa Check-Out app. Once cardholders have their profiles and card details loaded in Visa Check-out, they are able to make purchases at merchants who are accepting with Visa Check-Out payments. The Visa Check Out process flow explained below showcases the different parties involved.