WorldPay Module version 2.0 - Support thread

Epic Fail on my part... dont worry Ive fixed it I think.

Partial Epic Fail on my part...

Problem im having now after over a year of fantastic working success, is that we have recently upgraded to the new version of Zen cart, I have installed workldpay6 latest ver 2.1 I think, and the transactions are going through, but they are not getting posted on Zen Cart, ie the transaction gets stuck on the Thank You Page (fully branded), doesn't return to our site, and also the order doesn't get posted on our server so we don't know that we have a new order.

The not being returned isnt too much of an issue, but missing orders is HUGE.

Can anyone shed some light on this?

Hi Out2Lunch. What version are you ugrading to? I am about to go to 1.39h next week - The new PCI data security arrangements means that Worldpay won't accept payments from us if we don't have the latest version running. I have found that 1.38a worked perfectly since I installed it - not really looking forward to finding the needle in the haystack again if 1.39h causes problems. Did you upgrade to the latest version of PHP as well? (this is also a requirement of the PCI stuff)

Are you getting any error messages? If the shop doesn't return to the store, then the very useful debug feature won't give any information either...

Did worldpay shed any light on the problem? I have found that the Singapore support guys (I am in Oz) are actually quite useful.

Regards
FEQ

Yes we upgraded to 1.39h (Complete new install to J, then file patch to h), PHP upgrade to latest ver too.

Our host was hetting hacked through PHP, took all SQL sites off line for security made us all upgrade etc.

We haddnt realised worldpay wasnt working, as this is the slow time for us, and sales are minimal atm, had a load more paplay sales, when a customer phoned us yesterday saying wheres my clobber we said we had no order from them, so they sent us the worldpay receipt and thus we worked out its borked.

We arnt getting any debug emails that say anything is wrong. So I am at a complete loss on what to do here.

No I havent phoned Worldpay support yet, I though I would post here first to see if anyone else is having this problem.

lee_whitehead:

the rest of the callback part works fine, I have my header, navigation, footer, links, images, etc... except there is a big main body blank area that says nothing.
Did you find a solution for this?

The Guy who wrote the current Worldpay module had a spat with one of the forum moderators and he was banned (thanks moderators), so there is pretty much no chance he will contribute to a fix if there is a problem, meaning for me a new shopping cart may be the only choice.

Having said that, if you are not getting the debug emails (I assume you have turned these ON in the module - and NEVER post the content of these, it has all your logon details) then the customer is not being returned to your store. This can occur if the customer closes the browser instead of clicking the cancel purchase button. The shop can't notify you if the customer doesn't allow it.

Alternatively, maybe Worldpay has a problem with your callback script. If it can't find the script, or has a problem with it it doesn't know where to return the customer to.

When you run in test mode, are you returned to your store? Other things to check:

1. your callback settings in Worldpay's setup.
2. Have you got SSL up and running properly?
3. Check that you have made the payment response URL point to your SSL site (ie https:// instead of http://)

Remember also that Worldpay's setup is a bit dodgy - last time I used it, the command "copy to production environment" didn't work, so all the changes I made in the test environment didn't copy across. Apparently while there is a test environment and a production environment, I was told that I shouldn't use the test environment - I should put the shop in test mode and make all changes to the production environment. Go Figure... Hope something here helps!

webchills:

Did you find a solution for this?

Hi Webchills,

Maybe a long bow here, but I had hassles with the callback page. Turned out that the Worldpay servers had a problem parsing if your callback page had divs that DIDN'T have whitespace between tags.

ie <this div><didn;t work>

<this div> <did work>

When I manually inserted whitespace between the divs my callback page went from looking like a dog's dinner to perfect display.

FEQ:

The Guy who wrote the current Worldpay module had a spat with one of the forum moderators and he was banned (thanks moderators), so there is pretty much no chance he will contribute to a fix if there is a problem, meaning for me a new shopping cart may be the only choice.

Having said that, if you are not getting the debug emails (I assume you have turned these ON in the module - and NEVER post the content of these, it has all your logon details) then the customer is not being returned to your store. This can occur if the customer closes the browser instead of clicking the cancel purchase button. The shop can't notify you if the customer doesn't allow it.

Alternatively, maybe Worldpay has a problem with your callback script. If it can't find the script, or has a problem with it it doesn't know where to return the customer to.

When you run in test mode, are you returned to your store? Other things to check:

1. your callback settings in Worldpay's setup.
2. Have you got SSL up and running properly?
3. Check that you have made the payment response URL point to your SSL site (ie https:// instead of http://)

Remember also that Worldpay's setup is a bit dodgy - last time I used it, the command "copy to production environment" didn't work, so all the changes I made in the test environment didn't copy across. Apparently while there is a test environment and a production environment, I was told that I shouldn't use the test environment - I should put the shop in test mode and make all changes to the production environment. Go Figure... Hope something here helps!

Thanks for this reply, I did not know about the falling out between Philip Clarke, I have now found his new website, and emailed him there.

He is going to look at the code for php5 inconsistancies etc but will NOT be updating the version on Zen Cart, but he will be hosting it else where in the future (not defined as yet).

So it sounds like good news/ bad news issues as this sound like its going to become a pay for module, (not the end of the world depending on the proice imop).

Anyhoo I will update this thread when I have a reply from Philip Clarke.

hi,

im using version 1.3.9f and version 2.09 of the world pay module.

the payments are taken correctly, but after you click on pay, you are redirected from RBS to my site but a blank main page, not the success check out page.

the payment response URL is set to

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

any thoughts

regards

Dale

directstoves.co.uk

Hi Dale,
I would be contacting Worldpay and asking them what error response their servers are generating - if your callback isn't returned properly, their servers will register an error message that may help you track down the problem - or at least save you a few handfuls of hair...

The new PCI Data security requirements will require you to have the latest version of Zencart (so 1.39h), PHP etc to continue to qualify to take credit card payments

I notice you aren't using SSL on your site. I recall that installing my own SSL made interacting with the worldpay callbacks that little bit easier.

Thank you for the advise, i have upgraded now to the new version of zen, also installed SSL, but still no joy, so have sent a email to RBS.

but thanks for response will keep you posted

regards

Dale

this is the reply from RBS, thought it might help others

unfortunately i have no clue how to do this, any one simplify it :)

Dear Dale,

Thank you for your email.

Your callback script server should open a 'Thank You' page that is shown to your shopper who is still on our server.

The Thank You page that your callback server opens must be a HTML page (it cannot contain any script tags).

In this HTML page you should have a META tag (with a refresh rate of say 5 seconds, not 0 seconds) that re-directs your shopper from our server to your web server.

You will need to check what 'Thank You' page your callback server is opening to say thank you to your shopper and check the website that it is re-directing your shopper to, this re-direct will need to be corrected if it is going to the wrong URL on your website.

Also check that the 'Thank You' page is a HTML page without any script tags, as the script tags will be stripped out when the 'Thank You' page is shown to your shopper on our server before it re-directs back to your website.

FEQ:

Hi Webchills,
Maybe a long bow here, but I had hassles with the callback page. Turned out that the Worldpay servers had a problem parsing if your callback page had divs that DIDN'T have whitespace between tags.
ie <this div><didn;t work>
<this div> <did work>
When I manually inserted whitespace between the divs my callback page went from looking like a dog's dinner to perfect display.
Thanks! I finally found the <div>.
I saw your posting some pages before but did not find any suspicious divs.
Turned out that there was a ```

webchills:

Thanks! I finally found the <div>.
I saw your posting some pages before but did not find any suspicious divs.
Turned out that there was a ```

What is the page that you edit the DIV's on mate????

Includes/Templates/YOURTEMPLATE/common/tpl_header.php
Posted via Mobile Device

Philip Clarke and I have spent a week working on this problem, and he has finally worked out what has gone wrong ish. I will post the message below and others can reply about this probelm if its affecting them.

Philip Clarke:

FOUND THE BUG.

The bug is in the ip addressing system. If the information that I have used to bypass the system is set up to be sent from a different ip address as would be the case in worldpay, then your ZC installation redirects to a timed out / log in again page, which is why worldpay is not recreating the session and it's not hitting the module. It's stopping before. Now evither you are running Suhoisin and something strange is going on (because normally it would not respond to one test that I have already done, where it passed) or you have change the session settings that you sent the the screen shot of. If you haven't changed the configuration settings, and the system is still set to check ip address "false" then I would also suggest turning off the "ip to host conversion", even though in theory it has bugger all to do with it and testing again.

Basically although the bug is found, and is simply that the sessions are not being recreated from a differing ip address without the need to log in. The bug is not Solved. That will take a lot more work and going through the whole session handling system to try and work out why it is not responding to the the database settings. It may also be worth setting the db Check ip address to True, saving it, and setting it to false, in case there is something in the database that is not correct, or if ZC has done something to look for "true" instead of "True" or "False" instead of "false", of it maybe that the database is blank and just displays "False" in the row on your screen, but the code is actually looking for the word "false".

It would still be worth doing a survey on the forum as to when this issue affected people because then it may be possible to isolate the part of code responsible more quickly. I can solve it, but it will take time and FTP access. You can forget about putting that file into place now. I must consider what I should do since it's not a module problem, its a Zen cart problem and they kicked me out.

Boys and Girls Philip Clarke the creator of the World pay module has managed to fix this badboy.

This is going to be an ongoing fix too, as Zen Cart team has changed the way the cart syatem works. I have tried this on my site and can verify thats its full working, with out the need of an SSL certificate... Woo Hoo is all I can say...

Philip Clarke:

You will now see how it sucks your site in to be displayed on worldpay, look at the URL and you'll see that it's not your site but theirs. You may also find that some javascript does not work on the page that is sucked in, and that the layout may have changed, although it is a lot better than most that I have seen. I have still not got around to fixing the select box bug (or even looking at it).

I have to work out what I can charge for this, but basically it's a simple fix that overrides the way ZC deals with sessions and enables worldpay to re-establish the session, and is needed on any site that does not use SSL, and it is still secure, as in worldpay must still provide a matching password to the one you have entered in the admin section, otherwise there could be the possibility of a security hole, which I am guessing is why ZC put the additional code in. I could have stripped the ZC code but that would have left a hole, plus any upgrades would have wiped out the fixes, so I had to create something new, and the interesting thing is that because it's self standing, I could possibly charge for it which would be nice to make some money for once.

Quoted in full from my email with him.

Im sure we will all know how to go about a fix for this soon, as I am not Mr Clarke, and this is his module.

Please do not PM me for the fix as I do not have it at this time.

Hi
WorldPay is working on my site for normal payments but if someone enters a discount coupon the amount is taken from the order total but ignored by WorldPay. I'm running Zen Cart 1.3.9g. Any ideas anyone please?

I am trying to work out if this mod actually works or not?
. I get the 302 callback alert (callback not working rendering mod useless). I have followed instuctions - i am not using ssl I have the right passwords and have used http://<wpdisplay item="MC_callback">.

Have the callback issues still not bee fixed?

One of my customers received this email today from WP. I am hoping some one with more knowledge than I will be able to make any necessary changes to this mod to comply with the change.

Thank You
Dave G

We have made a change to MD5, a feature which you currently use to protect the transaction parameters you send to our payment service for processing. This is an essential update, which we have made to improve security.

As a result of making this change, we now need to ask you to make some small adjustments to your payment service. Importantly, you will need to make these by the 31st of May 2011 in order to continue with your current method of using MD5.

**** What is MD5? ***

MD5 is a security feature that is used to verify that the transaction submission parameters supplied by your website to our payment gateway have not been tampered with. When enabled, it allows you to secure your choice of parameters and ensure these cannot be modified by a fraudster who could potentially change details of what has been purchased, or the amount of the transaction.

**** What changes do you need to make and important dates? ***

The changes you need to make require some small adjustments to the way in which you currently pass the ‘signatureFields’ parameter. This parameter is used by your system to list the transaction parameters that must be encrypted. It is currently sent in your order details submission.

From today, you will be able to choose between two different methods of signing your transactions. The specific changes that you will need to make will depend on which of these your system uses to generate the MD5 signature:

Static Signatures (recommended method of generating MD5 signatures)

Merchants, who encrypt the same transaction parameters for every transaction, must now specify their signatureFields value in their Installation Settings located in the Merchant Administration Interface. Please note that this replaces the need to send the signatureFields parameter in your order details submission.

Dynamic Signatures

If however your system encrypts different transaction parameters for each transaction passed, you must now add the signatureFields parameter in the string used to calculate the MD5 signature and replace the current colon separation of parameters with semi colons.

It is important that you make the required changes by the 31st of May 2011.

*** Next steps ***

For further information and about this update and instructions on how to make the required changes please read the news page entitled ‘MD5 Update,’ by following the link below:

http://www.rbsworldpay.com/support/bg/index.php?page=news&sub=md5&c=UK