Welcome to the VSP Direct Custom Integration guide. This section has been designed to aid the intermediate / experienced web developer integrate an 'E-Commerce' website with our Protx VSP Direct solution. This section has been designed to be used in conjunction with the VSP Direct Protocol and Integration guide, which can be downloaded here.

Please see below a basic diagram of the VSP Direct process which should provide a quick understanding of which roles are played by the various parties involved in a VSP Direct transaction.

This guide has been broken down into logical, managable steps. These are briefly discussed below in the "How does VSP Direct work?" section, however each step is actually discussed in greater detail by clicking the associated button which is present at each interval.

VSP (Veri Secure Payment) is a method of passing details, in this case credit card and transaction related details, from your website/server to Protx, in order to obtain authorisation on those details.

VSP Direct is designed to enable you to take card details on your own secure servers and pass them across to us for authorisation and secure storage in a server-to-server session that does not involve redirecting the shopper to the Protx payment pages. This enables you to white-label the payment process. Your shopper never leaves your site and they do not necessarily know that Protx is authorising the transaction on your behalf, although in practice many vendors choose to tell their shoppers in case they have concerns about card security.

To use VSP Direct you will need a 128-bit SSL certificate to secure your payment pages. These can be obtained from a number of sources including VeriSign and Thawte.

You will also need to be able to make HTTPS POSTs from scripts on your server (using something like OpenSSL on Linux platforms, or the WinHTTP object in Win32). If you are hosting with a third party company we recommend you talk to them about these requirements before committing to use VSP Direct. If you cannot install a certificate for your payment pages, we would recommend using VSP Server instead. If you cannot perform HTTPS POSTs from your scripts, we would recommend VSP Form.

Recently Visa, MasterCard and other major card schemes have introduced security audits to ensure that all merchants who collect credit card data comply with strict guidelines surrounding the collection and storage of credit card data.

VSP Direct vendors collect credit card data on their own website and will be asked by their bank to undergo an audit to ensure that data is kept secure at all times.

Alternatively, if you do not wish to undergo such an audit, then you can outsource the collection of credit card data to Protx, by using VSP Form or VSP Server.

Custom integration means that you will not be using a 'shopping cart' solution and that the link between your website and Protx will be built either from scratch or using the Protx provided script kits, or a combination of both.

A Custom integration allows you the power to create a flexible and bespoke cart solution which would not apply the restrictions that a shopping cart may have. This means that you can choose which values you collect on your website, the way in which you collect those values and also the way in which you pass them to Protx. Importantly, as with all Protx products, you must meet and adhere to the latest Protx Protocol, in this case 2.22.

Protx are able to supply packages referred to as 'kits'. These kits vary depending on the language and the Protx product you are downloading the kit for, be it VSP Form, VSP Direct or VSP Server.

The kits contain a number of script pages, in various programming languages that allow you to connect your website with Protx and are written by Protx developers to correctly format and send the information Protx require for registering a transaction. It is not recommended to use one of our kits or to perform a custom integration if you do not have some level of web development experience.

Please refer the readme file within the kit for definitions and explanations of the files within the kit, and their purpose.

Step 1: Collecting and Formatting the information to POST to Protx

A shopper visits your site, selects a product or series of products from your web catalogue. They can select products from a drop down menu, a tick system or radio buttons - or any other method you desire. This part of the process is entirely up to you and there are no limitations set by VSP Direct. Remember, VSP Direct is only the method in which you pass the data to Protx, not the method in which you collect it.

Step 2: POSTING information to PROTX via HTTPS

The first set of details collected about your shopper and their orders are POSTed to Protx for the values to be validated. This means that Protx, before passing these values anywhere, will ensure that you have passed them in the correct format. Refer to the protocol guide to see what format these values should be passed in. If, for example, you pass a currency of more than 3 characters - or a VendorTxCode over 40 characters - Protx will return a reply to your server to let you know that the transaction will not go ahead, until the values are passed correctly. This status is referred to as 'Malformed'.

Step 3: VSP Direct and Protx MPI check 3D-Secure status (3D Secure Authentication ONLY)

Once you have posted the transaction to Protx, VSP Direct will validate the values to ensure that they have been entered correctly and that they are valid. If they are valid, 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" 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

Step 4: VSP Direct replies to your registration POST (3D Secure Authentication ONLY)

VSP Direct stores all the information from your transaction registration POST in the Protx secure database before replying to that POST with 6 fields (see VSP Direct Protocol and Integration guide).

Step 5: You redirect your shopper to their Issuing Bank for 3D Secure Authentication (3D Secure Authentication ONLY)

The registration page code on your server should check the Status field, and when a 3DAUTH status is found, build a simple, auto-submitting form which sends additional information (see Step 4), to the address specified in the ACSURL, and send this form to your shopper's browser.

Step 6: 3D-Authentication is carried out and your website called back with the results
             (3D Secure Authentication ONLY)

Your shopper completes the 3D-authentication process at their Issuing Bank's web site. Once complete (either successfully or not), the bank will redirect your shopper back to the page supplied in the 'TermURL' field you sent in step 5 above.

Step 7: Your site POSTs the 3D-Secure results to Protx (3D Secure Authentication ONLY)

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. This POST needs to contain the MD and PARes fields sent back to your site by the shopper's Issuing Bank.

Step 8: VSP Direct requests card authorisation

The VSP authorisation service then formats a bank specific message and sends the request to the Vendor's acquiring bank.This process happens in real-time whilst the script on your server is waiting for a response from VSP Direct. The request is normally answered within two seconds with either an authorisation code, or a failure message (at busy times of year, this process can take up to 60 seconds, but that is increasingly rare).

Step 9: PROTX reply to the payment registration POST

Irrespective of the status being returned, VSP Direct always replies in the response section of the POST that your server sent to us. This will either be in response to the transaction registration POST for non-3D-authenticated transactions, or in the response to the Terminal URL POST if 3D-Authentication was attempted.