Checkout to Payment OK Progression

[ju2ltd]

Has anybody got any expereince of measuring progression rates through the payment process? I am trying to improve the sales at www.haydockmusic.co.uk. I am using a web anlaytics package to do some funnel analysis on visitors looking at progression from the home page right through to the payment received page called Act_SECPayOK.html We use SECPay as our PSP.

The progression from product sections and sub categories are really high between 60-90% which indicates that our visitors are interested in what we have to sell. 62% of visitors who place a product in the cart progress to check out but then there is a precipitous drop at this stage. Only 15% of customers then go on to successfully make a payment as tracked by requests for Act_SECPayOK.html. Why do so few people successfully make a payment here - presumably the decision to buy has already been made. Also the payment process seems to be pretty standard.

May be we are tracking the wrong payment confirmation page?

Jim Williams
Managing Director
www.ju2.com www.ju2analytics.com

[Duncan Rounding]

I just placed a test order on the site. The transfer to SECPay is taking a very long time - in fact it's still busy trying as I typed all of this. (Took about 20 seconds)

This could be part of the reason.

I tried a couple of times since and after clicking next to go to SECPay after 20 seconds it times out. In fact it repeatedly times out now and I am unable to get to SECPay at all.

BTW if you're saying 15% of the visitors purchase then I'd be very pleased with the result.

[ju2ltd]

Drounding,

Thanks for the quick reply. I'll need to check this. How do you put through a test payment - can you get dummy credit card details from SECPay?

I am getting 6% of all customers entering the funnel get to the checkout but less than 1% (1 in 6) successfully complete payment. The problem you observe would explain this but we didn't see this during our testing.

Thanks again.

[Duncan Rounding]

I couldn't get to SECPay. I just placed a test order on your site to try to go through to SECPay.

[Mike Hughes]

I have seen this problem myself with Secpay and am seriously considering moving to protx. Secpay are using some form of IP 'switching' to avoid DOS attacks and I suspect this means that sometimes when they switch to another IP address that customers are being left trying to connect to a server that's no longer at the IP address their PC thinks it's at.

In terms of how much business this is costing you, the easiest way to measure this (and confirm your analytics results) you just have to look at the number of orders that aren't completing. Everytime actinic sends a customer to your PSP a new order is created. I quite often have customers trying 2-3 times before managing complete payment and this may be confusing your analytics package but it's easy to check by looking at the number of orders in your 'psp pending' tab.

Does anyone have these kind of issues with protx? If not then it's time for me to change. I think protx has handled the DOS attacks much more professionally and if there's fewer problems then I would be happy to make the move.

Mike

[ju2ltd]

My client does not have many pending orders - but I am going to use a piece of software from www.keynote.com to run some transactions to see the performance of each of the pages in the payment process to see if I can identify any performance issues. I'll also speak to SECPay - may be they can help.

Thanks for the advice.

[Mike Hughes]

You might also find that customers aren't going to the receipt page. This is presented as an option when using secpay and I do find that many customers head off to their home page at this point.

Mike

[ju2ltd]

We sort of thought of this and configured the SECPay Call Back page to be a tagged "Payment Accepted" page so in theory all successfully paying customers will view this page. However, I am not sure whether this is working correctly.

[ju2ltd]

SECPay Problem

I have now test the payment handling on the site and it is adequate in terms of download times. However, SECPay did have a problem this morning causing tranactions to be slowed.

It appears that I am tracking the wrong webpage. Well actually customers are still recieving payment confirmation (Callback Page) at a SECPay page www.secpay.com/java-bin/ValCard rather than a page on our domain. We can't tag an external page. Has anybody successfully configured their site so that the Callback Page is under their domain?

[Bruce]

Jim,

I would suggest reading the last post on this thread... http://community.actinic.com/showthread.php?t=16026

A search on SecPay Callback will give you several intersting threads.

Kind regards,