Donation Platform

01A donor taps donate — what happens before any money actually moves?

The donation is recorded as an intent first — campaign, amount, donor, payment token — and the donor immediately sees “thank you, processing”: committing to donate and completing the charge are two separate steps.

02The campaign just went viral — ten thousand people are donating this minute. Do we slow down?

No — accepting a donation is one cheap local write, so the platform keeps saying yes at viral speed while the actual charges drain through a queue at whatever rate the payment provider can take.

03What does the campaign page show while all of that settles?

A live progress total and donor count that move within seconds of each donation — approximate on purpose, backed by an exact append-only ledger it is reconciled against.

04Can money go back — one donor, or a whole campaign?

Both: a single donation can be refunded, and a cancelled or fraudulent campaign triggers a bulk refund of every donation — and each refund also walks the public progress total back down.

05Who takes a cut, and off which number?

Each donation splits into gross, payment-provider fee, platform fee or tip, and net-to-campaign — recorded per donation in the ledger, because fees are per-transaction facts, not an average you can apply later.

06When does the organizer actually get the money?

On a payout schedule, after a hold window that lets fraud signals and chargebacks surface — only settled net funds move, and a campaign under review is frozen before a single dollar leaves.

01How big is the spike we design for?

Around 100× baseline overnight: one viral campaign can jump from 2 donations a minute to 10,000 — the accept path must ride that without dropping a single intent.

02Retries everywhere — can a dollar ever count twice?

No: every capture call carries an idempotency key and every provider webhook is deduplicated by event id, so a retry on either leg lands in the ledger exactly once.

03Does the progress bar have to be exact?

Fast and honest, not exact: seconds of staleness and small drift are fine because a reconciliation job continuously trues the counter up against the ledger — the ledger itself is never approximate.

04The payment provider goes down for an hour — what breaks?

Nothing donors can see: intents keep landing, the queue holds the backlog, and workers retry with backoff when the provider returns — an accepted donation is a promise the queue keeps.

05What is the durability bar for an accepted donation?

An intent is synchronously replicated before the thank-you renders — thanking a donor and then losing their donation is the one failure this platform can never explain.