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
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
Airline Data **
Parameter
Node Type
Data Type
Min Length
Max Length
Description
PassengerName
subTag
AN
0
60
Passenger's first name.
PrimaryTicketNumber
subTag
AN
0
60
FirstDepartureLocationCode
subTag
AN
0
32
FirstArrivalLocationCode
subTag
AN
0
32
OfficeIATANumber
subTag
AN
0
32
OrderNumber
PlaceOfIssue
DepartureDate
Note: The fields in Blue will only be used when doing CyberSource Advanced Fraud Screening.
CompleteRoute
DepartureTime
JourneyType
Print Report – Batch Details *
**
Purpose *- To view a list of all transactions performed for a selected Date or Period.
Action: * In the menu bar, Select Batch - Print Report - Batch Details. *
Action: *
The user will select the applicable application ID.
Action: *
The user will select the Date range and click on Search. This will bring up the list of ALL transactions performed for your selection.
Action: *
Select the file format you wish to obtain from the drop down (either the default PDF, CSV or XLS) and then select the file from the list which you want to download and click on Print. This will bring up the following screen.
The Print Button will start an automatic download to your PC.
3D secure transaction process flow *
**
Cardholder is on the merchant’s checkout page, ready to pay for their order. They will input and submit their card details on the payment page hosted by the Gateway. The Gateway will proceed to check if the card in use is enrolled in 3DS by sending a request to the Directory Server. Directory Server will respond with enrollment status.
Considering the response is positive and the card is enrolled for 3DS, The Gateway will redirect to the issuer ACS for authentication
The ACS will prompt the cardholder to insert and submit OTP/Password/credential(etc.) Considering the authentication was successful, the response is returned to the gateway to confirm successful authentication Gateway then forwards the transaction details to the acquirer for authorizati
* Development phase *
**
At this stage you will proceed with development based on the integration method [1] you have selected, and may reach out for your contact at the acquiring bank if you require support.
[1] /knowsystem/general-requirements-10
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)