WorldPay Module for ZenCartv1.3x

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.