Step 2: POSTING information to PROTX via HTTPS

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

In the previous step, we covered which values needed to be collected in order to successfully register a transaction. Now these values have been collected and formatted they must now be POSTed securely to Protx - to begin the transaction registration process.

As a Vendor, you have now, through the use of your shopping cart or the kit provided collected a number of values that are mandatory requirements to successfully register a transaction against the VSP System. Those values are set out clearly and distinctly in the Protocol guide and must be adhered to strictly if you wish to experience trouble free transactions.

Whether you collect those values on one page or over a number of pages is down to your discretion. You can pass those values around the script pages in the kit using the session and also hardcode consistent variables such as your Vendor name, if you wished to do so.

In the previous section you will have gathered and formatted the fields, you now need to prepare them to POST to Protx. Please see below an example of the 'vsp_purchase.asp' page where the neccessary transaction information Protx require is prepared. (please note, all example code is in ASP ONLY)

In this kit you will use the standard WinHTTP component to POST securely to Protx. This component should be built into the server you have your website and cart hosted on. Please remember that the POST must come from an IP address that you have registered with your Protx account, by adding it into the appropriate administration area. This is additional security, and Protx will ONLY accept POSTs from IP's that are explicitly declared by being added into your admin area or supplied during your application.

Please now see below an example of the 'vsp_purchase.asp' page which makes the POST via the WinHTTP component created in the above screenshot.

In the above you are declaring the POST destination as 'PurchaseURL' (see line 83). These URL's are declared and listed in your includes.asp file. You will have a number of URL's to choose from. Where you POST to will depend primarily on two things:

•   What the POST is trying to achieve
•   What 'mode' your Protx account is set to

By this, we mean that there are individual and specific URL's for the following:

•   A transaction REGISTRATION
•   A transaction REFUND
•   A transaction RELEASE
•   A transaction REPEAT

Furthermore, these URL's reside on either our TEST or LIVE servers and are broken down into:

•   The SIMULATOR server URL
•   The TEST server URL
•   The LIVE server URL

So, for example, to register a transaction on the LIVE server, you would use the Live purchase URL and NOT a refund URL on the test server.

The URL's are simply called upon and pulled out of the includes.asp file. You will notice the following in that file:

The three examples above specify the full URLs used for SIMULATOR, TEST and LIVE. It is important that in your includes.asp file you have the below code set to whatever is appropriate for your current situation:

SimulatorSite=1
TestSite=0
LiveSite=0

Be aware that by default you will NOT be Live, until the testing criteria has been met. This will include at least ONE transaction being processed via your website to your Protx test account and followed by at least ONE refund.


Once your transaction has been POSTed to the Protx 'Purchase URL', VSP Direct begins by validating its contents

It first checks to ensure all the required fields are present, and that their format is correct. If all fields are present and correct, the information in those fields are then validated. The Vendor name is checked against a pre-registered set of IP addresses, so VSP Direct can ensure the POST came from a recognised source. The currency of the transaction is validated against those accepted by your merchant accounts. The VendorTxCode is checked to ensure it has not been used before. If any details are not present or contain the wrong type of data, a reply with a Status of MALFORMED or INVALID is generated, with the StatusDetail field containing a human readable error message. This normally only happens in the development stage.


If the Transaction Registrations fail

There are many reasons to why you will see a failure on the transactions.

If there is a problem with the initial registration of the transaction Protx will return back either a Status of MALFORMED, INVALID or ERROR along with a StatusDetail with a human readable error message.

MALFORMED, INVALID or ERROR can be generated for a number of reasons, some examples are; the amount field being a non numerical type, you are passing over a currency type that is not setup on your account or you have not included your unique Vendor Name.

The below example shows a MALFORMED status of when a non numeric character is passed in the amount field;

Status=MALFORMED StausDetail=VRTXAmountNotNumeric

When an error like the example given occurs, you should communicate to the shopper that something is wrong and online purchases cannot be made at present.

At this point you will need to debug your script to why you are getting a MALFORMED or INVALID response back from Protx. If you are having difficulties into seeing why you are getting these responses you will first need to go to our troubleshooting section. Here you will find all related responses back from Protx if you have had issues with your POST to Protx, detailing what the response means and how to go out resolving it.

If you are having problems debugging your scripts, you can run a test against our 'show post' address. Due to the volume of transactions that go through our system, it is too difficult to debug a single Vendors transaction through the normal Purchase URL, so you need to change the Purchase URL to be the following, and submit a transaction.

https://ukvpstest.protx.com/showpost/showpost.asp

This will post your transaction to a page where we can see all the information you post to Protx during a single transaction. If you do this you will need to contact the Protx support team by phone (0845 111 4455) to let us know when you have sent the post through and be prepared to send another through should we request it.

You can also receive back from Protx a status of NOTAUTHED or REJECTED which would happen after the transaction has gone to the bank for authorisation. In the case of NOTAUTHED, the transaction has completed through the VSP System, but it has not been authorised by the bank. A status of REJECTED means the bank may have authorised the transaction but your own rulebase for AVS/CV2 or 3D-Secure caused the transaction to be rejected.

On all the above cases you should communicate to the shopper that something is wrong and online purchases cannot be made at present.