|
PA12345
|
September 9, 2020 at 2:44 pm
We had two registrations come in within 2 minutes of each other on 8/31/2020:
The first one was Sylvia (Registration # 10021) in the amount of $29.95. Her order shows as being approved, with a completed transaction (Transaction # 5479, TXN ID / CHQ #42203753587).
The 2nd order was for Nancy (Registration # 10015) in the amount of $29.95 (different product, same price). This order shows as abandoned with no transaction.
In Authorize.Net (our payment processor), there is a transaction with the same ID # used with Sylvia’s order, however, the user shows as Nancy and the payment has been applied to Nancy’s credit card number instead of Sylvia’s.
We have documentation from Authorize.Net. Because of the confidential nature of this, you can email us and we’ll reply with it.
|
|
Tony
|
September 10, 2020 at 4:53 am
Hi there,
You can use support[at]eventespresso.com to send additional details and we’ll follow up there.
|
|
Tony
|
September 10, 2020 at 4:54 am
Side note I’d like to take a look over the payment logs on the site to see if anything stands out there, if that is ok you can send temp login details using this form:
https://eventespresso.com/send-login-details/
|
|
PA12345
|
September 10, 2020 at 10:25 am
This reply has been marked as private.
|
|
PA12345
|
September 14, 2020 at 2:05 pm
This reply has been marked as private.
|
|
PA12345
|
September 17, 2020 at 8:40 am
Still no update? This is a critical issue that needs to be addressed ASAP 🙂
|
|
Tony
|
September 21, 2020 at 8:38 am
Hi there,
My apologies for the delay one of the reasons I’ve delay replying is the log entries on your site didn’t go back far enough for me to review the details of these transactions so I’ve been reviewing the Auth.net payment method’s payment process to see if I could find any issues and that took longer than I expected.
In short, I can’t see any issues with the process and we’ve had no other reports of this which means that right now the only viable cause is caching. I can see your using Kinsta to host the site which has it’s own server-side caching:
https://kinsta.com/blog/wordpress-cache/
Have all of the EE critical pages been excluded from that caching?
|
|
PA12345
|
September 21, 2020 at 12:50 pm
Hi Tony,
Thanks for the update. No, the EE critical pages haven’t been excluded from caching/CDN. Should they be? If so, which pages specifically?
Thanks!
|
|
Tony
|
September 21, 2020 at 12:56 pm
Your site uses the default slugs for all of them, so its:
/events/
/registration-checkout/
/event-registration/
/transactions/
/thank-you/
/registration-cancelled/
Those should be excluded from all caching.
|
|
PA12345
|
September 21, 2020 at 2:07 pm
Thanks – we’ll try to do that. Do you think that caused the problem (or is that just something good to do)?
|
|
Tony
|
September 21, 2020 at 3:58 pm
I can’t say 100% that was the cause, but it’s the most likely suspect.
One recommendation I would make for the time being is to increase the duration of time that payment logs are saved on the site, as right now you only have 7 days to catch this before we can’t view the logs to see what is happening.
You change that in Event Espresso -> Payment methods -> Settings
Set ‘Gateway Logs Lifespan’ to at least 14 days so you have some extra wiggle room to troubleshoot this if it happens again.
|
|
PA12345
|
September 22, 2020 at 7:23 am
Okay, that’s done. We’ll keep an eye on things and let you know if it changes. Thanks again for your help Tony!
|
|
Tony
|
September 22, 2020 at 7:41 am
You’re most welcome.
For now, fingers crossed this doesn’t come up again 🙂
|
|
PA12345
|
September 23, 2020 at 9:10 am
Okay, I talked with our hosting company (which uses Kinsta) and they said “The Kinsta CDN doesn’t cache pages, only static files like CSS, JS or images files. There isn’t anything to configure with the CDN. It’s either turned on or off.” The good news is that specific pages *can* be excluded from caching. They’re doing that now. Thanks!
|
|
Tony
|
September 23, 2020 at 11:07 am
I don’t use Kinsta but their documentation states otherwise:
https://kinsta.com/blog/wordpress-cache/
To quote:
At Kinsta, we utilize the following four types of cache, which are all automatically done at the software or server-level:
Bytecode cache
Object cache
Page cache
CDN cache
That’s a lot more than just a CDN Cache.
I can’t argue any further on the type of hosting they are using as I have no involvement with your hosting but if the above are enabled on the site EE’s routes will need to be excluded from them.
|
|
PA12345
|
September 23, 2020 at 1:32 pm
Sounds like we should disable the CDN, in addition to keeping those EE pages from being cached… is that correct?
|
|
Tony
|
September 24, 2020 at 5:19 am
A CDN for static files should be fine, that won’t cause the above but Object and Page cache could so EE needs to be excluded from those at least.
|
|
PA12345
|
October 1, 2020 at 11:00 am
We’ve disabled the CDN entirely. Those pages you mentioned are still excluded from Kinsta’s caching. Here’s what our hosting provider said: “Again, the CDN only pertains to static files (.css, .js, images and etc). Disabling the CDN won’t affect anything relating to the payment part unless it has to do with an outdated .js Event Espresso JS file. I suspect there maybe something else going on here.”
|
|
Tony
|
October 1, 2020 at 11:29 am
As mentioned in my previous post here:
https://eventespresso.com/topic/charges-from-one-users-registration-went-to-another-users-credit-card/#post-316377
Kinsta use more than just a CDN, and as mentioned in another reply:
https://eventespresso.com/topic/charges-from-one-users-registration-went-to-another-users-credit-card/#post-316408
You should be able to use the CDN without issue, its the other forms of caching that the Kinsta documentation states they use which would cause issues here. It is common to see issues like this when Object and/or Page caching are enabled so if your site has them enabled the EE critical pages need to be excluded from that caching (not the CDN for static files).
|
