Givebear vs GiveWP. Kiosks, fees and funds, side by side.

GiveWP fits organizations with a developer or agency already maintaining their WordPress site: teams that want donation records inside their own database, template-level control over form markup, and that are comfortable owning plugin updates, gateway add-ons, staging tests, and compatibility checks themselves.

Givebear fits organizations where nobody on staff wants to maintain a plugin stack: keep WordPress for content and stories, add a one-script embed or a donate link to a hosted giving page, and let checkout, receipts, recurring billing, and donor records run on Givebear, with a lobby kiosk available that no website plugin can provide.

Compared with GiveWP, Givebear's kiosk for a lobby or event entrance is a 21.5-inch touchscreen with a built-in Stripe card reader, sold once at $999 to $1,099 (wall mount or battery floor stand) with no per-kiosk software subscription.

Score both platforms on who maintains the donation stack (updates, patches, compatibility), PCI scope and where the checkout actually runs, donation kiosk and in-person giving, cost model: add-on bundles plus hosting vs hosted platform, and what happens when the theme or page builder updates. Use your last year-end appeal as the test case: set up the same funds and receipt wording in a free Givebear account and check whether it produces the report your board asked for from GiveWP.

Export donation and donor history from GiveWP before deactivating anything, and note which payment gateway holds your recurring subscriptions: recurring gifts created through a gateway add-on live at the gateway level and may need to be re-created or migrated there. Keep old donation form URLs redirecting to the new giving page so bookmarked links and printed QR codes keep working.

Givebear imports contacts and past gifts from a CSV, so the GiveWP export is the first step. Create your funds in Givebear before importing the GiveWP file, since fund names in it do not create funds on their own. Saved cards move only if GiveWP and Stripe support a transfer; otherwise recurring donors restart their gift on your new page, so announce the change a few weeks ahead.

Before cutover, list every place a donor can reach GiveWP: website buttons, email footers, printed QR codes, and event pages. Repoint the ones you control; a printed code that sends donors to GiveWP keeps working only as long as GiveWP keeps that page up.

The GiveWP core plugin is free to install, and the paid features (recurring donations, fee recovery, additional gateways, form field tools) are sold as add-on bundles priced on givewp.com (verified June 2026). Those bundle prices change periodically and are not reprinted here; check givewp.com for the current figures. The structural point holds regardless: the plugin license is the smallest line in the budget. The real spend is WordPress hosting that can handle checkout traffic, SSL, a staging environment for testing updates, and the developer or volunteer hours that keep the whole stack compatible release after release.

Givebear's hosted model prices the other way around: a flat platform fee from 1.9% to 5.9% depending on plan (one rate online, at kiosks, and on memberships), plus Stripe card processing at cost, with no setup fee and no monthly minimum. There is no plugin to license, no annual bundle renewal, and no separate gateway add-on, because checkout, receipts, recurring billing, and donor records run on Givebear's infrastructure. WordPress keeps doing what it is good at (content, story pages, SEO) while the donation flow stops depending on the site's update cycle. For a treasurer building next year's budget, the comparison is bundle renewals plus maintenance hours on one side, and on the other a flat platform fee with no add-ons to license.

When the donation form is a plugin inside your WordPress install, your site's update discipline becomes part of your payment security posture. WordPress puts out several core releases a year, themes and page builders update on their own schedules, and every plugin in the stack is a potential conflict with the one that handles money. Card numbers go to the payment gateway, but the page serving the form is yours to defend: an unpatched theme or a compromised plugin can tamper with the checkout page, which is exactly the e-commerce skimming scenario PCI guidance warns about. Someone has to own backups, staging tests, and rollback plans, and at many small nonprofits that someone is a volunteer with a day job.

Givebear moves checkout out of that blast radius. The embed is a single script tag that works in the block editor, Elementor, Divi, or a plain HTML block, and the payment flow runs on Givebear's PCI-scoped infrastructure rather than your server. A theme update can still break your site's header; it cannot break the donation checkout. The setup options (hosted page link, embedded widget, or both) are walked through in Givebear's WordPress integration guide at /integrations/wordpress-donation-form, and the same embed keeps working if the organization ever rebuilds the site on something other than WordPress.

GiveWP is a website plugin, so its giving stops at the website: there is no GiveWP kiosk, card reader, or tap-to-donate hardware. Organizations that want in-person giving end up improvising with a tablet pointed at the donation form, which means a browser tab someone has to keep awake, no payment terminal, and donors typing card numbers by hand at exactly the moment a line forms behind them.

Givebear's kiosk is a one-time hardware purchase ($999 to $1,099 depending on wall mount or floor stand) with no per-device subscription, running Stripe Terminal so donors tap a card or phone instead of typing anything. Gifts from the kiosk land in the same donor records and receipt flow as gifts from the WordPress embed, so the lobby and the website stop being two separate spreadsheets to reconcile. Plan details are on /pricing and the hardware itself is at /products/donation-kiosk.