|
Michael King
|
October 3, 2014 at 9:40 am
{WP 4.0, EE4 4.3.1.p no add-ons, http://www.ninthdistrictpta.org]
In the middle of my first event, registrations just starting to pick up.
Two registrations paid with PayPal so far – in EE4 PAYMENT DETAILS the GATEWAY shows PayPal, but the GATEWAY RESPONSE field is blank. In both cases, I had to manually open the registration and click the APPLY PAYMENT button to get them to the APPROVED status.
In PayPal, in both cases the IPN log shows SENT and even RESENT after I resent the messages. My site’s /transactions/ page says “No IPN (or incomplete IPN) received.”
I have double-checked all the settings that I can find. PayPal says “sent it” & EE4 says “didn’t get it” as far as I can tell. Any tips on troubleshooting?
|
|
Tony
|
October 3, 2014 at 10:07 am
My site’s /transactions/ page says “No IPN (or incomplete IPN) received.”
When you navigate to thee transactions page your are not supplying an IPN with your request, therefore you will always see ‘No IPN (or incomplete IPN) received.’ when you visit that page manually.
Is the Paypal Account you are using a verified Business/Premier account?
Have you set the response URL for the IPN’s within your Paypal Account? Instructions are here:
https://eventespresso.com/wiki/how-to-set-up-paypal-ipn/#paypal
Also, 4.4.3 is the latest version of Event Espresso 4, I would recommend making a full site backup (all files and the database) and then updating to the latest version.
|
|
Michael King
|
October 3, 2014 at 10:19 am
“using a verified Business/Premier account” – Yes, Business.
“Have you set the response URL for the IPN’s within your Paypal Account?” Yes, and double checked, to http://www.ninthdistrictpta.org/transactions/. Also made sure IPN Messages are enabled in PP.
“you will always see ‘No IPN (or incomplete IPN) received.’ when you visit that page manually” – then why have that message? It makes us think something might happen… Something like “Move along, nothing to see here, and don’t monkey with this page” would be much more useful.
I get no error messages or any other outward indications that something is wrong that I can find in PP or EE4, other than the absence of the desired result.
|
|
Michael King
|
October 3, 2014 at 10:32 am
Further to the above, looking into the PP IPN message log, that says “DELIVERY STATUS: SENT” and “HTTP RESPONSE CODE: 200” which I take to mean that the IPN message was sent, some serve responded with “200 OK.” Right?
Where do I look next?
|
|
Michael King
|
October 3, 2014 at 10:36 am
Also, in EE4 “Use the Debugging Feature and the PayPal Sandbox” is set to “NO”
And just for the record, I am overall very happy with EE4, and have managed to fix some of my own problems without outside assistance 🙂
|
|
Tony
|
October 3, 2014 at 10:46 am
Hi Michael,
I did a little digging on your site and noticed you are running W3 Total Cache.
Your site is serving up a cached copy of the transactions page which will prevent the IPN’s from registering.
You’ll need to set all of EE’s critical pages on the do not cache list, we have instructions on how to do this here:
https://eventespresso.com/wiki/setup-nocache-exclusion-rules-event-espresso/
Once you have done that be sure to Purge/Delete the cache.
|
|
Michael King
|
October 3, 2014 at 11:29 am
Ah ha – there’s some useful information! That’s a very helpful wiki article – did I miss some place that pointed to that? I’m pretty sure it’s not mentioned on the IPN troubleshooting page.
Anyway, no-cache not set as instructed, page cache is flushed and I’ve made a note of this in case I ever go thru this again – we’ll see what happens with the next registration.
Thanks!
|
|
Tony
|
October 3, 2014 at 12:06 pm
It was not mentioned on the IPN troubleshooting page no, I think the reason for this is the issues caused from caching are not specific to the IPNs but dynamically generated content as a whole.
However I do think it would be a good idea to include a reference to caching within those troubleshooting steps so have updated that document, thank you.
|
|
Michael King
|
October 3, 2014 at 4:51 pm
Excellent, hopefully the next person with this problem can benefit from my experience now – thanks!
|
|
Michael King
|
October 7, 2014 at 4:55 pm
IPN is still not working for PayPal payments…
– per earlier guidance, W3TC is set to not cache the EE4 pages, including /transactions/ and CloudFlare (also used) set to never cache the same pages.
– I can see the client’s payment in my PP account.
– IPN log says the IPN message was sent with a status code of 200, which I believe means “OK”
– In EE4, the Payment DEtails says in big red letters “No payments have been applied to this transaction yet.”
– Per some EE4 doc, I FTP’ed into ninthdistrictpta.org/wp-content/uploads/espresso/logs looking for the error log, but there’s nothing there except an .htaccess file.
So, any advice for troubleshooting? or where to look for clues? I’m approaching a registration deadline this Friday, so I’m expecting traffic to spike; I’d like to not have to manually Apply Payment on every on-line registration…
|
|
Josh
|
October 8, 2014 at 8:26 am
Hi Michael,
Caching may still be the cause of the issue. Here’s what’s at the bottom of the source of the registration page:
Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/
Page Caching using disk: enhanced (Requested URI contains query)
Database Caching 35/84 queries in 0.054 seconds using disk
Served from: http://www.ninthdistrictpta.org @ 2014-10-08 07:19:55 by W3 Total Cache
What this means is the page is being cached, and the database is too. Caching both of these can interfere with the payment status (which is recorded to the database) being updated by Instant Payment Notification from PayPal.
In most cases (especially if you’re on a shared host) Database caching should be kept disabled. There’s a good guide on how to set up W3 total cache here that explains more:
http://www.wpbeginner.com/plugins/how-to-install-and-setup-w3-total-cache-for-beginners/
|
|
Michael King
|
October 8, 2014 at 3:04 pm
I had W3TC set almost exactly as specified in the reference article, except that I had database cacheing ON. To make it simple, I deactivated the W3TC plugin completely. That and my CDN are now completely out of the string. If I can get something working, I will turn functions back on one by one.
I didn’t mention earlier, but I get the same problems in sandbox mode.
Thanks!
|
|
Lorenzo Orlando Caum
|
October 8, 2014 at 3:25 pm
Hi,
Thanks for temporarily deactivating W3 Total cache. Could you also move Cloudflare into development mode so that its caching features are off?
—
Lorenzo
|
|
Michael King
|
October 8, 2014 at 3:31 pm
I deactivated Cloudflare last night – completely, off, deleted, gone. W3TC “and my CDN [CloudFare] are now completely out of the string.” Has not been a PayPal payment attempt since.
|
|
Josh
|
October 8, 2014 at 5:25 pm
Hi Michael,
Another thing to check is if there is server level caching going on, like Varnish. If you’re hosted on a DreamPress account, it’s going to have the Varnish caching mechanism set up, and I’m not certain that can be turned off. Can you find out if Varnish is being used and if so, do you have access to a different server that you can test the IPN with?
|
|
Michael King
|
October 8, 2014 at 6:55 pm
Support staff at DreamHost says yes, Varnish is in use, and is an integral part of the DreamHost service I pay for. In other words they don’t know of a way to turn Varnish off. I’d have to say for a plugin (EE4) to make rules about the low-level features of hosting doesn’t sit well with me. Or if that has to be the case, then that should have been disclosed CLEARLY in the pre-sales stage. I’m overall very happy with the DreamHost service, so not eager to part ways.
That all said, I have another, shared server, although still on DreamHost, that’s reserved for development – will take a day or two, but I can clone the production site over there. While I do that, maybe you guys can think a little more on the problem?
DH support staff did flush Vanish so we’ll have a “clean slate” for testing.
|
|
Lorenzo Orlando Caum
|
October 9, 2014 at 10:10 am
Hi Michael,
We have a page on caching here:
https://eventespresso.com/wiki/setup-nocache-exclusion-rules-event-espresso/
Here is a simplified version of caching:
Caching takes a copy of a page and makes it available for quick delivery for period of time before refreshing that cache (to ensure its up to date).
That works fine for static content that does not change often such as blog posts and WordPress pages. However, registration checkout is a dynamic experience as its an ecommerce platform. That is the registration information will be different for each person that is registering.
Therefore, you could use W3 Total Cache, WP Super Cache, and other caching services as long as you exclude the Event Espresso pages.
These caching rules also applies to other ecommerce platforms for WordPress:
https://easydigitaldownloads.com/docs/wp-super-cache/
https://shopplugin.net/kb/set-up-shopp-with-wp-super-cache/
http://docs.woothemes.com/document/configuring-caching-plugins/
Some web hosts also offer the ability to turn off caching from their end for various areas of your site:
http://wpengine.com/support/wpengine-ecommerce/
—
Lorenzo
|
|
Sidney Harrell
|
October 9, 2014 at 10:28 am
It may be something other than caching, as well. http://www.linuxjournal.com/content/speed-your-web-site-varnish?page=2,1 points out that POST requests are excluded from Varnish caching, and the IPN message from Paypal is a POST request. They point out that Varnish has excellent logging capabilities, so it should not be hard to set that up, run an IPN test, and see if the request comes through. You can use the re-send IPN message from your Paypal account, set up live logging on Varnish and Apache, and watch the server’s response in real time.
|
|
Michael King
|
October 9, 2014 at 1:24 pm
@lorenzo – I understand the concept completely, and have been using it successfully for on this domain a long time. If you will read back thru this thread, you will see that earlier I was referred to that same wiki piece about the no-cache rules, I set up the don’t-cache rules and still had a failure. All caching is is now disabled and waiting for the next customer.
@sidney – I’m with you. Caching seemed like a good theory, but results from experiments with it are not really pointing that way. As to live logging on Varnish and Apache….good thought, but really not sure I have access to that, especially Varnish.
Let’s all keep thinking! Hope to have a clone set up in a dev server shortly.
|
|
Lorenzo Orlando Caum
|
October 9, 2014 at 3:13 pm
Hi,
Varnish is a type of caching and it can be adjusted on the server level. The problem is that we don’t know the settings that are in use. From the searches that I’ve found, Varnish cannot be turned off through the DreamPress service. They can “purge” the cache but this is not the same as turning it off or excluding certain pages from it.
Let us know if you see different results on a different site that isn’t running under Varnish.
—
Lorenzo
|
|
Michael King
|
October 9, 2014 at 4:52 pm
Ok guys – I’m maybe not the average noob user here, so let me summarize what I hear from the various sources:
DreamHost – doesn’t think Vanish should be a problem. If you want me to tell them this is their problem, let me know, but I’ll probably need some hard facts. Didn’t sounds like I’m likely to get much control or insight into Varnish.
Sidney from EE – thinks the POST IPN message should flow right thru Varnish – no problem. He thinks the problem “may be something other than caching” which makes a great deal of sense to me based on results so far.
Lorenzo – still pointing at Varnish, and hints about changing hosting companies. Right now, I’m a happier with DreamHost than EE4, so if we can’t figure this out and something get’s replaced, it’s a lot more likely to be EE4 than DreamHost.
As I’m starting to not believe in the cache theory, I think late tonight I’m going to turn CloudFlare back on, with the appropriate Do Not Cache page rules of course. I’m feeling the effects from not having some of their security features – another reason reason I don’t like all these things turned off. I’ll leave W3TC off for now, as I think I don’t get much bang for that buck.
Keep thinking! In 10 days I’ll be past the current event and will have a little more ability to experiment on the production server.
|
|
Josh
|
October 10, 2014 at 12:15 pm
Hi Michael,
Here’s the general PayPal IPN Troubleshooting tips from PayPal:
https://ppmts.custhelp.com/app/answers/detail/a_id/14/related/1/session/L2F2LzEvdGltZS8xNDEyOTYzNjA3L3NpZC84ZlA2dXg0bQ%3D%3D
We have also seen it happen where security features can have the unintended effect of blocking the IPN and causing a failure to update the Payment status. There are a number of causes that relate to security features, and I’ll give you some links where more information is published (outside of what we’ve published, so you can see it’s not always an Event Espresso issue) :
Another security-related cause we’ve seen in the past is an improperly set up (or missing) CAcert.pem file on the server. What happens then is the IPN isn’t being blocked, but the IPN validation fails.
https://www.drupal.org/node/2070363
My guess is that shouldn’t be an issue on a modern host on DreamPress, but I’ll mention it here anyway just in case.
|
|
Michael King
|
October 10, 2014 at 1:20 pm
That sounds like some useful info, I’ll go to work on those. Meanwhile, here’s a few responses:
– never used the Bad Behavior plugin, so that’s not an issue
– PayPal side shows the IPN messages receive a status code 200, so I take that to mean SOME server is receiving and responding – I know that sounds like a cache issue but nothing I’ve done with caches so far have changed that. I’ll see if PayPal log shows and IP address or name for the server.
DreamHost is not a tiny niche player in hosting – could I be the only person with this configuration (and problem)?
|
|
Josh
|
October 10, 2014 at 1:37 pm
Hi Michael,
I included Bad Behavior as an example. Other security solutions are capable of doing the same thing.
You’re correct that DreamHost is not a tiny niche player in hosting, and many of our customers are successfully using DreamHost + the PayPal IPN.
|
|
Michael King
|
October 12, 2014 at 11:53 am
@josh – Security was a new theory, so I deactivated what I use (WordFence). Had no effect on the problem – IPNs still didn’t get thru. Good thought tho.
|
|
Michael King
|
October 12, 2014 at 12:23 pm
There have been 25 posts on this thread, so I thought I’d recap the current situation:
– registrations complete nicely in EE4 (4.4.3p now; worked the same with a 4.3 version) and payments complete in PayPal, but EE4 Payment Detail says “Transaction Failed” and I have to manually Apply Payment.
– there are no error messages generated, unless users are getting some that they aren’t telling me about.
– PayPal IPN log says
“Notification URL http://www.ninthdistrictpta.org/transactions/?e_reg_url_link=1-387ca0f64d3f1ed796365249ffe3a469&ee_gateway=Paypal_Standard
HTTP response code 200″
I take that to mean the IPN was sent, received, and the 200 response generated by the /transactions/ page (or some other page?), ie the IPN wasn’t “blocked” nor failed. That doesn’t seem to match the Payment Details?
– Deactivating all caches at my level had no effect; I now have only CloudFlare (no more W3TC) operating in a very minimal mode. CloudFlare page rules are set to not cache the EE4 pages per the EE4 support docs, although CF claims to be smart enough to deal with dynamic pages.
– Host is dreamhost.com DreamPress server with Varnish running but not at any level I can control.
– files are uploading as I type to clone the prod site onto a dev server, still on dreamhost but on a shared server vs. DreamPress. I’ll put PayPal in sandbox mode and see what happens there, but Sandbox on the prod server exhibited the same problem. I’ll be happy to share logins on that server with EE staff if they want, but not in this open forum 🙂
My theory – I have a setting wrong somewhere, rather than a cache problem. Unfortunately nothing I can find hints at any problem.
|
|
Michael King
|
October 12, 2014 at 1:04 pm
Update – dev site up on shared server, to the extent I can an exact copy of the prod site. Made sandbox registration but “No payments have been applied to this transaction yet. Click “Apply Payment” below to make a payment.” Problem unchanged again but we know now it’s not DreamPress. 🙁
|
|
Michael King
|
October 13, 2014 at 8:04 am
On a related topic, I went looking for EE4 log files – found a reference for where to look, ftp’ed in…nothing there at all…no files. That sent me off searching support for log file problems which led me to this one https://eventespresso.com/topic/paypal-payments-payments-incomplete-2/ (ignore page 2 – hijacked to unrelated topics).
That user as it turns out was having something like my IPN problem, and my log file MIA problem. Long story made short, I changed file permissions in the Logs folder to 777, and now there’s at least a log file, although didn’t seem to cure my primary problem as that individual claimed.
Any thoughts?
|
|
Josh
|
October 13, 2014 at 9:00 am
My initial thought after reading your update is maybe you can try using a sandbox PayPal account in Event Espresso PayPal sandbox mode. This will give you more debug info.
|
|
Michael King
|
October 13, 2014 at 9:14 am
And my update 1pm update says I cloned the prod site to a different server and switched over to PayPal Sandbox – same unfortunate result, but now I have a ton of log info that I don’t know what to do with.
|
|
Josh
|
October 13, 2014 at 10:40 am
You can forward the debug info to support @ eventespresso.com. Along with that, please be sure that the sandbox account has the PayPal IPN activated. It’s disabled by default.
|
|
Michael King
|
October 14, 2014 at 10:52 pm
One log file was sent yesterday, to the support@ address.
|
|
Josh
|
October 15, 2014 at 12:51 pm
Hi Michael,
We got it, and Sidney has followed up with you via email.
|
|
Josh
|
October 17, 2014 at 2:03 pm
Hi Michael,
Sidney’s testing has revealed that the error is on the validation part of the IPN:
EE_Paypal_Standard: payment_status and txn_id sent properly. payment_status:Completed, txn_id:xx
PayPal IPN Validation failed!
The validation is likely failing because of the escaped single quotes in the item_name field. If you remove the single quotes from the ticket name it will likely validate.
|
|
Sidney Harrell
|
October 20, 2014 at 10:58 am
I just got it to work on your dev site by changing lines 368-371 of EE_Paypal_Standard.class.php from
sprintf(
__( '%s for %s', 'event_espresso' ),
$line_item->name() ,
$line_item->ticket_event_name() ),
to:
rawurlencode( sprintf(
__( '%s for %s', 'event_espresso' ),
$line_item->name() ,
$line_item->ticket_event_name() ) ),
|
|
Michael King
|
October 20, 2014 at 11:51 am
Woo HOO! I was able to successfully register someone. Got the right feedback email, and payment status is “approved” without my intervention.
So, what’s next? The event I was working on was last Saturday & I don’t have another event for a while, so I’m good with waiting for a formal release, presuming that’s your plan. If need be, I could use the patched EE_Paypal_Standard.class.php but I’d prefer to stick with formal releases.
Thanks! Even with this I’m telling people you have a great product.
|
|
Josh
|
October 20, 2014 at 2:33 pm
Hi Michael,
I can recommend sticking with the release (no patch) and if you start a new event before the next update is released, please be sure to not include single quotes/apostrophes in the ticket name + event name.
|
|
Josh
|
October 29, 2014 at 1:26 pm
Hi Michael,
A little update on this: Event Espresso 4.4.4.p was finally released today and it includes a fix for the issue you reported.
|
