|
SBANE Webmaster
|
November 22, 2013 at 9:24 am
WordPress 3.1, EE 3.1.33.P with MER, Calendar, Members plugins
Over the last several weeks, we have had a handful of users report that they have been charged full price for events, instead of the Member price, when the payments are processed through the Authorize.net SIM gateway. This is not happening to all transactions, just a small minority. All the reports on our site indicate that the Member price was applied.
When we view the invoice sent by Authorize.net, we see the line item description containing the proper Member price, but the Total price shows the General Admission cost, which is what was processed in the transaction. Our comptroller contacted Authorize.net to troubleshoot one specific transaction, and was told that the data for the differing amounts was what was sent to them via the EE gateway.
Is there a known bug with EE/MER and discount codes, in the versions we were using. We just upgraded last night to WP 3.6.1, EE 3.1.35.P, and MER 1.04 – will that fix this issue?
Please advise how to proceed. As you can imagine, we have a number of unhappy users and need to get this issue resolved. If you need access to the system, I can provide that as well.
Thanks,
Erik
Erik Domingo
SBANE Webmaster
|
|
Josh
|
November 22, 2013 at 9:57 am
Hi Erik,
There were some pricing issues ironed out with Multi Event Registration in the Event Espresso 3.1.34 update. Can you clarify whether the issue you were seeing happened a) when a promo code was used? b) a member only price was in effect (the user was logged in when they purchased a ticket to get a member price) or c) both a & b?
|
|
SBANE Webmaster
|
November 22, 2013 at 10:12 am
Hi Josh,
The issue occurs when a member is logged in. We aren’t using promo codes in these instances.
Thanks,
Erik
|
|
SBANE Webmaster
|
November 22, 2013 at 10:27 am
Actually, we installed the upgrade to EE 3.1.35 two nights ago (11/20). I have an example of this issue occurring yesterday (11/21), so it would seem problems still exist in the code.
|
|
Josh
|
November 22, 2013 at 10:34 am
Hi Erik,
I’m not sure whether this was a known issue with Members and Multi Event Registration back then. I’m not able to reproduce this using the current versions of the software. Going forward I’d advise:
1) Make sure your WP User Integration add-on (aka Event Espresso Members plugin) is up to date.
2) If there were any customizations made to Event Espresso’s templates or the Authnet SIM gateway files, these should be updated to include any changes that were made since Event Espresso 3.1.33.
|
|
SBANE Webmaster
|
November 22, 2013 at 10:53 am
Hi Josh,
I will certainly check into making sure customizations to the templates (there are some) are in-line with current versions of the software. However, no changes were made to the Auth.net gateway files.
Is it possible to have you look at the data of the most recent example of this issue from yesterday? We can provide admin access to the site, as well as the database. Since this is an inconsistent issue, I haven’t been able to reproduce it either, but the data definitely proves it’s happening. We’re very anxious to track down the problem, since this is impacting our members financially, and seriously damaging their trust in our website.
Thanks again,
Erik
|
|
Josh
|
November 22, 2013 at 11:59 am
Hi Erik,
Can you clean up those old templates first? They may be causing the issue. If you see the issue happen after cleaning up the old templates please send the details to support at eventespresso.com and someone can take a look.
|
|
SBANE Webmaster
|
December 1, 2013 at 7:30 pm
Hi Josh,
Just a quick update to let you know that we stepped through the customizations to the templates, and they’re up-to-date with the present versions of the plug-ins that we’re running. There aren’t any changes to the gateway files for Authorize.net, so that isn’t an issue.
We’ll be monitoring this closely, and will notify support as soon as the issue occurs again (unfortunately, I have no reason to believe it won’t).
|
|
SBANE Webmaster
|
December 1, 2013 at 8:20 pm
Hi again Josh,
We’ve identified another occurrence of the issue this past week. I’ll notify support via the email address you provided.
– Erik
|
|
Josh
|
December 2, 2013 at 1:25 pm
So the data shows that they are logged in while they register and they’re not being charged the member only price? Is it possible that they were not logged in to the site at the time they registered for the event?
|
|
SBANE Webmaster
|
December 2, 2013 at 7:39 pm
It’s a bit more complicated than that. The transaction line item data sent to Authorize.net includes the member only price, but total transaction cost data includes the full price. So somehow both costs are being included in the string of payment data. Even more interesting, in looking at a couple examples of this behavior, I verified (comparing the date/time fields in the wp_loginlog and wp_events_attendee tables) that in one case, the user wasn’t logged in when they registered for the event, but in the other case, the user was logged in. Note these were two different users. So at this point, I’m not quite sure how to proceed, in terms of pinpointing what is happening. We just know that the issue is continuing to occur (another user reported it happening with a registration posted today).
So…what next?
|
|
Josh
|
December 3, 2013 at 7:47 am
Can you check to see if there is any caching set up on this server, either with a caching plugin installed or through the host? For example, WPEngine will cache the production site. We recommending setting the page that handles the registration served dynamically (not cached).
|
|
SBANE Webmaster
|
December 3, 2013 at 9:50 am
We aren’t using any caching plug-ins, but the hosting company (Rackspace’s Cloud Sites) does use a form of XCache for sites running PHP. I can disable it for the site and see if that helps.
Is there any chance of getting help in understanding how the cost is calculated in the code? That would let me debug the process better on a test copy of the site that I’ve setup.
Thanks,
Erik
|
|
Josh
|
December 3, 2013 at 12:16 pm
Hi Erik,
It’s probably the caching, since it’s not something that we can reproduce.
When you set the Authnet SIM gateway to test mode it will show the calculated price (and all the other fields that are sent to Authnet) in a table.
If you want to look through the code to see how Event Espresso 3.x calculates the final price, the event_espresso_get_final_price function in /includes/functions/pricing.php may be a good place to start.
|
|
SBANE Webmaster
|
December 6, 2013 at 6:11 am
Hi Josh,
We disabled the caching being done by the hosting company (for PHP code), but the problem continues to happen. Note that it is only happening intermittently – some Authorize.net transactions are going through with the correct price.
Given the importance of this issue, I’m going to purchase a support token to get direct support – obviously disappointed the forum couldn’t resolve things, but we need to fix this.
|
|
Josh
|
December 6, 2013 at 8:40 am
Hi Erik,
We are continuing to look into this. At this point, I can advise a few actions to take in order to help narrow down the issue:
1) Please remove all of the templates in /wp-content/uploads/espresso/templates. You can leave event_list.php and event_list_display.php in that location as they don’t play a role in passing prices to the gateway. We generally do not recommend having all of Event Espresso’s templates copied over to that location because it can cause things to break if they are out of date.
2) Please update to the latest versions of Event Espresso and the Event Espresso – Members Add-on. Event Espresso 3.1.36 had a few fixes that were related to using Multi Event Registration and the Member’s add-on together.
|
|
SBANE Webmaster
|
December 6, 2013 at 9:13 am
Hi Josh,
It isn’t realistic to disable all the templates in the uploads folder, as a number of those include changes critical to the display of our site. The same could be said for upgrading EE and the Members plug-in – given how upgrades have a history of breaking previously working functionality.
Instead, we’ll setup a copy of the site (as we’ve done previously) and do the upgrades there. I’ll also remove those template files that are identical to the stock files in /event/espresso for both the test site and the live site.
Once the test site is ready, I’ll update this post. In the meantime, I would hope support would examine the code and underlying data on the live site (as noted in my support token redemption request). Thanks.
|
|
Josh
|
December 6, 2013 at 9:33 am
Hi Erik,
30 minutes is not enough time to go through all of your custom code and do a complete review. Generally speaking, updating to a new version of Event Espresso will only cause issues if there is older code in the /wp-content/uploads/espresso/templates folder, which may be what’s happening here.
|
|
SBANE Webmaster
|
December 6, 2013 at 9:49 am
What time is required, ie., how many support tokens should we purchase, to at least get your team started…
|
|
Josh
|
December 6, 2013 at 9:53 am
We have started looking into the issue. Can you please work with us on this?
|
|
SBANE Webmaster
|
December 6, 2013 at 10:03 am
Of course – just let me know if/how many additional tokens are needed, if that’s the route you think best. Thanks.
|
|
Josh
|
December 6, 2013 at 4:25 pm
Hi Erik,
A little update: Sidney and I looked into this throughout the day today. We’re not sure what could be causing the issues you are seeing. He did send some tips on how to get more details via logging, which may help shed some light on what’s going on, going forward.
|
