Other Transaction Types

Card validity check

Documentation has been moved to a dedicated page in out Developer Portal. Please see: link

Mobile orders and telephones orders (MOTO)

Documentation has been moved to a dedicated page in our Developer Portal. Please see: link

Manual keyed-in transaction

TagDescription
Cntxt/PmtCntxt/CardPresfalse
Cntxt/PmtCntxt/CrdhldrPrestrue
Cntxt/PmtCntxt/CardDataNtryMdPHYS
Cntxt/PmtCntxt/TxChanlnot present
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/...not present

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.


Did this page help you?
Want a quick overview?