Verified Giving Protocol
Plate 00 · an open request

What we’re asking donation platforms for.

Here’s the test we ran. Ask an AI to give $50 a month to Power Poetry. It finds the donate page the nonprofit itself vouched for, the currency, the limits, all in about a second. Then it hits a wall, because no donation platform lets it open a checkout in code. That wall is yours. This page is us asking you to put a door in it.

Full disclosure: we wrote the protocol, so of course we want this built. We also tried to push a gift through Givebutter’s API first and couldn’t, which is how this page started. Since then we’ve read eleven platforms’ docs so you don’t have to. If we got yours wrong, say so and we’ll fix it.

Plate 01 · the request

The ask, in five parts.

  1. 01 A checkout session an agent can create

    One endpoint. It takes an amount, a currency, a frequency and a designation, and hands back an approval URL or a client token. Not a charge. The agent never touches a card number, and the donor finishes the payment in their own browser.

  2. 02 An idempotency key

    Agents retry. Send the same donation request twice and it should still be one gift. This is the one field we’d ask you to make required, not optional.

  3. 03 The rules, written down

    Min and max amounts, which currencies, what word you accept for “monthly,” whether a designation can be picked. Publish them once and nobody has to find them by trial and error.

  4. 04 Status and a receipt

    A way to ask what happened to a session, plus a transaction ID the donor and the nonprofit can both point to. Without it the agent has to tell the donor “I think it worked.”

  5. 05 Nothing about who’s authorized

    The nonprofit says which destinations are theirs, on its own domain. You’re not being asked to decide who deserves a gift. We just need to reach the page the nonprofit named.

Figure 01 · Number five is what keeps this small. It’s a checkout endpoint, not a trust decision.

Plate 02 · the agent donation flow

Where each platform is today.

A donation is four steps. Verify the org, build the gift, take the payment, confirm it landed. An agent does the ones you expose in code and hands the rest back to the donor. Here’s how far it gets on the four platforms we read closest. Nobody clears all four. Two get to three.

Checkout in code

The Giving Block

The one platform that will open a checkout for a third party. It’s crypto, stock and DAF, so not how most nonprofits take money.

  1. 01 Verify the org in code
  2. 02 Build the gift session
  3. 03 Take the payment browser
  4. 04 Confirm it landed webhook + api

One POST returns a real session. Send an ID with it and it comes back on the webhook, so you can match the gift to the ask. Ask about a transaction and you get its status.

What would finish it: an idempotency key, and signed webhooks.

Lookup and prefill

Every.org

Three of the four steps run in code, and looking up a nonprofit doesn’t even need a key.

  1. 01 Verify the org no key
  2. 02 Build the gift in code
  3. 03 Take the payment browser
  4. 04 Confirm it landed webhook

The lookup tells you whether anyone from the org has claimed the profile. Donate-link parameters are documented and exact. A webhook fires when a gift lands.

What would finish it: a checkout session, and a way to ask what happened to a gift.

Prefill and signed webhooks

Fundraise Up

The best prefill contract of the eleven, and signed webhooks. It only works for the org that holds the key.

  1. 01 Verify the org own org only
  2. 02 Build the gift in code
  3. 03 Take the payment browser
  4. 04 Confirm it landed signed webhook

The URL API takes an amount, a currency, a recurrence, a designation by stable ID and a success URL, and it can lock the amount. POST /v1/donations really charges a Stripe payment method.

Building that payment method from card data puts you in PCI SAQ D (their docs say so, and they’re right), so it’s not the agent path. What would finish it: a hosted checkout session and an idempotency key.

Prefill via URL

Givebutter

Prefill works through the URL. The API records gifts; it doesn’t take them.

  1. 01 Verify the org browser
  2. 02 Build the gift undocumented
  3. 03 Take the payment browser
  4. 04 Confirm it landed none yet

POST /v1/transactions logs a gift that already happened and has no payment field. The prefill parameters aren’t documented yet, but they work. Anything over 999 gets ignored.

Givebutter runs on Stripe, and Stripe has had checkout sessions for years. What would finish it: expose one, with an idempotency key.

Figure 02 · From public docs, live checkouts and sandboxes, 4 to 8 September 2026. We haven’t talked to any of these companies yet. If we misread your docs, open an issue and we’ll fix the page.

Step three is a browser step on all eleven, and that’s the right call, not a gap. Fundraise Up’s docs put a name on why: build a payment method from raw card data and you’re in PCI SAQ D. Let Stripe Elements take the card and you’re in SAQ A. The other platforms that charge don’t spell it out, but every one of them gates on a token minted in a browser.

Translation: nobody should let an agent hold a card, and we’re not asking anyone to. The donor pays in their own browser, same as today. The agent’s whole job is to get them to the right page with the right amount already filled in, then find out whether it worked. That’s it.

Plate 03 · the rest of the eleven

The other seven.

All seven take donations. None lets an agent start one today. Two publish an OpenAPI spec, which settles it. The rest say so in their own docs. Give Lively has no API to read, which made that one quick.

Platform Verify the orgBuild the giftTake the paymentConfirm it landed What it offers
Give Lively nononono No public API, no developer docs. The Zapier app has triggers and no actions. URL prefill parameters are ignored.
Blackbaud nononoyes There’s a server-side charge API for merchant-initiated transactions. The docs keep it off public websites and apps, so the public path is the iframe.
Neon One nononoyes The backend charges against a token, and card fields are read-only, so raw card data never gets near it. No public nonprofit lookup.
Classy nononono The spec says it: an offline transaction record doesn’t charge a card. No idempotency key anywhere in the API.
Bloomerang / Qgiv nononono You process the donation yourself, then submit the record. It takes a private key, so it can’t run from a donation form.
Donorbox nononoyes Three read endpoints. Webhooks are signed.
Zeffy nononoyes Read-only on purpose, and the docs say so. A webhook fires when a payment completes.

Figure 03 · From each platform’s own docs, 4 to 8 September 2026, including the OpenAPI specs Classy and Neon One publish. Four of the seven can confirm a gift after the fact. None of the eleven has an idempotency key yet.

Right now, when you ask an AI to donate to a cause, it’s guessing. It lands on whatever page it can parse, and that page may or may not be the one the nonprofit picked (usually not; we’ve written about shadow donation pages before). The platform that gives the agent a way in is the platform those gifts come through, donor record attached. That’s the whole pitch.

Respond in the open
Plate 04 · keep up

Tell me when the standard changes.

Version changes, new consumer tooling, and what adopters run into. Rarely, and never a pitch. Mailchimp opens in a new tab to say it worked, and this page stays where it is.

This one does leave your browser. The generator on this site never sends anything anywhere, but an email list has to. It goes to Mailchimp and nowhere else, and one click gets you off it.