Different payment options for events/membership
In release 2.3.4 you added the manual payment option which is valid for all payment types.
I would like to be able to make the manual payment option open to the few hundred people who are the membership but not make it available to the thousands who sign up for events.
I do not have a need to have it selectable at each membership level or for one event or another - just events vs. members. Any chance?
Released as a part of 5.7 version. See http://help.wildapricot.com/display/DOC/Release+5.7
Leah, it's possible to set payment instruction for any event and it will be shown on registration confirmation screen and in invoice details. See our help page for more details http://help.wildapricot.com/display/DOC/Registration+types+and+settings#Registrationtypesandsettings-Eventregistrationmessageandpaymentinstructions
Button Pay online is shown on invoice details screen after specified payment instruction. So registrant has an ability to pay online even after choosing manual payment .
Let us know if you have any questions.
Leah Gray commented
I'm having the issue of my clients signing up for our events and then choosing to pay offline - they then get confused by the fact that once their registration process is complete, the final page still shows an unpaid invoice and gives no option except a button saying to pay the invoice online. It doesn't say that their registration is confirmed or give any information about how to pay offline (cheque, cash etc). Would it be possible for us to manually enter information that could be displayed on the last page of the registration process? It would be nice to tell them that their registration is complete, but that we need the cheques or cash by a certain date in order to hold their spot (and maybe even give instructions on where or how to deliver the money to us). Is this already possible and I've just missed the option somewhere? Right now, my only option is to include that information in the first email that is sent out.
Walt Bilofsky commented
When you say the payment options can be set for each membership level, are you talking just about membership renewal, or about both membership renewal and event registration?
To offer event payment options based on membership level (as Robbi requested), it would seem simpler to apply the setting to each registration type, which could then also be used to specify the membership level(s) entitled to that payment setting.
Otherwise you need a more complicated UI for the payment option.
Fluid Apricot commented
Although the online/offline setting appears on "Registration types" page it will actually apply to the entire event (not individual registration type). i.e. You have to edit the event itself in this case, not a specific registration type.
You will also be able to set the allowed payment options (online/offline/both) for each individual membership level.
Walt Bilofsky commented
In the presentation, the choice of online/offline payment is shown under "General Registration Settings." Do you mean to show it as editing an Event Registration Type?
And will this choice also be available for dues payments?
We have the opposite problem from garylroth - we want to only allow offline payments for dues, but online option for event registrations.
This will be done together with payment options for per event/level.
To setup pay on the day event you will have to limit event to offline payments only and make appropriate payment instructions.
"Pay on the day" (cash) as an option when setting up an event.
Rather than having to have a free option or having a messy finance process to sort out the issue.
Russell Noble commented
Trying to work out will this mean we can have different online payment systems per event? I'm wondering if it's possible to have different Stripe accounts for different events?
We have finished analysis of this problem and you can review planned changes in the presentation below.
When implemented, all events and membership levels will have options to set up accepted payment methods. This feature was required to implement other payment-related changes in our public registration and application wizards, so it is likely that all these related issues will be developed at once.
Now issue is in development queue and you can always check current status in our roadmap http://help.wildapricot.com/display/DOC/Product+roadmap . Feel free to add your comments and suggestions to the forum thread.
Related wishlist threads:
Reduce number of emails and optimize per-payment method http://forums.wildapricot.com/forums/308932-wishlist/suggestions/8826745-reduce-the-number-of-emails-and-optimize-per-payme Only complete registration once payment is received http://forums.wildapricot.com/forums/308932-wishlist/suggestions/8826850-only-complete-registration-once-payment-is-receive
We need the ability to allow online payments for membership and prohibit online payments for events.
I'd advocate this as well.
Evgeny Zaritovskiy commented
Thanks for you comments. Unfortunately, this is still in queue and not going to be released soon.
This has also been a problem for us. We only use the event module (since it's too complicate to go through a two step process of registering to be a member and then registering again for the event). We want the most simple, fool proof methods of invoicing and payment. No one should be blocked out or logged off when registering.
I strongly support having the option for different payment types on each event and membership. Our events are varied in terms of size and cost and it doesn't make sense to us to require them all to be handled the same. My understanding of this thread is that we would have the option on each event of having manual, online, or both. Would the same be true of membership? - not that we need the option to have separation for membership.
However, we do need the ability to have separate accounts for online payments for membership and each event. Each of our events are run as a zero cost event and have their own checking accounts which are separate from our membership dues.
Dmitry Buterin commented
Hi Robbi, I do not think this is the best thread - but your point is very valid and makes good sense. The challenge with non-member users is that right now we can not authenticate them to let them continue the payment process. Anyway, in our next version 4.3 (~November) we are redesigning the workflows around this and all users will always get invoices and will always be able to go back and pay online at any time. I think this addresses your point.
In addition to the payment types themselves, it is very important that everyone (members and non-members) are able to return to their registration and pay on-line. Whether they did not complete their payment once selecting the payment type "online", or if they have an invoice that they want to pay on-line with their credit card, every registrant should be able to use the on-line payment service.
Currently, when a member registers for an event and selects "Manual payment" or selects "on-line Payment" but does not complete the payment checkout, the next time they try to register they are prompted to continue the registration and pay either on-line, or to create a new invoice (this is great, although the fact that a new invoice is generated is problematic for reasons I will discuss later).
We would like this same process to happen with non-members. Currently, if they select manual payment , or if they select on-line payment but don't pay, the next time they try to register non-members are not allowed to continue to the payment page, but instead are given the following message:
"User is already registered for this event but registration is still in pending status. Usually this means that payment was not completed. Feel free to contact administrator or proceed to add another registration".
We want to make it as easy as possible for all registrants to pay us, ESPECIALLY non-members since we have less capacity to hold them accountable. This is the reason we need to limit the privilege of invoicing to our members in the first place.
However, by not allowing non-members to return and pay on-line if they haven't completed the payment process, this severely limits the ability of the entire event registration module.
In regards to the automated cancelling and re-issuing of invoices when members return to their unpaid registration: I know this has been addressed elsewhere, but many companies/individuals require an invoice. Then they often want to pay that invoice by credit card. With this current set up, their accounts payable department won't be able to match invoices because when they go through the process to pay on-line, a new invoice number will be generated. Is there no way to let people see their outstanding invoice, and then pay on-line?
We could really use this. We give our members an option to pay for a whole year at a time or they can break it up into equal monthly payments if they set it up on automatic withdrawl. We obviously do not want the manual option available when they choose an automatic withdrawl membership, but it should be there for annual payments for which they can send in a check or pay cash. Please make this a priority!!!!!
I posted in another thread before being directed to this one.
This is a high priority for us. Our administration policy states that only members may be invoiced. All non-members attending an event, in addition to paying a special non-member price, must pay on-line (i.e. upfront). Invoicing is a privilege of membership for those members in good standing.
Our priority is not necessarily distinguishing between membership payments and event payments, but crucially by who is paying for the event. For us the distinction is more crucial between members and non-members vs membership applications/renewals vs. events.
The more customization the better, so I suggest that these settings should be able to be set at the lowest level for the maximum customization. There could be a default for memberships vs. events so those that are most concerned about that don't have to change the settings on each registration type. However it allows for customization at the individual ticket/registration level.
Currently there is no way to offer the option of "manual payment" to our members without by default having the option visible and available to anyone registering for our events. Although we can provide a disclaimer on the page as a temporary work around, we all know that not everyone follows instructions, and temporary workarounds are by definition not a permanent solution.
I would strongly suggest that in addition to being able to identify the types of registrations and price levels available to a registrant based on member vs. non-member status, and even by membership type, that the payment options are also customizable based on registration/and or membership type.
I also really like the text box suggestion. I think that would be very useful.
Our administration policy states that only members may be invoiced. All non-members attending an event, in addition to paying a special non-member price, must pay on-line (i.e. upfront). Invoicing is a privilege of membership for those members in good standing.
However, there is currently no way to limit the payment type by membership or registration type.
This means that there is no way to offer the option of "manual payment" to our members without by default having the option visible and available to anyone registering for our events. Although we can provide a disclaimer on the page as a temporary work around, we all know that not everyone follows instructions and this will not be a permanent solution.
I would strongly suggest that in addition to being able to identify the types of registrations and price levels available to a registrant based on member vs. non-member status, and even by member type, that the payment options are also customizable based on registration/and or membership type.
Dmitry Buterin commented
Whenever we plan a release, we always go through all the wishlist items. And while we have addressed many other things in the past 3 years, this particular one is still outstanding - which is bound to be the case for some of the items.
So what we are doing now is not some abstract fundamental redesign but something which
1) Addresses a number of issues on the wishlist AND
2) Addresses common support requests which are not visible here AND
3) provides the foundation for further changes (vs. being some dead-end hacks)
We will keep moving on the wishlist items as quick as we can.