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

This guide has been broken down into logical, manageable steps. These are briefly discussed below in the "How does VSP Server 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.

The backbone of VSP Server is a secure HTTPS POST from your web server to the Protx Test or Live servers, followed by a callback. VSP Server is arguably the most secure of Protx solutions, combining the security of HTTPS POST with other anti-fraud features like security key matching using an MD5 Hashing algorithm. This means that the security key (numeric) Protx pass to you must match with that which you store on record from the beginning of the transaction, ensuring that no tampering has taken place. This, combined with the fact that VSP Server will only work using HTTPS POSTs from an agreed source, means that it is an incredibly secure solution.

The benefits of VSP Server are primarily due to the advanced database compatibility it offers. This means you can store more information, and in fact, using VSP Server we would EXPECT you to store more information about a transaction, such as; amount, products selected, shopper's details and the result of authorisation provided by Protx.

The end result of doing this is that you do not have to rely on the Protx admin area. You can have your own customised reporting area and view everything from your end. You can also use the information within the database to send remote requests for refunds and repeats (see payment types). Unlike VSP Form where there is a reliance on logging into the VSP Admin area to perform refunds and repeat/releases in ALL circumstances, VSP Server, with some additional coding, will allow you to push a button on your own software which will send a request to have a transaction refunded, for example.

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 the above.

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. To download an integration kit please click here.

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 to 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, 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 Server. Remember, VSP Server 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

Once you have collected the necessary information about your Shopper, their orders need to be POSTed to Protx for the values to be parsed. This means that Protx, before passing these values anywhere, will ensure that you have passed them in the correct format. Refer to the VSP Server Protocol and Integration 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', for obvious reasons.

Step 3: Protx reply to the Vendor's POST, Shopper is redirected to Payment page and               Bank Authorisation occurs

If the values you have passed to Protx are formatted correctly and are valid then Protx will respond with an OK message, a security key (10 digit number) and a VPSTxID (unique Protx generated transaction code) as well as a website URL so that you can forward the shopper onto a Protx payment page.

The Shopper is now on the payment page and they are given the opportunity to enter their credit card details. After the details are entered, VSP Server will pass the values to ensure that they have been entered correctly and that they are valid. If they are valid, the Shopper is passed to a screen where they are given one last chance to abort the transaction.

Protx now use the details entered and approaches the acquiring bank, via our secure connection. We then obtain an authorisation or a decline message from the acquiring bank.

Step 4: An HTTPS POST to the NotificationURL

Protx now responds to your Notification URL with the result of the transaction as well as other transaction details. At this point you can check the security key returned to see if it matches with that on your database - thus ensuring the transaction has not been tampered with.

Step 5: Notification URL responds back with information to complete the transaction

Your notification URL will then make a final response to Protx with a 'Status=OK' and a 'RedirectURL'. The status is to let us know that all information has been received and that we can consider the transaction completed. If we do not receive this status, we will assume your server is unreachable and force an abort on the transaction.

Protx then uses the returned RedirectURL to pass the shopper back to your website, to whichever page you dictate. This page will then display a relevant message to the Shopper to thank them for their trade or if an error/invalid status is returned to your notification URL then the RedirectURL will provide a message asking the Shopper to contact Protx or the website.