Posts Tagged ‘access’

SagePay VSP Access becomes Reporting and Admin API but the protocol documentation is wrong!

Friday, August 13th, 2010

I just received an email this morning from SagePay to warn of their latest payment system update. For those of you who don’t know – SagePay is the (relatively) new name for ProtX since Sage bought them. ProtX developed a system back in 2008 called VSP Access, which was designed to allow you to programmatically access payment details for payments that have been put through using one of their payment systems (Form, Server or Direct (previously VSP Form, VSP Server and VSP Direct)).  For some reason, ProtX used to be downright secretive about this system and were difficult to get the information out of about it.  However, this is very useful for one of my clients as it allows us to confirm payments have actually gone through, keep track of refunds and spot any that somehow made it through without being logged by any of my systems (I don’t think that has ever actually happened, but it is a good double-check). They use that report for entering payments into their accounts software.

Anyway, back to the email I got today… SagePay are warning that they are upgrading their systems between 27th and 29th August and first of all, if anyone has IP addresses of their payment gateways hard coded, they need to update them (sounds like a bad idea anyway), and secondly, to say that if anyone is using the Reporting and Admin API then please check the Reporting and Admin API Protocol document (linked to in the email) as the code may need updating.

First of all, a couple of minor observations: -

  • They are allowing 14 days notice to make these changes.  That isn’t a great deal of time as many systems have a schedule of upgrades that are rolled out.  If anyone is in the middle of a big upgrade that could be a real pain in the neck.
  • The new name is rubbish – which marketing guy thought that “Reporting and Admin API” is easier to remember than “Access”?

However, that’s not the real problem.  The real problem came when I looked at the document.

The document says

All requests are sent to one gateway at address:
This immediately looked a little odd to me as I thought it isn’t very sensible to include spaces in the URLs, but I thought that it shouldn’t actually be a major problem, so I tried it.  I got a 404 page not found.  I had another look at the document and if you have a look at the links above, you’ll see that they actually link to 2 different addresses: -
https://test.sagepay.com/access/access.htm (Test)
https://live.sagepay.com/access/access.htm (Live)
Now these were actually the old addresses, so I thought I’d try these, but they are still reporting protocol version 1.01, when the new protocol is apparently 1.02.  This might be updated at the same URL, but I don’t want to rely on it.
A closer look at the document gives some other interesting problems: -
The XML field will contain the XML message, which always takes the following format:
<vspReporting and Admin API>
<command>whatever</command>
<vendor>Vendor Name</vendor>
<user>User name</user>
<other command specific parameters in here…./>
<signature>MD5 Hash Signature</signature>
</vspReporting and Admin API>
Now, I don’t claim to be an XML guru, but I’m pretty sure you aren’t allowed a tag name with spaces in, so that isn’t valid XML.  It actually looks to me like someone ran a search and replace, since the old tag was called vspaccess!  I think they might have been a bit too enthusiastic.  This would also make sense with the above URLs, but doesn’t really explain the protocol version problem that the old URLs return 1.01.
Since I ran out of other options and I didn’t want this to drag on, I decided to phone SagePay technical support.  A very nice lady there spent a few minutes trying to work out what I was talking about as she had obviously not heard of the Reporting and Admin API or VSP Access.  She managed to find the email that I had been sent and worked out where it had come from, so she forwarded my details on to the appropriate people.  I’ve just received an email back from them to confirm that the URLs are incorrect (big surprise!) and that they will send a new version of the document out with corrections.  They haven’t said when yet, but hopefully it will be in the next couple of weeks.