Sagepay RelatedVPSTxId cannot be found

SagePay are a payment card provider who process cards on behalf of many well known brands. The user posts http posts to the SagePay server to take payments from customer payment cards. Trying a new variation on how we could change our workflow I found a misleading error message.

DEFERRED payment

To validate a card you can take a deferred payment for £1/$1/€1 and then immediately ABORT that payment. This validates the basics of the card information.

Perhaps you don’t ABORT the DEFERRED payment in order to do a REPEATDEFERRED or REPEAT payment against that original transaction -we don’t want to hold the card details do we!

REPEAT payment

This action fails with the error 4028 : The RelatedVPSTxId cannot be found.

Hang on, we have just passed in the correct id for the transaction, what is going on? It turns out, reading the API guide again, that you cannot REPEAT or REPEATDEFERRED until a successful payment has been taken from the transaction. In the case of DEFERRED transaction, this means completing a RELEASE transaction. Looking at the way the web portal, MySagePay lays this information out I guess that the records are held somewhere separated for DEFERRED until they are RELEASED. At this point the transaction become visible to REPEATs. This is a slightly misleading error message in this context.

Multiple PageLoad User Control in Master Page header

PageLoad multiple calls

PageLoad was getting called multiple times for a user control in my Master Page. This had me puzzled for a couple of hours while I was looking in the wrong place for the cause. Then I realised what was going on.

IIS URL rewrite module

The site has a news directory that contains news articles, some static content others dynamic. The master page control in question listed the last few news articles and showed a thumbnail of those articles.

You may start to guess what is coming if I say there was also an IIS url rewriting rule to redirect any request that was not found as a physical file to /news/ and thus return the main news page (default.aspx). This had the effect of redirecting users who were using old links to the new front page.

Missing images

What happened was that development machine had got out of sync with the thumbnail images for this control. Thus when the browser asked for the missing thumbnail, instead IIS did a redirect for that request to /news/. In effect calling the default.aspx for the news directory. As the news front page was sent to the browser instead of the image, the header was rendered as part of this request for default.aspx, resulting in the page header control getting multiple hits depending on how many broken images were present.

This was identified as soon as fiddler was used to look at what the browser was up to. At this point all became very easy to see, several 200 requests for the /news/ url.

The solution for me was to limit the redirect in IIS to be just for .html/.aspx/.htm/.js etc. This solved the problem and properly reported missing images as not found.

Empty image tags

I also noticed a few people talking about empty image tags in server controls causing this same issue. They are correct, even without IIS redirects, there is a redirect in operation, that of serving default.aspx when an empty directory is called. If you have any image tags that render to an empty tag, the browser will unwittingly request default.aspx for the image. This will fire your page events twice or more depending on how many of these links lie in the page. I didn’t see any explanations for this behaviour in those posts so cover it here in case this variation on my issue catches you out.

IIS7 Hijacking my custom error pages

Custom error pages replaced by IIS?

Development Machine W7, Production IIS7 Windows 2008

Just had a sticky problem crop up in production. Custom error pages that used to work no longer work, I don’t know when but sometime our custom ASP.NET error pages have been replaced by stock IIS error pages.

How we use custom error pages

If a website user or search bot attempts to access a product page and the product no longer exists, we send them to a custom error page. The page suggests they try another product or search for alternatives. This page sends back a http 404 status so that the search engines know to drop the accessed URL from the index. It also causes our Google Mini to drop the page from its database too. If the user navigates to another url that has never had content they get a default 404 page returned.

Lets have a look

So you have a great little custom error page like this;

Protected Sub Page_Load1(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
        'Ensure a 404 not found sent for SEO purposes
        Response.StatusCode = 404
        Response.TrySkipIisCustomErrors = True
    End Sub

However even browsing direct to the page you only get,

IIS7 404 default error page

This is not your crafted custom page, instead this is the IIS7 page kicking in. IIS has put itself in the pipeline to the end user, replacing its own page with in place of the custom page.

IIS custom page configuration

The configuration for this is found in the site Error Pages section;

IIS7 Management Link to Error Pages

If you go into this menu you see all the custom error pages set up in IIS, now select the edit feature settings link on the right hand side;

IIS7 Error Pages Configuration

This is where the behaviour is set and currently this is set to show detail errors for users local to the machine but custom errors for people elsewhere. Note this is not ASP.NET, although the idea is the same, this is above ASP.NET, it is the handling IIS does for these pages.

You do not want normal users to see the detailed errors as it can give away important information about the configuration of your server thus the setting shown is fine and looking at it one would guess it would show our custom pages as we saw by the returned IIS 404 page this is not the case.

IIS7 Custom Errors Settings

So why do we not see our custom pages? Well back in the page code behind shot earlier is the key, you must set

Response.TrySkipIisCustomErrors = True

This tells IIS to get its nose out of what we’re up to and let us get on with it. Trying to browse the custom error page, now we get our custom error page retuned as would be expected in the first case.

Lesson learnt

The real nasty bit of this is that our development machines do not exhibit this behaviour, everything looks fine there. As Rick Strahl says it is another good case for using the staging servers with the production environment so that you test everything.

Other links:

Rick Strahl's Web Log has an almost identical post here

What to expect from IIS7 custom error modulethis link was the one that taught me what I needed to solve the problem.

Welcome to BlogEngine.NET 1.6.0

If you see this post it means that BlogEngine.NET 1.6.0 is running and the hard part of creating your own blog is done. There is only a few things left to do.

Write Permissions

To be able to log in to the blog and writing posts, you need to enable write permissions on the App_Data folder. If you’re blog is hosted at a hosting provider, you can either log into your account’s admin page or call the support. You need write permissions on the App_Data folder because all posts, comments, and blog attachments are saved as XML files and placed in the App_Data folder. 

If you wish to use a database to to store your blog data, we still encourage you to enable this write access for an images you may wish to store for your blog posts.  If you are interested in using Microsoft SQL Server, MySQL, VistaDB, or other databases, please see the BlogEngine wiki to get started.


When you've got write permissions to the App_Data folder, you need to change the username and password. Find the sign-in link located either at the bottom or top of the page depending on your current theme and click it. Now enter "admin" in both the username and password fields and click the button. You will now see an admin menu appear. It has a link to the "Users" admin page. From there you can change the username and password.  Passwords are hashed by default so if you lose your password, please see the BlogEngine wiki for information on recovery.

Configuration and Profile

Now that you have your blog secured, take a look through the settings and give your new blog a title.  BlogEngine.NET 1.4 is set up to take full advantage of of many semantic formats and technologies such as FOAF, SIOC and APML. It means that the content stored in your BlogEngine.NET installation will be fully portable and auto-discoverable.  Be sure to fill in your author profile to take better advantage of this.

Themes and Widgets

One last thing to consider is customizing the look of your blog.  We have a few themes available right out of the box including two fully setup to use our new widget framework.  The widget framework allows drop and drag placement on your side bar as well as editing and configuration right in the widget while you are logged in.  Be sure to check out our home page for more theme choices and downloadable widgets to add to your blog.

On the web

You can find BlogEngine.NET on the official website. Here you'll find tutorials, documentation, tips and tricks and much more. The ongoing development of BlogEngine.NET can be followed at CodePlex where the daily builds will be published for anyone to download.

Good luck and happy writing.

The BlogEngine.NET team