Support

October 15, 2017 at 7:41 pm

Hello!

I have been using Event Espresso for almost a year now, and have hired one of your recommended developers to create a custom plugin for Event Espresso for the organization I represent. They have invested a considerable amount of time to develop this plugin for me, but there are two errors that my developer cannot seem to overcome due to what he believes may be limitations within the Event Espresso coding. They are fairly important issues that I’m hoping to either find a solution for or a workaround, and was hoping you could help me. Let me first give you a background of my organization’s process flow and the challenge for which I hired the developer, to help you understand at which point in the process the errors are occurring.

General Process:

My members-only organization holds various events (fieldtrips, outings, gatherings) for families of young children. Members are encouraged to attend a monthly members meeting whereby they are able to register and pay for these events. Registrations for these events are on a first-come-first served basis and members are given priority based on the order by which they arrive at the meeting. Members who do not attend the monthly meetings only have the ability to register for events to the extent there is any remaining capacity. We have been adopting to Event Espresso to transform this process from a manual one to a fully electronic one.

Issue that Custom Developed Plugin is Meant to Solve:

The plugin is designed to automate the prioritization phase of the event registration approval process based on a member’s arrival to the meeting, and to automatically process registrations (or put them on a waitlist if an event has reached its capacity).

Current process that the Custom Plugin Follows:

There are two parts to the plugin – “Business Process #1” and “Business Process #2”. When BP#1 runs, it takes all current paid members registered on our website (through our membership plugin – MemberPress) and creates an approved registration to a Monthly meeting event in Event Espresso. Then, when members arrive at the meeting, we check them in using the Event Espresso Mobile app. BP#1’s primary purpose was to eliminate the need for a member to register for the monthly meeting event in advance.

Business Process #2 is the more complicated process of the plugin, and the one in which we have a few critical issues. This is the part of the process that performs the arrival prioritization and processes event pre-registrations. Here is the overview of the BP#2 process:

• Prior to the monthly meeting, members pre-register (selecting a “pre-registration” ticket type) for the various events being showcased with said monthly meeting. All pre-registration tickets default to “Not Approved”.
• Based on the timestamp recorded (to the monthly meeting event) upon the check-in of each member (I used this code for the timestamp – https://github.com/eventespresso/ee-code-snippet-library/blob/master/admin/jf_ee_registration_report_add_checkin_timestamps.php), BP#2 builds a prioritization matrix based on each member’s check-in timestamp.
• BP#2 then proceeds to process each member’s event registrations sequentially (in order based on the timestamp recorded) and sets the transactions to either “approved”, “pending payment” (if the event has a cost) or “declined” (if the event has reached capacity). E-mails are generated via Event Espresso’s natural process and set to each member. (NOTE: I decided to use the “declined” tag as a surrogate “waitlist” tag. I have altered the e-mail that gets sent out for declined status to notify the member that they have been placed on a waitlist).
• For each registration marked as “declined”, BP#2 also adds a line to the Ninja Forms waitlist that I am using based on your recommendation (https://eventespresso.com/wiki/using-ninja-forms-to-create-wait-lists-for-your-events/).

Now for the problems we are having:

1. Error #1 – When an event reaches capacity as a result of executing BP#2, and a member that has a registration in “declined” (waitlisted) status then goes to pay for their other events that they have been approved, the payment page errors out and won’t allow a successful payment through stripe. Here are the errors:

a. Error Message #1 (which shows immediately upon the said member clicking on their payment link to be brought to the payment page). “We’re Sorry. It appears that the event you were about to make a payment for has sold additional tickets since you first registered, and there are no longer enough spaces left to accommodate your selections. You may continue to pay and secure the available space(s) remaining, or simply cancel if you no longer wish to purchase. If you have already made a partial payment towards this event, please contact the event administrator for a refund.”
b. Error Message #2 – If you then try and proceed with payment (where it opens the Stripe payment popup), once you successfully pass the Stripe payment and after it returns you back to the Event Espresso page, it then shows the following error (and payment never completes): “An error has occurred: It appears that the <<EVENT NAME>> event that you were about to make a payment for has sold out since you first registered and/or arrived at this page. Please refresh the page and try again. If you have already made a partial payment towards this event, please contact the event administrator for a refund”. The “<<EVENT NAME>>” is the event for which the member has a declined registration. No payment actually processes after this error message disappears, so the overall process comes to a halt.
c. My developer has tried to set the “declined” (waitlisted) registration instead to “cancelled”, left as “not approved”, or even moved them to the trash can – the same error in ‘b.’ above still occurs.
d. The only workaround we have found is to have BP#2 increase the capacity for the event, which actually does then allow the payment for other events to be successfully processed for this member (with no payment for the declined event), but the issue there is that the event then has “false positive” capacity whereby a member can then still register for the event through a subsequent “general registration” ticket type (which only opens after the pre-registration and BP#2 has been completed).
e. Since the workaround described in ‘d.’ above only partially solves the main problem, the only other workaround I can think of is to add a hidden admin ticket and have the available tickets for the “general registration” ticket type go to zero through the BP#2 plugin. This would then prevent other users from buying tickets, but the event will also not be listed as “sold out”, and thus the Ninja Forms waitlist will not show up. Also not a very good option.

2. Error #2 –
a. When a member is able to successfully make a payment through Stripe (after opening the payment link from the email), the issue is that the stripe popup payment screen is showing the wrong amount. The strange thing is that the Event Espresso page shows the correct amount (and excludes payment for the event by which the member has been declined). For example – The event espresso payment page is showing that the member owes $10 (and does not show the declined event at all that would ordinarily add $5 to this total if approved), the Stripe plugin is actually showing $15 is to be paid.
b. The stranger thing now is that when the payment is posted to Event Espresso from Stripe, it is only posted for the $10 amount and not $15 as it looked like Stripe was processing. Also, when you log into the Stripe dashboard directly, it only shows that $10 has been paid.
c. So in the end, the correct amount is actually being paid (as shown through both the stripe portal and the Event Espresso confirmation page), but the member sees the incorrect amount in the stripe payment popup screen.
My developer noted that he has tried to find the hook for modifying the checkout process but he could not find anything that could be used directly. I know that EE is working on the waitlist plugin, so perhaps that will solve part of the problem above (Error #1), but Error #2 still remains that Stripe is showing the member the wrong payment amount but then is correctly processing the correct amount behind the scenes.
Any way you guys can help with this? We are due to start using this process in about a month, and I’d love to get this process wrapped up and going live.

Thanks in advance!
Marshall