Architecting Scalable Donation Systems for Global Nonprofits

Nonprofit fundraising platforms have an unusual load profile. For most of the year they are quiet. Then, over roughly seventy-two hours spanning Giving Tuesday and the final days of December, they take a large share of the organisation's annual revenue. A payment gateway timeout on 31 December is not a degraded user experience — it is money that never arrives, from a donor who will not try twice.

We built and operated fundraising infrastructure for Mozilla Foundation, processing donations from supporters in over 100 countries at 99.99% uptime through peak campaign periods. This guide sets out the architecture decisions that actually mattered, and the ones that turned out to be expensive distractions.

1. Design for the spike, not the average

The single most common architectural failure we see in nonprofit platforms is infrastructure sized against the annual mean. Donation traffic is not smoothly distributed: a well-executed end-of-year campaign can drive 10x baseline load within minutes of an email send, and the shape is spikier still when a matching-gift deadline is announced.

• Autoscale on the right signal. CPU is a lagging indicator for payment workloads that are I/O bound on gateway calls. Scale on request concurrency and queue depth instead, with a floor high enough that cold start never sits on the critical path during campaign windows.
• Pre-warm before the send, not after. Campaign sends are scheduled events. Scale the floor up ahead of them deliberately — treat it as part of the campaign runbook, not an infrastructure afterthought.
• Load test against the real shape. Simulate the actual end-of-year curve, including the recurring-donation batch jobs that run concurrently. Steady-state load tests will pass and tell you nothing.

Never make the donor wait on downstream systems

The donation write path should do the minimum: validate, authorise the payment, persist the transaction, return. Receipt generation, tax documentation, CRM sync, email marketing hand-off, and analytics events all belong on a durable queue behind the response. When Salesforce is slow — and during December it will be — the donor should never see it.

This also gives you a clean failure boundary. A CRM outage becomes a backlog to drain, not a fundraising outage.

2. Payment resilience: assume the gateway will fail

Single-gateway architectures are the most common source of lost revenue we find in audits. Gateways have regional outages, per-issuer decline anomalies, and rate limits that only surface under campaign load.

• Multi-gateway with routing and failover. Route by currency, region, and method, with automatic failover on gateway-level errors. This alone accounted for a large share of the 40% reduction in payment processing failures we achieved for Mozilla.
• Idempotency keys on every charge. A donor who double-clicks, or a client that retries a timed-out request, must not produce two charges. Generate the key client-side per donation attempt and enforce it at the payment service.
• Retry declines intelligently. Soft declines (insufficient funds, issuer timeouts) are recoverable on a schedule; hard declines are not. Treating them identically burns donor goodwill and gateway reputation.
• Reconcile daily. Automated three-way reconciliation between your ledger, the gateway, and the accounting system. Discrepancies discovered in January are forensic work; discovered daily, they are a ticket.

Recurring giving is a different system

Sustained giving programmes look like a feature and behave like a subsystem. Card expiry, account updater services, dunning sequences, upgrade and pause flows, and proration all need explicit design. Involuntary churn from expired cards is, at most nonprofits we assess, the largest single leak in recurring revenue — and it is fixable with an account-updater integration and a well-tuned dunning ladder rather than a redesign.

3. Compliance and security: scope reduction first

PCI-DSS is the compliance obligation most nonprofits underestimate. The correct strategy is almost always to minimise scope rather than to expand controls.

• Never let card data touch your servers. Use gateway-hosted fields or tokenisation so the raw PAN never enters your infrastructure. This drops most organisations from a heavyweight assessment to SAQ A territory.
• Tokenise, then treat tokens as sensitive. Tokens are not card numbers, but a leaked token plus a compromised API key is still a fraud path. Scope keys narrowly and rotate them.
• Fraud detection at the edge. Card-testing attacks target donation forms specifically because they accept small amounts from anywhere. Velocity limits per IP, per BIN, and per fingerprint, plus a challenge on anomalous patterns, stop the majority of it before it reaches the gateway.
• Audit trails as a first-class artefact. Immutable, append-only logging of every transaction state change. Nonprofits face donor-facing scrutiny and regulator scrutiny simultaneously; reconstructing a donation's history should take seconds.
• Data residency and privacy. Global donor bases mean GDPR obligations regardless of where the organisation is headquartered. Decide early which personal data lives where, and design deletion into the schema instead of retrofitting it. Our supply chain security guide covers the dependency side of the same problem.

4. Global performance: donors abandon slow forms

Donation conversion is measurably latency-sensitive, and a global supporter base means most of your donors are nowhere near your primary region.

• Serve campaign pages from the edge. Landing pages and the donation form shell should be static and CDN-cached; only the payment intent call needs to reach an origin.
• Multi-currency done properly. Present amounts in the donor's local currency with sensible suggested tiers, settle in the currency your treasury actually wants, and cache exchange rates with an explicit staleness bound. Currency confusion at the point of decision is a conversion killer.
• Minimise the form's critical path. Every third-party script on a donation page is a chance to delay or break the transaction. Analytics and marketing tags belong after the form is interactive, never blocking it.
• Multi-region failover. Active-passive with tested, automated failover is sufficient for most nonprofits and dramatically cheaper than active-active. What matters is that the failover has actually been rehearsed before December.

5. Operations: the campaign runbook is part of the architecture

The engineering work that protected Mozilla's peak periods was as much operational as architectural.

• Infrastructure as Code. Terraform across staging and production, so the environment you load-tested is the environment that takes the traffic.
• Blue-green deploys with a freeze window. Zero-downtime releases year-round, and a hard change freeze across the peak window with a documented exception path.
• Alert on donations per minute. Business-metric alerting catches failures that infrastructure metrics miss entirely — a form that renders fine but silently fails to submit will show green on every system dashboard.
• Rehearse disaster recovery. An untested failover plan is a document, not a capability.

What we would not build

Two things nonprofits routinely over-invest in: a bespoke CRM, and a custom payment ledger that duplicates the gateway's. Integrate with an established donor management system and treat the gateway as the source of truth for money movement, reconciled against your own transaction records. Engineering budget at a nonprofit is mission budget — spend it on the paths that touch donors.

Where to start

If your fundraising platform has not been stress-tested against a realistic end-of-year curve, that is the first piece of work, before any redesign. Most of the failures we are called in to fix during December were visible in a load test in September.

We work with nonprofits on fundraising architecture, payment resilience, and compliance readiness — from an architecture diagnostic through to delivery. If you are weighing a rebuild against targeted remediation, our guide on platform rescue versus rebuilding covers how we make that call.