PROTX (SagePay) new API version 2.23

21 Apr

Great news forProtx (SagePay) payment users! 

Along with new brand name and design Protx introduced new version of their API (2.23). 

For the end users everything stays the same except for design – it looks much better now 😉 Developers will be surprized with extended functionality of VSP Server for instance.

The very first thing I would like to mention is so called Low Profile payment pages which are run inside an IFRAME and can be customized to look like they are a part of your site. The only exception is payments that run 3D Secure checking – clients will be redirected to the card issuing bank’s 3D Secure pages (full screen HTML).

To start using Low Profile pages all you need is to pass an optional parameter in the transaction registration request:

Profile = “LOW”

Omitting this field or sending “NORMAL” renders the normal card selection screen.

Great new feature in terms of statistics is that new API provides an opportunity to access information on card type and last 4 digits of the card number used. List of fields for computing MD5 signature has also been changed.

The only drawbacks I could find are:

  • Testing of the previous versions of VSP Server with Simulator is no longer possible. Testing environment still supports 2.22 version but unfortunately doesn’t give the same detailed picture.
  • In new release fields like billing and delivery address are compulsory. This makes no sense at all for businesses that deliver services by email, for instance.

Protx (SagePay) made a really great job. The only questions I have as a customer are:

  1. Why do I need to collect all this completely irrelevant to the business nature information?
  2. If they need this information why don’t they collect it on their end?

To be continued with testing experience.


Posted by on April 21, 2009 in misc


Tags: ,

5 responses to “PROTX (SagePay) new API version 2.23

  1. Joe_SagePay

    April 22, 2009 at 9:19 am


    Thank you for your comments regarding our recent change of name to Sage Pay.

    We are very happy that you approve of the changes and that you share our enthusiasm for some of the new features and the look and feel of the new pages.

    To answer your questions briefly:

    We ask for these billing and delivery details primarily to supply to our fraud screening service. The more accurate the information we are provided, the better the fraud screening results we can give. We realise that not all business’ ship to a physical address but we are pro-active in our desire to tackle fraud and as such, we look for you to collect these details and pass them to us.

    As to why we do not collect them ourselves? Well, although it is not an assumption and is not always the case, it is more often than not that you, the vendor, will collect these details on your site as part of the order. As such we allow for you to supply these details to us.

    With our pay page products you may expect the customer to enter their billing address details on our payment pages.

    If you need to get in touch with me for any reason, please email for attention of Joe, and I would be delighted to get back to you or anyone else that wishes to discuss Sage Pay.

    Kind regards,


    • Dasha

      April 25, 2009 at 3:56 pm

      Thank you for reply Joe! New functionality is really great!

      Is there any difference for fraud checking in when the data is collected? I mean if the client enters details himself on your site or we pass the same details? As I understand fraud service checks the client but not the site he came from, right?

      Is it technically possible to make these fields optional? Is this planed for the next versions of API?

      We are still using version 2.22 though but planning to migrate shortly. Documentation seems to be straight forward – thank you for that!

  2. Joe_SagePay

    April 22, 2009 at 9:22 am

    And for any technical assistance people may need, such as changing Live URL’s:

    Kind regards,


  3. Joe_SagePay

    April 22, 2009 at 1:43 pm


    Could I also add that the iFrame solution should not insist upon 3D secure being opened in a new window; it should in fact allow you to open it in the iFrame (which is how Sage Pay payment pages work).

    Many thanks again,


  4. newwisdom

    September 23, 2010 at 12:51 pm


    Everytime I pass the “profile=low” paramater in my registration POST, it breaks the preceeding parameter…
    For example, if I have “&AllowGiftAid=0&Profile=Low” I receive an error for AllowGiftAid.

    Do you have any idea what I am doing wrong?

    I am using the test url so is that the problem?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: