WorldPay Module for ZenCartv1.3x

Bugger,

Totally forgot, someone asked me about getting worldpay to work with PHP5, at the moment it's simple, in you php.ini file there is a line

Code:

---

register_long_arrays = Off

---

change that to

Code:

---

register_long_arrays = On

---

restart apache and the current module will work, except you can't download it because until this bug is fixed it's been disabled. but anyway, I've seen the beta and it looks PHP5 compatible. Turning on register_long_arrays will slow down/ use more memory on an overworked server too.

Thanks
Philip.

OK folks - I'm back!

Been very very busy lately so have not been around the forums. Also I haven't had much to add since the module works fine if the host server maintains sessions. PHP5 is another issue but Philip seems to have a solution to that.

Regarding the SECURITY HOLE. It is real and does exist and needs to be closed. Also current users need to be vigilant and check that, before fulfilling any orders, the appropriate payment has gone through their WorldPay account.

The good news is that I have a fix and so far Philip has not been able to break it. It's a fairly simple fix but needs a little tidying up and some further testing before release.

Be back soon with download details.

Regards,

Alan

I think hats off to Alan for having "sorted" the initial hole (I though of a better word, EXPLOIT), so far in basic testing the new module is a real gem of programming and Alan has done exceptionally well in this short time scale.

Even better is that I did not give him my code, he's a clever bunny that one, once he was told the theory, he worked out how it was being done and patched it without being able to test. The would be the programming equivalent of dodging a bullet blindfolded wearing ear plugs, after having been turned around a couple of times and the gun would have a silencer on it. Give the man a sausage.

Now all we have to do is work out how to tell every zencart worldpay shop, to upgrade.

Quote:

---

Originally Posted by philip_clarke

Give the man a sausage.

---

Can I have a sausage too for being to the first to believe you - lincolnshire would be nice! :)

Quote:

---

Originally Posted by philip_clarke

Now all we have to do is work out how to tell every zencart worldpay shop, to upgrade.

---

How about we talk to Worldpay and ask them to email their customers?

Actually Snowy2007, you were great in helping me prove the concept, you probably deserve a sausage that is at least 80% meat.

Is your worldpay account in test mode, still ? (PM me) Because I found another entirely different exploit which I've confirmed with Alan (and I have asked him nicely to confirm this, as people have been offering me gainful employment, and I wouldn't want anyone to think I was a one-hit wonder).

AfterHour, he was great too, cynical, but I don't hold a sausage against him.

Philip.

Good Evening.

The second exploit is live and out there too, and is different from the first. Alan will be addressing it in the next version BUT there is a workaround for the second one.

The current advice is to either disable worldpay or to check for the confirmation emails or check the account. AfterHour should be able to confirm, that I have ordered about £80 of items from his shop but only paid 1 pence for the goods, he also received a confirmation email from WordPay that if he did not read carefully, he would have thought the transaction was fully paid up. It would only be spotted in careful reading and going to the worldpay account.

The current advice for anyone with worldpay installed is to carefully check your worldpay account by logging on and confirming the amount paid corresponds to what zencart is telling you. The workaround for the second exploit it to use MD5. These instructions have been provided for me by Carl Stone, who has been helping my research by allowing me to run test transactions through his server. Note at all times I have never been able to access the admin section, nor do I require administrative passwords, this is a critical exploit as it can be done on any zencart with worldpay. The advice for turning on MD5 is as follows:

Quote:

---

Ok, in the worldpay system settings you go to integration setup (you have to go to "production" first), then set your password in "MD5 secret for transactions" and save. You then switch to Test and do the same making sure you save after each change. [ this section in italics may only be if you are using the test mode as well as production, I believe - Philip ]

In Alan's module the is an MD5 field where you add the same password, you also have to set MD5 to True in another field.

---

Thank you Carl - aka snow-man
Thank you AfterHour - sorry I had to demo it on your server again but I had to make sure it was in the wild and that it wasn't anything I had introduced while working through the module with Carl.

I'm sorry but I had to do this, blame my sense of humour and Duncanad's Signature. I'll tell you about the penguins, bear in mind they are almost 10 years old and the code even works in Google Chrome without modfication since it was originally written in Javascript. You can check this on the internet archive, they used to be on bouncing.org's front page (the way back machine appears to be overloaded for most of today).
##############################___
########################.co.uk, exploiting IT for Business
also ########################.com for America and ######################## for YOU

Hm ... I don't think this is very special for WorldPay alone, it applies to most of the payment gateways because of the way Zen Cart, osC etc. works in this area. Arrest me if I'm wrong ... but MD5 should be used on all, if available, in order to avoid this behaviour. This is nothing new, we've seen it before on other modules.

Btw! This is also why some payment providers don't allow instant capture as default, because you should check all payments before shipping.

Just my 2 cents.

Morning,

I've tried it with the paypal IPN_Handler. That's very well written, and it won't pay for the items if the amount/ currency id different. It also throws an error if you have debug mode set and one tries the first exploit, which states

Code:

---

IPN WARNING :: Transaction was not marked as VERIFIED. Keep this report for
potential use in fraud investigations.
IPN Info =
INVALID

---

That would be email number 6 in debug mode, on a live site. After the ipn_main_handler.php receives a post, it posts the information back to paypal for more confirmation, so if the transaction never took place, if the currency is wrong, if the amount is different then the PayPal server throws an INVALID response.

I started testing other modules for similar exploits yesterday.

Thanks

I'll add to that comment above.

It's not complex to only mark a shopping cat as paid, if the amount and currency match.

MD5 or not, the first exploit worked, and any shopping cart could be marked as paid.

The second expoilt means that a £100 cart can be marked as paid up for 1 pence. Some people do not read their notification emals correctly, but as I was saying to Alan. A nice way to carry on fraud is to find things you like and then take a 10-20% discount off them, then free shipping. If caught one's defence is "how the friggin hell do I know why they gave me a discount", it's very difficult to prove in a court of law especially since the amount paid and authrosied is directly coming from paypal/ worldpay and they almost certainly have a contract with you stating that it's up to you to have used every available method to provide them with the correct payment amount.

Thanks
Philip.

PayPal is not the same type of payment gateway as WorldPay, DIBS etc., just so we know that. ;)

I haven't really investigated worldpay (as in going there and finding out how it works) as yet, the system is good if the module is implemented correctly, I do have to have a look at the documentation at some time to check for a few other things. I think that the next version of the module should be secure, myself and Alan have already gone over it for XSS possibilities and the "next" module itself is currently secure, whether ZC is secure against them further down the chain is another matter.

I'll be looking at how OsCommerce handles things too, but this is unpaid so it'll be when I can squeeze it in.

I have got your e-mails Philip, apologies for not replying sooner but I have been trying to spend more time with the kids this weekend :) I will get my fine tooth comb out for the morning...

I can confirm from a previous post of Philps, that it is possible to use the second exploit for worldpay to return a confirmation e-mail, that payment has been received and if you have lots of orders coming in (I wish!!) it could be quite easy to miss, that all was not well.

Thanks for all the time and effort to resolve this Philip and you too Alan... keep up the good work :)

Forever a Cynic.....
AfterHouR

Thank you Afterhour, I understand that some people have family commitments, I'm just a little too obssessive, although in the current fashionable words of the day, I suppose I could pass it off as being "passionate" about my work.

Alan can handle everything, I am going to shift my focus on some other things that have cropped up during this investigation, like how to set up a system within zencart to store "critical exploit alerts", it'll be a useful use of my time. I'll have to persuade the zencart developers, and the module developers to implement a simple version listing file in their systems and then a comparison and since I'm as subtle as an axe, it may be sometime before the system is implemented, but if you think about it, during this pretty serious alert, there's only been about 5 visitors to the thread, and I'm damned sure that there's a lot more installations around than that.

SECURITY PATCH AVAILABLE FOR DOWNLOAD

You will find below a link to dowload a Patch to address the Security Exploits discussed above. Thanks to Philip Clarke for identifying these and for his assistance in testing this patch. He has also made some further suggestions which I will try to absorb and incorporate in future releases as appropriate.

THIS PATCH IS FOR THE FOLLOWING VERSION OF THE WORLDPAY MODULE:

WorldPay_ZC1.3x_v1.0_beta

This version was not available from the Downloads but from my website - a link has been posted on the forums at least twice previously. It's beta because I was not able to test this on PHP5. Philip has posted above details of how to configure the host server to allow the module to work on PHP5.

IF YOU ARE USING THE VERSION FROM THE DOWNLOADS SECTION UPGRADE TO THIS VERSION FIRST AND THEN APPLY THE PATCH IMMEDIATELY

When upgrading follow the installation instructions carefully. You will need to remove all the previous version files from your server. Also it will only work on 1.3x versions of Zen Cart so if you are still using an earlier version of Zen Cart upgrade your Zen Cart first.

The two exploits are as follows:

1. The existing module can be fooled into processing an order without a payment having gone through WorldPay. This is fixed by setting a Payment Response Password. The patch adds functionality to process the Payment Response Password.

2. The order value processed by WorldPay can be altered so that the customer pays less than the order value. This is fixed by configuring the existing MD5 functionality which has always been available within the module.

Both of these exploits will only be successful if shop owners are not vigilant in checking orders against WorldPay payments.

The download links are as follows:

WorldPay_ZC1.3x_v1.0_beta

http://www.workingit.co.uk/ZenCart/W..._v1.0_beta.zip

WorldPay_ZC1.3x_v1.0_beta_security_fix

http://www.workingit.co.uk/ZenCart/W...curity_fix.zip

I will submit a new version, including the security patch, to the downloads section asap.

Regards,

Alan

Thanks again for all your hard work Duncan and Philip and for getting onto this straight away..

It is a real shame there hasn't been more of an uptake to this, I expected more of a response on these pages from people than this... Ignorance is bliss, or is it ignorance is no defence???

Anywho...

Can I make a small suggestion to your documentation Duncan

the dashboard in Worldpay has changed slightly and so has some of the wording...

Quote:

---

5. Also in the Configuration Options set the following if not done already:

Callback Enabled? - ensure this is ticked.
Use callback response? - ensure this is ticked.
Callback suspended? - ensure this is NOT ticked (it automatically selects if callback fails)
Payment Response Password - enter your password. Make this secure using numbers and letters. You only have to remember it long enough to enter it in your Zen Cart Worldpay module configuration.
MD5 secret for transactions - enter a pass phrase which can be up to 16 characters long and include spaces. You will need to contact WorldPay technical support first for this to be enabled.
Note: You will find more information on how to configure your WorldPay installation here: http://www.worldpay.com/support/kb/m...ect/rhtml.html

---

should read

Quote:

---

5. Also in the Configuration Options in Worldpay installation set the following if not done already:

Payment Response enabled? - ensure this is ticked.
Enable Recurring Payment Response? - ensure this is ticked.
Enable the Shopper Response? - ensure this is ticked
Suspension of Payment Response? - ensure this is NOT ticked (it automatically selects if callback fails)
Payment Response Password - enter your password. (and then again to validate, do not tick use default as it will reset password fields) Make this secure using numbers and letters. You only have to remember it long enough to enter it in your Zen Cart Worldpay module configuration.
MD5 secret for transactions - enter a pass phrase which can be up to 16 characters long and include spaces. (and then again to validate, do not tick use default as it will reset password fields)
Click on update installation (You don't have to contact WorldPay technical support anymore for MD5 as this is now done from Worldpay dashboard)

Note: You will find more information on how to configure your WorldPay installation here: http://www.worldpay.com/support/kb/m...ect/rhtml.html

---

I hope that helps

Kind Regards
AfterHouR

Err... Spoke too soon :(

I'm getting an MD5 signature could not be verified error from Worldpay.. There is something in the following that Worldpay doesn't like and yes before anyone asks, I have verified that fat fingers are compatible with the keyboard and the MD5 in Worldpay dashboard and zen worldpay module are the same :) hehehe

Quote:

---

function worldpay()
{
global $db, $order;
$this->code = 'worldpay';
$this->title = MODULE_PAYMENT_WORLDPAY_TEXT_TITLE;
$this->description = MODULE_PAYMENT_WORLDPAY_TEXT_DESCRIPTION;
$this->sort_order = MODULE_PAYMENT_WORLDPAY_SORT_ORDER;
$this->enabled = ((MODULE_PAYMENT_WORLDPAY_STATUS == 'True') ? true : false);
if ((INT)MODULE_PAYMENT_WORLDPAY_TEST_MODE !== 0)
{
$this->form_action_url = 'https://select-test.worldpay.com/wcc/purchase';
}
else
{
$this->form_action_url = 'https://select.worldpay.com/wcc/purchase';
}
if ((int)MODULE_PAYMENT_WORLDPAY_ORDER_STATUS_ID > 0)
{
$this->order_status = MODULE_PAYMENT_WORLDPAY_ORDER_STATUS_ID;
}

if (is_object($order)) $this->update_status();

}

---

Regards
AfterHouR

Sorry ignore the last post, 7 minutes had past before I could alter it.... should read


Err... Spoke too soon :(

I'm getting an MD5 signature could not be verified error from Worldpay.. There is something in the following that Worldpay doesn't like and yes before anyone asks, I have verified that fat fingers are compatible with the keyboard and the MD5 in Worldpay dashboard and zen worldpay module are the same :) hehehe

Quote:

---

if (MODULE_PAYMENT_WORLDPAY_USEMD5 == 'True')
{
$md5_signature_fields = 'amount:lang:email';
$md5_signature = MODULE_PAYMENT_WORLDPAY_MD5KEY . ':'.$OrderAmt.':' . $language_code . ':' . $order->customer['email_address'];
$md5_signature_md5 = md5($md5_signature);

$process_button_string .= zen_draw_hidden_field('signatureFields', $md5_signature_fields ) .
zen_draw_hidden_field('signature',$md5_signature_md5);
}
return $process_button_string ;
}

---

Sorry, it's 20 years since I have done any real programming, apart from the odd script alterations over the last 12 months and I have had all sorts of learning curves and constant insomnia to cope with :) So some of my basic knowledge has been fried along the way...

So any help from you experts out there will be greatly appreciated...

Regards
AfterHouR

AfterHour - I am getting this error having followed the re-installation instructions and applying the patch.

Is there anyone else out there that can help? Alan?

Carl, I am around if you want me to have a look.

Philip.

Please try this

Line 186 that says (worldpay.php from the "fix")

Code:

---


$md5_signature = MODULE_PAYMENT_WORLDPAY_MD5KEY . ':'.$OrderAmt.':' . $language_code . ':' . $order->customer['email_address'];

---

try this

Code:

---


$md5_signature = MODULE_PAYMENT_WORLDPAY_MD5KEY . ':'.$OrderAmt.':' . $_SESSION['languages_code'] . ':' . $order->customer['email_address'];

---

and put a transaction through. It appears Alan has changed the currency language construction higher up in the worldpay.php file but not changed it lower down. :oops:

We also have some other potential bugs in worldpay.php depending on shop configuration.

line 142 and 143 in the worldpay.php "fix" states

Code:

---


$callback_url = zen_href_link(FILENAME_WP_CALLBACK, '', 'SSL');
$worldpay_callback = explode('https://', $callback_url);

---

and further down on line 181 we have this

Code:

---


zen_draw_hidden_field('MC_callback', $worldpay_callback[1]);

---

Now this is going to cause problems. Firstly, $worldpay_callback[1] does not work if one is has been forced to manually alter the script to not using SSL, One should have to do this. Really FOR EVERYONE NONSSL OR SSL, then line 143 should be

Code:

---


$repl = array('http://','https://');
$worldpay_callback = str_replace($repl,'', $callback_url);

---

and then line 181 should be replaced with

Code:

---


zen_draw_hidden_field('MC_callback', $worldpay_callback);

---

There are however still problems. Alan has omitted the $zenId variable that he had previously, so unless the cartId re-established the session in his code (I haven't checked as I have pointed out, I have no worldpay access and so must code using my imagination as to what could happen). then really line 142 should read

Code:

---


$callback_url = zen_href_link(FILENAME_WP_CALLBACK, zen_session_name() . '=' . zen_session_id(), 'SSL');

---

The above code does set up an SSL callback, but it's stripped out later and then you enter whether your callback is SSL or not when you enter the details into the worldpay admin interface (well that's what I've understood from the general installation instructions).

Thank you
Philip.

I'll correct myself too:

line 142 should probably read

Code:

---


$callback_url = zen_href_link(FILENAME_WP_CALLBACK, zen_session_name() . '=' . zen_session_id());

---

since the SSL is superflous as one apparently enters either http:// or https:// into the worldpay module anyway.

I have a rough replacement for the worldpay.php file that was in includes/modules/payment it is located here:

http://bouncing.org/worldpay.zip

it may not work as it's bee done in a rush this morning. It contains last night's modifications. Use at your own risk

There have been some errors with the beta of this module. On occasion Worldpay is not submitting the new secret password and so is being treated like a hacker :clap:

Some people will report a 302 error. Also slow servers on cheap hosts time out on the last page and so do not present the shop back to the shopper, they present a worldpay page, which apparently can be customised so I would suggest people put links on there's if possible back to their shop's front page if they are using a cheap host (I still have no access to worldpay, so I do not know how easy the customisation process is though I have seen people's logos when popping through the gateway during testing).

Things I would suggest for the development of this module. The idea that people have to edit their files depending on whether they use SSL or not is lunacy. In the includes/configure.php file there is this

Code:

---

// Use secure webserver for checkout procedure?
define('ENABLE_SSL', 'false');

---

so it is easy to work out whether the callback should be SSL enabled. You know, there are many more things that could be done to make this module easier to use and install, but it's 2am, it's not my module, and I'm going for a :smoke:.

One Very important thing and Alan Duncan should be reading this,

THEIR ARE PEOPLE HERE WHO JUST UNZIP THEIR FILES. :beta:

I.e. they are leaving a file in their directory structure which still has an exploit in it, so you should create a blank 0kb file, so that when the copy or ftp their files across they wipe it out.

Alan, are you any further forward with this?

Regards
AfterHouR

Hey Guys,

I'm nearly there with my installation with WorldPay on ZC, but it's constantly dogged with errors leaving me confused about what Ive done so far, and what I have to do.

Simply put, I need advice on the following points (please!)

1) Worldpay Returning to ZC - It doesn't do anything! No redirect or anything. I've searched this thread and can't seem to find anything that answers it.

2) The "https://<wpdisplay item="MC_callback">" payment response - the url is set to the url of the website, and when I try to change it back to this, i get a 'database error' from World Pay.

3) So I guess without point 1, the order isn't going to hit the database and update on the admin area, which it doesn't.

Any help would be appreciated.

Thankyou :lookaroun

Hello the module is not mine but I do some of the work, PM me with the database error so I can have a look, as it's best not to publish those things, we can sort out the re-direct afterwards.

Philip.

thomas - I am sure Philip may have sorted you out by now, he's a star however I had similar troubles and the fixes were quite simple:

If you don't log into Production in Worldpay admin setup then you get the database error. Log in to production, edit in Production and then switch to Test using the button at the bottom of the page if you want to edit the Test setup.

Don't add the URL of your site - add the <<wd_display... string as you are trying to do but make sure the first 3 box options are ticked.

Regards

Ahh, now this is where I admit I am flawed since I do not have worldpay access. I advised him to lok through his logs to see if the worldpay java object is attempting communication with his zencart shop (which it wasn't but the advice is still valid).

Thanks Snow-man, for covering the bits that I can't reach.

Wow - this has been a busy thread.! Glad to see that some are taking note of this module. My apologies for any errors.

I'll try to cover the various points in order:

1. MD5 coding error.

Oooops! Sorry - so that's why I couldn't get it to work. And here was me thinking my host hadn't set up the MD5 functions correctly.
I do apologise - but I did say in the installation notes that I had not tested it. And until now neither had anyone else!

2. To 'SSL' or 'NONSSL'

The following is a quote from the installation notes included with the beta fileset:

Quote:

---

4. In the WorldPay admin screen click 'Configuration Options' for the installation i.d. (usually bottom of screen). Enter the Callback URL exactly as follows (including case):

https://<wpdisplay item="MC_callback">

N.B. If SSL is not enabled on your website the Callback URL should be:

http://<wpdisplay item="MC_callback">

Also in /includes/modules/payment/worldpay.php:

Un-comment out lines 134 & 135
Comment out lines 136 & 137

---

Since these notes were written WorldPay changed the way it handles test and live transaction - they are now directed to separate URLs rather than just relying on the 'Test Mode' value to direct the transactions appropriately. I therefore added the code at lines 53 to 60 to handle this. This moved the rest of the code down so the last two lines of the above should now read:

" Un-comment out lines 140 & 141
Comment out lines 142 & 143"

I think you will find that this works perfectly adequately - although Philip's method is more elegant.

I agree with Philip that it would be better to pick this up automatically but in my defence the default is SSL as this is how it should be configured. What is anyone doing passing customer name and address details insecurely over the internet! I don't make any apologies for making it difficult for someone to do this insecurely.

In any case I have limited time to support this module as it is.

'SSL' is not superfluous as this sets the path to the secure server which may not be the same as the path to the non secure server. The path to the secure server is set in the configure.php file. For some (those with their own security certificate) the two paths will be:

http://www.myserver.com
https://www.myserver.com

but for those using a shared security certificate the paths may well be:

http://www.myserver.com
https://secure.sharedserver.com/www.myserver.com

Just replacing 'http' with 'https' will not work.

3. The Missing $zenId

It's not missing - I deliberately removed it. The session ID is passed to WorldPay as cartId - see lines 124 and 135. WorldPay pass this back along with callback URL. When the $zenId was included in the callback URL it got included twice. Now that is superfluous!

4. Blank Obsolete Files

Now I never thought of that. Good idea - but what about those who are installing the module for the first time? They will end up with a lot of empty files on their server for no reason. I'll give it some thought before the next release.

LASTLY

Basically the module works out of the box if the installation instructions are followed. Don't muck about with the callback URL or try to set anything different from

"https://<wpdisplay item="MC_callback">" or
"http://<wpdisplay item="MC_callback">" if you must (but remember to make the code changes as per the installation instructions).

Implement the security features and welcome your customers to your store.

The most common problem people have is callback failure. My opinion is that this is invariably caused by the host server configuration. Ask your host if they maintain sessions. If they say 'No' or don't know - move to a host that does know and says 'Yes'. I have allowed several people with callback problems to test their sites on my server. In every case the module worked first time.

I hope I have covered everything and that this helps clarify things.

Thanks to all for your comments - especially for pointing out the error to the MD5 code. Obviously there is a need for the module out there or this thread would not be quite so long. It's nice to think that I might have been able to contibute in my own small and flawed way.

Regards to all,

Alan

Quote:

---

Originally Posted by duncanad

2. To 'SSL' or 'NONSSL'

The following is a quote from the installation notes included with the beta fileset:

Since these notes were written WorldPay changed the way it handles test and live transaction - they are now directed to separate URLs rather than just relying on the 'Test Mode' value to direct the transactions appropriately. I therefore added the code at lines 53 to 60 to handle this. This moved the rest of the code down so the last two lines of the above should now read:

" Un-comment out lines 140 & 141
Comment out lines 142 & 143"

I think you will find that this works perfectly adequately - although Philip's method is more elegant.

---

So do I, that was written after the "remove the SSL" comment as I had a gentleman with SSL and NOSSL at differing locations as you exemplify below.

Quote:

---

Originally Posted by duncanad

In any case I have limited time to support this module as it is.

---

Yes I have been up to 2AM every morning helping people with this.

Quote:

---

Originally Posted by duncanad

'SSL' is not superfluous as this sets the path to the secure server which may not be the same as the path to the non secure server. The path to the secure server is set in the configure.php file. For some (those with their own security certificate) the two paths will be:

http://www.myserver.com
https://www.myserver.com

but for those using a shared security certificate the paths may well be:

http://www.myserver.com
https://secure.sharedserver.com/www.myserver.com

Just replacing 'http' with 'https' will not work.

---

As mentioned above that's why I'd be elegant !

Quote:

---

Originally Posted by duncanad

3. The Missing $zenId

It's not missing - I deliberately removed it. The session ID is passed to WorldPay as cartId - see lines 124 and 135. WorldPay pass this back along with callback URL. When the $zenId was included in the callback URL it got included twice. Now that is superfluous!

---

Ah, but the exploitable version also had the cartId as the zenid and yet didn't use it to re-establish the session (it wasn't supposed to) and there wasn't the time to check whether the beta was "working", so quick fixes were made to be 100% sure.

Quote:

---

Originally Posted by duncanad

4. Blank Obsolete Files

Now I never thought of that. Good idea - but what about those who are installing the module for the first time? They will end up with a lot of empty files on their server for no reason. I'll give it some thought before the next release.

---

ZC themselves have "obsolete" files like index.html in includes/ that is to stop directory listing in case the .htaccess files work. I say blank them with a <HTML /> single tag in a page. I think because the define has changed then the old pages will fail, as one of the important constants has certainly altered.

Quote:

---

Originally Posted by duncanad

The most common problem people have is callback failure. My opinion is that this is invariably caused by the host server configuration. Ask your host if they maintain sessions. If they say 'No' or don't know - move to a host that does know and says 'Yes'. I have allowed several people with callback problems to test their sites on my server. In every case the module worked first time.

---

A handy hint is that if worldpay fails with a 302 error, it means the password is wrong in either worldpay or the admin section, and your zencart installation is treating worldpay as a hacker.

Ok guys. Thanks to the genius working of Phil, I've got it working.

Basically - Follow the instructions on this post:

http://www.zen-cart.com/forum/showpo...&postcount=422

And ensure the WorldPay url is set to

https://<wpdisplay item="MC_callback">.

The result of this fix isn't final, I'll stress that. I did it on a test transaction and I'm about to try it on a live one.

If you read a news report of "Man in Manchester office block hangs himself with keyboard wire" then you know it's failed.

I did offer you more help than that, but you went all quiet and shy, I thought you'd already done the keyboard thing.

I wish mine had gone so smoothly - tried everything and I still get this callback error, both for cancelled and completed transactions in test mode.

Completely stumped now....

Oh, and just to add - I went through it all with the host and he confirms that sessions are OK and it has nothing whatsoever to do with that...

Quote:

---

Originally Posted by Jon>

I wish mine had gone so smoothly - tried everything and I still get this callback error, both for cancelled and completed transactions in test mode.

Completely stumped now....

---

Smooth? Haha.

You looked at 53 and 54 on worldpay.php? There might be a line quoted out which could be useful.

That was my first issue anyway, that I was sending myself to the wrong url.

Oh and just to update you all, my live transaction did not work :-(.

I'm getting the old "This was NOT a live transaction - no money has changed hands." error message, which probably means I'm caught up with everyone else who are so close.

lol - yeah smoothly isn't a word I should have used but if someone got it working it looks smooth from where I'm sitting (with fistsfull of hair).

I'm using Phil's worldPay.php with the mods in and I've checked through everything in this thread, but still nothing works. Nothing commented out on those lines but thanks for the suggestion.

Thomas are you still getting the callback error or do you get returned to your site?

I'm getting returned to the site now. Hold on, I'll pm you my working worldpay.php.

Hello "jon" PM me and we'll talk a little while, maybe find out what's happening.

Thanks for sending worldpay.php, Thomas, but all I got was another error about the MD5 key - I checked out the differences between yours and mine, and copied over a few lines yours didn't have and that worked, but I still get the callback error.

Thanks anyway...

the main problem is that Zen have a "Recommended Services" page on their website for International Merchants to view

http://www.zen-cart.com/index.php?ma...es&pages_id=39

and most people go with Iridium or Nochex

If we can get Worldpay to work really well before Xmas, we should be able to convince Zen to add Worldpay to this page, that in itself would put a lot of confidence back into the Worldpay module that Alan wrote 2 years or so back :smile:


Peter

The worldpay module is safe secure and ready, but the best bit is that the main myths that have plagued this thread have been solved mainly due to the patience of jon> during a 36 hours bug tracking session. He put up test files on a server for me up til 3AM last night and from early this morning till afternoon when we worked out the diagnosis and the cure.

The disease is worldpay dropping the sessions and not being able to tell the ZC shops that orders have been paid for, or retunring people to the shops. All those work around's and the fault on shared hosting is not due to this module, it's due to server configuration and the adding of extra "secure" php hardening modules. In ZC admin, configuration sessions, there is the ability to share sessions, this is needed by worldpay.

What happens is this:

1. You happily shop
2. Your shopping cart is stored with a handy reference number called a session
3. The session and amount you have to pay is passed securely (now) to worldpay
4. Worldpay takes payment and hands the reference number back to the shop so that the shop owner knoes you've given the money and can ship your goods.

In the "disease" the reference number was doing nothing when worldpay passes it back. This diagnosis took a very long time and went through worldpay code, through ZC's core code and in the end to the heart of php and how some companies have se up their virtual hosting. The companies are adding a module to php to make it more secure, this sits in the background and is not visible to zencart. It encrypts the session details, it also links them to a web browser and ipaddress.

When Worldpay hands your zencart the reference number, this hardening tool kills the session before zencart can retrieve the details from the database, and so zencart never knows that worldpay was trying to pay. A hack is to really pass the session number through a different variable, then pull the details out from the database, and those talented people that wrote that hack should be congratulated for being able to work around a disease without knowing why it was happening.

In the case I was working on, it's called suhosin and I have "cured" the disease on one server so far. I can also write tools that will spot if the disease is present and inform shop administrators of how to work around it, because in this case techincal support of the virtual hosting company didn't know how the additional php module worked and what it was doing.

jon> has been great, I have 500 odd debugging emails from scripts he put up on the server as we followed the path from worldpay to the core configuration of the server. So the really funky news which is why everyone should dance, is that there's bugger all with Alan's or my secure sections of code. Worldpay will be ready by this weekend. Tomorrow I am being electrified for my own good in the morning so will be slightly unavailable but then will work on unifying the beta code and the security fixes for a single module installable module and then I'll work on the instructions and the warning system in case one is in danger of catching the "dropped session" disease and a vaccination.

Thank you
Philip.

great news, well done Jon & Philip, tremednous :clap:

What is the name of the offending PHP module that does the hardening bit without realising that is messed with Alan's code ?

silly me - I found it - Suhosin

http://www.hardened-php.net/suhosin

Yep, it has been a trawl, I have to say. Nothing new in this thread, though, eh?

I was able to provide the patience and a dogged determination to do whatever I could to help get this thing working properly, without everyone having to do this, then change that, then add this line of code, etc., but I can't take any credit whatsoever for the skill in being able to diagnose what was happening at each stage. Or for doing what now needs to be done.

Philip is currently smoothing things out on our server and doing what's necessary, so any time soon, we can all open our doors and start grabbing those orders with complete confidence (and without errors). Yay! :-)

That may not be the only module, but now we know what we are looking for (strangely encrypted sessions in the database is one big giveaway now) and it only requires a small config change to make everything work so everyone should be dancing.

What's interesting is that it protects php invisibly on a virtual host, because the bulk hosting end of the market has no access to their log files so can't see that something is examining their sessions for possible security issues and then locking down. It would be a great piece of software for running WorldPay itself, as it stops people intercepting sessions URL variables or session cookies, so if one only need to stay in the same website it's fantastic, it's a right bugger when you need WorldPay to talk outside of it's box and it doesn't inform you that it's going to cut the lines of communication.

That jon> bloke, seriously, he has done a sterling effort, because he could just have walked away from WorldPay and we would never have known the answer and the same old "I don't get told a payment's been made" or "my session's being dropped" or "I have a redirect failing on line 22 because the headers have already been sent". ALL of these bugs can be caused by that additional invisible module. (some of them can be caused by people being silly too, but hell, I'm one more step closer to enlightenment ).

Philip.

sterling work Jon and Philip, good to know that we have chaps like you around who can persevere with this sort of stuff and come up trumps :bigups:

Hi,

I'm having the same 302 problem as others. I could really use some help as a php5 upgrade brought down my payment system. It's not a high volume site but still...

WorldPay Java HTTP Request Object is attempting to acces and comes back with the 302, resulting in an error and failure of callback. I'd love some help. I just did a clean install of the module, applying Phil's new worldpay.php.

I tried to have a look in the database for oddities in the session table but didn't really know what to look for.

I'm not using ssl, btw.

Regards,

Niklas

Now have you installed the new callback password ?

In fact PM me and I'll have a look.

I am exceptionally unwell at the moment though, so be quick while I am still up.

Thanks to Philip for helping me out.

Turned out that WorldPay was not submitting the password. I tried entering the password into the test environment (as well as the production evironment) and suddenly everything worked. Very peculiar.

Yes that WP-thing is quite stupid in that way.

You can not change config in test environment, and you can not log in and then go to production to change this.

You have to log in to production first, change config there - and then enter test environment ... :)

Maybe I should clarify, in case someone else runs into a similar problem. the site has been live for a good year now. When I added the password to the production environment, I thought that was enough. It turned out, however, that I needed to add it to test environment as well.

Niklas

Quote:

---

Originally Posted by niklasalbin

It turned out, however, that I needed to add it to test environment as well.

---

That sounds strange, and it's not what WP support told last time I had contact with them. But maybe they has changed it after that, since it was so stupid. :)

Good Evening/ Morning.

We now have a release of "secure" (depends on the person installing really) code, all in one zip file available from

http://########################.co.uk/WorldPay_ZC1.3.x_v1.01.zip

Install Instructions - unzip the file, copy the docs section into your shop. then go to http://YOUR_SHOP/docs/worldpay and they'll be more exact instructions. DO NOT COPY includes over until you have read the documentation.

Changes.

This is what I call an interim version. It is a compilation of the beta version and security fix Alan Duncan created and finished. It is then my improvements, a restructuring of the documentation so that it does not overwrite ZenCart's own documentation and licence and has one new feature plus some hooks for some others. It also features automatic SSL detection so no editing by hand of files should be required.

The new feature is Debug mode, where the server can email out whatever the WorldPay server is sending back to the shop. Never post a debug email to a forum, this is a fully written up feature that I've been using to help other people with their installations (I used to provide them with a substitute file that did much the same thing) and has proved essential to check that WorldPay is

• communicating with the shop and
• that it's sending the right passwords and MD5 (hence why you don't post this to a forum as everyone would know your password)

The reason I call it an interim version, is that in the next version people upgrading will not have to re-write their passwords and MD5 strings.
In the history of this module, with every upgrade the administrator has had to re-enter their details, plus I do not like the way that the passwords are on display to anyone walking past a desk.
There is a new feature at the moment, where if you have any files left over from the previous versions with possible security exploits; then the system will tell you so that you can delete them. During installation the module will try and get rid of them itself, but may not have the correct permissions, so it'll then annoy you to remove them.

Version 2.0 will perform a proper "upgrade" rather than re-install, version 2.0 will also analyse the server to see if there is anything likely to cause problems, and finally version 2.0 will fork into a version available here, and a SBD (Secure By Default) version to be hosted on my website. The code will be similar and also GPL, but whereas ZenCart's philosophy is to let the user choose, so the "normal module" will allow empty passwords or MD5 strings, the SBD module will disable itself until passwords and security features are filled in. From a database point of view, the normal version when upgrading will be the same as previous modules, so if the shop owner is running without passwords, so be it. If the SBD version is installed it will not "activate" until it is secure (thereby taking away choice in the interests of security).

From Version 2.0 a new thread will be started and this one will close. The security exploits and session problems of the past have been solved and it would be better if new users didn't have to search through 44 pages of irrelevant information to get some help or even file a new bug report.

Thank you
Philip.

Already a couple of bug fixes, all credit to Carl, one in the documentation where I forgot some people would be getting error messages because I forgot to set a variable. AND a more important one where the module now correctly generates a DECLINE response at worldpay but filling in the cardholders name as REFUSED.

This version is available from

http://########################.co.uk/WorldPay_ZC1.3.x_v1.02.zip

and probably goes to show the importance of having a warning system when the module is out of date. ASFAIK the REFUSAL mechanism of this version may not work because I haven't tested it !

My concern has been to get Authorised transactions and callbacks working securely, so there may still be bugs in the system if someone's card is declined.

Thank you
Philip.

p.s. It also shows the need for a new thread Carl mentioned pages and pages ago that worldpay had changed it's decline mechanism and I have not read that far back into the thread and I am now responsible for the project !

New version at

http://########################.co.uk/WorldPay_ZC1.3.x_v1.03.zip

only one change, unfortunately some legacy code was informing shoppers that though they had paid successfully, they were still in Test Mode, the correct emails were still going out, so they would t least of had some form of confirmation. Thanks to snowy2007 for spotting this.

Philip.

Sorry, I have been absent from the board for a while and not left any feedback.

One of my problems, identified by Philip was my slow hosting which didn't help things when trying to debug the module..

Any how, new host in place, I have installed the newest version from Philip as above v1.03. For whatever reason, it didn't work first time but by all accounts that was something to do with the way my hosting was set up and nothing to do with the module. Philip no doubt will fill in the blanks, on this.

To cut a long story short, with all the hard work and determination from Philip, initial tests of this module works!!! with MD5 and secure response......

I can't thank you enough Philip

Kind Regards
AfterHouR
http://www.allgoodideas.co.uk
Collectable walking sticks and canes for the discerning customer

I have installed the new mod ok and i can make a payment through the site.

However no order shows in my admin and the payment screen does not return back to my site after completion.

*EDIT* My fault, one missing passowrd and it appears to work fine now!

Glad you sorted it out OK.

I have made sure that my passwords in Worldpay test, match the passwords in production, as was mentioned in a previous post. I didn't want any ambiguities causing problems, I have had enough of those with hosting providers :)

Regards
AfterHouR
http://www.allgoodideas.co.uk
Wedding canes and stickmaking supplies

Quote:

---

Originally Posted by DVDTitan

*EDIT* My fault, one missing passowrd and it appears to work fine now!

---

Pillock ! (I'm the author), use the debug feature next time and check if worlpay is sending the field callbackPW.

Hey Again guys.

Good job on the updated module. Discovered a few things I've missed.

Anyway, I installed the module on a 1.3.8 (as opposed to a 1.3.7) and removed all old files.

I set everything up according to your helpful documentation and tried a test transaction.... it goes back to how it was before. i.e. a thankyou page, but no callback to the old site.

When I get the debug email (awesome idea by the way) I get 'password failure' at the top. It's odd, since I've ensured that both md5 and payment response passwords are exactly the same.

Not tried the live one yet.

EDIT. looking at the above post, no callbackpw has been sent. What could cause this?

Hi thomasharding

Make sure the passwords in both envirnments of worldpay are the same, for instance you md5 and payment response in test environment are set to 123456, you must also have the same in your production environment ie 123456

I hope that helps

Regards
AfterHouR
http://www.allgoodideas.co.uk
[email protected]

Hi again.

Yeah, the test worked fine this time. The callback worked fine!

However, I'm back to square one again when doing the live transaction. I still get the "Money has not changed hands" message.

The debug email states that it was a success and it's passed everything through fine. I really do. not. know. whats going on!!!

Thanks again!

I know this isn't a fix but a workaround, if everything is going through fine look for that text in developer toolkit and edit out the text between the quotes, so it is not displayed on screen.

Hahaha, I never thought about that. Looking at things from that perspective, the order has gone through and shown up in the admin area, along with the payment to worldpay (which was authorised).

I've been having the same error message for like a month now, so by all means it could have been sorted long ago!

Must be a very complicated reason why it does that and an even more complicated fix, or a dead simple one if you are Philip....

But works for me ;)

Happy to help

Kind Regards
AfterHouRhttp://www.allgoodideas.co.uk
collectible walking sticks and canes

Quote:

---

Originally Posted by thomasharding

Hi again.

Yeah, the test worked fine this time. The callback worked fine!

However, I'm back to square one again when doing the live transaction. I still get the "Money has not changed hands" message.

The debug email states that it was a success and it's passed everything through fine. I really do. not. know. whats going on!!!

Thanks again!

---

I think you are using 1.02 instead of 1.03

Hello

Just installed version 1.03 on a 1.38 store with ultimate seos/admin profiles/image handle installed - and the one thing I can't get is the call back to work.

Have double checked all passwords with clients.

Would this be because of the ultimate seos? or could it be because the site is not yet live so I am using a live test url instead of the correct site url (world pay have the correct site url).

I have turned on the debug mode - but no email has came through.

Stuck and don't even know where to begin to look - started going through this thread but haven't found anything yet.

Quote:

---

Originally Posted by peanut77

Hello

Just installed version 1.03 on a 1.38 store with ultimate seos/admin profiles/image handle installed - and the one thing I can't get is the call back to work.

Have double checked all passwords with clients.

Would this be because of the ultimate seos? or could it be because the site is not yet live so I am using a live test url instead of the correct site url (world pay have the correct site url).

I have turned on the debug mode - but no email has came through.

Stuck and don't even know where to begin to look - started going through this thread but haven't found anything yet.

---

So are you saying that this server is not "on the net" ? Getting the debug email is quite important. PM me and I'll have a run through the theory, because if the server is not findable, then worldpay is not going to be able to retrieve the callback.

Are you getting error messages from worldpay about the callback, those type of things would be helpful.

Philip.

As promised Version 2.0 of the worldpay module have been released by the end of the month.

The new thread is here:

http://www.zen-cart.com/forum/showthread.php?t=112021

Please do not post any more questions here unless they are about 1.0 versions of worldpay and you are strongly advised to upgrade.

Please use the new thread, can a moderator close this thread ? as it is 44 pages long and deals with insecure code dating back 4 years.

Thank you
Philip Clarke.