Additional Data for Procurement Transactions
**
Procurement transactions refer to transactions that contain the line item (or order basket) details. If the line-item details are sent to iVeri within a transaction, then a procurement card holder get those details from their issuing bank (for example on their monthly statement). This is of assistance in tracking business to business transactions particularly in large corporations. Procurement transactions are currently only available within distributor Nedbank.
Coding for Procurement *
The following optional input parameters are Procurement specific per transaction:
CustomerReferenceIdentifier CustomerVATRegistrationNumber DestinationCountry DestinationZIPCode NationalTax NationalTaxIndicator OrderDate PurchaseIdentifier ShipFromZIP
Refund – “Follow-Credit”
**
Allows for a previously debited amount to be returned to the cardholders account using a detail of a previously processed transaction.
REST
SOAP
Request
{
"Version" : "2.0" ,
"CertificateID" : "{5c4b9c74-0063-4240-9cff-f730675c5bd0}" ,
"ProductType" : "Enterprise" ,
"ProductVersion" : "WebAPI" ,
"Direction" : "Request" ,
"Transaction" : {
"ApplicationID" : "{d8d5a94-8fa0-428d-a539-3a5baf166f7f}" ,
"Command" : "Credit" ,
"Mode" : "Test" ,
"Amount" : "1000" ,
"MerchantTrace" : "20220812_1107" ,
"MerchantReference" : "20221123_1106" ,
"TransactionIndex" : "{CB7A9E38-4797-4513-85EE-AFE63C957ED3}"
}
}
< soap:Envelope xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd = "http://www.w3.org/2001/XMLSchema" xmlns:soap = "http://schemas.xmlso
Advanced Fraud Screening
**
The following optional input parameters are CyberSource specific per Line item:
Discount ItemCommodityCode ItemDescriptor ProductCode Quantity TaxRate Total UnitCost UnitOfMeasure PassengerFirstName PassengerLastName PassengerID PassengerStatus PassangerType
Note: The fields in Blue will be used when doing Advanced Fraud Screening and is not recorded on the iVeri system. Since Line items are repeated, the advanced Enterprise methods openElement and closeElement must be used. The following is a code snippet in https://vb.net/
enterprise.setTag("ShippingTaxRate", shippingTaxRate)
enterprise.setTag("TransactionDiscount", transactionDiscount)
enterprise.setTag("UniqueVATInvoiceReferenceNumber", vatReferenceNo)
Dim dr As DataRow
For Each dr in myTable.Ro
Refund – “Initial Credit”
**
Allows the merchants to essentially “pay” or “credit” the cardholder without referencing any original or previously processed transaction
REST
SOAP
Request
{
"Version" : "2.0" ,
"CertificateID" : "{cf4b7e7a-4fec-43b4-a2cb-221263c0a34b}" ,
"ProductType" : "Enterprise" ,
"ProductVersion" : "WebAPI" ,
"Direction" : "Request" ,
"Transaction" : {
"ApplicationID" : "e7c523a4-7da7-4e59-b888-569fe65c535b" ,
"Command" : "Credit" ,
"Mode" : "TEST" ,
"MerchantReference" : "20211014_0129" ,
"MerchantTrace" : "NAHSI-1112" ,
"Currency" : "ZAR" ,
"Amount" : "1000" ,
"ExpiryDate" : "1025" ,
"PAN" : "4242424242424242"
}
}
< soap:Envelope xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd = "http://www.w3.org/2001/XMLSchema" xmlns:soap = "http://
Void
**
Void should be performed on an event where transactions are not responded to or not completed to the merchant’s application which could be due to a timeout scenario. When used the void message should be performed closer to the time it relates. For more on the use of Void messages, refer to the Ensuring end to end Transaction Integrity
REST
SOAP
Request
{
"Version" : "2.0" ,
"CertificateID" : "{5c4b9c74-0063-4240-9cff-f730675c5bd0}" ,
"ProductType" : "Enterprise" ,
"ProductVersion" : "WebAPI" ,
"Direction" : "Request" ,
"Transaction" : {
"ApplicationID" : "{d8d5a94-8fa0-428d-a539-3a5baf166f7f}" ,
"Command" : "Void" ,
"Mode" : "Test" ,
"OriginalMerchantTrace" : "DIAAAY22734" ,
"OriginalRequestID" : "{9667792F-635A-4121-AC85-E06856ADC3EF}"
}
}
< soap:Envelope xmlns:xsi = "
CyberSource Fraud Management
**
CyberSource data is additional transaction data which iVeri Payment Technologies Ltd needs to process orders within CyberSource's fraud screening solution.
Device Fingerprinting *
To successfully implement Device Fingerprinting, a 1-pixel image file (which cannot be seen) and two scripts need to be placed in the <body> tag of the merchant’s checkout page*. This will ensure a 3-5 second window in which the code segments can complete the data collection necessary to create a fingerprint for the device making the order.
Below are the code segments for implementing Device Fingerprinting:
PNG Image
<p style="background:url(https://h.online-metrix.net/fp/clear.png?org_id= <org ID> &session_id= <merchant id><session ID> &m=1)"></p> <img src="https://h.onli
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
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)
* iVeri Lite Process Flow * **
iVeri Lite requires very little integration and is aimed at Internet merchants who have limited technical resources. Lite transactions are processed on a web site and secured via an SSL certificate without the merchant having to buy SSL since iVeri lite takes care of it on their behalf. Although ideal for websites with small catalogs, iVeri Lite still provides a powerful processing engine.
*/ Process Flow /*
This diagram illustrates the flow of events of an iVeri Lite transaction:
/*Process Flow Description:*/
(1) The cardholder is at the point in the purchase process where the basket has already been selected and he is now on the brink of paying for it. The website thus knows the price of the basket, the Invoice Number (the merchant could also have iVeri Bac
* 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