Other Transaction Types

Card validity check

Card Validity Check service also referred as "Card Account Status Check", allows the validity of the card to be checked. This transaction can be submitted using card chip data, magstripe data or card data manually entered, and has no financial impact on the card account.
It is always authorized online and force a decline of the transaction at offline only terminals. Supplementary amount or cashback amount is not allowed for this service.
Card Validity Check transcation is implemented using AcceptorAuthorisationRequest/Response containing:

TagDescription
Hdr/MsgFctnUse value 'AUTQ'
Tx/TxCaptrFalse
Tx/TxTpUse value 'VALC'
Tx/TxDtls/TtlAmtUse '0'
Tx/AddtlTxDataUse value '/request/token'
(in case token provisioning is also required along with account validation)

Mobile orders and telephones orders (MOTO)

Device operator will enter the card details as supplied by cardholder per mail or telephone on the terminal.

Mail order transactions are with Address and without CVD and implemented using AcceptorAuthorisationRequest/ Response containing following elements:

TagDescription
Cntxt/PmtCntxt/CardPresFalse
Cntxt/PmtCntxt/CrdhldrPresFalse
Cntxt/PmtCntxt/CardDataNtryMdPHYS
Cntxt/PmtCntxt/TxChanlUse value 'MAIL'
Envt/Crdhldr/BllgAdr/...Address of cardholder

Telephone Order transactions are with CVD and address details and implemented using AcceptorAuthorisationRequest/ Response containing following elements:

TagDescription
Cntxt/PmtCntxt/CardPresFalse
Cntxt/PmtCntxt/CrdhldrPresFalse
Cntxt/PmtCntxt/CardDataNtryMdPHYS
Cntxt/PmtCntxt/TxChanlUse value 'TLPH'
Envt/Crdhldr/Authntcn/AuthntcnMtdUse value 'CSCV'
(if CVD present)
Envt/Crdhldr/Authntcn/PrtctdAuthntcnValCard code value as BCD value, padded with trailing 'f's (e.g.: 123 => 0x123f)
The key used to encrypt is this, is the same as for the card-data. Also the encryption method is the same as for the card-data (TDES, padding).
Envt/Crdhldr/BllgAdr/...Address of cardholder

In AcceptorAuthorisationResponse for purchase, preauthorisation or card verification the Gateway will populate the tag TxRspn/TxVrfctnRslt/Mtd as CSCV and ADDB, and will populate the verification result in tag TxRspn/TxVrfctnRslt/Rslt.

Note:

Address is configurable (Optional or Mandatory) for Mail Order; Address and CVD are configurable (Optional or Mandatory) for Telephone Order transaction.

Manual keyed-in transaction

Use the same tags as for Mobile orders and telephone Orders (MOTO) but Cntxt/PmtCntxt/TxChanl should be absent.

Deferred payment

The nexo Deferred Payment is a service that allows the merchants to obtain an authorization for a maximum amount and to confirm a final amount lower or equal to the initial one after the delivery of goods. The mechanism is similar to a pre-authorization, followed by a completion, the difference being that the final confirmation is expected to be received on the same day as the initial authorization, or even within minutes, depending o the merchant type. Depending on the acquirer, the deferred payment may be presented by our gateway as a pre-authorization followed by a completion, or as a purchase followed by a partial reversal. For certain merchant categories, the delivery of goods is expected to be the most common scenario, so the Gateway will present the deferred payments to the card scheme as a purchase, and send a partial reversal only in case of exception scenarios. Please note that this transaction type is limited to automatic fuel dispensers and vending machines.

Deferred authorization

Deferred authorizations are authorization requests which occur when a terminal captures transaction information while connectivity is interrupted; the terminal holds the transaction until connectivity is restored. After connectivity is restored, the terminal sends the transaction for an online authorization request, and receives an authorization response from the issuer.

In order to make use of this feature our gateway expects an AcceptorAuthorisationRequest with one occurance of AddtlTxData with value '/DeferredAuth'.

Recurring transactions

The Gateway's Nexo API only supports the initialization if the first transaction in a recurring series. This transaction must include elements Tx/AddtlSvc with value 'RECP' and Tx/SvcAttr with value 'FREC'. The transaction must be performed with strong cardholder authentication - CHIP and PIN. It is expected that the subsequent transactions in the recurring series will be initiated on the eCom environment.


Want a quick overview?