SecPay module not functioning

[phil81uk]

Hi,

 

We've just opened a SecPay account and entered the details into OSCommerce as follows:

 

 

However, there is some problem. When I checkout and complete payment it seems to go back to the checkout_payment.php page. Here are the screenshots:

 

SecPay payment page is completed using test details:

 

I press 'authorise' and the following page loads, which seems to be the checkou_payment.php page, but look at the URL!

 

So, I am stuck! Any suggestions for why this is happening?

 

Philip

[phil81uk]

Hi. Is there no one with using SecPay who can confirm that the SecPay module built into OSCommerce is up to date and should function correctly?

[lewis1111]

I noticed you had it on production mode but you were entering a test cc number.

 

Try it again with "Always successful" switched on.

 

Netscreen Firewalls

[djmarkm]

Hi,

I'm also having difficulty getting this secpay module to work.

 

My issue is similar to phil81uk, in that I get to the secpay screen but when I click the Authorise button (after entering card details) I then get a blank white page with "Invalid Template File Type" and the address of "https://www.secpay.com/java-bin/ValCard"

 

I have asked secpay re this and they say that it's usually solved by removing and reinstalling the secpay module but that was one of the first things I did before contacting them. It didn't !

 

I'm not using a custom template.

 

As a test I have removed my site, installed a clean OSCommerce install with the default products, changed the default currency to GBP, installed the secpay module and ran a test charge. But got exactly the same result.

 

This is my final hurdle before we set this site live but it's a bit of a show stopper.

 

WIth regard to secpay module versions I have found 3

 

1) Default installed with OSCommerce

2) Contrib (adds digest key check)

3) Alternate found in the forum posts (Adds custom template as a parameter to contrib 2 but doesn't seem to install properly)

 

I have tried all 3 and still get the same "Invalid Template File Type" error.

[djmarkm]

Right Ladies And Gentlemen,

 

I think I have solved this or at least I have got this working and have some pointers for other users.

 

I'm using the contrib secpay module with degist key.

 

The problems seem to be related to SSL (or lack of it) on the OSCommerce site. The Secpay module is written to call back from the secpay website back to a secured OSCommerce site. If SSL is incorrectly set up or you have chosen not to have SSL on your site (like me) and instead just rely on the secpay transaction being secured, the Secpay call back fails with either "Invalid template file type" or calling back to your insecured site but with the address still "https://www.secpay.com/java-bin/ValCard" and a warning from IE that you are moving to an insecure site (on IE7 the site images were also disabled)

 

Anyway, to cut a long story short, by enabling SSL on the Shopping cart the call back works properly. In my case I am using my hosters shared certificate and it's still fine.

[Guest]

It seems we are but an unfortunate few that has opted for this contrib. Finding help on SECPay is proving to be rather difficult.

 

I have no problem with any other part of my website as far as cookies or session IDs are concerned, but for some reason, after processing a transaction I am returned to my website's cookie usage page. The transaction was authorised by SECPay, and if the authorisation was succesfull it would then continue to process the transaction and charge the card for it, yet still takes me back to my Cookie Usage page and on top of that, the cart has not been emptied and the order has not been processed in my store. Obviously this causes confusion and customers retry the transaction and get charged twice and the only way that I know of the transaction is the email from SECPay informing me of the transaction. This forces me to phone up the customer and confirm the content of their order.

 

This seems very strange as I was told by SECPay that they dont accept cookies and that the transaction info is transferred via a form. The problem seems to be on the callback. I was told by SECPay that OSC passes a certain value to SECPay which is returned once the Auth has been done. This value that is returned by SECPay seems to either be wrong or interpreted incorrectly by my OSC install.

 

Anybody out there that had a similar problem or know of anything that I could try would be most appreciated.

 

:huh: Thanks

[Guest]

Came across this and thought I would impart some experience which may (or may not) help someone out there.

 

There is a problem with the way the SECPay module handles the callback. When the callback occurs, the OSC code uses a http 301 redirection to cause the browser to bring up the "order complete" page.

 

However, this does not always work correctly; it depends on whether you have SSL enabled in the callback (you should ALWAYS have SSL enabled - I'm very surprised SECPay even provide an option not to), and may also be affected by some of the other options that you can specify to SECPay.

 

Some time ago, I spent many hours trying to work out what was happening. With the generous help of the SECPay crew, I managed to work out that the problem was the 301 redirection; it does not always work! Instead you must initiate a http page redirection. This involves creating a small html page with the redirection instruction in it (sorry - I can't remember the exact details/syntax and I can't be bothered to look it up right now, but it's the same mechanism that is used to cause periodic refreshes of a web page so I'm sure you can find it on google).

 

The reason the 301 redirection does not work is not at all obvious if you don't understand how the SECPay transaction works, but basically it is because when the client browser is within the transaction phase, the data flow is from the client browser through SECPay and then to OSC. Therefore, some of the OSC code is running in the "context" (not really the correct word) of SECPay and NOT the client; the SECPay site is operating as a sort-of proxy (again, not quite correct, but it will do for this explanation).

 

In order to fix this, you need to hack OSC to change the 301 redirection into a http redirection. I shall leave this as an exercise to the reader to work out; it's not a 2 minute job to do though because other bits of OSC still use the 301.

 

There may well be other problems with the SECPay module in OSC (OK, I know that there are - it doesn't check the callback integrity correctly, for example) but this is one of the fundamental faults that can stop it working.

 

Oh, and no - SECPay does not use cookies.

 

Hope this helps someone.

 

regards

 

Rich.

Edited August 15, 2006 by CMOTD

[indivai]

Came across this and thought I would impart some experience which may (or may not) help someone out there.

 

There is a problem with the way the SECPay module handles the callback. When the callback occurs, the OSC code uses a http 301 redirection to cause the browser to bring up the "order complete" page.

 

However, this does not always work correctly; it depends on whether you have SSL enabled in the callback (you should ALWAYS have SSL enabled - I'm very surprised SECPay even provide an option not to), and may also be affected by some of the other options that you can specify to SECPay.

 

Some time ago, I spent many hours trying to work out what was happening. With the generous help of the SECPay crew, I managed to work out that the problem was the 301 redirection; it does not always work! Instead you must initiate a http page redirection. This involves creating a small html page with the redirection instruction in it (sorry - I can't remember the exact details/syntax and I can't be bothered to look it up right now, but it's the same mechanism that is used to cause periodic refreshes of a web page so I'm sure you can find it on google).

 

The reason the 301 redirection does not work is not at all obvious if you don't understand how the SECPay transaction works, but basically it is because when the client browser is within the transaction phase, the data flow is from the client browser through SECPay and then to OSC. Therefore, some of the OSC code is running in the "context" (not really the correct word) of SECPay and NOT the client; the SECPay site is operating as a sort-of proxy (again, not quite correct, but it will do for this explanation).

 

In order to fix this, you need to hack OSC to change the 301 redirection into a http redirection. I shall leave this as an exercise to the reader to work out; it's not a 2 minute job to do though because other bits of OSC still use the 301.

 

There may well be other problems with the SECPay module in OSC (OK, I know that there are - it doesn't check the callback integrity correctly, for example) but this is one of the fundamental faults that can stop it working.

 

Oh, and no - SECPay does not use cookies.

 

Hope this helps someone.

 

regards

 

Rich.

 

 

hi Rich,

Thanks for this post..

I am having the same problem..

hope this hepls me out.

thanks

[all2coolnick]

I had the same problem. I think you will find the solution here:

 

http://www.oscommerce.com/forums/index.php?showtopic=204716

 

This worked for me and solved the problem in 5sec flat!