How to Add Donation Forms to Client Websites (Agency Guide)

First rule: the client owns the payment account

Before you touch a single embed, settle this. The donation money goes into the client's own Stripe account, set up under the client's legal entity, with the client's bank details and the client's tax info. Not yours. Not a shared agency account. Not a platform that pools the money and pays them out later.

This matters for boring reasons that become very exciting reasons if you ignore them. If donations route through your account, you are now holding charitable funds that are not yours, you are on the hook for refunds and chargebacks, and you will be answering the client's bookkeeper at tax time forever. When the client offboards you, the donations should not break. The only clean way to guarantee that is that the account was always theirs.

Practically, this means you sit with the client (or screen-share) for twenty minutes and walk them through creating their Stripe account. They enter their EIN, their bank, their org name. You can help them apply for Stripe's discounted nonprofit rate (2.2% + 30¢ instead of the standard 2.9% + 30¢) while you are in there. Then your tool connects to their account. You never hold the keys to the money.

The three ways to add a form, and which one to default to

There are really only three shapes this comes in, and they have very different maintenance tails.

Redirect

You wire a button to a hosted donation page on someone else's domain. Fastest to ship. Also the one that quietly undoes the design you just got paid to build — the donor leaves the client's beautiful site and lands somewhere that looks nothing like it. Conversion drops, and you both know it looks cheap. There is a whole post on why sending donors off-site hurts conversion if you need to talk a client out of this.

Plugin

Mostly a WordPress thing — GiveWP and similar. Powerful, but it is software living inside the client's site that needs updates, has add-ons that cost money, and breaks in fun ways after a theme update. Guess who gets the panicked email when it breaks. If the client is non-technical, every plugin you add is a future support ticket with your name on it.

Inline embed

You paste one snippet and the form renders right on the client's page, branded to match. No redirect, nothing to update, the form lives in a hosted service the client manages from a dashboard. This is the default I reach for on agency work because it has the shortest maintenance tail. You build it once, the client owns the dashboard, and there is no plugin rotting inside their CMS.

For most nonprofit clients, inline embed wins. The exceptions are real but narrow: a WordPress-native team that already manages plugins, or a one-campaign-a-year volunteer group that genuinely does not care about brand match.

How the embed actually goes in, by platform

The mechanics barely change across builders. You generate a snippet in your donation tool, then drop it into whatever the client's site is built on. Here is the honest version by platform.

That is genuinely it. If a setup guide makes this sound like a weekend project, it is selling you something. For the platform-specific deep dives, see adding a donation form to WordPress and adding one to Webflow.

Making it match the design you just built

You did not spend three weeks dialing in the client's brand to bolt a gray default form onto the homepage. Before you embed anything, brand the form in the tool's dashboard: the client's logo, their exact hex colors, their button styling, their suggested amounts, their copy.

The test is simple. Pull up the live page and ask whether the form looks like part of the site or like a widget someone glued on. If a stranger can tell where your design ends and the form begins, you are not done. A good inline form should be indistinguishable from a section you built by hand. This is also the difference the client actually notices and remembers you for — most of them have seen a donate button that looked nothing like their site, and they hate it.

Set the suggested amounts to something sensible for the org (a row like $25 / $50 / $100 with one highlighted, plus a custom field) and turn on monthly giving. Recurring donors are worth far more over time, and you are already in the dashboard.

The handoff: where you stop being the support desk

This is the part that decides whether donation forms are a clean add-on or a forever-tax on your business. The goal is that the client can edit the obvious things — amounts, copy, the goal on a campaign — without emailing you.

1. Hand over the dashboard login. The donation tool account should be in the client's name, with the client's email as owner. You can be a collaborator, but they own it.
2. Record a five-minute Loom. Show them where to change suggested amounts, edit the thank-you message, and find a list of recent donations. Five minutes of video kills ninety percent of future "how do I" emails.
3. Write down what they should never touch. The Stripe connection, the embed snippet. One short note: "Don't delete this code block; everything else you can edit in the dashboard."
4. Make a real test donation together. Have them donate $1 on their own phone, watch the receipt arrive, then refund it from the dashboard so they have seen the whole loop.

Do this and the form stops being yours the day you hand it over. That is the entire point.

What breaks later (and how to not own it)

Six months out, here is what actually generates emails, and how the inline-embed approach defuses each one.

• "The form disappeared." Usually a redesign or a content editor who deleted the code block. With an embed, the fix is pasting the snippet back — a two-minute job you can quote as support, not a plugin debugging session.
• "Donations stopped landing." Almost always something on the Stripe side: an expired bank link, a verification request Stripe emailed the client and they ignored. Because it is the client's Stripe account, this is between them and Stripe, not you.
• "Can we add a second campaign page?" This is the good kind of email — it is billable. A new campaign page with goal tracking is a small, scoped piece of work, not an emergency.
• "The plugin wants me to renew an add-on." You only get this one if you went the plugin route. Another reason the embed defaults win for handoff.

If you want to see what a hand-off-friendly inline form looks like — branded, recurring built in, client-owned Stripe — the features page covers the embed and the receipts side. The short version: pick the approach that has the shortest support tail, because on nonprofit work, the support tail is the real cost.