James Allen's Coldfusion and Internet Technology Blog - SagePay

Problems connecting to SagePay's TEST and SIM servers - FIXED

Fri, 18 Sep 2009 13:20:00 +0100

Since Tuesday afternoon we have found that we can't connect to the TEST or SIM servers at SagePay. Live is fine however, even though the exact same code is used.

It's a strange problem as an immediate connection failure is received when attempting to POST a transaction registration to either the test or sim servers.

After this had happened we contacted SagePay support who did some checks but told us that there are no problems on the server. However, when I did a quick Twitter search I found another developer who is also getting this issue. I confirmed the problem via my local development server in the office and on the live server so it doesn't appear to be a specific ISP routing problem etc.

However over the past few day SagePay have confirmed that a small number of user's are having problems. It's most certainy not affecting the majority though.

This has led support to believe that the problem is due to Coldfusion and the way it is sending the POST request to the SagePay server.

The Solution

Luckily while throwing this problem out to Twitter a very helpful user (@Zefer) suggested that the problem might be due to the server sending back a gzipped response which cfhttp in Coldfusion can't handle (and certain URL functions in PHP it seems). To fix this we just need to send headers to tell the server what we can accept:

{code}

{/code}

The raw headers sent in the request will look like this:

{code}
Accept-Encoding: deflate;q=0
TE: deflate;q=0
{/code}

Once I made this change the problem went away immediately.

I assume that SagePay must have made a system change on SIM and TEST but not on LIVE (luckily).

SagePay: Inconsistency in IFrame 'Low profile' option on Server solution - Workaround

Tue, 19 May 2009 15:41:00 +0100

I've recently been integrating the SagePay Server solution into a client site and it was decided to utilise the new 'Low Profile' option (introduced in protocol 2.23). This new option allows the SagePay payment pages to appear within an Iframe placed inside the main site template. The obvious benefit of this is that the customer is not redirected to another site to complete payment and confidence in the vendor is improved.

The integration went pretty well with the SagePay XSLT templating system being relatively easy to use and customise. I soon had a template which nicely matched the style of the vendor's website.

During testing everything worked great. The payment form appeared within the IFrame, the card details could be entered and the 3D Secure page worked as expected. After the payment side had been handled SagePay redirect back to the vendor website outside of the IFrame - just what we need.

However, during testing I tested an AMEX card. AMEX cards are not part of the 3D Secure system and so the customer is not shown a 3D Secure page - just the card input form. Now this shouldn't really be a problem but when the card details have been entered and validated, SagePay redirect the customer back to the vendor site but inside the IFrame!

This is definetely NOT what we want as once redirected to our payment processing template the full site design is shown within the IFrame (header, sidebar and footer).

At this point I hit the HTTP debugger to find out what was causing this inconsistency. Here is what I found:

When 3DS authentication is required, the following HTTP requests are triggered:

{code}

https://test.sagepay.com/gateway/service/carddetails                302         POST     test.sagepay.com                /gateway/service/carddetails
https://test.sagepay.com/gateway/service/cardconfirmation    302         GET        test.sagepay.com                /gateway/service/cardconfirmation
https://test.sagepay.com/gateway/service/authentication         200         GET        test.sagepay.com                /gateway/service/authentication
https://test.sagepay.com/mpitools/accesscontroler?action=pareq         200         POST     test.sagepay.com                /mpitools/accesscontroler?action=pareq
https://test.sagepay.com/mpitools/accesscontroler?action=auth            200         POST     test.sagepay.com                /mpitools/accesscontroler?action=auth
https://test.sagepay.com/gateway/service/authentication?action=callback        200         POST     test.sagepay.com                /gateway/service/authentication?action=callback
https://test.sagepay.com/gateway/service/authentication?action=completion                302         POST                test.sagepay.com            /gateway/service/authentication?action=completion
REDIRECT
http://dev.jamesallen.name/index.cfm/page/orders.order.cfm             200         GET                dev.jamesallen.name /index.cfm/page/orders.order.cfm
{/code}

In this case, the final SagePay request is a POST (assumng it uses target="_top" which jumps the customer out of the Iframe)
The redirect back to the site is thus outside of the Iframe and all is good.

If 3DS authentication is NOT required the following HTTP requests are triggered:

{code}
https://test.sagepay.com/gateway/service/cardselection?vpstxid={283FE985-CE13-A510-B9E6-840531*****} 302                GET        test.sagepay.com            /gateway/service/cardselection?vpstxid={283FE985-CE13-A510-B9E6-840531*****}
https://test.sagepay.com/gateway/service/carddetails                200         GET        test.sagepay.com                /gateway/service/carddetails
https://test.sagepay.com/gateway/service/carddetails                302         POST     test.sagepay.com                /gateway/service/carddetails
https://test.sagepay.com/gateway/service/cardconfirmation    302         GET        test.sagepay.com                /gateway/service/cardconfirmation
https://test.sagepay.com/gateway/service/authentication         302         GET        test.sagepay.com                /gateway/service/authentication
REDIRECT
http://dev.jamesallen.name/index.cfm/page/orders.order.cfm             200         GET                dev.jamesallen.name/index.cfm/page/orders.order.cfm
{/code}

In this case the last request inside SagePay is a GET which means the customer is left in the Iframe.

So there is a fundamental inconsistency in the implementation of the new 'Low Profile' option in the SagePay Server product. So, how do we solve this?

After some head scratching I came up with a solution which I feel is fairly straight forward and will ensure that when SagePay fix the problem, the site will not suddenly change it's behaviour and will be easy to modify to remove the Javascript redirect.

The solution is as follows:

In your notification template (the one that SagePay POSTS back to and you respond with Status, RedirectURL, StatusDetail), set the RedirectURL to a new handler template (e.g http://site.com/orders/go.cfm). Then set a session variable to the URL you want the customer redirected to to continue the payment process.
Create the handler template. This will build a dynamic form whose target is set to the redirect URL set in session in the step above. Javascript will be used to automatically submit the form when the page is loaded. An HTML submit button will be created inside the form in case the user does not have Javascript enabled.

That's the solution in a nutshell. We are modifying our notification template to always redirect to a new handler template which will jump the customer out of the Iframe and direct them to the correct template that continues the order process. The form target on the handler template is set to "_top" which causes the form submission to break out of the IFrame.

To help with this below is the code I use on my handler template (go.cfm). I use JQuery for the automatic form submission and to hide the submit button. You could of course code that functionality without JQuery.

{code}

<cfset targetURL = session.targetURL>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
    <link rel="stylesheet" href="/styles/styles.css" type="text/css" />

    <title>Payment Processor</title>

   <script language="javascript" src="/functions/jquery.js"></script>

    <script language="javascript">
        $(document).ready(function() {
            $("#jump").hide();
            $("#jump").submit();
        });
    </script>
</head>

<body>
    <cfoutput>
        <form id="jump" action="#targetURL#" target="_top">
            <input type="submit" value="Click to continue your order">
        </form>
    </cfoutput>
</body>
</html>

{/code}

With this approach, once SagePay fix the inconsitency I can simply change this template to perform a server redirect to the required URL instead of using the Javascript and self submitting form.
Either that, or to change the notification template so that it goes directly to the required URL's as before.

Hopefully this will help some people who have got this problem when implementing the Server solution.

New SagePay URL's

Tue, 21 Apr 2009 14:19:00 +0100

I thought it might be easier if I listed the new SagePay URL's here.

I'll start with some code for Coldfusion developers who want to quickly copy and paste straight into their payment pages.

Note: These URL's are for the VSPDirect product

Also, this is not a complete list of the operations available (I don't use all of them in my code so didn't include).

{code}

{/code}

Now here are the URL's without the code:

LIVE

purchaseURL = https://live.sagepay.com/gateway/service/vspdirect-register.vsp
voidURL = https://live.sagepay.com/gateway/service/void.vsp
refundURL = https://live.sagepay.com/gateway/service/refund.vsp
releaseURL = https://live.sagepay.com/gateway/service/release.vsp
repeatURL = "ttps://live.sagepay.com/gateway/service/repeat.vsp
authoriseURL = https://live.sagepay.com/gateway/service/authorise.vsp
callbackURL = https://live.sagepay.com/gateway/service/direct3dcallback.vsp

TEST

purchaseURL = https://test.sagepay.com/gateway/service/vspdirect-register.vsp
voidURL = https://test.sagepay.com/gateway/service/void.vsp
refundURL = https://test.sagepay.com/gateway/service/refund.vsp
releaseURL = https://test.sagepay.com/gateway/service/release.vsp
repeatURL = https://test.sagepay.com/gateway/service/repeat.vsp
authoriseURL = https://test.sagepay.com/gateway/service/authorise.vsp
callbackURL = https://test.sagepay.com/gateway/service/direct3dcallback.vsp

SIM

purchaseURL = https://test.sagepay.com/Simulator/VSPDirectGateway.asp
voidURL = https://test.sagepay.com/Simulator/VSPServerGateway.asp?Service=VendorVoidTx
refundURL = https://test.sagepay.com/Simulator/VSPServerGateway.asp?Service=VendorRefundTx
releaseURL = https://test.sagepay.com/Simulator/VSPServerGateway.asp?Service=VendorReleaseTx
repeatURL = https://test.sagepay.com/Simulator/VSPServerGateway.asp?Service=VendorRepeatTx
authoriseURL = https://test.sagepay.com/Simulator/VSPServerGateway.asp?Service=VendorAuthoriseTx
callbackURL = https://test.sagepay.com/Simulator/VSPDirectCallback.asp

Protx - SagePay URL switch today - Old URL's DO NOT work anymore due to forwarding failure

Tue, 21 Apr 2009 13:15:00 +0100

NOTE: It looks like this problem may only affect Coldfusion and Java.

Protx have just switched over to the new SagePay URL's today on LIVE and unfortunately the old URL's have broken. This was not supposed to happen and the old URL's should have continued for the forseeable future.

SagePay are telling developers to update all sites to the new URL system.

I can't imagine how many orders are being lost this morning.

Get your URL's updated ASAP, full details here:

https://support.sagepay.com/forum/Topic8090-22-1.aspx

ProtX is rebranding to SagePay - TEST and SIM servers now use different URL!

Fri, 17 Apr 2009 20:28:00 +0100

I wondered why when I tried to test my Protx VSPServer integration today that it just wouldn't work. I kept getting this SSL problem when submitting the HTTP POST:

{code} I/O Exception: Name in certificate `test.sagepay.com' does not match host name `ukvpstest.protx.com'{/code}

I assumed this was a temporary issue but have just found out that ProtX is rebranding to SagePay and you need to use the following domain for TEST and SIM:

http://test.sagepay.com

There is also a new path for each operation so check out the table posted on the ProtX support forums:

https://support.sagepay.com/forum/Topic8090-22-1.aspx

James Allen's Coldfusion and Internet Technology Blog - SagePay

Problems connecting to SagePay's TEST and SIM servers - FIXED

SagePay: Inconsistency in IFrame 'Low profile' option on Server solution - ** Workaround **

New SagePay URL's

Protx - SagePay URL switch today - Old URL's DO NOT work anymore due to forwarding failure

ProtX is rebranding to SagePay - TEST and SIM servers now use different URL!

SagePay: Inconsistency in IFrame 'Low profile' option on Server solution - Workaround