Choosing a WordPress Donation Plugin
A donation is not a purchase, and treating it like one costs you money at the form. The categories differ mainly in how they handle recurring giving, receipts and donor records.
The thing that separates donation tools from shop software is that a donor chooses the amount, often chooses to repeat it, and needs a receipt that is not an invoice. Everything else is presentation. If your fundraising is one-off and infrequent, almost any option works; the moment recurring giving is involved, the category choice decides how much administrative work you inherit.
The three routes
| Route | Strengths | Weaknesses |
|---|---|---|
| Dedicated donation plugin | Donor records, recurring giving, receipts, campaign goals, fee cover | Another system to maintain alongside any existing shop |
| Ecommerce with a donation product | One checkout, one order history, existing tax and reporting | Awkward for open amounts, recurring gifts and non-commercial receipts |
| Payment form or contact form add-on | Fast, minimal, cheap | No donor records, no recurring management, no reporting |
The third route is genuinely fine for a small campaign with a fixed end date. It stops being fine the moment somebody asks how much a particular donor has given over three years, because nothing recorded it.
If you already run a shop, adding a donation product to WooCommerce avoids a second checkout and a second set of emails. Accept that you will be editing order email templates so that donors are not thanked for their "purchase".
Evaluation criteria
- Recurring giving. Whether it is native or an extension, which processors support it, and — the important part — whether donors can change or cancel their own recurring gift without emailing you.
- Amount handling. Suggested amounts, a free-entry field, minimums, and one-off versus monthly presented as a genuine choice rather than a buried toggle.
- Fee cover. An optional, clearly labelled checkbox that shows the actual amount added.
- Receipts. Whether the plugin can issue a receipt that meets your jurisdiction's requirements for tax-deductible giving, including any registration numbers and required wording.
- Donor records. A donor entity that persists across gifts, rather than a list of unrelated transactions.
- Offline and pledged donations. The ability to record a cheque or bank transfer manually so reporting is complete.
- Campaigns and goals. Multiple funds, progress displays, and honest handling of what happens when a goal is exceeded.
- Data export. Because donor data will eventually need to live in a CRM rather than in the plugin.
- Anonymity. Some donors do not want to appear on a public list. That needs to be a per-donation setting, not a global one.
The parts that go wrong
Email. Donation receipts are transactional email, and WordPress sending mail through PHP is unreliable at the best of times. Sort this out before launch, not after a donor complains — WordPress not sending emails covers why and what to do.
Trust signals. A form asking for money on a page with a browser warning gets abandoned. Fix any not secure warning first, and make sure the donation page names the organisation, the fund and the processor.
Personal data. Names, addresses, amounts and sometimes tax identifiers are stored on your site. Tighten the basics using the WordPress security checklist, and check what your tracking scripts are collecting on the donation page.
Spam and card testing. Public payment forms attract automated card-testing attempts. Whatever plugin you choose needs a rate limit or a challenge — adding reCAPTCHA to a WordPress form is one way, and the processor's own fraud rules are another.
Test with real money
Test mode proves the code path; a real transaction proves the account.
- Give a small real donation, on a phone, as a logged-out visitor.
- Check the receipt arrives at an external address and reads correctly.
- Confirm the transaction appears in the processor's dashboard with the right reference.
- Set up a recurring gift, then cancel it as the donor.
- Refund the test donation and confirm the plugin's records update.
- Submit the form with a deliberately failing card and read the error the donor sees.
- Record an offline donation manually and check it appears in totals.
- Export the donor list and open the file.
- Confirm no card data appears anywhere in your database.
Choosing
Pick a dedicated donation plugin if recurring giving, receipts or donor history matter — which is almost always true for an organisation rather than a one-off appeal. Pick the ecommerce route only when you are already selling and donations are the smaller half. Pick a simple payment form only when the campaign has an end date and you are willing to have no donor records at all afterwards.
Frequently asked
- You can, and it works if donations are occasional and one-off. It struggles with recurring giving, donor-chosen amounts, gift aid or tax-receipt fields, and anonymity options, and every donor gets an order confirmation that reads like a shop receipt unless you rewrite the templates.
- Offering it as an opt-in checkbox is normal and a meaningful share of donors accept. Making it compulsory or pre-ticking it is not, and in some jurisdictions a pre-ticked charge is a consent problem, so present it as a clear choice with the amount shown.
- A properly built one never does. Card data should go directly from the donor's browser to the payment processor through a hosted field or redirect, so your database only ever holds a transaction reference. If a plugin offers to store card numbers, that is a reason to reject it outright.