Embed a donation form on your website with one script tag

On WordPress, add a Custom HTML block in the block editor (or an HTML widget in Elementor or Divi), paste both lines, and update the page: there is no plugin to install or keep patched. On Squarespace, add a Code block where the form should appear and paste the same two lines; Squarespace runs script embeds on paid plans above Personal, so a site on the Personal plan should point its donate button at the hosted Givebear giving page instead.

On Wix, use the Embed HTML element and paste both lines into the same element: Wix sandboxes embeds in an iframe, so the widget renders inside the element's bounds, which makes the inline form (sized to fit the element) a better choice there than the modal button. On Webflow, drop an Embed element into the layout, paste the snippet, and publish: Webflow runs custom code only on the published site, never inside the Designer canvas, so test on the staging domain. On a hand-built site, place the div where the form belongs and load the script once before the closing body tag; one script load mounts every widget on the page.

The conversion gap between an embedded form and a donate-button redirect comes from friction that compounds at the worst possible moment. A redirect inserts a full page load between intent and action, switches the donor into someone else's visual identity, and asks them to trust a domain they have never seen. On a phone over a patchy connection, those three frictions stack right at the point of highest giving intent, and some share of donors simply closes the tab.

A hosted donation page still has a job. It is the right destination for QR codes on printed flyers, links in email appeals, and the bio link on social profiles: contexts where there is no host page to embed into. The embedded form's job is the pages supporters already read, like the campaign story, the program page, and the homepage. Both channels write to the same funds and the same donor records, so choosing per placement costs nothing in reporting.

Givebear's embed runs on the same organization account as the lobby kiosk (a one-time $999 to $1,099 purchase with no per-kiosk subscription) and every QR code, so each channel writes to the same funds, campaigns, and donor records the moment a payment clears. The alternative is a silo: a donation form bolted onto a website usually keeps website gifts in one export, kiosk gifts in another, QR campaign gifts in a third, and a treasurer merging CSVs every month to answer how the building fund is actually doing.

That single ledger changes the reporting rhythm. A campaign thermometer counts the $50 embedded-form gift and the $20 kiosk tap in the same total in real time. The donor behind both appears as one record with a complete giving history, and their year-end statement covers every channel in one document. The treasurer reconciles one export against one deposit stream instead of untangling three platforms with three fee structures.

Most embed failures trace to three configuration mistakes, all visible before launch. The organization ID must be the UUID from the dashboard (a slug or organization name in data-organization-id will not mount), the organization must be payment-ready with its Stripe account fully onboarded, and any fund or campaign referenced by data-fund-id or data-campaign-id must be published and active. The browser console reports each of these as a [Givebear] warning that names the specific problem.

With configuration confirmed, run one real test gift on a phone, not just a desktop, and check that the receipt email arrives and names the right fund. For visitors with JavaScript disabled and for search crawlers, pair the widget with a static fallback link (a data-givebear-fallback element pointing at your hosted giving page): the SDK removes the fallback automatically once the live widget mounts, so human visitors never see both.