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.
Two things this is not. It’s not a product: VGP costs $0, it’s MIT, and nobody takes a cut of a gift. And it’s not another middleman. The last thing giving needs is an industry of “agent donate buttons” wedging one more toll collector between the donor and the nonprofit. The checkout stays yours. The donor stays yours. We just want the agent to find the door.
Four steps and one rule.
A donor tells an agent to give. The agent should be able to finish the gift at your checkout, to the page the nonprofit named. That takes four steps, and each has one test.
-
01
Verify the org
An agent can confirm in code, by EIN, that you serve this nonprofit.
-
02
Build the gift
One API call takes an amount, currency, frequency, designation and tip, and returns the full total. It takes an idempotency key, so a retry is still one gift.
-
03
Take the payment
Your checkout takes the payment without a captcha because it can check who approved it. Passes: a signed approval the agent carries from the donor, as an ACP or AP2 token or an x402 wallet payment. Part: a login the nonprofit gives its own server, or handing the donor to a browser.
-
04
Confirm it landed
The agent can find out the gift went through, and the donor and nonprofit get the same receipt ID.
-
rule
No hidden fees
Every fee and tip the donor pays is in the total the agent shows before the donor approves. Nothing defaults on, and nothing is added after.
Figure 01 · Two levels. Handoff-ready is steps one, two and four in code, with the donor paying in their own browser. Agent-complete is all four. Not on the list: deciding who is authorized. The nonprofit says that on its own domain.
Who’s out there, and how far an agent gets.
The same four steps, graded. An agent does the ones a platform passes and hands the rest back to the donor. Eleven platforms, sorted by level, then by how many steps pass.
A platform that reaches a level goes to the top of this table with a badge, and we name it on the home page. Nobody’s there yet.
| Platform | Verify the org | Build the gift | Take the payment | Confirm it landed | What it offers |
|---|---|---|---|---|---|
| The Giving Block | in code | session, no designation | browser | webhook + api | The only platform that mints a checkout in code, and it answers status queries. Card, ACH, crypto, stock and DAF, depending on what each nonprofit turns on. The session takes an amount but not a designation: those are configured per organization, not passed per gift. Webhooks are encrypted, not signed, so there is no signature to verify and no replay protection. The public crypto checkout needs a captcha; the partner API’s deposit-address endpoint takes a login instead and accepts a designation (from their docs; we haven’t run it yet). The public widget URL can’t carry an amount, TGB confirmed. Missing: an idempotency key. |
| Every.org | no key | link, tip on screen | browser | webhook | Nonprofit lookup needs no key and says whether the org claimed its profile. Donate-link parameters are documented, but the link opens on a default tip it can’t set, so an agent can’t quote the total before handing off. Missing: a checkout session, a tip parameter, a status query. |
| Fundraise Up | profile, no EIN | prefill link | Link, announced | signed webhook | Agentic Giving, opt-in by the nonprofit’s administrator: an agent-readable profile of up to 25 live campaigns, linked from the nonprofit’s footer, with prefilled links into its own checkout. The nonprofit can fix which campaigns it lists, and the profile rebuilds every 15 minutes. A giving.json can point to it, but only once the nonprofit has turned it on. Gifts made inside the chat are reported under their own source, Agent, and need an agentic profile on the nonprofit’s Stripe account; the docs still don’t say how an assistant completes one, and elsewhere say the assistant is not part of the payment. The best prefill contract of the eleven, and it can lock the amount. The docs don’t say how fee coverage is set on an agent gift. Missing: the legal entity and EIN, a checkout session an outside agent can open, an idempotency key. |
| Blackbaud | no lookup | iframe | browser | yes | A server-side charge API exists for merchant-initiated transactions, but the docs keep it off public websites and apps. The public path is the iframe. |
| Neon One | no lookup | no | browser | yes | The backend charges against a token and card fields are read-only, so raw card data never gets near it. No public nonprofit lookup. |
| Donorbox | no | no | browser | signed webhook | Three read endpoints. Webhooks are signed. |
| Zeffy | no | no | browser | webhook | Read-only on purpose, and the docs say so. A webhook fires when a payment completes. |
| Givebutter | browser | undocumented | browser | none yet | URL prefill works but isn’t documented, and anything over 999 is ignored. The API records gifts; it doesn’t take them. Runs on Stripe, so a checkout session is one layer down. |
| Classy | no lookup | record only | browser | no | The spec says it: an offline transaction record doesn’t charge a card. No idempotency key anywhere in the API. |
| Bloomerang / Qgiv | no lookup | record only | browser | no | You process the donation yourself, then submit the record. It takes a private key, so it can’t run from a donation form. |
| Give Lively | no api | no api | browser | no | No public API, no developer docs. The Zapier app has triggers and no actions. URL prefill parameters are ignored. |
Figure 02 · From public docs, live checkouts and sandboxes, 4 to 29 September 2026, including the OpenAPI specs Classy and Neon One publish. One company has written back since: The Giving Block answered this page, and its row reflects what they told us. If we misread your docs, open an issue and we’ll fix the row.
Step three is a browser step on all eleven. We used to think card security was the reason. It isn’t, or not only. The Giving Block’s crypto checkout involves no card at all: one request returns a deposit address. It still needs a captcha, and their server checks it. That’s the real wall. A checkout needs to know a person is behind the gift, and today a captcha is the only way it can tell.
So step three asks what replaces the captcha, and there are two answers. The one that passes is a signed approval: the donor approves the gift once, the agent carries that approval (an ACP or AP2 token, or an x402 wallet payment), and your checkout checks the signature. Any agent can use it, and nobody new holds anything. The one that counts as part is a login the nonprofit gives its own server. The Giving Block’s partner API works this way: its deposit-address endpoint takes a login instead of a captcha. It works, but only for a nonprofit that runs its own server, and most won’t. Nobody should hand an agent a card number either way. Until then the donor pays in their own browser, and the agent’s job is to get them to the right page with the amount filled in, then find out whether it worked.
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, no new toll collector in between. That’s the whole pitch.
Respond in the openRather not post publicly? Write to help@verifiedgiving.ai.