Tokenization
New COF Indicators
The iVeri Gateway, in collaboration with Nedbank, has introduced enhanced indicators to explicitly identify whether a transaction is initiated by the cardholder or the merchant, along with the applicable payment types.
These changes define specific transaction scenarios, each with corresponding parameters and merchant profile configurations that must be correctly set.
CIT - COF
Scenario 1 – Cardholder Initiated, Ecommerce Transactions
These are adhoc ecommerce transactions initiated by the customer, typically using tokenized payment credentials.
| Parameter & Values | Scenario and Conditions |
| CardHolderPresence: CIT, COF, SecureChannel | CIT: Cardholder-initiated transaction |
| SecureChannel: Ecommerce transaction without any 3D secure authentication data | |
| COF: Credential On File (Where tokenized data is used) | |
| Merchant Profile Configuration | |
| No configuration requirements | |
| CardHolderPresence: CIT,
COF 3D secure 2 Parameters |
CIT: Cardholder-initiated transaction |
| COF: Credential on File (Where tokenized data is used) | |
| Merchant Profile Configuration | |
| 3D secure must be enabled, and triggered by the merchant |
MIT - COF
Scenario 2 –Merchant Initiated, Recurring Transactions
These include recurring or adhoc transactions initiated by the merchant, often using tokenized credentials for periodic payments or unscheduled charges.
| Parameter & Values | Scenario and Conditions |
| CardHolderPresence: MIT, COF, Recurring, SecureChannel | MIT: Merchant initiated transaction |
| COF: Credential on File (Where tokenized data is used) | |
| Recurring: Recurring Payment | |
SecureChannel: Ecommerce transaction without any 3D secure authentication data | |
| Merchant Profile Configuration | |
| Recurring must be enabled | |
| CardHolderPresence: MIT, COF, SecureChannel |
MIT: Merchant-initiated, adhoc transaction where tokenized data is used |
| COF: Credential on File (Where tokenized data is used) | |
SecureChannel: Ecommerce transaction without any 3D secure authentication data | |
| Merchant Profile Configuration | |
| No configuration requirements |
Legacy Card on File
This section applies to transactions that are first initiated by the cardholder where 3D secure is enforced, whereafter monthly debits can be processed by the merchant. The same principle may be applied for the Batch (product) recurring transactions, even though in the below example we have used a second Enterprise application ID which is not 3DS enforced.
COF & 3D Secure
First 3DS Transaction
Scenario – Cardholder initiated transaction with 3D Secure elements
|
Parameter & Values
|
Scenario and Conditions
|
|
Debit with PAN
PAN: ExpiryDate:
|
Process a transaction by setting and providing the full card details. Merchant Profile Configuration 3D secure must be enabled |
|
Debit with TransactionIndex
CardHolderPresence": "COF” PANFormat PAN: ExpiryDate: TransactionIndex
|
Process a COF transactions by setting the PANFormat and “Sanitised/tokenised card details Merchant Profile Configuration 3D secure must be enabled |
The gateway will return the TransactionIndex, masked PAN and Expiry Date, which you will need to store in your database. The following field response values should be stored on your database, linked to the card holder details.
- TransactionIndex
- PAN
- ExpiryDate
COF & MOTO
First Transaction
When performing your first transaction using application id: 00000000-263b-4315-b2cd-000000000000, the following options are available:
Scenario: Cardholder initiated or merchant-initiated MOTO use case
|
Parameter & Value |
Scenario & Condition |
|
Debit with PAN CardHolderPresence": “MOTO, Securechannel” PAN: ExpiryDate |
Process transactions by setting CardHolderPrense to MOTO” and providing the full card details
Merchant Configuration None required
|
|
Debit with TransactionIndex CardHolderPresence": "COF, MOTO” PANFormat PAN: ExpiryDate: TransactionIndex
|
Process a card of file (COF) transactions by setting the PANFormat and “Sanitised/tokenised card details Along with CarHolderPresence with COF and MOTO Merchant Application Configuration None required
|
The gateway will return the TransactionIndex, masked PAN and Expiry Date, which you will need to store in your database. The following field response values should be stored on your database, linked to the card holder details.
- TransactionIndex
- PAN
- ExpiryDate
COF & Recurring
When processing recurring payments, the merchant should use two application IDs - one for handling initial cardholder-initiated transactions, and the other for managing recurring payments initiated by the merchant.
First Transaction
Scenario – Cardholder Initiate transaction where 3D secure maybe triggered or without
|
Parameter & Value |
Scenario & Condition |
|
Debit with PAN PAN: ExpiryDate
|
First transaction that is cardholder initiated. This transaction can be 3D secure enforced or without. Merchant Configuration If the merchant triggers 3D secure ApplicationID must be enabled for 3DS, otherwise merchant must set CardHolderPresence to “Securechannel”
|
|
Debit TransactionIndex
CardHolderPresence: “COF,” PAN: first 4, last 4 of the card ExpiryDate
|
Cardholder initiated transactions with tokenized data Merchant Configuration
|
The following field response values need to be stored on your database, linked to the card holder details.
- TransactionIndex
- PAN
- ExpiryDate
Subsequent Recurring Transaction Message
In the sample below "CardHolderPresence" is set by the merchant on the Debit instruction:
REST
SOAP
Network Tokens
What is Tokenisation?
Tokenization is a process in which the customers sensitive card information is replaced by a unique identifier ("token") which can be used to make online payments.
What are Network Tokens?
Card Networks like Visa, Mastercard offer tokenization services, where the card network holds the card number (PAN) and replaces with a network token which can be used to effect online payments.
Benefits of Network Tokens
- Seamless checkout experience and reduced customer friction as the payment token is carried across the payment ecosystem
- Reduces transaction failures attributed to expired or stolen cards
iVeri Gateway Token Vs Network Token
- Network Tokens - Merchants or Payment Service Providers can do a direct integration for tokenization services with the card networks and only make use of the network token during payment instruction to the iVeri Gateway
- iVeri Tokens - Merchants processing iVeri tokenised transactions can be enabled for network tokens, the iVeri Gateway will manage the tokenRequest onbehalf of the merchant to the brand networks.
Use Cases
- Online, ecommerce merchants where card acceptance is processed on web or mobile applications
- Where merchants have customer profiles, along with card on file payment credentials
Network Token Flows
Network Token Parameters - Auth/Debit to the Gateway
|
Non 3D Secure Transactions |
3D Secure Transactions |
Comments |
|
PAN = “Token” |
PAN = “Token” |
As returned by the network scheme |
|
ExpiryDate= “expiry date” |
ExpiryDate= “expiry date” |
As returned by the network scheme |
|
CardHolderAuthenticationID = “TAVV”
|
CardHolderAuthenticationID = “XID”
|
TAVV as returned by the network scheme for non-3D secure transactions, while for 3D secure the XID value should be passed( if available) As a note, from an acquirer perspective, and with Visa Tokens, there is only one field that can handle the XID and TAVV values. In a nutshell, the merchant can either process a 3D secure transaction or Non-3Dsecure transaction. One transaction cannot carry both values at the same time. |
|
ElectronicCommerceIndicator = “SecureChannel”
|
ElectronicCommerceIndicator = “ ECI "
|
For 3D secure transactions, existing ECI's should be passed
For non 3D secure transactions - only ECI value "SecureChannel" should used |
|
CardHolderPresence =” COF, SecureChannel” |
CardHolderPresence ="COF" |
Expected when Non-3D/3D secure transactions are processed. |
|
|
CardHolderAuthenticationData |
For 3D secure transaction, the CardholderAuthenticationData ("CAVV") should be included in the Auth/Debit as is to-date |
The following table outlines applicable parameters when 3D secure or non 3D secure transactions are processed to the iVeri Gateway.
To note, all existing parameters that are applicable for 3D secure transactions remain unchanged. To add, merchants that do not support card on file payment credentials with their customers can still continue to accept and process payments using full card details.
iVeri Token Flows
iVeri Token Parameters - Auth/Debit to the Gateway
The following table outlines applicable parameters when 3D secure or non 3D secure transactions are processed to the iVeri Gateway.
|
Non 3D Secure |
3D secure |
Comments |
|
|
PAN = “first 4 last 4” |
PAN = “first 4 last 4” |
As returned by the iVeri Gateway on the initial transaction or token response |
|
|
ExpiryDate= “expiry date” |
ExpiryDate= “expirydate” |
|
|
|
PANFormat = “TransactionIndex” |
” PANFormat =“TransactionIndex” |
|
|
|
TransactionIndex = iVeri Token (“TransactionIndexValue”) |
TransactionIndex = ” iVeri Token (“TransactionIndexValue”)
|
As returned by the iVeri Gateway |
|
|
|
CardHolderAuthenticationID = “XID value ”
|
If available, should be included on the Auth/Debit for 3D Secure authenticated transactions |
|
|
|
ElectronicCommerceIndicator = “ ECI " |
For 3D secure transactions, existing ECI's should be passed
For non 3D secure transactions - only ECI value "SecureChannel" should used
|
|
|
|
CardHolderAuthenticationData = "CardHolderAuthenticationData" |
For 3D secure transaction, the CardholderAuthenticationData ("CAVV") should be included in the Auth/Debit as is to-date |
|
|
CardHolderPresence= "COF" |
CardHolderPresence= "COF" |
|
For additional uses cases where tokens can be used, refer to the Card On File - Recurring/Adhoc section.