|
Michael King
|
May 26, 2016 at 12:04 pm
This is my on-going battle with EE4 or something over getting status recorded correctly in EE4. I have about 300 registrations for my event next Saturday, and about 200 of those were COMPLETE & APPROVED, all good.
However when I looked at my csv download, there were about 20 with REGISTRATION STATUS, “PENDING PAYMENT,” some with TRANSACTION STATUS of “COMPLETE” and some with “INCOMPLETE” but transaction status shows paid with a gateway transaction id number and everything. I checked a few of these in my payment processor – all showed as paid.
So, ok, not very difficult to go through all of them, one by one, and change the status to APPROVED & COMPLETE but it’s a real tedious PITA task, that I was expecting the software to do. And now I wonder how may of the others are incorrectly statused…
I’ve raised similar issues before and felt like I got a response like you know more but don’t want to tell. I can understand there can be issues with the response coming back from the payment processor, but this is different – there is a response recorded for the payment, but the rest of the status doesn’t match. BTW, I check on transaction dates – some of the problems were on busy days, and some were on days when there was only one transaction all day.
Can anyone explain what’s going on? This is really no fun, especially when the problem doesn’t surface until someone is at the event with a payment receipt and no creds on my side.
|
|
Michael King
|
May 26, 2016 at 12:05 pm
Oops – typo in title…should say “…but ACTUALLY paid”
|
|
Sean Firth
|
May 26, 2016 at 4:57 pm
I am having similar problems
|
|
Michael King
|
May 26, 2016 at 5:09 pm
That is interesting Sean – thanks for adding that note.
|
|
Tony
|
May 27, 2016 at 3:11 am
I’ve raised similar issues before and felt like I got a response like you know more but don’t want to tell.
I’m sorry if you feel I’m holding back some secret information, but that really is not the case. Offsite payment methods are a pain, they always have been and likely always will (especially PayPal), there is just a lot that can go wrong and we need to work through all of it to troubleshoot the issue. So if it seems like we are asking seemingly random questions with no explanation it’s simply to narrow down the most likely cause and work from there.
A explanation for each situation would drag out a thread and cause yourself to become frustrated even further with information that has little to no relevance to your issue.
I can understand there can be issues with the response coming back from the payment processor, but this is different – there is a response recorded for the payment, but the rest of the status doesn’t match.
As you correctly pointed out this is different from your previous thread here:
https://eventespresso.com/topic/paypal-status-incomplete-but-actually-fully-paid/
Previously it seemed the IPN was just simply not received for the problem transactions, then you had an instance of an IPN validation failure (which appeared to be an issue on PayPals servers).
On these transactions it looks like your receiving the IPN but the registration (or transaction) status is not updated, that’s a completely different issue than before. There’s no information above that can help troubleshoot that but personally I would consider moving away from offsite payment methods that rely in IPN’s and move to something like Stripe.
(Seans issue is with Stripe as I have seen from his thread but issues with Stripe are far more rare than with PayPal Standard)
Check your servers error logs around the dates of these transactions, any errors from EE at all?
If you view the payment logs:
Event Espresso -> Payment Methods -> Logs.
Look for the payment logs for those transactions (PayPal payments should have at least 3 entries in the log for each transaction) any errors within those?
I’ll check in with our developers for any likely causes for this.
|
|
Michael King
|
May 27, 2016 at 9:22 am
I looked at the Payment Method/Logs for a sample of some of the problem payments and ‘adjacent’ good payments…
Good payments had two log entries each consisting of several parts, not three. I guess maybe I don’t understand what you mean by “three entries”
Bad (PENDING PAYMENT but with a completed transaction) had only one log entry, which appeared to be equivalent to the first entry in the good cases.
I don’t know if this helps, but here is the .csv data from a couple of the problem items.
_________
17334 4170 1402 5/10/16 22:01 17334-17-1-d369 1 of 1 50 USD Pending Payment Incomplete 50 0 5/11/16 5:19 PayPal Standard 3611672457255464H 0
_________
18027 4204 1462 5/18/16 15:40 18027-17-1-4fcb 1 of 1 50 USD Pending Payment Complete 50 50 5/18/16 22:41 PayPal Standard 8WT2156956999284E
_________
I don’t have time right now to dig out server error logs, and I don’t know if those are kept long enough to be cover the times in question.
Call me crazy, but I have to ask – if you guys know PayPal & Stripe transactions are unreliable and can’t be made so, which leads to conversations like this, seems like a peculiar design decision. Why do you offer them? Or at least why not build in some error handling – marking a registration PENDING PAYMENT when there’s a completed payment just doesn’t seem right.
And for the record, I’m not a PayPal fan – I have a whole bunch of issues with them beyond the technical, but it’s the choice of the organization that I work for. Until it’s my name on the front door, my options are limited. That said, you recommend moving away from off-site payment methods – which ones would you recommend? I don’t know which are on-site and which are off-site.
|
|
Tony
|
May 27, 2016 at 9:52 am
Good payments had two log entries each consisting of several parts, not three. I guess maybe I don’t understand what you mean by “three entries”
Three separate entries in the log, each with their own details – http://take.ms/hIxxV
1. The details sent to PayPal.
2. The details received from PayPal.
3. The details when the transaction is updated.
And for the record, I’m not a PayPal fan – I have a whole bunch of issues with them beyond the technical, but it’s the choice of the organization that I work for.
That answers your previous question…
Call me crazy, but I have to ask – if you guys know PayPal & Stripe transactions are unreliable and can’t be made so, which leads to conversations like this, seems like a peculiar design decision. Why do you offer them?
So, simply put, because everyone uses PayPal.
It is market leader for payments and both our users and the user making payments on our users sites are most familiar with it, as it stands any payments system must support PayPal to be considered ‘serious’ because everyone will ask for it.
Does that make it a good choice for users to use? No. But it’s the reality of it. The majority of users will choose to use PayPal Standard regardless of other options.
Note I did NOT say the same about Stripe. Stripe works differently from PayPal and is more reliable in my opinion.
Or at least why not build in some error handling – marking a registration PENDING PAYMENT when there’s a completed payment just doesn’t seem right.
Do you seriously think we don’t have error handling for PayPal (and other payments)? There’s a lot going on under the hood but things can go wrong, each time we find an issue we can prevent (or reduce) to a minimum we do 🙂
The registration status should be updated once the transaction has updated, that hasn’t happened for some reason and the clue to why is likely within the error logs.
That said, you recommend moving away from off-site payment methods – which ones would you recommend? I don’t know which are on-site and which are off-site.
What I actually said was to move away from off-site payment methods that rely on IPN’s… ie PayPal Standard.
Stripe is one of those I would recommend. (Stripe is considered On-site but is different than ‘standard’ onsite payment methods)
Mijireh another (although that’s basically a 3rd party intermediate for other gateays)
Switching from offsite to onsite also brings in PCI compliance the majority of which concerns your server setup and internal policies, an SSL cert is required for all on-site payment methods to be compliant.
You can view and overview of EE payment methods here:
https://gist.github.com/lorenzocaum/37dba9df5a035f073c78
|
|
Tony
|
May 27, 2016 at 9:53 am
I don’t know if this helps, but here is the .csv data from a couple of the problem items.
_________
17334 4170 1402 5/10/16 22:01 17334-17-1-d369 1 of 1 50 USD Pending Payment Incomplete 50 0 5/11/16 5:19 PayPal Standard 3611672457255464H 0
_________
18027 4204 1462 5/18/16 15:40 18027-17-1-4fcb 1 of 1 50 USD Pending Payment Complete 50 50 5/18/16 22:41 PayPal Standard 8WT2156956999284E
_________
Unfortunately not, that’s basically all of the information we know already.
|
|
Michael King
|
May 27, 2016 at 10:57 am
I went back to the PAYMENT METHODS/LOGS and scrolled thru some entries for the primary registrants
Looking at the CONTENT window for a “good” case, going down the left side there is:
url
message
transaction (updated)
payment (updated)
use_paypal_shipping
use_paypal_tax
grand_total_needed_resaving
There is no data associated with the last three.
For a “bad” case (PAY_ID 552; TXN_ID 19072) there is:
url
message
payment
IPN_data
Those are obviously different, but I don’t know enough to know what the differences mean. Maybe this all a feckless exercise as my online registrations are closed now and I won’t be doing any till next spring. Maybe I can talk the board into something more reliable by then.
If one of you want to look at the log, the creds I set up for you a while back should still be active. Tony – if you want to join us here on June 4 I’ll comp that registration you started.
|
|
Tony
|
May 31, 2016 at 2:11 am
Thanks for the offer however I’m based in the UK, so that would be a really long trip 😉
The first log you posted is from the function that updates the payment based on the response from the IPN (or from the user returning to the site) the last 3 will be empty unless needed.
The second log I’m not sure about, I looks like the log from wp-cron which is ran when your session expires, but without the full messages I can’t tell.
For security reasons we do not store login details so if you could reset the password and resend the details using this form:
https://eventespresso.com/send-login-details/
I’ll take a look at the longs and see what I can find.
|
|
Michael King
|
June 6, 2016 at 2:18 pm
Hey Tony – I uploaded the requested login creds a few days ago. Any news?
|
|
Tony
|
June 7, 2016 at 4:59 am
I had a look into the payment logs for a couple of the transactions.
Event Espresso -> Payment Methods -> Logs
ID – 1699 & 1700
ID – 2117 & 2118
What it looks like might be happening is the user and the PayPal IPN are hitting the site at the exact same time which is locking the transaction (both of the requests contain the IPN data from PayPal, its how PayPal works). The payment gets applied to the transaction but because its locked the status doesn’t update.
Can you install Adminer onto the site so I can see if there is any log of the transactions being locked within the database please.
Also did you have a look within the log files for any errors around the same time of these transactions?
|
|
Michael King
|
June 7, 2016 at 9:41 am
Adminer is installed now. I looked into server logs but they don’t go far enough back to catch the error periods. Sorry but I was busy running the event when you asked about that earlier – unfortunately I have a staff of exactly me.
I continue to think that having a payment recorded with a gateway ID and everything but with a PENDING PAYMENT status is an error condition that your software should not allow. Until this event, I did not have AUTO RETURN set in PayPal and I don’t remember getting this error, and over all I had less payment errors. Changing to AUTO RETURN seems to be consistent with your theory about simultaneous arrivals and lock-out – remember that’s what you advised me to set. As I said earlier, there’s no correlation the traffic level when the errors happen, so that’s also consistent with your theory.
Any opinion from engineering about this?
|
|
Tony
|
June 9, 2016 at 3:42 am
If you prefer not to use Auto Return then please feel free to disable the option again however you’ll then need to rely on either your users clicking to return to the site (which could still cause the same issue with them and the IPN returning together) or rely completely on the IPN and wait for the users session to expire to update the registration.
As I mentioned in your other thread when recommending you enable that option (and still advise to leave it enabled) its not required for PayPal to work, but improves the user experience.
I’ve asked feedback from one of our developers on this but my advice is to move away from PayPal standard.
|
|
Sean Firth
|
June 9, 2016 at 5:14 am
I am still experiencing these kinds of problems and don’t see moving away from Paypal standard as an option.
|
|
Michael King
|
June 9, 2016 at 6:57 am
I don’t think I said that I “prefer not to use Auto Return” – that’s what you recommend, and at least anecdotally, that only swapped one kind of error for another. Please don’t put words in my mouth.
I understand you want me to move away from PayPal Standard – convenient for you in that I have to send you a $60 or $70 license fee for what you recommend, and maybe Engineering doesn’t have to deal with a tricky problem. That’s going to be a tough sell with my board, especially since your product is advertised to work with PayPal Standard. We are a small non-profit and not technologically focused, so there won’t be much sympathy when I start talking about IPN and database locking.
|
|
Josh
|
June 9, 2016 at 12:58 pm
For what it’s worth Michael, the development team has spent months worth of hours dealing with this tricky problem. At some point we may end up removing PayPal standard from Event Espresso altogether and replace it with PayPal Express or one of their other newer solutions.
|
|
Michael King
|
June 9, 2016 at 1:27 pm
Thanks Josh – that sounds like an honest answer at last! Previous responses made this sound like I was a one-off unknown problem. I’m an engineer too, so I understand something about the nature of problems like this.
Honestly, if you can’t make PP Standard work reliably, I’d rather see you discontinue support rather than leaving us limping along with a known bug. If you drop support, then I have a much stronger case with my board for the $70 for another payment gateway. Good for me too, since I spent several tedious man-hours finding and fixing the 8% of my sales that didn’t record right.
|
|
Josh
|
June 9, 2016 at 1:44 pm
Thanks for the feedback.
|
