Before You Start

This guide covers the front-end integration: how each platform connects to your Webflow site, what breaks, and who is accountable for the part of the giving flow you do not control. It does not cover configuring the donation platform itself (campaigns, payment methods, recurring giving, donor receipting). Those live in each platform's own dashboard.

What you need before starting:

  • A Webflow site on a paid Site plan. Donorbox's own Webflow guide is explicit that you need "a paid Webflow account or a project with an active site plan to embed content", and that applies to custom code and Embed elements generally, not just to Donorbox
  • A configured donation campaign in your chosen platform
  • The installation code or campaign identifier from your platform dashboard
  • Admin access to the Webflow site

If you have not chosen a platform yet, the donation software comparison for nonprofits covers the main options. Choose first, then integrate. Swapping platforms after launch means rebuilding the page, the thank-you flow and the reporting.

The Accountability Split, Before Any Code

An embedded donation form is the one place on a charity website where the most important transaction happens inside markup you did not write and cannot edit. That is the governance fact this whole guide hangs on, and it decides who answers when something goes wrong.

You are accountable for: the page the form sits on, the wrapper around the iframe, the button that opens it, the placement, the thank-you destination, and whether anyone has ever tested the flow end to end.

The platform is accountable for: the fields, the payment step, the error messages, the keyboard behaviour inside the form, and the accessibility of everything the iframe renders.

Both platforms I can verify say this in writing. Donorbox's terms state that the "Customer is responsible for accessibility of Customer-provided content, fundraising pages, and third-party embeds" (checked September 2026). The same terms say Donorbox "does not store, process, or transmit cardholder data on behalf of Customer" and that card data is handled directly by the payment processor, with the customer responsible for its own PCI-DSS compliance outside Donorbox's systems. Read that as intended: the card handling is genuinely off your site, and the parts left on your site are genuinely yours.

Name that split before you pick a platform, not after a donor reports that the form will not submit. If nobody at your organisation owns the answer to "who fixes the donation form", that is the finding, not the form.

Fundraise Up: One Installation Code, Then an Element Code

Fundraise Up's checkout opens over your page rather than sitting in it. The integration has two parts: the organisation-level installation code, and the element code that opens the right campaign.

Step 1: Add the Installation Code to the Head

Fundraise Up's installation documentation (checked September 2026) says the code goes in the head of your site's HTML, "as the last script in the <head> section for optimal performance", and warns: "Do not install Fundraise Up using script managers like Google Tag Manager. Script managers can disrupt conversion reporting and affect platform performance."

In Webflow that is Site settings → Custom code → Head code, not Footer code. This is worth correcting if your site already has it in the footer: the placement is the vendor's own instruction, and conversion reporting is the thing at risk.

The code is organisation-level and contains your account's unique details, so one installation covers every campaign on the site.

Step 2: Get the Element Code

Elements are created in the Fundraise Up dashboard, and each one comes back as a snippet. The Elements documentation shows the shape of it: <a href="#XTGWFZFR" style="display: none"></a>. The code begins with X. Your fundraising team can supply it. You do not need access to the Fundraise Up backend to do the integration.

Step 3: Put the Code on Your Own Button

In Webflow, select the button, set the link type to URL, and enter the element code including the leading #. Fundraise Up's script picks up the anchor and opens the campaign. Applying the code to a button you already styled is the documented approach, and it preserves your own hover state, focus ring and sizing rather than importing the platform's.

What opens depends on how the campaign is configured. Fundraise Up's documentation is clear that if only the campaign page is enabled the link opens that page, if only the checkout modal is enabled it opens the modal, and if both are enabled the modal opens on your site. Check which one your campaign is set to before you write the button label, because "Donate" that navigates away and "Donate" that opens an overlay are two different promises to the donor.

Step 4: Verify

Publish, open the page, and confirm the correct campaign appears. Open it with the keyboard, not just the mouse. On a phone, confirm the overlay scrolls and that closing it returns you to the page you were on rather than the top of the site.

Donorbox: An Inline Embed Inside a Container

Donorbox puts the form in the page. Donorbox's own Webflow guide (checked September 2026) sets out the route: find the campaign in your dashboard, open Share & Embed, and choose the format you want. Donorbox offers an embedded form, a pop-up button, a sticky button, or a link to its hosted page. Copy the code rather than typing it, because the identifiers must be exact.

In Webflow, add an Embed element from the Add panel and paste the code. The form shows as a placeholder in the Designer and renders on the published site.

Then constrain it. Donorbox's guide notes that an embed added on its own can span the width of the page, and recommends adding a container or column element first. I keep the form to roughly 500–600px and centre it, and I never set a fixed height on the wrapper: the form is multi-step, and a fixed height clips the later steps on exactly the devices where you will not notice.

Two things to decide rather than default into. Pop-up and sticky buttons are the formats that most often collide with the rest of a page, because a sticky element competes with your own header and your cookie banner for the same corner. And the hosted page option is worth considering on its own merits rather than treating the inline embed as automatically better. What the inline embed buys you is that the donor never leaves your domain. What it costs you is that a chunk of your most important page is markup you cannot open. If you want to understand why that trade matters beyond donations, what your website builder actually produces is the longer argument.

Enthuse: A Hosted Checkout and a Return URL

Enthuse's help centre documents the website route as a hosted checkout rather than an embed. You create a donation checkout, take the payment page URL, and put that URL on your donate button. You also set a return URL, which is where the donor is sent once the donation completes, so you can bring them back to your own thank-you page rather than leaving them on the Enthuse domain.

Practically, that makes Enthuse the simplest of the three to wire into Webflow: it is a link on a button, with no custom code and no iframe to caption. It also means your donation journey has a handover in the middle of it, and the return URL is the only thing holding the two halves together. Test that return, including what happens when a donor abandons partway and hits Back.

I have not found an inline embed documented by Enthuse for a charity's own website. If your Enthuse account offers one, take the code from Enthuse rather than from any guide, including this one.

Accessibility: The Part You Own

Accessibility on an embedded donation form splits the same way accountability does, and the split is testable.

The wrapper is yours. A third-party iframe with no title attribute fails WCAG 2.2 success criterion 4.1.2 Name, Role, Value. A screen reader announces an untitled frame as nothing useful, and every automated checker flags it. Add a title to the iframe element inside the embed code, for example title="Donation form". This is a one-line fix and there is no reason for it to survive a launch. WCAG 2.2 AA is the standard the rest of the site is held to, so see WCAG AA accessibility on Webflow for what the surrounding page has to clear.

The form is theirs, and their claims differ. Fundraise Up's accessibility documentation states that it "conforms to WCAG 2.2 AA standards across the Checkout Modal, Campaign Pages, Elements, and Donor Portal", and says independent third-party auditors verify that regularly. Donorbox's terms say it "endeavors to make the Services reasonably accessible and to align, where feasible, with WCAG 2.1 AA". Both checked September 2026. Those are different commitments: one names a version and a level and points at an audit, the other is a best-efforts alignment with an earlier version. If accessibility conformance is something your funders or your regulator ask you about, that difference is procurement evidence and belongs in your file, not in a developer's head.

How to test it, since a claim is not a result. Run the page through an automated checker to catch the iframe title and anything in your own markup. Then do the two things automation cannot: complete the whole donation using only the keyboard, from the button through every field to the confirmation, and run it again with a screen reader. If the form opens as an overlay, confirm it can be opened with Enter, that focus moves into it, that Tab does not escape it while it is open, and that Escape closes it and returns focus to the button that opened it. If the platform's form fails any of that, you cannot fix it. You raise it with the platform, and you record that you raised it.

Gift Aid and What Happens After the Donation

For a UK charity, the integration is only half the question. Gift Aid lets a charity claim back 25p every time an individual donates £1, and the declaration has to be collected in the form itself, which means it is a platform capability, not something you can add on your page.

Fundraise Up documents Gift Aid support for UK organisations: it is enabled per campaign in the dashboard, adds a donation-type step so supporters confirm the money is their own, and shows the uplift the donor is adding. The claim to HMRC is still yours to submit (Gift Aid documentation, checked September 2026). Confirm your own platform's Gift Aid behaviour against its current documentation before launch rather than assuming it, and check it again at renewal.

The other half is where the donation lands. A donation that completes but never reaches your CRM is a donor you cannot thank, which is the most expensive kind of integration failure. CRM integration for a nonprofit Webflow site covers that side of the handover.

Where the Call to Action Sits

Three placement principles I apply consistently on client sites.

Homepage. Place the call to action after an impact section or programme description. Donors need context before they are ready to give, and a donate button above the first sentence of explanation asks for money from a stranger.

Dedicated giving page. All three platforms do better on a dedicated /donate page where the form is the only purpose of the page. Everything else on that page is a reason not to finish.

Campaign pages. Keep the form or button close to the campaign content so donors can act immediately after reading the ask.

The form's own design is the platform's, but the page around it is yours, and it does most of the persuading. Nonprofit website form design covers what that page has to do.

Testing Before You Promote the Page

Test the complete flow on desktop, tablet and phone, and in at least two browsers. Start with Chrome and Safari. Check that the form loads without layout shift, that every field is reachable by keyboard, that the payment step completes, and that the confirmation or redirect works.

On the transaction itself: do not assume a sandbox exists. Test provision varies by platform and by payment processor, and on some platforms the only genuine end-to-end test is a small real donation you then refund. Confirm how your platform supports a test transaction in its current documentation before you commit to a launch date, so the answer is not discovered on launch morning.

And do not treat styling changes as cosmetic. CSS on a container can change how the embedded form renders, particularly on a phone, so run the full flow again after any change to the wrapper.

Checklist Before Promoting the Donation Page

  • Installation code or embed in place, in the field the platform's own documentation specifies, and the site published
  • Form or checkout opens in the browser and shows the correct campaign
  • One end-to-end transaction completed the way the platform supports it
  • Flow tested on a phone, not just a narrow desktop window
  • Iframe carries a title attribute
  • Whole flow completed once using only the keyboard
  • Thank-you page or return URL configured and tested, including the abandoned-donation path
  • Gift Aid setting confirmed, if you are a UK charity
  • Donation confirmed as arriving in the CRM
  • Named owner recorded for the donation form, so there is an answer when it breaks

A Blueprint Audit maps this across your own site, as part of a full governance diagnostic.

Further Reading