-
-
The treasurer asks the books in plain words. The AI fills a typed filter that the AG Grid table also uses.
-
The receipt shows the gift, the PayPal fee and what the church actually receives.
-
A member says what to give. Claude turns it into a proposal; nothing is charged until she confirms with PayPal.
-
Judges pick a role in one click, no sign-up: member, treasurer or pastor. PayPal sandbox, no real money.
-
The pastor's weekly brief, written by Claude from the books. It cannot move money; the pastor gives the second key.
-
The AI proposes a distribution. The rules engine blocks the Rivera family: not an approved recipient. Every rule is shown.
Inspiration
At E-Ministry we build software for churches in Guatemala. Pastors keep telling us the same thing: giving is easy to collect but hard to steward well. Small churches still run on cash, scattered transfers and spreadsheets. The treasurer spends hours checking numbers, money for missionaries takes weeks to move, and the person who gave never learns what their gift did.
We wanted to see if AI could help with that without ever being trusted with the money itself.
What it does
A member says what they want to give, in English or Spanish, and the assistant turns it into a proposal they confirm with PayPal, one-time or monthly. The receipt shows what PayPal took and what the church actually received.
The treasurer asks the AI to plan a distribution. A rules engine checks every line against the approved-recipient list, per-recipient and batch payout limits, and the fund balance, and shows every rule it checked, not only the ones that failed. The treasurer signs, the pastor signs, and only then does PayPal Payouts send the money.
Afterwards the AI drafts a note for each donor about what their giving did, and a person approves it before it is sent. The treasurer can ask the books questions in plain language, an auditor compares our ledger with PayPal Transaction Search, and the pastor gets a weekly brief.
The AI proposes. Code decides. Two people approve.
How we built it
React + Vite + AG Grid on the front, Express + Prisma + PostgreSQL behind it, in a pnpm monorepo.
PayPal, through plain REST: JS SDK v6 and Orders v2 for one-time gifts, Catalog Products, Billing Plans and Subscriptions for monthly giving, Payouts for distributions, Webhooks with signature verification, and Transaction Search for reconciliation.
Claude (Anthropic) through the official SDK with tool use. Sonnet runs the giving, distribution and ledger agents; Haiku writes impact notes and the pastor's weekly brief. Each agent has a hard boundary in code: the giving agent cannot charge, the distribution agent cannot pay or skip a rule, and the ledger agent cannot write SQL. It only fills a typed filter that the grid also uses, so the answer and the table always match.
Money is stored as integer cents. Every proposal, approval and payout is written to an audit log, shown in an "AI activity" tab. 49 unit tests (19 for the rules engine) and 56 end-to-end Playwright tests run in CI and against production.
Challenges we ran into
- The PayPal button hung intermittently. The
paypal-web-sdk-loadedevent often fired before React mounted, so the listener never heard it. We now poll for the SDK and the test reloads the page five times, because one good load proved nothing. - Hand-written TypeScript types claimed a method that did not exist (
createPayPalSubscriptionSessioninstead ofcreatePayPalSubscriptionPaymentSession). It compiled and left a blank page. - With a tight
max_tokens, the model spent its budget reasoning and returned a truncated impact note. We now give agents room and reject truncated answers. - Approving an already-paid distribution failed with "insufficient balance" instead of "already done", because rules ran before the state check.
Accomplishments that we're proud of
- Real end-to-end money flow in sandbox: captures, active subscriptions, a Payouts batch, and webhooks delivered by PayPal with verified signatures.
- Guardrails people can see: the rules panel reads its limits from the server, so the screen can never claim a limit the code does not enforce.
- A judge can try every role in one click, with no sign-up.
- Fully bilingual, built for Latin American churches.
What we learned
A green build does not mean a working screen. Almost every serious bug we found compiled cleanly, and only showed up when we loaded the page or ran the end-to-end tests. We also learned that the most useful place for AI in a financial flow is proposing and explaining, with deterministic code and people holding the final say.
What's next for Steward AI
Steward AI will become the giving module of the E-Ministry platform, which already serves churches in Guatemala. Next: a WhatsApp giving channel, scheduled nightly reconciliation, editable distribution amounts in the UI, year-end giving statements, and pilots with partner churches.
Built With
- ag-grid
- ai-agents
- anthropic
- claude
- express.js
- llm
- node.js
- paypal
- paypal-javascript-sdk-v6
- paypal-payouts
- paypal-subscriptions
- paypal-transaction-search
- paypal-webhooks
- postgresql
- prisma
- react
- tailwindcss
- typescript
- vite