The matching-campaign engine
Matching campaigns that help nonprofits raise more.
$612,000
raised
Illustrative. The donor calculator and the ledger call the exact same function, so a promised multiplier is always the one delivered.
Pools stack. A $100 gift against a 2× pool and a 1× pool is multiplied 3× — claimed from each pool atomically, in order, and shown to the donor before they confirm.
$100
donor gift
$200
Matcher A · 2×
$100
Matcher B · 1×
$400
total to the cause
One organisation signs itself up and configures everything, runs a clock-driven campaign, and settles with its matchers — end to end.
Branding, locale and RTL, currency, tax entity, receipt numbering, senders, payouts — all self-service. Invite your team by role.
Set the clock, add matchers and their capped pools, and stack multipliers. Donors see a live calculator showing exactly what their gift becomes.
Gapless numbered receipts issue automatically. Matchers settle on what was actually raised. The reconciliation reports tie out to the shekel.
Matching is a money ledger under extreme concurrency, not a display feature. The architecture is the differentiator.
Every allocation is an append-only ledger entry, and the thermometer is derived from it — never a stored counter that can drift. Pools cannot over-allocate, even under hundreds of simultaneous gifts. A refund unwinds the match automatically.
Your lead donors commit the largest sums in the campaign and usually get a phone call and a spreadsheet. Here they see live pool utilisation, allocation detail, their shortfall exposure and a self-serve settlement statement.
The campaign clock, send windows and donor nudges understand candle-lighting by location. A campaign can pause for Shabbos and extend its deadline by exactly the stopped time.
True right-to-left through the admin, not just the donation page. US 501(c)(3) and Israeli amuta receipts, each with its own gapless, legally-defensible numbering series.
An ILS gift against a USD pool is matched at an auditable rate, and the ledger keeps both the original and the settlement currency. No guessing which rate applied when.
Each org connects its own payment account by OAuth — we store only the account id, never a credential. Funds settle directly to your bank; the platform never sits in the money flow.
The unserved user
Your lead donors commit the largest single sums in the campaign — and on every other platform they get a phone call and a spreadsheet. Give them a portal that is correct because the ledger underneath it is correct.
Multi-tenant from the first row of the database — one organisation or five hundred, each isolated in Postgres, not just the interface.
Run your annual matching day with a real clock, real matchers and receipts your donors can file — without a spreadsheet and a prayer.
One login, an org switcher, and a clean tenant boundary per client. Run five organisations' campaigns without their data ever touching each other.
Many organisations under one roof, each with its own branding, tax entity, processor and payouts — isolated in the database, not just the interface.
No hedging. If something is still being finalised, it says so.
Lead donors (matchers) commit capped pools that multiply every crowd gift — 2×, 3×, or 4×. The urgency of a timed clock plus the leverage of a match is what drives the giving-day surge. The hard part is doing the accounting correctly under load, which is exactly what this platform is built around.
Yes — and that is by design. Each organisation connects its own processor by OAuth; we store only the account id, never a credential. Donations settle directly into your own bank account and the platform never sits in the money flow.
The platform supports US 501(c)(3) and Israeli amuta tax entities, each with its own gapless receipt-numbering series, and true right-to-left Hebrew through the admin. (Israeli receipt content and the tax-authority filing integration are being finalised with an accountant before issuing to Israeli donors.)
The engine claims from pools atomically, so a pool can never over-allocate — proven under hundreds of simultaneous gifts. If a pool exhausts, the donor still gives; their gift is simply matched by whatever capacity remains, and the calculator only ever shows a multiplier the ledger will actually honour.
Yes. Installments (tashlumim) split a gift across dated payments with the match unwound proportionally if one fails, and open-ended recurring commitments are drained by a daily job. Both are first-class, not bolted on.
Gapless receipts
Sequential numbering that never burns a number on a rollback — legally defensible in the US and Israel.
Enforced in the database
Tenant isolation and permissions live in Postgres row-level security, not in a hidden button. One org can never read another's donors.
Every gift multiplied correctly
Pools proven not to over-allocate under hundreds of simultaneous donations. Refunds unwind the match automatically.
Create your organisation, invite your team, and configure everything yourself. No sales call required to get started.