GiveWP

A donation is structurally different from a purchase. There is no stock, no shipping, no cart, and the amount is chosen by the person paying. The follow-up is a thank-you and a receipt, not a dispatch note. Attempting this in a shop means switching most of the shop off.

GiveWP models donations directly, and that is the case for using it rather than WooCommerce.

What it handles that a store does not

• Donor-chosen amounts, with suggested levels and a free-entry option.
• Recurring giving as a first-class concept rather than a subscription product.
• Fee coverage — the option for a donor to add the processing fee, which meaningfully changes net income.
• Donor records rather than customer records: lifetime giving, history, and the ability to see a supporter rather than a series of orders.
• Receipts appropriate to a donation, including the fields a tax-deductible receipt needs in your jurisdiction.
• Anonymous giving and tribute or in-memory donations.
• Campaign and goal tracking, with progress display.

Any one of these can be bolted onto a store. All of them together is a different product, and that is what you are choosing.

The add-on model

The core plugin is free and handles one-off donations through a basic gateway. Almost everything an organisation actually needs is an add-on:

Bundles exist and are usually how organisations buy it. Work out which three or four add-ons you genuinely need before comparing bundle prices — and price the annual renewal, not the first year, because this is an ongoing cost for an organisation that is often working to a fixed budget. The wider budgeting picture is in what a WordPress website costs.

Gateways and fees

Payment processing is the largest ongoing cost of taking donations, and it is worth more attention than the plugin licence:

• Check the rates you will actually pay, including whether your organisation qualifies for a nonprofit rate — many processors offer one and it must be applied for.
• Enable fee recovery if your donors are the kind who will cover it. On a small donor base this changes net income more than anything else on this page.
• Confirm recurring support at the gateway, including how a failed renewal is retried and whether a bank authentication challenge can prompt the donor. The mechanics are the same as in WooCommerce subscriptions, and so are the failure modes.
• Keep card details at the gateway, never on your site.

Receipts and compliance

Donation receipting is regulated differently in every jurisdiction, and the plugin cannot know yours. Before launch, confirm with someone who does:

• what a valid receipt must contain;
• whether the recurring donation receipt differs from the one-off receipt;
• what records you must retain and for how long;
• whether donor data has residency or retention requirements.

The plugin gives you configurable receipt templates. Filling them in correctly is your obligation, and it is the part most likely to be wrong on a site that was set up quickly.

The lock-in

Donor records and completed donations export. That part is fine.

Active recurring donations do not. A recurring gift is a payment token held at the gateway, created by this plugin under its identifiers. Moving to another platform generally means asking every recurring donor to set their gift up again — and a meaningful share will not.

That cost grows with every recurring donor you add, which makes the platform decision one to take seriously at the start rather than to revisit later. It is not specific to GiveWP; it is true of anything that owns recurring billing, and it is the same trade described in MemberPress.

Add-ons are tied to the plugin, so the lock-in compounds with each one you configure.

Performance and caching

Donation forms and the confirmation page are personalised and must never be served from a page cache. A cached confirmation page showing one donor another's details is the worst available outcome here, and it comes from a missing exclusion rather than a bug — the rules are in choosing a cache plugin.

Receipts and recurring notices are transactional email, so send through an authenticated service and verify delivery before launch: WordPress not sending emails.

Common mistakes

• Running donations through a store, then spending weeks removing shipping, tax and stock behaviour.
• Launching without recurring giving because it was an add-on, then adding it later and asking existing donors to re-enrol.
• Not applying for a nonprofit processing rate.
• Receipts that do not meet local requirements, discovered at audit.
• A cached donation form, showing stale campaign totals or worse.
• No test of the failed-payment path on recurring gifts.

Before you launch

On a staging copy, with the gateway in test mode: make a one-off donation and a recurring one, confirm both receipts arrive at an external address and contain what your jurisdiction requires, confirm the campaign total updates, then fail a renewal deliberately and confirm the retry and the donor email. Finally, cancel a recurring gift and confirm it actually stops.

The last two are the ones organisations skip, and they are the ones donors notice.