Start a project
tokenized card
payment rails
partial and full
refunds
reconciled per project
reporting

A PTA can run a fundraiser and trust the numbers it hands to the school treasurer, down to the fee and the refund, instead of reconstructing what actually landed after the platform took its cut.

// the problem

The problem

A PTA running a fundraiser needed to accept card donations from parents and supporters, then know exactly what landed in the school's account after processing costs and a platform fee — and get that arithmetic right every time, because the money belongs to a school, not the platform.

  • Schools and their projects must be approved before they can raise money, not opened to anyone
  • The catalogue of live projects changes as fundraisers launch, hit goals and close
  • Consumer donations must work by card as a guest or signed in, anonymously if the donor chooses
  • Refunds — partial or complete — have to unwind cleanly against the same reconciliation
  • Card data must never touch the platform directly

// engineering

How we built it

Donations, fees and rewards as one flow

Parents and supporters donate to a specific project, choosing a reward tier where one applies, and can opt to cover the processing fee themselves so the school keeps more of the donation. Guests can give without an account, and anonymously if they choose.

Reconciliation is the product, not an afterthought

Every donation is broken out into gross contribution, payment processing cost, platform fee and net settlement, and that breakdown rolls up into a per-project reconciliation report. Consumer donations with fees and refunds look simple from the donor's side; getting the arithmetic right on every one of them, at scale, is the actual work.

Refunds that unwind the same ledger

Partial and full refunds reverse the same gross, fee and net figures they created, so a refunded donation never leaves the reconciliation report out of balance.

Card data never reaches the platform

Card payments are tokenized through a payment gateway at the point of entry, so the platform holds a token, never a card number. A back office handles school and project approval, sponsor and co-administrator management, with email verification and device fingerprinting to keep fraudulent signups and donations out.

// result

Outcome

Schools raise money through approved projects with goals, deadlines and reward tiers; donors pay by tokenized card as guests or signed in, anonymously if they choose; refunds — partial or full — reverse cleanly; and every donation reconciles to gross, processing cost, platform fee and net settlement per project.

No donation totals, school counts or launch dates are claimed here — this case describes the mechanics we built, not figures we don’t have.

Payment gateway integration · Relational database · Fraud signal ingestion · Financial reconciliation reporting · Frontend application layer

30 minutes with a senior engineer.

Tell us what you're building. You'll leave with an honest opinion, even if it's "you don't need us."

Reference calls with past clients are available under NDA during evaluation.