I have an event set up to require payment to RSVP, but it allows people to RSVP without paying.
Are they placing the event into their cart and then not checking out?
That is a known issue: RSVP without payment bug
As of right now it is up to the user to Checkout, or for an Admin to go into the Payments page and charge their TT account.
I know it is an old issue, but it very much bugs me.
I find this workaround strategy to not be very ideal. I feel like it involves a lot of oversight.
Perhaps the Member gets to checkout and realizes they have insufficient funds, but does not empty their cart. Was their intent to leave the item in the cart until they fund the account, or withdraw from the event?
If I, as an administrator, look at the event and see this person RSVP:Yes, but not having paid, and insufficient funds to pay, what should I do? I could withdraw them for non-payment and run the risk I will disappoint a Scout who thought they were going (they are on the list). Or, I could charge their account and run the risk they do not show up for the event thinking they withdrew. I might never collect on that debt. Neither is a good option.
It kinda defeats the purpose of TT. I end up having to manage RSVPs and contact the family and ask what their intent was. It is insufficient to look at the event main page and see what the body count is. Additional digging must be done to know if the “Coming” list is also a paid list.
I get that there might be difficulties in the way the application is structured that might necessitate a bit being flipped somewhere, but putting them down as “RSVP’d without purchasing” when the setting is literally “Payment required to rsvp” strikes me as wrong. If nothing else, the name of the setting is horribly misleading. “Placing item in shopping cart, but not necessarily paying, required to rsvp” would be more accurate.
If the application requires a bit to be flipped, maybe they can make an intermediate stop in the RSVP:Maybe category before switching to RSVP:Yes when payment is made. But the present system leaves a lot to be desired.
Hopefully I have no hijacked the original post… No confirmation this is even the problem.
Oof. That’s disappointing. One of the main reasons I chose TroopTrack was the ability to require people to pay in order to RSVP. The website we were using before didn’t have that feature and it’s a lot of remembering and oversight to keep up on who has paid and who owes money.
This is being looked into but the TT Admins, it may take some time to think through how to fix it and then program the system. I know everyone runs their Units their own way, in my experience allowing for Accounts to be overdrawn shows the parent they need to add money into the account but allows them to RSVP to an event and pay from their account, it does require a Treasurer to check on the Money Accounts periodically and potentially ask parents to make their payments, I am sure we have all had a few that we have to chase after but the vast majority pay on time and without reminding.
What you describe can be achieved by turning on this option:
The shopping cart issue is somehow worse because they manage to RSVP to the event and NOT end up with a negative balance. If they are planning to attend, there is no negative balance indicating to them they owe money. And, at least in the system you described, if they fail to attend the event, I would have a strong leg to stand on that they agreed to pay for the event by spending the money. When they just fail to check out, they can claim they never checked out and did not know they were recorded as RSVP:Yes. Meanwhile leadership (perhaps wrongly) relied on TT’s RSVP count to purchase food/camping/whatever.
But I do not think it is good for the product as a whole to make the solution to not rely on the information that it is displaying on the screen without checking it/digging deeper. The purpose of these systems is to be reliable. Even a little red flag that indicated there were unpaid RSPVs when the “Payment required to rsvp” option is checked would go a long way.
Hopefully they will be able to come up with a better solution quickly, always trying to make the product better. This kind of input is great. Keep it coming.
Another take on this issue, what do you think?