GiveWP plugin review and common issues

Payment success and donation recording are two separate steps — the payment gateway must notify GiveWP that payment completed. Check: (1) for PayPal, verify IPN (Instant Payment Notification) is enabled — GiveWP requires PayPal IPN to record completed donations; (2) for Stripe, verify the webhook is registered in Stripe Dashboard pointing to your site URL; (3) check Give → Reports for any failed or pending donations that may be stuck; (4) enable WP_DEBUG and check error logs for GiveWP payment processing errors; (5) verify the donation form is using the correct payment gateway and that the gateway is fully configured in Give → Settings → Payment Gateways.

Go to Give → Settings → Emails → Donation Receipt and verify the email is enabled and the template contains valid content. Check: (1) WordPress email is working — use WP Mail SMTP test to verify; (2) the donation is recorded as “Complete” status in Give → Donations (pending donations may not trigger emails); (3) the donor’s email address is correctly captured in the donation form; (4) spam filters may catch “donation receipt” emails — ask the donor to check spam; (5) configure WP Mail SMTP with a proper SMTP provider to improve email deliverability for important transactional emails like donation receipts.

Go to Give → Settings → Payment Gateways → Stripe. Verify: (1) the Stripe API keys (publishable and secret) are entered correctly — test keys start with pk_test_ and sk_test_, live keys with pk_live_ and sk_live_; (2) test mode matches the key type — do not use test keys in live mode; (3) register a webhook in Stripe Dashboard → Webhooks pointing to your site’s webhook URL (found in Give Stripe settings); (4) the Stripe account is fully verified and not restricted; (5) check Stripe Dashboard → Logs for specific error messages for failed charge attempts.

The Crowdfunding add-on (part of GiveWP’s premium add-ons) provides campaign goals and progress bars. With it installed: go to Give → Donation Forms → [form] → Crowdfunding settings. Enable the campaign goal, set the goal amount, and configure the progress bar display. The form page shows a visual progress bar tracking donations toward the goal. When the goal is reached, the form can automatically close to new donations or display a completion message. For simple fundraising thermometers without the full crowdfunding add-on, display donation totals using GiveWP shortcodes.

Go to Give → Settings → Payment Gateways and look for the “Fee Recovery” option (this may be part of the core or a specific add-on depending on your GiveWP version). Enable fee recovery and configure the fee percentages for each payment method (Stripe card: 2.9% + $0.30, ACH: 0.8%, etc.). With fee recovery enabled, donors see a checkbox option “Add X% to cover processing fees” on the donation form. When checked, the extra amount is added to their donation so the nonprofit receives the full intended donation amount after fees.

For small nonprofits with limited technical capacity, Donorbox’s SaaS model (hosted, maintained, no WordPress required) has lower operational overhead. Donorbox charges a platform fee (1.5% on donations after the first $1,000/month free), which adds up at higher volumes. GiveWP’s flat add-on pricing becomes more cost-effective as donation volume grows — above approximately $5,000/month in donations, GiveWP’s flat pricing typically outperforms Donorbox’s percentage model. For nonprofits with WordPress sites and basic technical capability, GiveWP’s data ownership advantage is also meaningful.

Yes — through the Recurring Donations add-on (available as part of GiveWP’s premium bundles). The add-on adds subscription billing frequency options (monthly, quarterly, annually) to donation forms. Donors select their giving frequency at checkout. GiveWP automatically charges the stored payment method on schedule using the gateway’s subscription API (Stripe Subscriptions, PayPal Subscriptions). Donors can manage or cancel their recurring donations from the GiveWP donor portal.

Yes, that can happen, especially on older sites with many plugins. This usually happens when the plugin, theme, and add-ons are updated out of sequence. In most cases, testing on staging catches the issue before it reaches the live site. From experience, backups and changelog reviews save a lot of cleanup time.

Start by checking whether another plugin already does the same job. In most cases, overlap is what creates avoidable conflicts and performance issues. A common issue is installing a plugin because it looks convenient without checking the stack first. From experience, a short compatibility review avoids most of the pain later.