WorldPay Module version 3.0 - Support thread

niccol:

Yes.

Then issue yourself a voucher. Use the voucher to buy a product. You should get an email from Worldpay about the payment.

I have sent you a PM.

Nick

Thanks so much for your help. Just emailed you. If we find a solution I will post it here in case anyone else is having the same issue.

One more thing I was hoping to ask as well. Has anyone got the plugin to work with Google Analytcis? Currently, Google Analytics records all sales made on our site using paypal, but none of the ones using Worldpay. Thanks.

bonheddwr:

I've just noticed a major issue with this plugin, has anyone else had the same issue? We don't often offer coupons, but have just offered a 20% discount for a week to previous customers on our site. People can choose to pay via Worldpay or Paypal.

There haven't been any issue for customers who have chosen to pay via Paypal, but for the customers choosing Worldpay, when they insert the Coupon Code, it is worked out how much they should pay on our site with 20% off, but when they leave our site and arrive on the Worldpay site ANOTHER 20% has been taken off!

Is this a bug, or just an issue with our site?

v1.5.5 // https://www.welsh-lovespoons.co.uk/

Thanks for any advice.

Unfortunately I haven't manged to solve this issue. What I have done is:

1, Turned on debugging. I now receive an email every time somone orders via Worldpay. I've looked through the ones that have used the coupon code and cannot really see what's going wrong. It seems that both the correct and incorrect prices are included in the emails.
2, I've tried a different Voucher and code.
3, I un-installed the plugin, and installed a clean version.
4, I noticed that this issue didn't arise on another website that I run using the save version of Zen Cart, I therefore copied all of the plugin files from the website cadwyngifts.com (where there wasn't an issue) to welsh-lovespoons.co.uk (where there is an issue).

There is still no issue with Paypal on either site when using a coupon. The correct amount is sent to their site. ANy advice on what next I can do? Are there other files (not the plugin ones) that I should try to copy from the website where there isn't an issue to the one where there is an issue?

Thanks for any advice.

Unfortunately I haven't managed to find a solution to the above issue. If I do find a solution I will let you know.

Regarding my second question, has anyone managed to get Google Analytcis to record sales made via the Worldpay plugin?

Hi, I've spent many, many hours trying to nail the 302 redirect issue as this suddenly started happening on a website I develop a few weeks ago.
We're running ZC 1.5.5f and had successfully upgraded the WP module to V3, as part of this we had to upgrade PHP on the server, but had got it all running just fine.
It then stopped working and we are getting the 302 issue - it looks like WP have made some changes their side in relation to PCI, and I wonder if anyone else has experienced any issues since the end of April 2018? We've never needed MD5 or SSL as all financial transactions are handled in WP, but I wonder whether this is now a requirement?
Any help gratefully received!!

philjclarke:

Hi, I've spent many, many hours trying to nail the 302 redirect issue as this suddenly started happening on a website I develop a few weeks ago.
We're running ZC 1.5.5f and had successfully upgraded the WP module to V3, as part of this we had to upgrade PHP on the server, but had got it all running just fine.
It then stopped working and we are getting the 302 issue - it looks like WP have made some changes their side in relation to PCI, and I wonder if anyone else has experienced any issues since the end of April 2018? We've never needed MD5 or SSL as all financial transactions are handled in WP, but I wonder whether this is now a requirement?
Any help gratefully received!!

Hi,

A couple of things for consideration.....

1. What PHP version are you running? Zen v1.5.5f is best suited to PHP v7. This module hasn't been updated for sometime and most likely running PHP v5 or v6.

2. I have received email from WorldPay this week talking about changes to PCI compliance, most of this is aimed at Virtual Terminal connections but does extend to people running "old style insecure connections (legacy)".

3. WorldPay is an off site payment module, changes made to PCI compliance shouldn't influence your store to badly as long as your "handover" is secure (CURL or SSL required). Also make sure your return is entered perfectly on WorlPay configuration setup (on worldpay site).

4. Have you made changes your zen cookie settings?? I had an issue that stopped this working for a long time and it was all the cookie settings in Zen.

If you are really stuck still I could forward v4 that was never released. No promises it will fix your problem but could be worth a try. It's only had some minor changes but works more stable for me and causes a lot less callback failures than v3. Let me know if you want to give it a go.

Good luck

Regards

bonheddwr:

Regarding my second question, has anyone managed to get Google Analytcis to record sales made via the Worldpay plugin?

Yes Google Analytics Plugin works perfectly for me.

Also I don't have the discount code issue you experience either....... I do offer codes regularly fixed price and percentage based and they work and process with the worldpay plugin fine.

Maybe a repair install/upgrade for your zen store could be a good place to start.

Good luck

Thanks for speedy reply @SpaceMonkey! -Yes, we're running PHP v7, and I've made a few changes to cookies etc... but have changed them back/tried various options. I thought the PCI changes by WP would be a red herring but seemed so coincidental! I'm sure I read a post at some stage in the past regarding PHP config changes that needed to be made with v7, which I made (but didn't document - doh!) to do with redirects, and I wondered whether that may be an issue, although a bit flummoxed as it was all working...
If you do have a later version I'd certainly give it a go as I'm running out of ideas!
Cheers

philjclarke:

It then stopped working and we are getting the 302 issue

Temporarily removed, redirected.

Make sure the following settings are as follows:

Admin/Configuration/Session

Cookie Domain = True
Check SSL Session ID = True
Check User Agent = False
CHECK IP ADDRESS = FALSE

That is the required setup to stop 302 errors if callback failure causes issues...... At least it was for me.

philjclarke:

If you do have a later version I'd certainly give it a go as I'm running out of ideas!
Cheers

I will grab a copy out when I get home later this eve and forward a link via PM.

Yeah - thanks for posting that - it's what we also have in the current config

Looking at you call back failure email from worldpay is your call back string similar to:

https://yourdomain.com/index.php?main_page=wp_callback&zenid=4c5715ae607bd4ddfea0faff07f7b5db ??

If not what is the string?? That would be a good clue what it's looking for.

Are you using CURL connection or SSL.

Regards

Yes, call back string is the same structure - followed by "NOT OK, received. HTTP status 302".
Not using SSL on the site or in any config either.
Thanks for your help on this @SpaceMonkey!

philjclarke:

Yes, call back string is the same structure - followed by "NOT OK, received. HTTP status 302".
Not using SSL on the site or in any config either.
Thanks for your help on this @SpaceMonkey!
PM with download link sent. Luckily was already on my cloud.

I will test a CURL with php 7 later and look to see what I get. :yes:

Great, thanks for this - will check it out!

philjclarke:

Great, thanks for this - will check it out!

My colleague has suggested your CACHE is not properly set....... Does it have to correct writable permissions, WorldPay will recreate the session of a logged in user from a new user agent and IP. Therefore the CACHE must be writable. Worth a check :smile:

SpaceMonkey:

My colleague has suggested your CACHE is not properly set....... Does it have to correct writable permissions, WorldPay will recreate the session of a logged in user from a new user agent and IP. Therefore the CACHE must be writable. Worth a check :smile:
Not sure how to check this - there is a cache directory at the root of the install and I've given everything 0777 permission - is there anything else I should check?

Yeah that's right 0777 and yes probably the root cache used, you can check in

Admin/Configuration/Sessions

Session Directory = /home/#######/public_html/cache

This folder must be 0777 permission

philjclarke:

I've given everything 0777 permission

Ummm.... Please check that you have followed the installation instructions properly. Only certain directories should be 0777. Don't want to teach basics but that comment left me wondering. :unsure:

Regards

***
Extract from the Zen Cart installation instructions***: AVAIL HERE
Some folders and files need special "writable" permissions for use in Zen Cart. "Writable" typically requires 777 permission. (Your hosting company may only allow 755 as writable, and using 777 may cause blank screens when accessing your site. In that case, use 755. Ask your hosting company for direction.)

As such, you need to change the permissions on the following directories to 777 (read/write/execute). If your program allows you to set these permissions "recursively", choose that option.
/catalog/cache
/catalog/images
/catalog/includes/languages/english/html_includes
/catalog/media
/catalog/pub
/catalog/admin/backups
/catalog/admin/images/graphs

Note: open the catalog/images directory and change all of the subdirectories and their subdirectories to 777 as well. For example (this is a partial list):
/catalog/images/attributes
/catalog/images/banners
/catalog/images/categories
/catalog/images/large
/catalog/images/large/dvd
/catalog/images/manufacturers
/catalog/images/medium
/catalog/images/upload

NOTE: If you miss any of the images directories and subdirectories inside /images and try to use them later, you will get an error message that you cannot write to these directories.

As for other files, they can be CHMOD 644, or 444, depending on your webserver configuration. Folders don't usually get set below 755.

Sorry - when I said 'everything' I just meant on the cache directory - thought I'd take the nuclear option with it!
Still no joy :(