PayPoint (Secpay) blank callback page, v1.3.9b

Hello all,

I've just installed v1.3.9b, using the same PayPoint (SecPay) module I was using in v1.3.7, which has been working fine. However in v1.3.9b, the order is received and processed by PayPoint, but when returned to the callback page, it's blank, and the order isn't recorded by ZC.

I've tried 2 installations of v1.3.9b just to check it was nothing I'd done in the course of customisation, and the clean install has the same problem. I even installed another v1.3.7 just to check, and that still works OK.

Spoke to a PayPoint tech yesterday, and they've had no other problems reported, and can't immediately think of what the problem might be. The hidden fields in the PayPoint template payment page source code all seem to be correct, so I assume it's some change in the 'checkout success' process of v.1.3.9, but I've no idea what I should be looking for. Any thoughts much appreciated.

Thankee.

Three things to check:
a) Are there any "myDebug-xxxx.log" files in your /cache/ folder? Those should show any PHP errors that are occurring.
b) When you get that "blank page", what is the HTTP Header code your browser is receiving?
c) And what's the complete URL showing in the browser when you get that "blank page"? (you can mask the domain name ... I'm interested in the rest of the URL) .. ie: the parameters coming back from the payment server

Hi DrB,

1. No error log files created.
2. Not completely sure where to look for the HTTP header code - I'm guessing you mean the code number shown the server log entry, in which case it's 406
3. URL is the usual PayPoint URL - https://www.secpay.com/java-bin/ValCard

Security protections are likely what's blocking the message, and that's likely because the module was written using old methods, and hasn't been updated to use $messageStack to pass error (or even success) messages, and is instead trying to pass them via the URL, resulting in very long messages, which are similar to rogue hacker activity, and thus getting flagged and halted.

Where did you get the module from?

I got it from Secpay ages ago, and I believe it's the same one available here http://www.zen-cart.com/index.php?main_page=product_contrib_info&products_id=328 - 2006 was their latest version. I added a few lines a while back re: truncating long product names for 3D Secure MPI, but can't for the life of me remember where I got those lines from.

What's the best course of action? I'm not familiar enough with ZC code to update the module myself.

That module is written for PHP 3, and requires Register Globals to be enabled. It's likely that it will encounter problems with PHP 5.3 and newer.
I strongly recommend that you rewrite all the use of no-longer-supported variables like $HTTP_GET_VARS with their corresponding equivalents, not only because that would be the right thing to do, but also because some of the sanitizing code in Zen Cart blocks their misuse for security reasons.

I am having this problem on one of our clients websites. I assume looking at other threads this is not solved, or the information is not freely available, hopefully someone will find the below useful.

After some investigation the issue appears to be that the callback is not processed or halted when zen cart detects a variable named "hash" in the query string. You can replicate this issue by placing ?hash=xyz at the end of one of your zen cart URLs.

The callback from sec pay includes the hash variable in the query string which appears to be what is causing the callback not to complete. I am not sure why Zen Cart would do this - though I imagine it could be security related however this seems a little bit excessive?

I do not have the option of switching to another payment processor so will continue to investigate and update accordingly unless otherwise instructed.

The "hash" is a very commonly-used parameter by hackers and scriptkiddies wishing to attempt to exploit various vulnerabilities in various PHP applications.
It is specifically checked-for and blocked in Zen Cart in an effort to prevent such activity which commonly wastes CPU resources and raises unnecessary alarms.

If you wish to allow such traffic to badger your site in order to use your payment module, simply go into /includes/application_top.php and remove the following line 22:```
$paramsToAvoid[] = 'hash';

DrByte:

The "hash" is a very commonly-used parameter by hackers and scriptkiddies wishing to attempt to exploit various vulnerabilities in various PHP applications.
It is specifically checked-for and blocked in Zen Cart in an effort to prevent such activity which commonly wastes CPU resources and raises unnecessary alarms.

If you wish to allow such traffic to badger your site in order to use your payment module, simply go into /includes/application_top.php and remove the following line 22:```
$paramsToAvoid[] = 'hash';

That was very quick, thank you very much - you have likely saved me a couple of hours tracking that down. :D