3D Secure *
**
3D secure is an XML-based security protocol for online credit and debit card transactions. 3D Secure adds an authentication step for online payments, making it possible for cardholders to authenticate their online transactions with their card issuers, using a password or OTP.
Benefits of using 3D secure *
Reduces fraudulent debit & credit card transactions processed through online platforms Gives the merchants and acquiring bank liability protection
3D secure providers *
CyberSource Bankserve
3D secure with iVeri *
High: 3D secure – If a merchant is deemed high risk, the acquiring bank can set merchants on this level. Merchants that want lowest possible risk can also opt for this level. Medium: 3D secure/attempted- This option gives merchants a broader reach in the cards the
An action corresponds to the combination of a payment mechanism and a command. The concept of an action is used within the documentation and examples as a means of describing functionality. The Enterprise API and iVeri Gateway use the concepts payment mechanism and command instead of Action.
The iVeri Gateway allows for the following actions:
Authorisation with PAN
Reserve
funds when a card is not present.
This
action is commonly known as a "Pre-Auth/Pre-Authorisation"
Authorisation with Track2
Reserve
funds when a card is present. Funds reservation is not applicable for cards requiring
a PIN.
This action is commonly known
as a "Pre-Auth/Pre-Authorisation"
Authorisation with
VisaCheckoutCallID
Reserve
funds when a card is present. Funds reservation is not applicable for cards
requiring a P
An action corresponds to the combination of a payment mechanism and a command. The concept of an action is used within the documentation and examples as a means of describing functionality. The Enterprise API and iVeri Gateway use the concepts payment mechanism and command instead of Action.
The iVeri Gateway allows for the following actions:
Authorisation with PAN
Reserve
funds when a card is not present.
This
action is commonly known as a "Pre-Auth/Pre-Authorisation"
Authorisation with Track2
Reserve
funds when a card is present. Funds reservation is not applicable for cards requiring
a PIN.
This action is commonly known
as a "Pre-Auth/Pre-Authorisation"
Authorisation with
VisaCheckoutCallID
Reserve
funds when a card is present. Funds reservation is not applicable for cards
requiring a P
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 ShipFromZIPC
Now that we have a grasp of the process and the parameters required for a new BIN request, let's delve into the process of amending or updating an existing BIN.
Navigation Path:*
From the main menu select:
Systems > iVeriDB BIN > Local BIN*
1. Capture the BIN number in the search bar provider. Run the search.
The information related to the BIN will populate.
2. To amend the BIN, select the ‘Edit’ tab.
3. The general information tab will populate with information relating to the BIN.
Since this is an existing BIN you are amending or updating, the BIN number cannot be edited, which is why it appears greyed out.
Update and amend the applicable parameters based on the requested amendments or updates.
The most common parameters that are requested to be amended are ‘Card Number Length’ and ‘Car
Appendix A *
**
The prompts are specific to devices so depending on which devices are attached to the Indigo server will determine which prompts are used. These prompts are, in general, loaded onto the device at initialisation so if this has not been done then prompts will not be supported. There is a hardcoded default prompt so that if the Index used from the list below does not happen to be loaded on the device or does not exist on the device then this prompt will be used as a generic request for data to be entered.
Appendix B – QA Environment for Development and Certification *
**
During the development and certification phases of an integration project the Indigo server will be located within iVeri's QA environment and a Merchant Profile for the Integrator performing the integration must be created on iVeri's QA Gateway as well as on the iVeri QA Indigo Server and the resulting credentials distributed to the Integrator. This must be performed by iVeri Support who can be contacted at assist@iveri.com. Please make sure in all communication with Support that they must deal with QA Indigo and the QA Gateway.
Network wise, the Integrator must ensure that the POS/Till system which will be communicating to the Indigo server using the Generic POS Channel protocol has outbound internet access to the iVeri QA
Appendix C – Test Plan *
**
The purpose of the following section is to validate the implementation of the Generic POS Channel protocol for the transaction sets chosen by the Integrator. An Integrator may choose to only implement a subset of all the Test Cases (1, 2, 3, 4 and 5) below but, having chosen a Test Case, all sub Test Cases and the transaction types applicable to these Test Case must be performed. By way of example, if an Integrator only wants to perform Debits then only Test Case 3 comprising 3.0, 3.1, 3.2, 3.3 and 3.4 need to be tested and logs for these submitted. In this case logs for 3.0a, 3.1a, 3.1b, 3.2a, 3.3a, 3.3b, and 3.4a would need to be submitted.
Integrators should keep logs of all requests sent to the Indigo Server as well as the responses received and the data and