Portal | Homepage | Blog

Checkout issues with server?


We have received a large number of complaints over the last day or so as customers are reporting that they do not have permission to access /store/go/checkout/ on this server error messages. This seems to be happening regardless of browser version and also regardless of the payment option selected. Switching browsers does seem to fix the issue for some customers.

Has anyone else been receiving these emails over the last 48 hours? I suspect it’s a result of a server side change to Apache.

I have raised a ticket but have also open this thread in case other customers are experiencing similar and so that the issue can be resolved more quickly by sharing information.

Here’s a few sample message I’ve received from customers in the last 24 hours.

*HI, When I try and checkout on your site (buying an e-gift card), I get an error message saying I can’t access the server

*Why will your site not allow me to complete my purchase by PayPal? Every time I try it tells me, “Forbidden
You don’t have permission to access /store/go/checkout/ on this server.”

*I am unable to place my order. I am logged in, have items in my cart, and am choosing to pay by Paypal. When I click the green ‘Complete’ button, I get a message saying ‘The website declined to show this page’. I tried yesterday and today and am getting the same issue every time.



Hi @jbw,

Is it possible our web app firewall upgrade could be blocking the PayPal return URL request?



Hi Donogh, thanks for the reply. I don’t think it’s Paypal specific as customers have advised of the same occurring when attempting to pay directly by credit card (via eway). If you refer to the ticket, you’ll notice that the issue occurs for some users regardless of browser or device as some have tried multiple devices including PC’s, Macs, mobile devices without success. I’m not sure there’s a single commonality across these failed transactions, I’m leaning towards this being a server side issue rather than a client side issue due to the number of browsers affected.


Hi Andy,

It seems one of our providers, Rackspace, were experiencing DNS issues yesterday due to a DDoS attack, which affected our checkout URLs. It has since been resolved:

Unfortunately, it was out of our control. Sorry for the inconvenience.

We are now taking steps to ensure the DNS for those URLs are not entirely dependent on Rackspace.

Kind regards,


Thanks Donogh, much appreciated. Hopefully it’s the last we see if this issue this side of the holidays.

I hope the team has a safe and Merry Christmas :smile:


Same to you, thanks Andy!


Donogh we appear to be having the same issue once again as we’ve received a large number of emails from customers this afternoon saying they’re receiving a 403 forbidden errors when being routed through the checkout process,

I’ve raised a ticket but am hoping this post may raise awareness of the issue a little sooner.



Hi Andy,

We’re not currently aware of any general issues with the checkout.

Is this only with PayPal orders? Have you been able to reproduce the problem?



Thanks for the quick reply Donogh.

I can’t replicate the issue on my end but we’ve received at least 10 - 15 emails and a number of phone calls earlier in the day. You may also recall we had a similar problem a few months ago (ticket #97140) that ended up being a firewall issue. Based on the error customers are reporting it could well be the same cause.

I’ve sent out a few replies to those customers that have bothered to email to try and gather more information about the issue.



Hi Andy,

Unfortunately, we’re not seeing any obvious problems here.

@jbw would you mind double-checking that our web app firewall isn’t blocking any checkout requests, please?




I found one issue which seemed to relate to invalid (missing) encoding on the following args - looks to be part of a constant contact campaign:

_utmz=“79418632.1427771100.1.1.utmcsr=We Miss You - $20 OFF - March|utmccn=Constant Contact|utmcmd=email”

I have whitelisted this now so there shouldn’t be any further problems.

Let me know if you’ve any further issues!



Thanks Jerry.

Are we likely to have similar issues in the future or was there something specific with the utm tag generated for that particular campaign?

We obviously use Constant Contact often.



Hi Andy

You shouldn’t have any further issues - the specific rule on our firewall which was causing the block has been disabled to prevent future false positives.



I’ve noticed a similar issue lately…Although due to Google analytics on sub-domain webstores (secureX.nitrosell.com is blocked from recreating cookies created on other sites of the domain) One way to get around these types of 403 errors is to have the user dump all of their cookies and try again. I’ve created a notfound.html to assist with 404’s - is there any opportunity for a forbidden.html so that we may instruct customers to dump cookies?


Although not a major problem, but whilst on this topic, there appears to be an issue with the /notfound.html file being forbidden as well when trying to access a file or image that doesn’t exit.

You don’t have permission to access /notfound.html on this server.