Pre-Auth Reversal – “Authorisation Reversal” ***
Allows merchants to submit an instruction to cancel/reverse a pre-authorized amount on the cardholder’s card
REST
SOAP
Request
{
"Version" : "2.0" ,
"CertificateID" : "{5c4b9c74-0063-4240-9cff-f730675c5bd0}" ,
"ProductType" : "Enterprise" ,
"ProductVersion" : "WebAPI" ,
"Direction" : "Request" ,
"Transaction" : {
"ApplicationID" : "{8d5a94-8fa0-428d-a539-3a5baf166f7f}" ,
"Command" : "AuthorisationReversal" ,
"Mode" : "Test" ,
"TransactionIndex" : "{34799783-6A61-4EFB-8E1C-DA3D73C27F05}"
}
}
< soap:Envelope xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd = "http://www.w3.org/2001/XMLSchema" xmlns:soap = "http://schemas.xmlsoap.org/soap/envelope/">
< soap:Body >
< Execute xmlns = "http://iveri.com/">
< validat
Pre-Auth Completion – Follow-up Debit
**
Allows the merchant to instruct the cardholders bank to release and debit the funds previously reserved or pre-authorized
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" : "Debit" ,
"Mode" : "Test" ,
"Amount" : "1000" ,
"MerchantTrace" : "20220812_1044" ,
"TransactionIndex" : "{5C8F61BE-15AD-4201-B361-66AD52D2EFAE}"
}
}
< soap:Envelope xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd = "http://www.w3.org/2001/XMLSchema" xmlns:soap = "http://schemas.xmlsoap.org/soap/envelope/">
< soap:Body >
< Ex
Pre-Auth – “Authorisation with PAN” *
**
Reserve or withhold funds on the cardholders related card account
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" : "Authorisation" ,
"Mode" : "TEST" ,
"MerchantReference" : "20221108_1042" ,
"MerchantTrace" : "DIAAAY4QW2" ,
"Currency" : "ZAR" ,
"Amount" : "3000" ,
"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://schemas.xmlsoap.org/soap/envelope/">
< soap:Body >
< E
Sale – “Debit with PAN” *
**
This where the cardholder is debited, and merchant account is credited by the acquiring bank or PSP that holds the merchant agreement
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" : "Debit" ,
"Mode" : "TEST" ,
"MerchantReference" : "20221108_1029" ,
"MerchantTrace" : "DIAAAY4734" ,
"Currency" : "ZAR" ,
"Amount" : "3000" ,
"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://sche
EMV Transactions *
**
The introduction of smart cards based on the EMV standard (EMV: Europay, MasterCard, Visa) is progressing worldwide. More and more banks rely on secure transactions for payments. With the migration from magstripe to EMV chip, banks can offer their customers the utmost in security. EMV chip technology prevents unauthorized access to card information and helps fight fraud.
Coding for EMV data *
The following is a code snippet in C#:
EMV Request Tags:*
enterprise.setTag("EMV_AuthorisationRequestCryptogram", authorisationRequestCryptogram);
enterprise.setTag("EMV_ApplicationIdentifier", applicationIdentifier);
enterprise.setTag("EMV_ApplicationInterchangeProfile", applicationInterchangeProfile);
enterprise.setTag("EMV_CardSequenceNumber", cardSequenceNumber);
enterprise.s
Debit with PIN and Balance Enquiry *
**
The merchant determines if the card is PIN based typically via a local bin list (section 17.6.4). If it is PIN based, the merchant reads in the PIN from the PED, and obtains an encrypted PINBlock.
A PIN based request is identified by the existence of a PINBlock tag. The existence of the PINBlock tag implies Track2, DeviceSerialNumber, DeviceMake and DevicePINKey is mandatory.
Account Type is 'Savings' or 'Cheque' or 'Credit' or 'NotSpecified'.
Debit with PIN *
The mandatory Amount tag refers to the total transaction amount. The optional CashAmount tag is any cash portion of the transaction. Therefore, always Amount >= CashAmount.
Normal Withdrawal: CashAmount = Amount
Normal Sale: CashAmount = 0 (or not specified)
Combined Sale and Withdrawal: 0 < Ca
PAN encryption via Dukpt encryption *
**
A POS Device Integration architect has the option sending the PAN to the iVeri Gateway in an encrypted format. This optional functionality is there as an extra security measure against someone sniffing the data between the device and the server communicating with the iVeri Gateway.
The Dukpt PAN encryption process flow is the following: A Device (with a DeviceSerialNumber and a DeviceMake) is injected in a Trusted Centre with a Track2 IPEK (initial pin encryption key). This IPEK is different from the one injected for Dukpt PIN encryption. For this encryption, the following are mandatory input parameters together with the PAN tag:
DeviceSerialNumber DeviceMake PANKeySerialNumber
Track2 encryption via Dukpt encryption *
**
A POS Device Integration architect has the option sending the Track2 to the iVeri Gateway in an encrypted format. This optional functionality is there as an extra security measure against someone sniffing the data between the device and the server communicating with the iVeri Gateway.
The Dukpt Track2 encryption process flow is the following: A Device (with a DeviceSerialNumber and a DeviceMake) is injected in a Trusted Centre with a Track2 IPEK (initial pin encryption key). This IPEK is different from the one injected for Dukpt PIN encryption. For this encryption, the following are mandatory input parameters together with the Track2 tag:
DeviceSerialNumber
DeviceMake
Track2KeySerialNumber
Track2 IPEK Injection for Dukpt Mode Test *
BDK: 1534C275
Track2 encryption via Master/Session encryption *
**
A POS Device Integration architect has the option sending the Track2 to the iVeri Gateway in an encrypted format. This optional functionality is there as an extra security measure against someone sniffing the data between the device and the server communicating with the iVeri Gateway.
The Master/Session Track2 encryption process flow is the following: A Device (with a DeviceSerialNumber and a DeviceMake) is injected in a Trusted Centre with a Track2 Master Key. A merchant periodically sends a request for a session key (getTrack2SessionKey) which is returned encrypted under the Track2 Master Key. When performing a transaction or a balance enquiry, the Track2 is sent encrypted using the current Track2 session key.
Track2 Key Injection for
PINBlock encryption via Master/Session encryption *
**
Master/Session keys are Double Length and are sent to the iVeri Gateway in Hexadecimal format.
The Master/Session PINBlock encryption process flow is the following: A Device (with a DeviceSerialNumber and a DeviceMake) is injected in a Trusted Centre with a Device Master Key. A merchant periodically sends a request for a session key (GetDevicePINKey) which is returned encrypted under the Device Master Key. When performing a Debit with PIN, the PINBlock is sent encrypted using the current session key.
Key Injection for Master/Session Mode Test *
There is one Test Device Master Key that is public knowledge. When a Device is to be injected with the Test Device Master Key, it can be done within the iVeri Test Loading Centre, or by the merc