PINBlock encryption via Triple DES DUKPT encryption *
**
The DUKPT PINBlock encryption process flow is the following: A Device (with a DeviceSerialNumber and a DeviceMake) is injected in a Trusted Centre with an Initial PIN Encryption Key (IPEK) and Initial Key Serial Number (IKSN). Whenever a PIN block is required from the device, a counter is incremented, which indicates a PIN Encryption key. When performing a Debit with PIN, the PINBlock is sent encrypted using the PIN Encryption key, along with the current KeySerialNumber (which indicates the device and the current counter value).
Key Injection for DUKPT Mode Test *
There is one Test IKSN and IPEK that is public knowledge. When a Device is to be injected with the Test Device Master Key, it can be done either within the iVeri Test Loadi
Advanced Settings *
**
This section documents functionality within the iVeri Gateway that is not enabled by default. Contact your local distributor should you wish to activate one of these settings for your ApplicationIDMerchant Reference validity period See “Duplicate Transactions” (section 7.3.2) for a discussion of this option.
Recurring transaction checking *
See“Duplicate Transactions” (section 7.3.3) for a discussion of this option.
Recon Reference extraction *
ReconReference extraction setting is only available for the Nedbank https://distributor.an/ 8 digit ReconReference is sent from iVeri to the acquirer to uniquely identify a transaction. This number is used to query transaction information with the acquirer, and it may appear on the merchant reconciliation statement. By default
Mode: Test Vs Live *
**
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 a test environment. When the merchant is ready s/he can perform live transactions, which are routed to the genuine card issuer. merchant specifies the mode of a transaction by setting Mode as “Test” or “Live” and sends their corresponding Test or Live ApplicationID.
Sending the following card numbers to the Test environment has the following results:
PAN
Result
4242424242424242
returns "Authorised"
2121212121212121
randomly returns "Hot
Card", "Please Call" or "Denied"
5454545454545454
randomly returns "Unable
to process" or times out
All other card numbers
(eg "1111222233334
Payment Mechanisms: Pan Vs Track2 Vs Pin *
**
iVeri Gateway separates accounts into 3 different payment mechanisms:
PAN Track2 PIN
To process a transaction with an account you need to know which payment mechanism you are going to use
/Note /*that independent of the payment mechanism is used, the iVeri Gateway returns a dotted out “PAN” which can be used for display purposes.
PAN (also known as “Card Not Present” or “Keyed”) *
The Primary Account Number (PAN) is given by the card holder to the merchant.
Either the card is not present with the Merchant, or the Merchant does not have a card reader to “swipe” the card.
The account can be any card that has the PAN embossed or printed on the card but does not require a PIN.
Mandatory Input Parameters: PAN, ExpiryDate.
Optional Input Parameters:
Transaction Terminology *
**
An iVeri transaction is the combination of a transaction request (command: Authorisation, AuthorisationReversal, Debit, Credit, Void), and its corresponding response. A transaction sequence relates to the complete set of movement of goods and services and can include many related transactions.
An iVeri transaction involves communication between the following players:
Card Holder .>Merchant > iVeri Gateway > Acquirer > Association > Issuer
Unique Identifiers *
The players in an iVeri transaction generate the following fields to identify an individual transaction
Player
Individual
transaction identifier
Merchant
Merchant Trace
iVeri Gateway
RequestID
Acquirer *
Acquirer Reference *
The players in an iVeri transaction generate the following fields to identify a t
Specialized Techniques *
**
Ping *
The Ping command is primarily used to determine if the connection between the Merchant and the Acquirer is down. If the connection is down, then a Ping can be used to poll the iVeri Gateway to see when the status is back up.
The Ping command checks that:
the merchant is communicating with the iVeri Gateway, and the merchant configuration is active, and the iVeri Gateway is online, and the iVeri Gateway is communicating with the acquirer.
This is different to checking network connectivity to the iVeri Gateway, where a network ping should be employed. The Ping takes an ApplicationID as a mandatory input parameter and is sometimes referred to as an ApplicationID Ping. As mentioned previously, an iVeri transaction involves communication between the following
Duplicate transactions *
**
A problem of a duplicate transaction can occur if a merchant submits a previously successful transaction in a new request. A duplicate transaction of this nature is typically due to a user's unintentional mistake, e.g. pressing the “Submit” button twice, or submitting the same batch twice. It is responsibility of the merchant to ensure that a single transaction request is not submitted successfully more than once.
Nevertheless, the iVeri Gateway provides three mechanisms to protect against duplicate transactions. Specifying a unique MerchantTrace is a client-side configuration, while the latter to require contacting your local distributor.
Specify a unique Merchant Trace for each step in a Transaction Sequence *
As mentioned in section 8.2, a MerchantTrace is a
Individual transactions *
**
Void *
A “Void” of a previous transaction request is a command to ignore (i.e. cancel the effects of) a previous (recently submitted) transaction request. When a merchant receives a successful response for a transaction request, and thereafter “something goes wrong”, then the Merchant has the option to “void” the transaction.
Examples of “something goes wrong” are:
communications error between merchant and cardholder printer could not print the invoice problem accessing merchant database
A merchant can also call “void” when s/he does not know whether a response was received from the iVeri Gateway (for example a power failure). A successful void (cancellation) typically results in the transaction not being shown on the merchant nor the cardholders’ statements.Tr
Online vs. Offline Transactions *
**
When a Merchant submits an Online Transaction, s/he expects a response while the card holder is waiting. An Online Transaction can be a Card Present or a Card Not Present transaction. The result of such a transaction needs to be responded to as soon as possible. When a Merchant submits an Offline Transaction (typically with Batch of Transactions), the merchant requires a response for the transaction within the immediate future. The time frame of such transactions is they should preferably be settled before the current cycle cut off. A Batch Transaction can only be a Card Not Present transaction. PIN based cards can only be processed within online transactions. (It is possible for the card holder's chip card to verify the card holder's PIN locally at the
Card Present vs. Card Not Present *
**
A Merchant interfaces with a card holder and submits a Card Present Transaction request whilst the card holder is waiting, and the card holder authenticates the transaction (typically via signature or PIN entry). In the event of a dispute of the transaction, the merchant must prove that the card holder authorized it, else merchant is liable to refund the card holder.
A Merchant submits a Card Not Present Transaction according to previously arranged agreement with a card holder. The card holder is not present to authenticate the transaction. In the event of a dispute on the transaction, the merchant must prove the card holder authorized it, else the merchant is liable for refunding the card holder.
Fully 3D Secure transactions are Card not present tran