Once the
PARes (Payment Authentication Result) value has been correctly decoded and either a successful 3D Authentication has occured or your 3D Secure Rulebase allows the transaction to continue for bank auhtorisation then the VSP authorisation service format a bank specific message and send the request to the Vendor's acquiring bank.
This bank authorisation process happens in real-time whilst the script on your server is waiting for a response from VSP Direct.
The bank authorisation process works on a
'3 Connection Attempt' (20 seconds per authorisation connection request) basis. This request is normally answered within two seconds with either an authorisation code or a declined message; However, at busy times of year, this process can take up to 60 seconds if 3 connection attempts are required (this is increasingly rare though). It is suggested that your payment session time is set to at least 61 seconds - after the 3 bank authorisation connection attempts our VSP authorisation services will give up and return a
'NOTAUTHED' value in the
Status field.
Depending on the response from the acquirer, VSP Direct prepares either a response POST back to the callback page - this will be an
'OK' response with an Authorisation Code, a
'NOTAUTHED' response if the bank declined the transaction or an
'ERROR' if something has gone wrong (you will very rarely receive these except during planned outages and upgrades).
If
AVS/CV2 checks are being performed, the results are compared to any rule bases you have set up (see the
AVS/CV2 Rulebase guide for more information). If the bank has authorised the transaction but the card has failed the AVS and/or CV2 rules you have established, Protx immediately reverse the authorisation on the card and prepare a
'REJECTED' response, returning the reason for the failure in the
StatusDetail field as well as the individual breakdown of the CV2, Billing Address and Billing Postcode results.
