Card Validity Check service also referred as "Card Account Status Check" transaction, allows the validity of the card to be checked. This transaction can be submitted using Chip card, Magstripe swipe, manual entry mode and has no financial impact on the card account.
It 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:
|Use value 'AUTQ'|
|Use value 'VALC'|
|Use value '/request/token'|
(in case token provisioning is also required along with account validation)
Device operator will enter the card details as supplied by cardholder to merchant as per mail order form or telephone.
Mail order transactions are with Address and without CVD and implemented using AcceptorAuthorisationRequest/ Response containing following elements:
|Use value 'MAIL'|
|Address of cardholder|
Telephone Order transactions are with CVD and address details and implemented using AcceptorAuthorisationRequest/ Response containing following elements:
|Use value 'TLPH'|
|Use value 'CSCV'|
(if CVD present)
|Address of cardholder|
In AcceptorAuthorisationResponse for Purchase, Pre-Authorization or Card Verification our gateway will populate the tag
TxRspn/TxVrfctnRslt/Mtd as CSCV and ADDB, and will populate the verification result in tag
Address is configurable (Optional or Mandatory) for Mail Order, Address and CVD are configurable (Optional or Mandatory) for Telephone Order transaction.
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 Fiserv will present the deferred payments to the card scheme as a purchase, and send a partial reversal only in case of exception scenarios.
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'.
First Data's Card Present product only supports initiating the first transaction in a recurring series on the POI. 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.
Updated about 2 months ago