Support

May 16, 2024 at 7:35 am

Hi there,

Unfortunately, due to the date of that payment, your site will not have payment logs saved for it to be able to look back at what the PayPal request returned. The longest option we have for saving payment method logs is 30 days but yours may be set differently (Event Espresso -> Payment methods -> Settings).

So I can’t tell you for sure what has happened here, however, we had a similar report of this on our sister site (EventSmart) and from investigating that issue what I can tell you is PayPal likely returned an order status of complete, but then within that order, had a payment with a status of declined. This was/is inconsistent with the PayPal documentation at the time of creating the add-on and didn’t happen with the declines we tested for the above.

EE originally relied on the order status and if that was complete, EE would consider the payment approved but we have since added additional logic within the payment method to traverse through all of the payments in a PayPal order and confirm the status of those as well (that happened in version 5.0.18+).

So right now, based on the date of that payment I’m guessing your site was running 5.0.17.p lower and the PayPal response had an order status of complete for the above payment. I can’t say that for sure unless you have a site backup from around that time which may have the logs within the database I can then check?

—-

So to actually answer the questions you posted above:

Why did this occur?

As much as I’d love to dig into this and find this out, without logs of the request/response to/from PayPal (which neither we, your current site, or PayPal have anymore) I can’t give you an definitive answer.

Why did EE show it as a completed paid transaction?

My best guess is the above, PayPal returned an order status of Complete with a payment of declined so then EE set the payment status to Approved which then updates the EE Transaction to complete.

Personally, I don’t understand how you can have an order status of complete when a payment has failed within that order but that’s a discussion we would need to have with PayPal.

and how to I fix it from happening again….

Your site is currently running 5.0.19 which has all of the current fixes, so IF the above was the cause it shouldn’t happen again the payment will show as declined.

But without knowing the original cause again I can’t say this with 100% certainty (when I say that, know that I don’t like not knowing either but its the reality of not having logs to work through).

…or find out is it already has.

This is tricky as PayPal apparently don’t list these transactions.

The only way I can think of checking this is to export the registrations and compare those to your PayPal transactions and check for inconsistencies. Not being able to search by TXN/Order ID for these makes that harder.

(Side Note: PayPal not having a TXN ID to be able to find that payment within their system doesn’t really make sense to me, its shown in screenshot you added. The ‘TXN ID/CHQ #’ value for that payment is taken directly from PayPal, that’s not from EE and it’s the order_id or capture_id from their response).

PayPal has said there are no issues on their and it is a communication issue on EE/my sites end?

For this I’m going to give you my own, personal opinion based on experience working with payment merchants such as PayPal and many others (both within EE and outside of it).

The issue is almost never on their end. You could have an issue with X request (which worked previously), sending hundreds of those requests with the exact same values set on each one during testing and they all fail… open up a ticket with the merchant to be told there is no issue on their end but all of a sudden those requests start working again, automagically.

That’s not always the case, sometimes parameters are incorrect and things need to be updated but then other ‘random’ errors disappear with no changes on both sides, but only after it’s been reported to them. I’ve sat and logged requests to show the parameters set, and the response received directly from merchants to still be told it’s not on their end…. then it works a day later, exactly the same request.

So, in short, I never rely on ‘its not out end’ from any merchant and only rely on the logs of both what was sent and what was received.

—

Some notes from PayPals reply.

I’ve already mentioned that not having the ID here doesn’t make sense to me as we saved (at least) the order_id from them, which should be able to find the transaction this was for, they say they don’t keep declined transactions? Seems odd… everyone else usually does.

Reviewing your account, I do not see that you are using a Post-Transaction communication like Instant Payment Notification (IPN) or webhooks which makes me suspect that your system is relying primarily on information that occurs during the transaction process, which while this is the fastest method of communicating with our system it can be prone to communication errors in some situation. If your system supports a secondary communication such as the methods mentioned above, it could help alleviate these types of scenarios.

Well.. yes an no.

IPNs – We’ve used and if I have my way we will NEVER use them again with PayPal. They are far to unreliable. We’ve worked through users issues where they’ve had IPN’s not send for days/weeks after the transaction was complete or not at all.

An IPN is a request sent separately from when you return the user ‘home’ to the site where they made their purchase. If that’s delayed we have to rely on the data sent back WITH the user originally (in which case, no point in the IPN) …. IPN’s don’t help if they aren’t instant (Sorry PayPal but they simply can’t be relied upon to be instant).

Webhooks – Sure. Maybe. They work differently to IPN’s and we’ve used them from other providers successfully so maybe.

What we do now is use the data sent back from PayPal directly on the payment request. If the above issue was what happened… I don’t think using IPN’s or Webhooks themselves would have helped here, the only difference being we may have been been targing something different with those, which may have highlighted the problem… but IPN’s and Webhooks themselves, wouldn’t have fixed it.