Design a Charity Donation System with Payments, a Ledger and Payouts to Charities

Design a charity donation system: users pick a charity on the platform and donate money to it, the platform charges the user's payment method, and the collected funds are passed on to the charities. The report gives only the name of the problem, so the scale, the donation flows to support and the money-handling rules are open: settle them with the interviewer before designing. ```hint Never charge twice Think about what happens when the user taps the donate button twice, or the app retries after a timeout, and what must be stored before the payment provider is called. ``` ```hint Follow the money Trace one donation from the donor's card to the charity's bank account and ask at which steps the platform must record who owes what to whom. ``` ### Clarifying Questions - Are donations one-off amounts, recurring monthly gifts, or attached to another purchase on the platform, for example rounding a payment up to the next whole amount? - How many donations arrive per day and at peak, for example during a fundraising campaign or a disaster appeal, and how many charities take part? - Does the platform collect the money through a payment provider and pay charities in batches, or should each donation go directly to the charity's own account? - How are charities onboarded and verified, and must donors receive receipts usable for tax purposes? - Do campaigns show a running total toward a goal, and how fresh must it be? - Which currencies and countries are in scope, and how are refunds and card disputes handled? ### What a Strong Answer Covers - Requirements and estimates agreed first, including peak load during campaigns - A donation write path that is idempotent end to end, so that a retry never charges or credits twice - Integration with a payment provider: asynchronous outcomes, signed webhooks, timeouts and reconciliation - A double-entry ledger that tracks every amount from the donor's charge to the charity's payout, including refunds and disputes - Batched, idempotent disbursement to verified charities, and donor receipts - Read paths for donation history and campaign totals, plus failure handling, fraud protection, security and observability ### Follow-up Questions - The call to the payment provider times out after the user taps the donate button. How does the system learn whether the charge happened, and what does the user see? - A disaster appeal brings many times the normal traffic for an hour. Which parts of the system are at risk, and how do you protect them? - A donor disputes a charge after the money was already paid out to the charity. How is that recorded and recovered? - How do you keep a campaign's live total accurate under heavy concurrent donations without one hot database row?