Step 3: VSP Direct and Protx MPI check 3D-Secure status

(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.)

VSP Direct contacts 3D-Secure Directory Servers


If you have posted the transaction registration to Protx with the 'Apply3DSecure' flag populated (see Appendix A1 : Payment Registration Protocol) or 3D Secure is "Switched On" via your VSP Admin account (see our 3D Secure section), VSP Direct will send the card details you provided in the post to the Protx 3D-Secure Merchant Plug-In (MPI). The plug-in will format a request called a VEReq (Verification Request) which is then sent to the 3D-Secure directory services to query whether the card and card issuer are part of the 3D-secure scheme.

The Visa / Mastercard 3D-Secure directory then looks to see whether the card details provided exist in the directory and formulates an appropriate response message to the Protx 3D-Secure Merchant Plug-In (MPI) - this is called the VERes (Verification Result).


What happens with the response from the 3D-Secure Directory


If the card details provided are valid for 3D Secure Authentication and 3D Secure is "Switched On" then the appropriate response POST is returned to the Venodor's 'vsp_purchase.asp' page (please see Step 4: VSP Direct replies to your registration POST)

If the card or the issuer is not part of the scheme, or if an MPI (Protx 3D-Secure Merchant Plug-In) error occurs, VSP Direct will check your 3D-Secure rule base to determine if authentication should occur. By default you will not have a rule base established and transactions that are not, or cannot, be 3D-authenticated will still be forwarded to your acquiring bank for authorisation. (please see example screenshot of this rule base below)

If you do have a rule base, the value of the transaction and the AllowCardNotInScheme, AllowIssuerNotInScheme and AllowMPIErrors flags will determine if authorisation should be attempted.

In the example below, the rulebase will allow for both, a card not being part of the 3D scheme or the card issuer not being part of the scheme. It will NOT allow for a MPI failure.

If your rulebase rejects the transaction due to your criteria not being reached, VSP Direct replies with Status of REJECTED and StatusDetail indicating why. The 3DSecureStatus field will contain the results of the 3D-Secure lookup. REJECTED transactions will never be authorised and the shopper's card never charged, so your code should redirect your shopper to an order failure page, explaining why the transaction was failed.

If your rule base DOES allow authorisation to occur for non-3D-authenticated transactions, VSP Direct continues as though 3D-Secure is not active on your account. Jump ahead to Step 8: VSP Direct requests card authorisation in these circumstances for the authorisation stage.

If the card and the card issuer are both part of the scheme, VSP Direct will reply to your POST which is covered in Step 4: VSP Direct replies to your registration POST.