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

(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 this section you will see how Protx handles the response on receipt of your POST and how VSP Server begins validating the contents.

The Vendor's transaction POST is first checked 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 VSP Vendor name is checked against a pre-registered set of IP addresses, so VSP Server can ensure the POST came from a recognised source. The currency of the transaction is validated against those accepted by your internet 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.

The below screen shot shows a section of code from the ASP Server kit. This particular section relates to the VPS order Purchase file, this particular section of code is at the point of where you are about to POST the details over to the Protx VSP Server to be validated.

N.B: This example is in ASP only. For other VSP Server Kit languages please go to our Downloads section

The original POST is checked out and Protx generate the VPSTxId

If everything in the original POST checks out, the transaction is registered with the VSP Server system and a new transaction code is generated that is unique across ALL vendors using the VSP systems, not just unique to you. This code, the VPSTxId, is our unique reference to the transaction, and is sent back to you in the reply along with a Status of OK and a blank StatusDetail field.

If Protx responds, indicating that there are no problems with the data that has been sent through, Protx will respond with a status of OK.

The below screen shot shows how you would handle the Protx response of OK, the code still relates to the 'vps_order_purchase.asp' file on the ASP Server kit. The snippet of code shows how you would handle the response back from Protx.

N.B: For other VSP Server Kit languages please visit our Downloads section

Protx respond with an OK, supply the VPSTxId, SecurityKey and the VendorTxCode

When Protx respond back with a Status of OK Protx also supply; the VPSTxId (our unique reference to the transaction), SecurityKey (this is a ten character long alphanumeric string), used as a key for confirming the MD5 hash signature in the notification post and finally the VendorTxCode.

This next screen shot now shows you how you would handle the response, the code still relates to the 'vps_order_purchase.asp' file on the ASP Server kit. This is the point where you would be storing the VPSTxId, SecurityKey and VendorTxCode.

It is very crucial that you store these details in your database alongside the Shopper and order details for this transaction. This is very important for your own records so you can match the transaction details to your shopper and their purchase from your online store. The Protx Admin area does contain basic information on the Shoppers transaction, like the billing address, Shopper name etc. but having your own database is far more comprehensive and can be tailored to your needs.

Another very important fact for storing the VPSTxId, SecurityKey and VendorTxCode is you can automate more than one payment. VSP Direct and VSP Server place you in control of your transactions. Because you will have your own secure database servers and web servers on which you store details of your Shoppers and their transactions, you may well wish to automate many of the daily procedures, such as RELEASING and ABORTING DEFERRED transactions, REPEATING regular payments or issuing REFUNDS to Shoppers.

The process of Releasing a payment, or Refunding a transaction, are essentially the same as registering a VSP Server or VSP Direct payment. Your server sends an HTTPS POST containing a collection of Name=Value pairs directly to the VSP system, which validates the information and either carries out the instruction returning an OK status along with any relevant transaction ids and authorisation codes for you to store in your database, or generates an INVALID, MALFORMED, NOTAUTHED or ERROR Status with a description of the error in the StatusDetail field.

For further information please go our payment types section and also review the VSP Server and Direct Shared Protocol, which can be downloaded here.

NextURL, supplied so you can redirect the Shopper to a payment page

The final stage of this step (if everything is OK) is a field called NextURL, the NextURL is passed back after the initial transaction is registered with Protx. This is the Protx Payment page to which you should redirect the shopper to allow them to continue with their purchase.

Below is a screen shot to how your code may handle this, the code still relates to the 'vps_order_purchase.asp' file on the ASP Server kit.

N.B: For other VSP Server Kit languages please visit our Downloads section

This is now the stage where your Shopper can actually see a noticeable change happen, as far as the shopper is concerned they have just clicked a "continue" button. Everything else that has been described from the start of this section has been in a HTTPS POST and response; this is a completely invisible process to the Shopper. Now the shopper will find themselves on the Protx VSP Payment Page.

The shopper is now presented with the payment page where it requests their credit/debit card details. The details will be entered into the payment page and sent to the bank for authorisation. This page will also show your company logo (unless you are using customised templates) and a description of the items purchased. Depending upon whether you have 3D Secure set up on your Protx account and whether the Shopper's card is registered on the 3D Secure Scheme, they may be redirected to the Verified by Visa/MasterCard Secure Code web page for verification before authorisation is obtained from the bank.

There are many reasons as to why you will see a failure of a transaction.

If there is a problem with the initial registration of the transaction Protx will return back either a Status of either a MALFORMED, INVALID or ERROR message along with this a StatusDetail is returned 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 VSP Vendor Name.

The below example shows a MALFORMED status of where a non numeric has been 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 see why you are getting a MALFORMED or INVALID response back from Protx. If you are having difficulties in 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 about 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 Vendor's 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 that we can see all the information you post to Protx during a single transaction. If you do this you will need to contact us by phone (0207 292 3900 - option 4) 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 and finally 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 these above cases you should communicate to the Shopper that something is wrong and online purchases cannot be made at present.