@Victor, still in backlog unfortunately, but we'll get there early 2025.

Hi @Oleg, any updates on this feature? Processing online donations during these key moments of truth is a great start.

Thanks for your comments, @JPR. As we implement this, donations would be processed and recorded separately from membership/event payment.
And invoice memo for offline payments will be added automatically, no need to worry about this.
As for handling it with donation invoices - we will be definately implementing thesed in future, but no timeline yet, since it's a major overhaul of finance module of WA.

Well, I'd say it's a worthwhile but not complete solution assuming that the online payments solution records the donation as a genuine donation by the contact, not as event or membership income. Otherwise, I don't perceive any improvement. For those who want to pay offline, e.g. by check, I can easily enter the payment manually in two parts: a manual event/membership payment and a donation. I see how to include an "invoice memo" as part of the payment instructions, but don't know how to make it appear only for offline payments. The wording that would appear for both online and offline payments would depend on whether the online payer saw the invoice before or after adding the donation to the transaction.

Here's another reason to make paying for a donation like paying for an event or membership: If a user obtains a credit balance for any reason, he/she can apply it toward a donation.

I don't like it. As you have said, the donation as extra is not automatically registered as a donation by the user and visible as such in the member's profile. I am in the middle of converting 70+ donations made in the context of an otherwise free event to true donations. It is taking me days to do it. I will have to avoid donations as extra cost in the future. Having invoices for donations, whether they are pure donations or donations as extra cost, seems to have advantages, including the ability to represent pledges. What is the argument against having invoices for donations?

I may have started this topic some years ago. I haven't been tracking it in this forum, but it has come back as important to me. I have two organizations that have included donations as extra costs in membership applications and/or event registrations. My problem is, I would like those donations to appear under the contact's list of donations, but they don't. It is possible, but very labor-intensive, for the admin to tweak the WA financial records to separate the donations from the base transactions.
One possible solution is to recognize donations as a special type of extra cost. When the original membership application or event registration is submitted and its invoice generated (whether that invoice is paid immediately or later online or offline). a separate donation invoice would be generated, essentially a pledge, that could also be paid immediately or later online or offline. The paid donations, and possibly the pledges, would be listed under the contact's Donation tab.

@alex absolutely

To confirm @oleg - for online payments for events reg/membership application/renewal the invoice with a donation will have

1) an invoice for the total event/membership component
2) a separate donation generated with the appropriate amount/receipt sent to customer

So there will be an invoice, an invoice payment with tender online payment and a separate donation receipt for the donation amount with the tender online payment set as well.

Is that right?

@Oleg - right you would not want to put a donation line item on an invoice. So if you include a invoice memo to buyer to add $X to their payment you're basically counting that the buyer will do that using their preferred payment method. I see what you mean. The payment received can be split into settling the actual invoice and then applying the remaining payment towards the donation, generating a payment receipt. As long as this is documented I guess it could work.

If there was a way to generate a "draft" donation receipt for these offline membership+donations that would be a bit better. Then the draft receipt can be marked as paid in the donations module once the payment was received.

That proposed solution makes a lot of sense to me! The vast majority of our membership payments are online, and offline payments are handled manually by our Treasurer, and the money (whether it is a donation or membership fee) will ultimately end up in the same bank account.

@Alex Sirota: If we include donation into invoice - it will be taxed and in WA it will be considered as membership or events revenue. That's the main driver for this feature. There are numerous ways to include donations into invoices already - any extra charge field. But all of these workarounds would have exactly the same flaw - revenue will not be considered a donations.

@oleg - still seems overly complex. What does received extra payment for an invoice mean? You mean someone has paid more than the invoice amount and somehow that signals to WA to create a donation? Shouldn't it be part of the invoice total if the donation is marked there? I don't see how this would not be confusing.

@Alex Sirota: there's no need to adjust invoice amount - this way donation would be part of invoice, not a separate donation transaction. What we are suggesting to do is to add donation as separate financial document in WA once association has received any extra payment for an invoice.
All membership/event invoices will remain "clean" this way

The approach for offline payments seems to be odd since the invoice will not include the donation and thus involve manual interventions to adjust the invoice to include the amount of the donation afterwards. If the invoice doesn't have the donation amount someone can't pay for the donation afterwards anyways.

Why not just restrict a donation as part of the membership process only to online payments? That way a proper donation receipt can be registered and the invoice will just have the membership part of the transaction keeping records clean.

The proposed solution would work fine from my perspective. The vast majority (in my experience) of registrants/memberships that pay by invoice are large companies that would rarely if ever include a donation. The donations during a membership renewal or event registration would almost always come from individuals who generally pay by credit card.

Requiring a member to go back to the home page and make a second transaction to give a donation when they pay their membership dues is costing us significant $'s....perhaps as much as we spend on Wild Apricot (before the price increase). With 350 votes, and on the list for so long, am wondering if you are listening>

Commented in 2021, just adding a comment here in 2022 - really want/need this feature - we are a not for profit and collect donations for geology students.

@alan there is a vibrant user group on Facebook. It’s called the grove. Have you heard of it?

https://www.facebook.com/groups/WildApricotGrove/?ref=share

We plan to implement this in our next WordPress plugin. See https://newpathconsulting.com/wap for more. The partner community is doing a lot here. Join us to help.

@Oleg,

Firstly, its good to hear that WA product development reads these forums.

Secondly, without spending too much of my life trawling thru this forum, it seems to me that this request has been open for at least six years, possibly much more. And when you have administrators posting that donations are important for their revenue stream and that they are losing revenue because a "Donation" feature at the point of renewal is not available, you got to wonder what prioritises WA product development life. If Clubs are missing out on revenue because of a lack of functionality then they may start thinking about moving on from Wild Apricot.

And finally, why no WA User Group? How does WA product development know what is really needed by the Users and what is really annoying them about the product? Its a bad path for a software developer, whether that be in-house or provider such as WA, to "know" what users want and what are the burning issues. If this path is taken, invariably the developer picks the wrong functionality to implement and not surprisingly paying users can wait years (and lose revenue) while the wrong functionality is implemented

Given that I am sure WA wants to do the best by its paying User base, how can we get a User Group going to help guide functionality development? Who do I need to talk to?

thanks
Alan
PS anyone reading this who would like to contact me about getting a WA User Group going, please contact me at alan.baldry@students.mq.edu.au. Please share this offer with other WA users. If I get enough interest I'll start the ball rolling.