|
July 16, 2019 at 4:09 pm
Hi there,
I should prefix this (as I don’t think its clear above) that the PayPal Standard payment method has been deprecated within EE for some time now and weird issues with IPN’s randomly not working, then suddenly fixing themselves is one of the reasons for us doing so.
New users of Event Espresso have PayPal standard hidden on activation, they can enable it using a filter, but its no longer supported and has effectively been replaced by PayPal Express.
We spent a considerable amount of time working through issues with users on PayPal standard, one day IPN’s would fail, the next they worked (with no changes to the plugin at all). Then all of a sudden they would stop again, or the IPN’s would be heavily delayed (24hours+) and so on. We didn’t make the decision to deprecated PayPal standard lightly and imo, your best bet is to move away from it for a ‘better’ implementation, aka PayPal Express
It’s important to mention that as it’s unlikely that any efforts your developer goes through to troubleshoot/fix the above will result in changes to the plugin in the long term.
—
With that said, you’ve asked for comments, but there isn’t much of an analysis we can comment on as they don’t provide any actual details.
The website at this stage is trying to tell the Paypal server that it has successfully registered the payment. This in turn causes Paypal to “complete” the withdrawal.
Whilst this is mostly correct, the part that he appears to be referring to (the commend about something being ‘wack’) is essentially a catch-all for when we send the response to PayPal and an error is returned.
Meaning:
The fact it is getting here actually rules out network issues such as time-outs, at least on the website’s server side.
Again, is pretty much correct, however:
Therefore we are left with 2 options, it is a logic issue or a data issue. A logic issue could be of the type that the IPN is arriving too early or too late and the plugin code doesn’t handle it.
This is not an issue with the IPN request arriving too early/late.
The IPN is hitting the site and the request sent back to PayPal from that returns an error, in your case its:
400 Bad Request Bad Request Your browser sent a request that this server could not understand.
Something is incorrect in the request, what this is we can’t say from the above, it can be any number of issues with the request.
Indeed the Paypal documentation states:….
That’s correct and we don’t rely solely on IPN’s, but we also can’t ignore them.
PayPal POST back the user to the site and also send and IPN, we have to monitor for both, why? Because users often seem to close their browser when they make a payment and never actually return to the site, the only way we can then validate a payment is via the IPN.
I’m not going much detail here for the reasons mentioned above.
However there is quite a bit of… unusual… code in the way the programmer is handling inputs.
There is not enough detail here for us to comment on really.
What do they consider unusual here?
I therefore suggest in the first instance that I add some code that only fires if there is a IPN error and e-mails me the exact details (which aren’t currently provided in the logs). This way we can rule out data issues.
They could do this, or just add the full request to the log itself and view it there.
However, the reason I opened my post with the above is this is essentially a waste of time for you both. The PalPal standard integration method is slow and unreliable (their docs state this when you read between the lines) and PayPal now has ‘better’ methods to use. We used one of those to create a new payment method, PayPal Express and then again with PayPal Express with Smart Buttons.
Your developer is welcome to open a pull request with any changes they make to the PayPal standard payment method to fix this, but as mentioned, as it’s deprecated it is unlikely to be included as eventually that Payment method will be removed.
|
