The nonprofit ops lead who finally shipped the website redesign usually finds one thing the redesign could not fix: the donate button still bounces supporters to a third-party page wearing someone else's branding, and the analytics show donors dropping off at exactly that handoff. To embed a donation form on your website instead, Givebear needs two lines of HTML: a div carrying data-givebear-* attributes and a script tag that loads givebear.js. No plugin to install, no iframe builder, no developer ticket.
Keeping the gift on your own page is not a cosmetic preference. The drop-off your analytics show at the donate-button handoff has a mechanical cause: a redirect adds a page load, a context switch to unfamiliar branding, and a beat of hesitation about whether the new domain is legitimate. An embedded form removes all three, so the donor completes the gift inside the story that prompted it.
Because the embed runs on the same Givebear organization account as everything else, a gift made through the website form lands in the same ledger as a tap on the lobby kiosk and a scan of the QR code on an event flyer. The supporter who gives $50 through the embedded form in March and taps $20 at the kiosk in June is one donor record with one year-end statement, and the treasurer reconciles one export instead of three.
Who this is for
- Nonprofit ops leads and communications managers who own the website and need the donate button to stop sending supporters to a page that looks nothing like the site they just redesigned.
- Freelance designers and agencies building Squarespace, Wix, Webflow, or WordPress sites for nonprofit clients, who need a giving form that survives theme changes and platform updates.
- Treasurers and finance volunteers who currently reconcile website gifts, kiosk taps, and QR code donations across separate monthly exports.
- Organizations stuck on a heavy iframe embed that slows page loads, breaks on phones, or clashes with the site's typography and colors.
The two lines of HTML that do the whole job
The complete install is two lines. First the mount point: <div data-givebear-embed data-organization-id="YOUR_ORG_ID"></div>. Then the loader: <script src="https://givebear.io/sdk/givebear.js" async></script>. Replace YOUR_ORG_ID with the UUID from your Givebear dashboard (Settings, at the bottom of the General section), publish the page, and the inline donation form mounts exactly where the div sits.
Swapping data-givebear-embed for data-givebear-button renders a compact donate button that opens the giving flow in a modal, and data-givebear-card renders a richer card with suggested amounts. Optional attributes adjust each widget without writing code: data-button-text="Give now" changes the label, data-accent-color="#1a5c8a" matches your palette, and data-fund-id or data-campaign-id locks the widget to one fund or campaign. The script tag can sit anywhere on the page, because mounting waits for the DOM to finish loading.
Platform walkthroughs: WordPress, Squarespace, Wix, Webflow, hand-built
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 Business and Commerce plans, so a site on a 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.
How embedded gifts join kiosk taps and QR scans in one ledger
The quiet cost of a donation form bolted onto a website is that it usually becomes its own silo: 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. Givebear's embed runs on the same organization account as the lobby kiosk (a one-time $699 to $899 purchase with no monthly kiosk software fee) and every QR code, so each channel writes to the same funds, campaigns, and donor records the moment a payment clears.
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.
A five-minute test plan before donors find the form
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.
Practical use cases
Replace a redirecting donate button with an inline form (data-givebear-embed) on your /donate page, so the gift completes without ever leaving your domain.
Drop a campaign-specific button into a story or blog post with data-campaign-id, so a reader moved by the appeal gives to that exact campaign in the same scroll.
Embed a fund-locked form with data-fund-id on a building fund or scholarship page, so every gift from that page is classified to the restricted fund before checkout.
Run several widgets on one page (a button near the header, a donation card in the sidebar): each mounts independently with its own fund or campaign target.
Common questions
How do I embed a donation form on Squarespace?
Add a Code block where the form should appear and paste two lines: a div with data-givebear-embed and your organization ID, then the givebear.js script tag. Squarespace runs script embeds on Business and Commerce plans; on a Personal plan, point your donate button at your hosted Givebear giving page instead. Both channels share one ledger, so nothing is lost in reporting.
Will an embedded donation form slow down my website?
No. The givebear.js script loads with the async attribute, so it never blocks page rendering, and widgets mount only after the DOM finishes loading. Widgets inherit the host page's fonts rather than shipping their own, which keeps the added weight small compared to a typical donation plugin stack.
How much does it cost to embed a donation form on my website?
The embed and the full SDK are included with every Givebear account at $0/month with a 0% platform fee when donors tip (4.9% when a donor declines, one flat rate online, at kiosks, and on memberships), plus Stripe card processing at cost. There are no per-widget, per-page, or per-domain charges, so one account can power forms on the main site, a campaign microsite, and a school PTA page at once.
Is an embedded donation form PCI compliant?
Payment fields in Givebear embeds are handled by Stripe's payment infrastructure, so card numbers never touch your website's server or your organization's systems: the host page provides the container while the payment surface runs on Stripe's PCI-compliant rails. Your team's responsibility stays at the level of normal website hygiene, like serving the page over HTTPS, rather than card-data compliance.