|
wfinley
|
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:
1. how do you recommend I look at the transactions to ensure it didn’t happen to anyone else
2. why did this happen?
3. how can I stop it from ever happening again?
|
|
wfinley
|
September 17, 2020 at 9:54 pm
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.
Plugins include:
Event Espresso – Attendee Mover (EE4.9.13+)
Version 1.0.5.p
Event Espresso – Event App Customization (EE4.9.9+)
Version 1.0.2.p
Event Espresso – Events Table View Template (EE 4.4.9+)
Version 1.3.9.p
Event Espresso – MailChimp (EE4.4.5+)
Version 2.4.5.p
|
|
Tony
|
September 18, 2020 at 5:04 am
Hi there,
Yesterday we had caching issues on our website
Can you expand on this please, what caching issues?
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.
Which specific auth.net payment method are you using?
This was a large amount – $425 – and very alarming. Now I’m afraid there might be others (150 signed up yesterday).
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)
1. how do you recommend I look at the transactions to ensure it didn’t happen to anyone else
I see you’ve already done this but thats the recommendation I would have given, export Auth.net transactions and compare.
2. why did this happen?
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.
3. how can I stop it from ever happening again?
What happened to enable caching on the site as I’m guessing it wasn’t originally?
Bumping this back up.
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.
|
|
wfinley
|
September 18, 2020 at 1:10 pm
Thanks for the reply. See my notes below:
Can you expand on this please, what caching issues?
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.
Which specific auth.net payment method are you using?
We’re using Authorize.net.
What happened to enable caching on the site as I’m guessing it wasn’t originally?
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).
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.
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.
|
|
Tony
|
September 21, 2020 at 9:15 am
We’re using Authorize.net.
That’s actually a provider rather than a payment method, there’s a few for Auth.net, AIM, SIM, ACCEPT
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
|
