What donation plugin should I install on a nonprofit client's site if they can't pay an annual license?
The honest constraint on a small nonprofit build is not the plugin. It is the renewal. You can absorb a one-time cost inside a $2,500 build. You cannot absorb something that comes back every year on a budget that was approved once, by a board, for a website, and will not be revisited until somebody notices the site is broken.
So the requirement is narrower than "a good donation plugin". It is: nothing that expires, nothing keyed to a domain, nothing that reduces the client's deposits, and nothing that turns into your problem in eighteen months when the executive director who signed the contract has moved on.
Donor Merchant is built to that shape. It is GPL, listed on WordPress.org, version 2.4.1, requires WordPress 6.2 or newer and PHP 7.4 or newer, and ships every feature in the free plugin. There is no Pro edition, no add-on store, no activation screen. You install it the same way on the first client site and the fortieth.
Does the free version of GiveWP take a percentage of donations?
This is the question that ends the conversation for most developers, and the best statement of the problem is not marketing copy. It is a one-star review left on WordPress.org by somebody in exactly your seat:
"I had to find out the hard way when a mad client contacted me asking why I was taking 2% of their money and in fact it's GiveWP giving themselves 2% of their money and never even mentioning it... Fine, I'll move on to something else."
Read the mechanics of that sentence, because they are the whole argument. A percentage skimmed from a client's Stripe deposits does not arrive with a vendor's name on it. It arrives as a smaller number in the bank account of an organisation that trusts you and does not read Stripe's balance reports. The person the client calls is you. You are the only vendor they have a phone number for.
Per the vendor's own fee documentation, GiveWP's free version applies a 2% platform fee to Stripe donations after an initial grace period, removed by holding a license or the premium Stripe add-on. PayPal is not subject to the added platform fee. That documentation URL has moved since the corporate consolidation described below, so verify the current terms before you quote them to a client. Checked August 2026.
Donor Merchant takes no percentage of anything, ever. There is no code path in the plugin that adds a fee, an application fee, or a Stripe Connect platform account. Your client's Stripe secret key belongs to your client's Stripe account, and the money lands there minus Stripe's fee only. We wrote the longer version of that argument in donation plugins with no platform fees.
What happens to a client's donation forms when their plugin license expires?
Nobody in this category writes this section, which is strange, because on a client book it is the most likely thing to actually happen. A card on file expires. The bookkeeper who owned the receipt retires. A renewal invoice goes to an inbox that no longer forwards anywhere.
With a licensed donation plugin, a lapse is not neutral. The forms usually keep rendering, so nothing looks broken, but updates stop, premium gateway add-ons fall out of support, and where the vendor's free tier carries a platform percentage, that percentage comes back after the grace window closes. The client's donations quietly shrink and no error appears anywhere. Reinstatement pricing after a vendor consolidation is its own open question, and one you should confirm in writing with the vendor rather than assume.
With Donor Merchant there is nothing to lapse. No key is checked, no domain is registered, no remote server is asked for permission. If you disappear tomorrow and the client never speaks to us, the forms keep taking donations and updates keep arriving through the normal WordPress.org update channel.
What does this actually cost across a book of client sites?
Do the arithmetic per client rather than in the abstract, because "it's only $399" sounds different when it is a line on a nonprofit's operating budget.
| Scenario | Cost to the client, per year |
|---|---|
| A 2% platform fee on a client raising $50,000 online | $1,000, deducted invisibly from deposits |
| Same client, raising $150,000 online | $3,000 |
| An annual license at the tier that unlocks recurring giving, on one site | Several hundred dollars, renewing |
| Twelve client sites each carrying that license | Four figures a year across the book, and twelve renewal dates to babysit |
| Donor Merchant on any number of sites | $0, plus Stripe or PayPal's own processing fee |
For reference, Give lists tiers at $199, $399 and $599 per year, with recurring donations, the donor portal and fee recovery at Pro and tributes plus funds and designations at Elite. Charitable lists roughly $99, $199 and $299 per year, gating recurring donations, fee relief and annual receipts above the entry tier. Verify both before quoting. Prices checked August 2026. The full per-feature breakdown lives in our donation plugin cost comparison.
The features those tiers gate are the ones a nonprofit actually needs: recurring giving, a donor portal, fee recovery, tributes, funds and designations. All of those are in the free Donor Merchant plugin.
What happened to GiveWP after the Liquid Web acquisition, and should I keep using it?
Since 12 May 2026, following the retirement of the StellarWP brand, givewp.com no longer stands on its own. The blog, product and pricing paths redirect into liquidweb.com, and the documentation has moved again on top of that. Checking in August 2026, the fee documentation URL on liquidweb.com now issues a 302 to docs.nexcess.com. Context on the reshuffle is at WPBeginner's write-up.
That is not a reason to rip a working install out of a happy client's site this week. It is a reason to check, before you commit a new build to it, that the pricing page, the fee terms and the support channel you are promising the client still resolve to a stable address. Notably, the same product page pitches directly at you: "Give is built for agencies and freelancers managing fundraising sites for nonprofit clients."
No paid tier also means no upgrade-migration bugs
This is the structural argument, and it is the one developers care about once the pricing conversation is over. A plugin with a free edition and a paid edition must ship an upgrade path: a schema migration, a settings translation, an add-on compatibility matrix. That path is code, and code is a place bugs live.
Two documented examples from this exact category:
- A user upgrading to Charitable Pro reported: "Yesterday, I switched our website from the free version of Charitable to Charitable Pro... When I tried to save that change, WordPress crashed." It traced to a schema mismatch, "Unknown column favorite in wp_charitable_donors", which blocked settings saves entirely (support thread).
- A review titled "Right after a fundraising dinner they crashed our website", where the vendor conceded: "we released that yesterday afternoon, and were immediately made aware of an incompatibility with our Form Field Manager add-on."
Donor Merchant has one edition. There is no free-to-paid code path, so there is no upgrade-migration class of bug, and there is no core-versus-add-on version skew because there are no add-ons. One version number moves.
Who owns the donor data, and how do I hand it off?
Say this to the client in writing, because it is true and it is unusual: the donor records live in their own WordPress database, in the plugin's custom tables, on their own hosting. Nothing is mirrored to us. We have no account, no dashboard and no copy.
The donations CSV export is the piece that matters at handoff. It writes these columns: ID, First Name, Last Name, Email, Amount, Fee, Total, Currency, Frequency, Status, Method, Campaign, Designation, Transaction, Tribute, Tribute Name, Note, Custom Fields, Date. Gross, fee and total are separate columns, and the processor's transaction ID is its own column, which is what lets a bookkeeper reconcile the export against the Stripe or PayPal payout without guessing. A client who wants to leave can leave with a complete, usable file.
Setup that survives you leaving the project
Prefer configuration a non-technical successor can inspect. Donor Merchant takes API keys entered directly into the settings screen rather than an OAuth connect flow, which sounds less slick and is more durable: a key you can see is a key someone can re-enter, whereas a broken connect handshake produces threads like "10 hours trying to get Stripe working".
- Create or get access to the client's own Stripe and PayPal accounts. Never your own. Follow Stripe setup and PayPal setup.
- Enable test mode for Stripe and PayPal sandbox and run a card donation, a recurring donation and a PayPal donation end to end.
- Check the receipt email arrives and the admin alert goes to a real monitored address, not the developer's.
- Add the webhook endpoints for both gateways. Recurring renewals depend on them.
- Switch to live keys and make one real donation of a small amount from your own card. Confirm it appears in the client's Stripe or PayPal balance, in the plugin's donations list, and in the client's inbox. Refund it.
- Publish the form with the block or the shortcode, and hand over the sheet below.
Making it look like the client's site without a CSS fight
A documented complaint about a competitor: "Customizing the style of a form is something out of a nightmare... They've riddled their CSS with !important classes so overriding is difficult. I have wasted many hours." (support thread).
Donor Merchant exposes six named accent swatches plus a custom colour picker with live preview, and three button shapes (pill, rounded, sharp). Those settings are injected as CSS custom properties named --dm-accent, --dm-accent-dark and --dm-radius via wp_add_inline_style, with no !important anywhere. Your theme stylesheet wins normally. For anything past that, redefine the properties in your child theme and you are done.
The developer surface, concretely
| Surface | What is there |
|---|---|
| REST | Namespace donor-merchant/v1, including donate, capture, verify, receipt, statement, portal and the signed Stripe and PayPal webhook routes |
| Filters | Documented hooks including donor_merchant_rate_limit, donor_merchant_suppress_receipt and donor_merchant_suppress_admin_notification |
| Output | A Gutenberg block plus [donor_merchant], [donor_merchant campaign="N"], [donor_merchant_progress campaign="N"] and [donor_merchant_portal] |
| Outbound | Signed outgoing webhooks for Zapier or Make, and Mailchimp audience sync (integrations) |
| Source | GPL, readable in wp-content/plugins/donor-merchant, and on WordPress.org |
The one-page handover sheet
Copy this into a document, fill it in, and give it to the client at launch. It travels: a departing volunteer forwards it to their replacement, and you stop being the only person who knows how the donation page works.
| Item | Fill in |
|---|---|
| Where the payment keys live | WordPress admin, Donor Merchant, Settings, Stripe tab and PayPal tab. Account owner: ______ |
| Who receives donation alert emails | ______ (Settings, Email tab) |
| Where donations are listed | Donor Merchant, Donations. Export button produces the CSV for the bookkeeper. |
| How to add a cash or cheque gift | Donor Merchant, Donations, Add Donation. See offline donations. |
| How to pull year-end tax statements | Donor Merchant, Donors, annual statement. See receipts and statements. |
| Where donors manage their own recurring gift | The portal page at ______ , passwordless magic link by email |
| Who to contact | Website: ______ . Payments: Stripe or PayPal support. Plugin: WordPress.org support forum. |
Migrating an existing client off another plugin
Be straight about this, because overclaiming here costs you a weekend. There is no automated importer today. Historical donor records do not move across by themselves.
What is not at risk: recurring plans created by another plugin live in the client's own Stripe or PayPal account, not in the plugin, and they keep charging on schedule regardless of which plugin is installed. Donors do not get cancelled by a plugin swap.
What needs a plan is record-keeping. Export the old plugin's donation history to CSV and archive it as the pre-migration record, keep the old plugin's reporting available until the client's year-end statements are issued, and decide with the client whether the first year's statements come from the old system, the new one, or both. If a donor asks a question about a gift made before the switch, someone needs to be able to answer it. Tax treatment of receipts is a question for the client's accountant, not for us.
Where the paid support tiers fit for an agency
Plainly: they buy a person, not features. Every feature is in the free plugin and always will be. The Agency tier exists so that when a client's Stripe webhook starts failing on a Friday you have somewhere to escalate rather than a forum queue. That is a cost you carry as a vendor and bill inside your own retainer, at your own margin, instead of routing your client's donation revenue to a plugin company. It is optional, and plenty of agencies never buy it.