Step 7: Your site POSTs the 3D-Secure results to Protx

(N.B: ALL code examples and references to integration kit files within this document are related
to the ASP kit ONLY. To download kits in other languages please visit the Downloads page.)

The code in your call back page formats a simple HTTPS, server-side POST, which it sends to the Protx VSP Direct 3D-Callback page - the Protx VSP Direct 3D-Callback page is defined in the 'includes.asp' file (screenshot shown below).

This POST needs to contain the MD and PARes (Payment Authentication Result) fields sent back to your site by the shopper's Issuing Bank.

No other information is necessary because the Protx system can use the MD value (which uniquely identifies the 3D Secure Transaction) to retrieve all the other transaction information (VendorTxCode, VendorName, Amount, etc) you originally supplied in Step 2: POSTING information to PROTX via HTTPS

Please see below, the example of the 'callback.asp' page (present in the standard ASP VSP Direct Integration Kit) which makes this server-side POST to Protx and provides the PARes (Payment Authentication Result) value from the Shopper's 3D Authentication process with their Issuing Bank.

Once Protx VSP Direct has recieved the server-side POST, it marries up the MD value with the original transaction data and proceeds to decode the PARes (Payment Authentication Result) to determine the outcome from the 3D-Authentication.

If the decoded PARes indicates that the 3D-Authentication was successful, Protx VSP Direct goes on to obtain a bank authorisation (see Step 8: VSP Direct requests card authorisation). If decoded PARes value indicates a failure or error then the Protx VSP Direct system examines your 3D-Secure rule base to determine whether bank authorisation should be attempted (this will be the same process that occurs when the Protx MPI checks the Visa / Mastercard directories in Step 3: VSP Direct and Protx MPI check 3D-Secure status). By default 3D-Authentication failures are NOT sent for authorisation, but all other message types are. Refer to the rulebase guides for more information about using 3D-Secure Rulebases and AVS/CV2 Rulebases.

Transactions that are not sent for bank authorisation are returned to your callback page with a 'REJECTED' status where they can be handled accordingly.