Lite Developer's guide


Lite Introduction 

The iVeri range of payment solutions, developed by iVeri Payment Technologies (Pty) Ltd provides proven credit card payment solutions for businesses that have online or physical presence. LIte is an online payment product.


Overview of iVeri Lite - The Hosted Payment Page


Overview

 
Overview of iVeri Lite - The Hosted Payment Page
The iVeri Lite hosted payment page is an ecommerce solution that is geared for merchants that want card acceptance in their online stores. The acceptance of various card schemes and different payment methods available is dependent on the acquiring bank and or merchant agreements. The iVeri Lite hosted payment page can be integrated in 1 of 3 ways: 

  1. Full Redirect - A full redirect to the hosted payment page shifts the interaction of the shopper/buyer away from the merchant’s website and only goes back to the merchant website when the transaction is complete.

  2. LiteBox - The LiteBox hosted payment appears or pops up within the merchant’s website, the merchant’s website remains unchanged, providing for a more user friendly and seamless checkout experience for both cardholder and merchant. 

  3. Shopping Carts - The iVeri Lite hosted payment page is integrated to some of the commonly used shopping carts.

Payment Features


Overview

Payment Features
Depending on the acquirer involved, iVeri Lite has the capacity to offer the following payment methods: 

  1. VISA
  2. MasterCard
  3. AMEX
  4. Diners
  5. UPI
  6. EcoCash
  7. MasterPass
  8. Visa Checkout


Other functionalities available:

  • 3DSecure: iVeri Lite, being an e-commerce product, includes the 3DSecure protocol for payer authentication in online transactions. 
    To learn more about 3D Secure, visit this page.
  • Fraud Management
  • Transaction history reporting
  • BackOffice: more on iVeri Lite BackOffice features can be found on this page


Lite Process Flow


Overview

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 BackOffice allocate the Invoice number for them by using the “AUTOGENERATE” option) .

 
(2) Once the “Submit” button has been clicked, the customer’s captured details are sent to the Gateway verifying that the ApplicationID is valid, validating the variables i.e. purchase amount is an integer and that all required fields have been populated.


 
(3) The customer’s card details are captured on a SSL secured website where, after clicking on the Submit button, validation of the entered values (i.e. credit card number, expiry date…) will take place. Once validation has succeeded a “Please wait ......” message is returned to the cardholder while the transaction is in process
Authorization is performed at the respective acquiring financial institution/department who will then interact with the issuing financial institution/department.

(4) The return of an authorization can be either of the following:

successful, failed, system error or please try again later.

A redirect is sent to the cardholder’s browser telling it which Result URL to display.

(5) In the event of a successful/error transaction the cardholder as well as the Merchant can be emailed a statement indicating the successful completion of the transaction. Those transactions can be tracked via the BackOffice.

(6) A success/error page is returned to the cardholder by the merchant to show the transaction type, transaction amount, authorization code, merchant reference and purchase date


Getting Started With Lite


Getting Started With Lite

 Lite process:


Registering as a merchant


Registering as a merchant 


Merchant account can be attained by registering with an acquiring bank, a list of which can be found on this page


Development Phase


Development phase

 
At this stage you will proceed with development based on the integration method you have selected, and may reach out for your contact at the acquiring bank if you require support.


Test Phase


Test phase

The iVeri Gateway provides a mechanism where a merchant can perform test transactions that are routed to an iVeri Gateway issuer simulator. This enables a merchant to complete testing within the test environment. When the merchant is ready to process LIVE transactions, the acquiring bank can activate the merchant profile for LIVE processing which will be routed to the genuine card issuer. 

When performing a test transaction, using your Test Application ID, the following credit card numbers must be used, based on whether 3DS is enabled, and the MPI (3DS Provider) at play:

Non-3DS iVeri Gateway test cards:

Card Number

Result Status

Result Description

 4242424242424242
 Expiry Date: Current or future date

0

“”

 

 2121212121212121

 (Randomly returns one of 3 results)
 Expiry Date: Current or future date

3

“Hot Card”

4

“Denied”

5

“Please call…”

 5454545454545454
 Expiry Date: Current or future date

9

“Unable to process” (times out)

 Any other card number

14

 “Invalid card number”


BANKSERV (3DS 2)

Frictionless Full Authentication

Scenario 1

Authenticated Frictionless Transaction

Test Values

Visa:4069425217889137

MasterCard :5163426869252246
Expiry Date: Current or future date

 

Failed Frictionless Authentication

Scenario 2

Failed Frictionless Transaction

Test Values

Visa: 4069421358347845

MasterCard: 5178872338408971
Expiry Date: Current or future date

 

Challenged Full Authentication

Scenario 3

Authenticated Challenged Transaction

Test Values

Visa: 4895749143709709

MasterCard: 5192602720584796
Expiry Date: Current or future date

issuer ACS Password: test123

CYBERSOURCE (3DS 2)

Frictionless Full Authentication

Scenario 1

Successful Frictionless Authentication

Test Values

Visa: 4456530000001005

MasterCard: 5200000000001005
Expiry Date: January/ (current year+3)


Failed Frictionless Authentication

Scenario 2

Unsuccessful Frictionless Authentication

Test Values

Visa: 4456530000001013

MasterCard: 5200000000001013
Expiry Date: January/ (current year+3)


Challenged Authentication

Scenario 3

 Successful Step-Up Authentication 

Test Values

Visa: 4456530000001096

MasterCard: 5200000000001096
Expiry Date: January/ (current year+3)


NOTES: The Card Security Code (CVV) Field can be kept empty or set to any three numbers for testing purposes. If you want to generate the error “Invalid Expiry Date”, make the expiry date in the past.


Live Phase


Live phase

Before the merchant can start doing Live transactions, the acquirer or iVeri must validate that their implementation is correctly completed. For that purpose, the merchant shall send a request via email to the acquirer contact (available here) once they have completed their implementation, and after they have tested in the Test environment, while providing the following:

  •  Merchant's Website URL
  • User Group Number / Merchant number 
  • Test login credentials (Username / Password) for logging in to the merchant website as an end-user (if applicable) NB: It is time consuming for our test team to register as users on each website that we have to test hence this is required by them. If no log-in required, please state so within your email. 

Instruction on how to buy products from your website.
Once the integration has been validated, the acquirer will enable the live ApplicationID. At this point, the merchant must replace the test ApplicationID used during testing with the live ApplicationID and deploy the code into the merchant’s production environment.


Gateway Addresses


Gateway Addresses

Nedbank Gateway – Applicable for Nedbank acquired merchants located in South Africa, Zimbabwe, Namibia, Lesotho and Swaziland

Website

URL

Port

BackOffice

https://backoffice.nedsecure.co.za/

443

Lite

https://portal.nedsecure.co.za/Lite/Authorise.aspx

 

Authorization Information

https://portal.nedsecure.co.za/Lite/AuthoriseInfo.aspx

 

 

CIM Hosted Gateway – Applicable for merchants acquired by CIM Finance in Mauritius

Website

URL

Port

BackOffice

https://backoffice.merchant.cim.mu/

443

Lite

https://portal.merchant.cim.mu/Lite/Authorise.aspx  

 

Authorization Information

https://portal.merchant.cim.mu/Lite/AuthoriseInfo.aspx

 


CSC Hosted Gateway – Applicable for merchants that acquired by banks affiliated to CSC

Website

URL

Port

BackOffice

https://backoffice.cscacquiring.com/

443

Lite

https://portal.cscacquiring.com/Lite/Authorise.aspx

 

Authorization Information

https://portal.cscacquiring.com/Lite/AuthoriseInfo.aspx

 


Hosted Gateway – Applicable for merchants based in Kenya, Zimbabwe, Mauritius, Angola, Ghana

Website

URL

Port

BackOffice

https://backoffice.host.iveri.com/

443

Lite

https://portal.host.iveri.com/Lite/Authorise.aspx

 

Authorization Information

https://portal.host.iveri.com/Lite/AuthoriseInfo.aspx

 


If you are not sure which of the Gateway addresses applies to your merchant account, please refer to your acquiring institution for confirmation.


Integration Methods


Integration Methods

 


General Requirements


General Requirements

 
iVeri Lite implementation consists of doing a submission of a form post to the Gateway endpoint while including all required/mandatory parameters.
Applicable Parameters to be passed in the request are common to all the integration methods supported on iVeri Lite, and elaborated in this documentation.

The list of applicable parameters can be found here


Full Redirect – Hosted Payment Page


Full Redirect – Hosted Payment Page

An example is available online on this link


LiteBox Hosted Payment Page


LiteBox Hosted Payment Page

 
The LiteBox hosted payment page is an e-commerce solution that allows merchants to connect, send payment requests to the iVeri Payment Gateway without redirecting the cardholder away from their website. When implemented, the LiteBox pops up and sits in-front of the merchant’s website. From a merchant/cardholder point of view the LiteBox solution provides a more seamless checkout experience.

An example is available online on this link. To simulate the LiteBox behaviour, click on “Modal”.

 
Merchants’ developers can download the JavaScript library that handles the events to generate the button. The library can be found on the following URLs:
For Nedbank acquired merchants located in South Africa, Zimbabwe, Namibia, Lesotho and Swaziland: https://portal.nedsecure.co.za/scripts/jquery/js/jquery.litebox.js 

For merchants based in Kenya, Zimbabwe, Mauritius, Angola, Ghana:
https://portal.host.iveri.com/scripts/jquery/js/jquery.litebox.js 

For merchants acquired by CIM Finance in Mauritius: https://portal.merchant.cim.mu//scripts/jquery/js/jquery.litebox.js 

For merchants that acquired by banks affiliated to CSC: https://portal.cscacquiring.com/scripts/jquery/js/jquery.litebox.js

If you are not sure which of the URLs applies to your merchant account, please refer to your acquiring institution for confirmation.

LiteBox Implementation Steps:

Step One: In order for the LiteBox to render correctly to the device being used and to connect to the appropriate gateway end point the below must be defined on the head tag

<meta name="viewport" content="width=device-width, initial-scale=1.0" />

<link rel="stylesheet" href="https://[endpoint]/scripts/bootstrap/css/bootstrap.min.css" />

<script src="https://[endpoint]/scripts/jquery/js/jquery.min.js"></script>

<script src="https://[endpoint]/scripts/bootstrap/js/bootstrap.min.js"></script>

<script src="https://[endpoint]/scripts/jquery/js/jquery.litebox.js"></script>

 NB: replace “[endpoint]” with the appropriate gateway address

Step Two: Place the LiteBox button to be used to trigger the LiteBox page in the body tag, the merchant developer can set the color, and the label of their own choosing for the button. Download the JavaScript library that handles the button on https://[endpoint]/scripts/jquery/js/jquery.litebox.js . Also, to note is that the jQuery uses an id attribute on the HTML elements.

<!-- Button HTML -->

 <a id="iveri-litebox-button">Make Payment</a>

 <!-- Modal HTML -->

 <div id="iveri-litebox"></div>

 
Step Three: Initialize the LiteBox. Define event handlers for the data that is to be returned from the gateway and when the LiteBox closes.

<script>

 liteboxInitialise(portalUrl); // pass the appropriate gateway address or endpoint

 function liteboxComplete(data) {

 /Place your code to handle the response here

 }

</script>

 
Step Four: Data returned to the merchant is JSON formatted The following parameters are some of the data elements returned to the merchant, some of which will only be returned if present in the request message. Data parameters that can be passed to the iVeri gateway as part of the transaction request can be referenced in 8.2 iVeri Lite Specification

  • Lite_Merchant_ApplicationId 
  • Lite_Merchant_Trace 
    Ecom_Payment_Card_Number 
  • Ecom_Payment_Card_ExpDate_Month 
  • Ecom_Payment_Card_ExpDate_Year 
  • MerchantReference
  • Lite_Order_Amount 
  • Lite_Order_Terminal 
  • Lite_Order_AuthorisationCode
  • Lite_BankReference 
  • Lite_TransactionDate 
  • Lite_TransactionIndex 
  • Lite_Payment_Card_Status 
  • Lite_Result_Description

Shopping Carts



Parameters


Parameters

 
The following parameters are expected in the form submitted to the Gateway at step 3 of the iVeri Lite 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 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 lineamount*linequantity for each line item

Lite_Website_Successful_Url

Success End Url

255

URL to pass control back to upon successful completion of a transaction. Control of the transaction is passed back to this URL if the Lite_Payment_Card_Status = 0

Lite_Website_Fail_Url

Failed End Url

255

URL to pass control back to if the authorisation is refused by the financial institution. Control of the transaction is passed back to this URL if the Lite_Payment_Card_Status is anything other than 0, 1, 2, 5, 9 or 255

Lite_Website_TryLater_Url

Network error End Url

255

URL to pass control back to if there is a system error which could be overcome by trying again later. Control of the transaction is passed back to this URL if the Lite_Payment_Card_Status = 1, 2, 5 or 9

Lite_Website_Error_Url

Code error End Url

255

URL to pass control back to if the form has not been filled in correctly of there is an inconsistency in the form. Control of the transaction is passed back to this URL if the Lite_Payment_Card_Status = 255

Lite_Order_LineItems_Product_#

LineItem

255

Line item of what is being ordered. The # indicates a number starting at 1 and incrementing by 1 for every line item. This is essentially a description of the item being ordered

Lite_Order_LineItems_Quantity_#

LineQuantity

10

Line item Quantity of what is being ordered. The # indicates a number starting at 1 and incrementing by 1 for every line item. This is the number of units being ordered.

Lite_Order_LineItems_Amount_#

LineAmount

10

Line item cost including tax if any of what is being ordered. The # indicates a number starting at 1 and incrementing by 1 for every line item. This is the unit price for this particular item.

Lite_ConsumerOrderID_PreFix

Autogenerate Invoice Extension

5

If the Merchant sets the ECOM_CounsuremOrderID to “AUTOGENERATE" then this field is used to control the first 3 to 6 characters of the autogenerated consumerorderid E.g. “INV” set in this field will result in an autogenerated consumerorderid of “INV0001”, “INV0002” and so on.

Ecom_BillTo_Online_Email

Bill to email

40

This is the email address the invoice would be mailed to. e.g., jsmith@isp.com

Ecom_Payment_Card_Protocols

Payment protocols available

20

A space separated list of protocols available for a specified card. Initial list of case insensitive tokens: "none", "set", or "setcert". "Set" indicates usable with SET Protocol (i.e., is in a SET wallet) without a SET certificate. "Setcert" indicates same but does have a SET certificate. "None" indicates standard is being used but wallet is not SET capable or the card has not been entered into the SET wallet. Usually a hidden field.
Values: IVERI

Ecom_ConsumerOrderID

Consumer generated order ID

20

unique order ID generated by the consumer software. If at all possible, this should be filled out. If it is impossible iVeri will generate one for you but it should preferably be filled out by the merchant. For iVeri to create a unique ordered for you please set this to "AUTOGENERATE" and refer to the Lite_ConsumerID_PreFix which enables you to specify the first few letters of the invoice

Ecom_TransactionComplete

End transaction flag

-

A flag to indicate that this web page/aggregate is the final one for this transaction. Usually a hidden field.
Values: False



Optional Parameters:

Name

General Description

Length

Notes

Lite_Version

Version

5

Set to current Version number ex. 4.0, for Old Version left blank – Not available.

Lite_Payment_Card_Status

iVeri Status

10

Status of transaction received in response

Lite_Merchant_Trace

MerchantTrace

64

Unique merchant identification for the request. This value can be used by the merchant to confirm the status of the transaction if need be. Appendix D

Lite_Recurring_Payment

CardHolderPresence

5

Set to True or False. If True, then if your ApplicationID has been enabled for Recurring transactions, this will be the first transaction. Note: Your ApplicationID has to be enabled for recurring payments otherwise this indicator will be ignored.

Lite_Order_Terminal

Terminal on the Web

8

 

Lite_Order_DiscountAmount

Discount

10

this is the discount field for iVeri lite, this field should be used as a discount field for the entire shopping basket. Please make use of this field and remember to adjust the Lite_Order_Amount

Lite_Order_AuthorisationCode

Authorisation Code

6

Pre-authorisation code received from a financial institution

Lite_Order_BudgetPeriod

Budget Period

2

Request to put this order onto a budget plan. The normal options for this are 0, 6, 12, 18, 24 and 36. 0 indicating to budget period. Specifying this field does not guarantee that the request will be granted a budget period

Lite_Authorisation

Card Pre-Auth Mode

5

Set to True or False. If True then a Authorisation will be made, if false a Debit will be made. The Authorisation code will be stored for 3 weeks before you need to confirm the transaction in the BackOffice under view orders.

Lite_Transaction_Token

Transaction Token

32

Merchant should generate the token: Encoded data should be Lite_Order_Amount, Lite_Merchant_ApplicationId, Ecom_BillTo_Online_Email & TimeStamp

Ecom_ShipTo_Postal_Name_Prefix

Ship-to title

4

e.g., Mr., Mrs., Ms.; field commonly not used

Ecom_ShipTo_Postal_Name_First

Ship-to first name

15

 

Ecom_ShipTo_Postal_Name_Middle

Ship-to middle name

15

 

Ecom_ShipTo_Postal_Name_Last

Ship-to last name

15

 

Ecom_ShipTo_Postal_Name_Suffix

Ship-to name suffix

4

e.g., Ph.D., Junior, Esquire; field commonly not used

Ecom_ShipTo_Postal_Street_Line1

Ship-to street1

20

 

Ecom_ShipTo_Postal_Street_Line2

Ship-to street2

20

 

Ecom_ShipTo_Postal_Street_Line3

Ship-to street3

20

 

Ecom_ShipTo_Postal_City

Ship-to city

22

 

Ecom_ShipTo_Postal_StateProv

Ship-to state or province

2

2 characters are the minimum for the US and Canada, other countries may require longer fields; for the US use 2-character US Postal state abbr

Ecom_ShipTo_Postal_PostalCode

Ship-to zip or postal code

14

 

Ecom_ShipTo_Postal_CountryCode

Ship-to country

2

use ISO 3166 2 letter codes for country names

Ecom_ShipTo_Telecom_Phone_Number

Ship-to phone

10

10 digits are the minimum for the US and Canada, other countries may require longer fields, recommend placing on "x" before an extension

Ecom_ShipTo_Online_Email

Ship-to email

40

e.g., jsmith@isp.com

Ecom_BillTo_Postal_Name_Prefix

Bill-to title

4

e.g., Mr., Mrs., Ms.; field commonly not used

Ecom_BillTo_Postal_Name_First

Bill-to first name

15

If this is blank your invoice would read Dear Customer

Ecom_BillTo_Postal_Name_Middle

Bill-to middle name

15

may also be used for middle initial

Ecom_BillTo_Postal_Name_Last

Bill-to last name

15

 

Ecom_BillTo_Postal_Name_Suffix

Bill-to name suffix

4

e.g., Ph.D., Junior, Esquire; field commonly not used

Ecom_BillTo_Postal_Street_Line1

Bill-to street1

20

 

Ecom_BillTo_Postal_Street_Line2

Bill-to street2

20

 

Ecom_BillTo_Postal_Street_Line3

Bill-to street3

20

 

Ecom_BillTo_Postal_City

Bill-to city

22

 

Ecom_BillTo_Postal_StateProv

Bill-to state or province

2

2 characters are the minimum for the US and Canada, other countries may require longer fields; for the US use 2-character US Postal state abbr

Ecom_BillTo_Postal_PostalCode

Bill-to zip or postal code

14

 

Ecom_BillTo_Postal_CountryCode

Bill-to country

2

use ISO 3166 2 letter codes for country names

Ecom_BillTo_Telecom_Phone_Number

Bill-to phone

10

10 digits are the minimum for the US and Canada, other countries may require longer fields, recommend placing on "x" before an extension

Ecom_ReceiptTo_Postal_Name_Prefix

Receipt-to title

4

e.g., Mr., Mrs., Ms.; field commonly not used

Ecom_ReceiptTo_Postal_Name_First

Receipt-to first name

15

 

Ecom_ReceiptTo_Postal_Name_Middle

Receipt-to middle name

15

may also be used for middle initial

Ecom_ReceiptTo_Postal_Name_Last

Receipt-to last name

15

 

Ecom_ReceiptTo_Postal_Name_Suffix

Receipt-to name suffix

4

e.g., Ph.D., Junior, Esquire; field commonly not used

Ecom_ReceiptTo_Postal_Street_Line1

Receipt-to street1

20

 

Ecom_ReceiptTo_Postal_Street_Line2

Receipt-to street2

20

 

Ecom_ReceiptTo_Postal_Street_Line3

Receipt-to street3

20

 

Ecom_ReceiptTo_Postal_City

Receipt-to city

22

 

Ecom_ReceiptTo_Postal_StateProv

Receipt-to state or province

2

2 characters are the minimum for the US and Canada, other countries may require longer fields; for the US use 2-character US Postal state abbr

Ecom_ReceiptTo_Postal_PostalCode

Receipt-to zip or postal code

14

 

Ecom_ReceiptTo_Postal_CountryCode

Receipt-to country

2

use ISO 3166 2 letter codes for country names

Ecom_ReceiptTo_Telecom_Phone_Number

Receipt-to phone

10

10 digits are the minimum for the US and Canada, other countries may require longer fields, recommend placing on "x" before an extension

Ecom_ReceiptTo_Online_Email

Receipt-to email

40

e.g., jsmith@isp.com

Ecom_Payment_Card_Type

Card type

4

use the first 4 letters of the association name: American Express=AMER; Diners Club=DINE; Discover=DISC; JCB=JCB; Mastercard=MAST; Visa=VISA; other association names may require more than 4 characters. You can tell card numbers apart from the first digit of a credit card number. 3 - American Express 4 - Visa 5 - MasterCard

Ecom_SchemaVersion

schema version number

30

Identifies the ecom schema version number; format 999_99; digit (3) _digit (2); defined within a URL (e.g. http://www.w3c.org/ecom/1_0). Field should be included on every page with an ECML field on it and is usually a hidden field.

Lite_Result_Description

Description lite transaction

255

Status of transaction described, if any error – error description.

MerchantReference

consumer generated order ID

20

unique order ID generated by the consumer software. If at all possible, this should be filled out. If it is impossible iVeri will generate one for you but it should preferably be filled out by the merchant. For iVeri to create a unique ordered for you please set Lite_ConsumerID to "AUTOGENERATE" and refer to the Lite_ ConsumerOrderID PreFix which enables you to specify the first few letters of the invoice.

Lite_BankReference

Bank Reference

11

Cycle, Trace number eg. 12345,12345

Lite_TransactionDate

Transaction Date

 

The date the authorisation took place

Lite_Referrer

Referrer

 

The Website Referrer where the merchants Transaction started

Lite_Currency_AlphaCode

Currency

3

The Currency in which the transaction will be processed


Note: The below fields are required when Implementing section Tokenisation: TransactionIndex on Subsequent Transactions

Name

General Description

Length

Notes

Lite_PanFormat

PanFormat

64

Methodology that specifies how to obtain the PAN details

Lite_TransactionIndex

TransactionIndex

38

Unique identifier allocated by iVeri for a series of related transactions. If PANFormat is 'TransactionIndex', TransactionIndex is used to locate a previous transaction for the PAN to be resolved.

Ecom_Payment_Card_Number

CardNumber

20

A dotted Pan number as returned in a previous transaction would have to be passed in this field


Note: The following fields will be used when submitting to CyberSource for Advanced Fraud Screening and will not be saved to the iVeri system.

 Name

 General Description

 Length

 Notes

 Lite_Order_LineItems_PassengerFirstName_#

 Passenger FirstName

 60

 Passenger's first name

 Lite_Order_LineItems_PassengerLastName_#

 Passenger LastName

 60

 Passenger's last name

 Lite_Order_LineItems_PassengerID_#

 Passenger ID

 32

 ID of the passenger to whom the ticket was issued. For example, you can use this field for the frequent flyer number

 Lite_Order_LineItems_PassengerStatus_#

 Passenger Status

 32

 Your company's passenger classification, such as with a frequent flyer program. In this case, you might use values such as standard, gold, or platinum.

 Lite_Order_LineItems_PassengerType_#

 Passenger Type

 32

 Passenger classification associated with the price of the ticket. You can use one of the following values: 

• ADT: Adult 

• CNN: Child 

• INF: Infant 

• YTH: Youth 

• STU: Student 

• SCR: Senior Citizen 

• MIL: Military


Note: The following Airline addendum data is additional transaction data which appear on a card holder's statement when buying a ticket from an airline merchant who include this data in a transaction request

Name

General Description

Length

Notes

Airline_PassengerName

Passenger Name

20

Passenger name as printed on ticket.

Airline_PrimaryTicketNumber

Primary TicketNumber

15

The ticket numbers.

Airline_FirstDepartureLocationCode

First Departure LocationCode

3

Code for departure airport location, eg. JNB for Johannesburg

Airline_FirstArrivalLocationCode

First Arrival LocationCode

3

Code for destination airport location, eg. JNB for Johannesburg

Airline_PNRNumber

PNR Number

6

 

Airline_OfficeIATANumber

Office IATA Number

8

The office IATA number

Airline_OrderNumber

Order Number

8

The order number

Airline_PlaceOfIssue

Place of Issue

20

The ticket office location

Airline_DepartureDate

Departure Date

8

Date of departure in yyyymmdd format

Airline_DepartureTime

Departure Time

15

Departure time of the first leg of the trip. Use one of the following formats:
• HH:mm \"GMT\"zzz
• HH = two-digit hour in 24-hour format
• mm = two-digit minutes
• zzz = time zone of the departing flight, for example: If the airline is based in city A, but the flight departs from city B, z is the time zone of city B at the time of departure. Important For travel information, use GMT instead of UTC or use the local time zone. Examples 19:55 GMT+02:00 19:55 GMT+0200 11:25 GMT-03:00 11:25 GMT-0300 Note When specifying an offset from GMT, the format must be exactly as specified in the example. Insert no spaces between the time zone and the offset.

Airline_CompleteRoute

Complete Route

25

Concatenation of individual travel legs in the format ORIG1-DEST1[: ORIG2-DEST2...:ORIGn-DESTn], f or example:CPT-JNB :JNB-:NBO. For airport codes

Airline_JourneyType

Journey Type

25

Type of travel, for example: one way or round trip.

 

Note: The following fields will be captured when the merchant’s website transfers control to the Lite web page on the iVeri Gateway.



Name

General Description

Length

Notes

Ecom_Payment_Card_Number

card number

19

The card number embossed on the cardholder’s card

Ecom_Payment_Card_Verification

cardholder verification value

4

additional cardholder verification number such as American Express' CIV, MasterCard's CVC2, and Visa's CVV2 values

Ecom_Payment_Card_ExpDate_Month

card expiration date month

2

Jan - 1, Feb - 2, March - 3, etc.

Ecom_Payment_Card_ExpDate_Year

card expiration date year

4

Value in wallet cell is always 4 digits, e.g., 1999, 2000, 2001

Ecom_Payment_Card_Name

name on card

30

name of cardholder

 

NOTE: Please remember to do the relevant configuration of the card capture page in BackOffice.

Refer to the Lite BackOffice user guide.



Query Transaction Status


Query Transaction Status

 
Note: This is just an extra step that can be used by the Merchant to make sure about the Transaction results. We would recommend that a Merchant should use this as a call to make sure the results he received back from the Authorization (Debit) of a transaction are consistent with the results returned here. The URL to post to is defined under the Gateway Addresses

Name

General Description

Length

Notes

Lite_Merchant_ApplicationId

iVeri ApplicationID

36

Allocated to the merchant during registration

Lite_Merchant_Trace

Merchant Trace

64

Unique merchant identification for the request. This value is to be used by the merchant to confirm the status of the transaction.


 
The response to the Authorisation Information request is the following:

  • Lite_Merchant_ApplicationId 
  • Lite_Merchant_Trace 
  • Ecom_Payment_Card_Number 
  • Ecom_Payment_Card_ExpDate_Month 
  • Ecom_Payment_Card_ExpDate_Year 
  • MerchantReference 
  • Lite_Order_Amount 
  • Lite_Order_BudgetPeriod 
  • Lite_Order_Terminal 
  • Lite_Order_AuthorisationCode 
  • Lite_BankReference 
  • Lite_TransactionDate 
  • Lite_TransactionIndex 
  • Lite_Payment_Card_Status 
  • Lite_Result_Description


Transaction Notification


Transaction Notification

Email to Merchant

This is an order confirmation from the Payment Gateway to Lite Application.
We have received the following Sale from your customer: 
Customer Details: 
Name : Mr. John Doe 
Email : John 
Payment Details: 
Transaction Type : Sale 
Transaction Index : A0394EB4-BBC1-4567-BBCB-A56B702050DD 
Merchant Reference : LITE0000028 
Card Number : 4242........4242 
Expiry Date : 092025
Acquirer Reference : 80903:09089990 
Electronic Commerce Indicator : SecureChannel 
Order Details: 
Purchase DateTime : 2022-09-03 09:08:32 
Total Order Amount : R 100.00 
Line Item Details: 
Item Description Quantity Unit Cost Line Total
----------------------------------------------------- 
Donation product#1 1 100.00 100.00
Additional Info:
Please contact <Distributor> should you have any queries.

Email to card holder

 
Dear Mr. John Doe
This is to confirm that <MERCHANT NAME> Lite Application has made a Sale on your card (number: 4242........4242) for R 0.99. 
The transaction occurred at 2022-08-14 10:13:27 (South Africa Standard Time). 
The reference number used by <MERCHANT NAME> Lite Application was <App Id> 
Order Details 
Purchase DateTime : 2022-08-14 10:13:27 
Total Order Amount : R 0.99 
Line Item Details: 
Item Description Quantity Unit Cost Line Total 
----------------------------------------------------- 
Donation product#1 1 0.35 0.35 
Donation product#2 2 0.32 0.64 
Additional Info: 
Expiry Date Month : 09 
Expiry Date Year : 2025 
Should you have any concerns about this transaction or the services offered by<MERCHANT NAME> 's Lite Application, please contact <MERCHANT NAME> 's Lite Application directly.


Additional Variables


Additional Variables

 
Note: These are form variables that are not part of the iVeri Lite specification but may be required by the merchant.

These form variables (if used) will be returned to the website together with all the iVeri Lite form variables. 

For added security, to prevent possible fraud by someone obtaining the websites return URL and parameters, we highly recommend that you submit an additional form variable of arbitrary name chosen by the merchant and random value which changes from transaction to transaction. This will be returned to the website along with all the iVeri Lite form variables and all you need to do is check for the existence of the form variable and that the value thereof is the same as that generated and used during the submission of the iVeri Lite page


Introduction to 3D Secure


Introduction to 3D Secure

 
3D secure (Secure Code or Verified by Visa), is all about call back protection and making sure card holders are who they say they are. The Illustration and process that follows, shows 3D secure in use as implemented by Merchants using iVeri Enterprise and not iVeri Lite. Illustrating the process in this way, helps to show how each entity is involved even if certain functions are performed on behalf of Merchants using iVeri Lite.


Process flow of a 3D secure transaction


Process flow of a 3D secure transaction




3D secure transaction process flow


3D secure transaction process flow

 

  1. 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.
  2. The Gateway will proceed to check if the card in use is enrolled in 3DS by sending a request to the Directory Server.
  3. Directory Server will respond with enrollment status. 
    Considering the response is positive and the card is enrolled for 3DS, 
  4. The Gateway will redirect to the issuer ACS for authentication
    The ACS will prompt the cardholder to insert and submit OTP/Password/credential(etc.)
  5. Considering the authentication was successful, the response is returned to the gateway to confirm successful authentication
  6. Gateway then forwards the transaction details to the acquirer for authorization (Debit)
  7. The acquirer sends an authorization request to the issuer
  8. Issuer authorizes the transaction and sends response to the acquirer
  9. Acquirer sends response to the Gateway
  10. Gateway in turn reflects the response to the merchant by calling corresponding callback url set by the merchant in their implementation.


Tokenisation: Transactionindex On Subsequent Transactions


Tokenisation: Transactionindex On Subsequent Transactions

 
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


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


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 would simply select the masked card on file and make a payment.


Subsequent Transactions implementation


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.


Merchant Hash Token Generation


Merchant Hash Token Generation

 
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


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


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


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


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(unixEpoch)).TotalSeconds; 
return unixTimeStamp; 
}
public static string GetHashSha256(string text) 

35 byte[] bytes = Encoding.ASCII.GetBytes(text); 
SHA256Managed hashstring = new SHA256Managed (); 
byte[] hash = hashstring.ComputeHash(bytes); 
string hashString = string.Empty;
foreach (byte x in hash) 

hashString += String.Format("{0:x2}", x);

return hashString;
 

Sample Code:

ApplicationId:{c0f9f3e2-b75c-4864-b6c6-df1372fbedb0} 
LiteSharedSecret:AFcWxV2NG9W4 
Lite_Order_mound:4130 
OnlineBilltoEmail:jdoe@mail.com 
Timestamp:1471358394 
Lite Transaction Token: 1471358394:8dd2f3c016662ef48743cf73a0b2e88de79b3e56791cbf48f8e0a688e363439915

VISA Checkout with Lite


VISA Checkout with Lite

 
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.


Process Flow in Visa Check-Out with Lite


Process Flow in Visa Check-Out with Lite

 

  1. Cardholder selects Visa Check-Out as payment method
  2. iVeri Lite calls Visa Light Box or Widget and presents it to the Cardholder to Login
  3. Cardholder Logins via Visa Light Box
  4. Cardholder selects a card and presses Continue
  5. Upon clicking Continue, iVeri Lite receives a Call ID (uniquely identifies the transaction)
  6. iVeri Lite uses the Call ID to get the Payload from Visa services
  7. Payload is returned by Visa services to iVeri Lite
  8. iVeri Lite decrypts the Payload and retrieves the PAN
  9. iVeri Lite sends the transaction request to the gateway/acquire
  10. When the response is received, Visa services is updated with either a Failed or Successful response
  11. Lastly, a redirect to the merchant with the transaction response is made.


Illustration of Visa Check-Out Process With iVeri Lite


Illustration of Visa Check-Out Process With iVeri Lite





MasterPass


MasterPass

 
MasterPass is a safe and easy way in which merchants can present the QR code which customers can scan using a MasterPass application to affect a payment.

Requirements 
Merchant must be onboarded for MasterPass on the iVeri Gateway and on the MasterPass platform.


Create Code


Create Code

 
Function: Generate a transactional code that can then be paid for by a cardholder. This code can be represented as a QR code, transferred using NFC or manually entered a device. The code can also be used as part of an In-App payment.

Create Code Parameters

Request Parameter

Description

MasterPassAction

Mandatory, The action to perform.

MasterPassMerchantID

Mandatory, The merchant id as captured on MasterPass.

MasterPassShortDescription

Mandatory, This will be displayed to the consumer at the time a code is scanned. Length is 5 to 45 characters

MasterPassCodeExpiryDate

Optional. If this is empty the code will by default expire in 30 minutes from issue. If this value is 0 the code will never expire. This time is specified in epoch.

Amount

Mandatory, To use a variable amount use 0 as the amount.

Currency

Mandatory, The currency is tied to the merchant setup.

MerchantReference

Mandatory, Used to link code to transaction.

Response Parameter

Description

MasterPassAction

The action that was performed

MasterPassCode

This is the result code

MasterPassCodeExpiryDate

Date until the code is valid. This is in epoch time.

Create Code – REST Sample

 

Request

Response

Request:

{

    "Version""2.0",

    "CertificateID""{xxxxxxxx-71dd-4044-802d-xxxxxxxxxxxx}",

    "ProductType""Enterprise",

    "Direction""Request",

    "Enquiry": {

      "ApplicationID""{xxxxxxx-68e0-42eb-aba9-xxxxxxxxxxxx}",

      "Command""MasterPassQuickResponseCode",

      "Mode""Live",

      "MasterPassMerchantID""xxxxx",

      "MasterPassAction""CreateCode",

      "Currency""ZAR",

      "MerchantReference""Ref_001",

      "Amount""1075",

      "MasterPassShortDescription""Basket of goods"

   }

}

 

{

    "Version""2.0",

    "CertificateID""{xxxxxxxx-71dd-4044-802d-xxxxxxxxxxxx}",

    "ProductType""Enterprise",

    "Direction""Request",

    "Enquiry": {

      "ApplicationID""{xxxxxxx-68e0-42eb-aba9-xxxxxxxxxxxx}",

      "Command""MasterPassQuickResponseCode",

      "Mode""Live",

      "MasterPassMerchantID""xxxxx",

      "MasterPassAction""CreateCode",

      "Currency""ZAR",

      "MerchantReference""Ref_001",

      "Amount""1075",

      "MasterPassShortDescription""Basket of goods"

   }

}

 

Create Code – SOAP Sample

SOAP Request

SOAP Response

<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/">

  <validateRequest>false</validateRequest>

  <protocol>V_XML</protocol>

  <protocolVersion>7.0</protocolVersion>

  <request>&lt;V_XML Version="2.0" CertificateID="xxxxxxxx-71dd-4044-802d-xxxxxxxxxxxx" ProductType="Enterprise"

ProductVersion="iVeriWebService" Direction="Request"&gt;

&lt;Enquiry ApplicationID="xxxxxxxx-68e0-42eb-aba9-xxxxxxxxxxxx" Command="MasterPassQuickResponseCode" Mode="LIVE"&gt;

&lt;Amount&gt;1075&lt;/Amount&gt;

&lt;Currency&gt;ZAR&lt;/Currency&gt;

&lt;MerchantReference&gt;Ref_002&lt;/MerchantReference&gt;

&lt;MasterPassMerchantID&gt;xxxxx&lt;/MasterPassMerchantID&gt;

&lt;MasterPassAction&gt;CreateCode&lt;/MasterPassAction&gt;

&lt;MasterPassShortDescription&gt;TestProduct1&lt;/MasterPassShortDescription&gt;

&lt;/Enquiry&gt;

&lt;/V_XML&gt;

</request>

  </Execute>

  </soap:Body>

  </soap:Envelope>

 

<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body><ExecuteResponse xmlns="http://iveri.com/"><ExecuteResult>&lt;V_XML Version="2.0" Direction="Response"&gt;
  &lt;Enquiry ApplicationID="{xxxxxxxx-68E0-42EB-ABA9-xxxxxxxxxxxx}" Command="MasterPassQuickResponseCode" Mode="Live" RequestID="{xxxxxxxx-DBC4-484A-84C1-xxxxxxxxxxxx}"&gt;
    &lt;Result Status="0" Code="0" Description="" AppServer="QAGW2012APP1" DBServer="QAGW2012DB2" Gateway="QA" /&gt;
    &lt;MasterPassAction&gt;CreateCode&lt;/MasterPassAction&gt;
    &lt;MasterPassCodeExpiryDate&gt;1647807283989&lt;/MasterPassCodeExpiryDate&gt;
    &lt;MasterPassCode&gt;xxx6944xxx&lt;/MasterPassCode&gt;
  &lt;/Enquiry&gt;
&lt;/V_XML&gt;</ExecuteResult></ExecuteResponse></soap:Body></soap:Envelope>

 



Query Code


Query Code

 
Function: Query a code that has been created.

Query Code Parameters

Request Parameter

Description

MasterPassAction

Mandatory, The action to perform.

MasterPassMerchantID

Mandatory, The merchant id as captured on MasterPass.

MasterPassCode

Mandatory, The result code that must be queried

Response Parameter

Description

MasterPassAction

The action that was performed

MasterPassShortDescription

Short decription linked to the code

MasterPassCodeExpiryDate

Date until the code is valid. This is in epoch time.

MasterPassMerchantName

The name of the merchant as captured on MasterPass

Amount

Amount linked to the code.

Currency

The currency is tied to the merchant setup.

MerchantReference

Linked to the code.


Query Code – REST Sample

Request

Response

{

    "Version""2.0",

    "CertificateID""{xxxxxxxx-71dd-4044-802d-xxxxxxxxxxxx}",

    "ProductType""Enterprise",

    "Direction""Request",

    "Enquiry": {

      "ApplicationID""{xxxxxxxx-68e0-42eb-aba9-xxxxxxxxxxxx}",

      "Mode""Live",

      "command":"MasterPassQuickResponseCode",

      "MasterPassMerchantID""xxxxx",

      "MasterPassAction""QueryCode",

      "MerchantReference""Ref_001",

      "MasterPassCode":"xxx2720xxx"

   }

}

 

{

    "Version""2.0",

    "Direction""Response",

    "Enquiry": {

        "Currency""R",

        "MerchantReference""Ref_001",

        "Amount""1075",

        "MasterPassAction""QueryCode",

        "MasterPassShortDescription""Basket of goods",

        "MasterPassCodeExpiryDate""1645187074000",

        "MasterPassMerchantName""Retail Merchant 001",

        "ApplicationID""{xxxxxxxx-68E0-42EB-ABA9-xxxxxxxxxxxx}",

        "Command""MasterPassQuickResponseCode",

        "Mode""Live",

        "RequestID""{xxxxxxxx-2207-4C11-A89C-xxxxxxxxxxxx}",

        "Result": {

            "Status""0",

            "Code""0",

            "Description""",

            "AppServer""QAGW2012APP1",

            "DBServer""QAGW2012DB2",

            "Gateway""QA"

        }

    }

}

 


Query Code –SOAP Sample


Request

Response

<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/">

  <validateRequest>false</validateRequest>

  <protocol>V_XML</protocol>

  <protocolVersion>7.0</protocolVersion>

  <request>&lt;V_XML Version="2.0" CertificateID="xxxxxxxx-71dd-4044-802d-xxxxxxxxxxxx" ProductType="Enterprise"

ProductVersion="iVeriWebService" Direction="Request"&gt;

&lt;Enquiry ApplicationID="xxxxxxxx-68e0-42eb-aba9-xxxxxxxxxxxx" Command="MasterPassQuickResponseCode" Mode="LIVE"&gt;

&lt;MerchantReference&gt;Ref_002&lt;/MerchantReference&gt;

&lt;MasterPassMerchantID&gt;xxxxx&lt;/MasterPassMerchantID&gt;

&lt;MasterPassAction&gt;QueryCode&lt;/MasterPassAction&gt;

&lt;MasterPassCode&gt;xxx5104xxx&lt;/MasterPassCode&gt;

&lt;/Enquiry&gt;

&lt;/V_XML&gt;

</request>

  </Execute>

  </soap:Body>

  </soap:Envelope>

 

<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body><ExecuteResponse xmlns="http://iveri.com/"><ExecuteResult>&lt;V_XML Version="2.0" Direction="Response"&gt; &lt;Enquiry ApplicationID="{xxxxxxxx-68E0-42EB-ABA9-xxxxxxxxxxxx}" Command="MasterPassQuickResponseCode" Mode="Live" RequestID="{xxxxxxxx-55EC-4835-9817-xxxxxxxxxxxx}"&gt; &lt;Result Status="0" Code="0" Description="" AppServer="QAGW2012APP1" DBServer="QAGW2012DB2" Gateway="QA" /&gt; &lt;Currency&gt;R&lt;/Currency&gt; &lt;MerchantReference&gt;Ref_002&lt;/MerchantReference&gt; &lt;Amount&gt;1075&lt;/Amount&gt; &lt;MasterPassAction&gt;QueryCode&lt;/MasterPassAction&gt; &lt;MasterPassShortDescription&gt;TestProduct&lt;/MasterPassShortDescription&gt; &lt;MasterPassCodeExpiryDate&gt;1647898033000&lt;/MasterPassCodeExpiryDate&gt; &lt;MasterPassMerchantName&gt;Sample Merchant Enterprise Enterprise&lt;/MasterPassMerchantName&gt; &lt;/Enquiry&gt;

&lt;/V_XML&gt;</ExecuteResult></ExecuteResponse></soap:Body></soap:Envelope




Delete Code


Delete Code

Function: Delete a code that has been created


Delete Code Parameters

Request Parameter

Description

MasterPassAction

Mandatory, The action to perform.

MasterPassMerchantID

Mandatory, The merchant id as captured on MasterPass.

MasterPassCode

Mandatory, The result code that must be deleted

Response Parameter

Description

MasterPassAction

The action that was performed


Delete Code – REST Sample

Request

Response

{

    "Version""2.0",

    "CertificateID""{xxxxxxxx-71dd-4044-802d-xxxxxxxxxxxx}",

    "ProductType""Enterprise",

    "Direction""Request",

    "Enquiry": {

      "ApplicationID""{xxxxxxxx-68e0-42eb-aba9-xxxxxxxxxxxx}",

      "Mode""Live",

      "command":"MasterPassQuickResponseCode",

      "MasterPassMerchantID""xxxxx",

      "MasterPassAction""DeleteCode",

      "MerchantReference""Ref_001",

      "MasterPassCode":"0790455080"

   }

}

 

{

    "Version""2.0",

    "Direction""Response",

    "Enquiry": {

        "MasterPassAction""DeleteCode",

        "ApplicationID""{xxxxxxxx-68E0-42EB-ABA9-xxxxxxxxxxxx}",

        "Command""MasterPassQuickResponseCode",

        "Mode""Live",

        "RequestID""{xxxxxxxx-1DC1-4D06-A632-xxxxxxxxxxxx}",

        "Result": {

            "Status""0",

            "Code""0",

            "Description""",

            "AppServer""QAGW2012APP1",

            "DBServer""QAGW2012DB2",

            "Gateway""QA"

        }

    }

}

 


Delete Code – SOAP  Sample

Request

Response

<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/">

  <validateRequest>false</validateRequest>

  <protocol>V_XML</protocol>

  <protocolVersion>7.0</protocolVersion>

  <request>&lt;V_XML Version="2.0" CertificateID="xxxxxxxx-71dd-4044-802d-xxxxxxxxxxxx" ProductType="Enterprise"

ProductVersion="iVeriWebService" Direction="Request"&gt;

&lt;Enquiry ApplicationID="xxxxxxxx-68e0-42eb-aba9-xxxxxxxxxxxx" Command="DeleteCode" Mode="LIVE"&gt;

&lt;MerchantReference&gt;Ref_002&lt;/MerchantReference&gt;

&lt;MasterPassMerchantID&gt;xxxxx&lt;/MasterPassMerchantID&gt;

&lt;MasterPassAction&gt;DeleteCode&lt;/MasterPassAction&gt;

&lt;MasterPassCode&gt;xxx5104xxx&lt;/MasterPassCode&gt;

&lt;/Enquiry&gt;

&lt;/V_XML&gt;

</request>

  </Execute>

 

<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body><ExecuteResponse xmlns="http://iveri.com/"><ExecuteResult>&lt;V_XML Version="2.0" Direction="Response"&gt; &lt;Enquiry ApplicationID="{xxxxxxxx-68E0-42EB-ABA9-xxxxxxxxxxxx}" Command="DeletCode Mode="Live" RequestID="{xxxxxxxx-304D-4EB0-882D-xxxxxxxxxxxx}"&gt; &lt;Result Status="0" Code="0" Description="" AppServer="QAGW2012APP1" DBServer="QAGW2012DB2" Gateway="QA" /&gt; &lt;MasterPassAction&gt;DeleteCode&lt;/MasterPassAction&gt; &lt;/Enquiry&gt; &lt;/V_XML&gt;</ExecuteResult></ExecuteResponse></soap:Body></soap:Envelope>



Distributors Contact Information


Distributors Contact Information

 

Below is the contact information per distributor for registering billing and banking details with iVeri. An iVeri Distributor markets the services of the iVeri Gateway and products within a locality.

Nedbank South Africa

Location: South Africa

Telephone: 0860 114 966

Websiteshttp://www.iveri.co.za/   | http://www.nedbank.co.za/

Email:

·        Technical Assistance operations@iveri.com

·        Non-technical requests/questions (e.g. costs, agreements, product information etc): info@iveri.co.za


Nedbank Namibia

Location: Namibia

Websiteshttp://www.iveri.co.za/   | http://www.nedbank.co.za/

Email:

·        Technical Assistance operations@iveri.com

·        Non-technical requests/questions (e.g. costs, agreements, product information etc): info@iveri.com 


I&M Bank

Location: Kenya

Websiteshttp://www.iveri.com/   | http://www.imbank.com/KE/ 

Email:

·        Technical Assistance operations@iveri.com

·        Non-technical i.e. product information: info@iveri.com 


CBZ Bank

Location:  Zimbabwe

Websiteshttp://www.iveri.com/   | http://www.cbzbank.co.zw/ 

Email:

·        Technical Assistance operations@iveri.com

·        Non-technical i.e. product information: info@iveri.com 


CSC and CSC24Seven Bank

Location:  Lebanon & Cyprus

Websiteshttp://www.iveri.com/   | http://www.cscgroup.com/ 

Email:

·        Technical Assistance operations@iveri.com

·        Non-technical i.e. product information: info@iveri.com 


CIM Finance 

Location:  Mauritius

Websiteshttp://www.iveri.com/   | http://www.cim.mu/ 

Email:

·        Technical Assistance operations@iveri.com

·        Non-technical i.e. product information: info@iveri.com