The Gateway Domain Knowledge

 The purpose of this section is to give some domain knowledge to people not familiar with the payment domain.

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 transactions with the protection of a Card present transaction.

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 acceptance device, using the on-board cryptography of the card and the PED).

Online Transactions

In an Online Transaction the transfer of goods and services is ready to take place directly after the approval. No approval means no transfer of goods and services.

A Merchant interfaces with a card holder and submits an Online Transaction request whilst the card holder is waiting for the response.

• If the transaction request is approved, there is a transfer of goods or services.

• If the transaction request is denied, then either the proposed exchange of goods and services is aborted, a parameter (e.g. amount or expiry date) is changed and the transaction retried, or a different payment channel is used.

• If the transaction experiences an error, then the transaction is retried as long as the card holder is prepared to wait. Thereafter the transaction details are assessed if either it should be done offline or the proposed transfer of goods and services be aborted.

Offline Transactions

PIN based cards can therefore not be included in offline transactions.

An Offline Transaction is submitted when either the transfer of goods and services have already taken place, or the transfer of goods and services is not a once off transfer that takes place immediately (e.g. a repetitive / continuous service).

A Merchant submits a set of offline transactions (via iVeri Enterprise or iVeri Batch) according to previously (implied) arranged agreement with a card holder.

A Merchant interfaces with a card holder. An offline transaction is initiated after one of the following occurs:

• a repetitive transaction (e.g. monthly bill) is agreed to, either in advance or in arrears

• (Store and Forward): the transaction details are below a floor limit, pass hot card and black card checking, and therefore the merchant decides to take the risk of transferring the goods and services without guaranteed payment, since either:

  • it is outweighed by the cost of going online (time or money is not worth it), or

  • an online transaction was attempted but experienced an error.

• there was a problem when the transaction was attempted online.

If the transaction request is:

• approved, the merchant gets paid.

• denied, then if the transfer of goods and services has occurred, the merchant can consider contacting the card holder, think about revising their offline business rules, or contact a debt collector.

• in error, then the transaction is retried until it is in a known state.