Posted: September 16, 2020 at 6:56 pm
Yesterday we had caching issues on our website and before I got it fixed we had an issue where one customer signed up for an event but when she paid the payment was applied to another customer. This was a large amount – $425 – and very alarming. Now I’m afraid there might be others (150 signed up yesterday). Three questions:
Bumping this back up. Luckily this only happened to one customer and I was able to export Authorize.net transactions and match the registration ID to the EE customer ID to compare transactions.
Still concerned about #2 and #3 though.
Using version 4.10.7 and WP 5.5.1.
Event Espresso – Attendee Mover (EE4.9.13+)
Event Espresso – Event App Customization (EE4.9.9+)
Event Espresso – Events Table View Template (EE 4.4.9+)
Event Espresso – MailChimp (EE4.4.5+)
Can you expand on this please, what caching issues?
Which specific auth.net payment method are you using?
I understand seeing this happen will cause alarm but literally the only time we see anything like this happen is due to caching issues. You can’t cache EE (or pretty much any e-commerce solution) or things like this happen. Why? Because if EE tries to pull specific data for specific registrations and is then given cached data (meaning data from another registration) from some cache trying to be ‘helpful’ it’s none the wiser and updates what it’s been given.
(The above is obviously a very high-level overview and there is much more to it than that but the point being is that caching dynamic per visitor data such as EE’s is a no go)
I see you’ve already done this but thats the recommendation I would have given, export Auth.net transactions and compare.
99.9% of the time, issues like these are due to caching.
IF EE asks for X and gets Y (cached data), but Y is packaged up like X, , walks, talks and acts like X, then as far as EE can tell its X and will use it.
What happened to enable caching on the site as I’m guessing it wasn’t originally?
Just a quick side note that generally, bumping your threads will have the opposite effect than intended as we try to work through posts based on reply date.
Thanks for the reply. See my notes below:
The caching issue was due to two issues: We had the Lightspeed cache engine enabled and also had Succri enabled. I had done all the purges / traps for Lightspeed but not Succri.
We’re using Authorize.net.
The server (and above caches) had the same setup that we had all last year without issues (except I ran all the plugin updates right before registration opened). The other difference b/t last years registrations and this years was that the customer ran a promo and the site saw a huge spike in traffic when registration opened and we saw 150 registrations in a day (whereas last year the most we saw was 9 in a day).
I understand that… but a caching problem shouldn’t impact database inserts. If you can send me an email privately I’ll send screen shots of the DB to show you what happened.
Sure it can, again, if Y walks, talks and acts like X it will be used as such and the ID’s won’t match what they should. Now the relationship between your payment, transaction/registration etc is incorrect.
The only time we see a kind of issue where a payment (or any other object really) applies to a completely unrelated entity (another registration) it is due to caching.
For emails please use support[at]eventespresso.com