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:
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:
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.
<!--- URL to redirect to (set in session before the jump to here) --->
<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>
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.
