Nonprofits move enormous amounts of money across borders. Most of it flows through web forms and third-party processors that were never designed with attackers in mind. Unlike banks or fintechs, charities rarely have anyone dedicated to watching that infrastructure, and that’s exactly what makes them predictable targets.
Ransomware attacks, scraped donor databases, skimming scripts running for weeks, the pattern holds across cases. These organizations aren’t careless. They’re just under-resourced in ways that are easy to exploit.
This piece covers where donation infrastructure actually breaks down: payment flows, compliance gaps, and the infrastructure choices that either close those gaps or widen them.
How Donation Pages Get Compromised
Fundraising pages concentrate risk uncomfortably well. The public form, payment flow, third-party scripts, and a CMS were last updated during the previous campaign. Lots of entry points.
- SQL injection – SQL injection keeps showing up on donation platforms. GiveWP, Charitable, and all have had CVEs filed against them. CVE-2021-24917 in GiveWP allowed unauthenticated SQL injection via the give_payment_mode parameter. Not theoretically actively exploited.
- Formjacking – Formjacking is harder to catch because nothing visibly breaks. Magecart Group 5 compromised shared CDN resources used by dozens of smaller sites, including charity pages. A few dozen obfuscated lines POST card data to an attacker’s endpoint before the legitimate transaction completes. Silent, clean, effective.
- API Exposure – API Exposure is the third consistent problem. If payment processor keys end up hardcoded in frontend JavaScript, and they do, or if webhook endpoints skip signature verification, the payment flow is compromised without touching the database at all.
Blockchain Infrastructure: What It Actually Solves
Smart contract-based donation routing, as used by platforms like Gitcoin for open-source funding and The Giving Block for nonprofit crypto acceptance, puts transaction logic on-chain. The flow from donor to recipient is deterministic, publicly verifiable, and doesn’t depend on the security posture of a single web server. Auditing where funds went means querying the chain directly, not trusting a backend API or hoping the CSV export is accurate.
For organizations evaluating practical implementation, the ability to receive crypto payments through purpose-built gateways changes the risk profile meaningfully. Key management, AML checks, and fiat conversion workflows happen at the processor level; the nonprofit’s own infrastructure never touches private keys. That’s a significant reduction in attack surface compared to managing custody internally.
The security model here is genuinely different from card payments, and comparing them directly is useful:
| Threat vector | Card gateway | Crypto gateway |
| Card data theft | Yes | N/A |
| Formjacking | Yes | No |
| Database breach (donor credentials) | Yes | Reduced |
| Smart contract exploit | No | Yes |
| Wallet phishing | No | Yes |
| Chargeback/payment reversal fraud | Yes | No |
| Intermediary freezing funds | Possible | Rare |
Neither model is categorically safer. They have different threat surfaces and require different mitigations. What’s worth noting for organizations operating in conflict zones or high-scrutiny environments: crypto transactions have no chargebacks and are significantly harder for intermediaries to reverse or freeze.
That’s operationally relevant for disaster relief campaigns where speed and funding availability matter. Whether it’s a feature or a compliance risk depends on jurisdiction and donor base.
PCI DSS and GDPR: Where Nonprofits Underestimate Exposure
A common assumption in the sector: using Stripe means having no PCI DSS obligations. That’s not accurate, and it causes real problems.
PCI DSS v4.0 is fully mandatory since April 2024, which reduced the compliance burden for organizations using hosted payment pages, but didn’t eliminate it. SAQ A eligibility requires that the nonprofit’s own systems never handle cardholder data, that the website doesn’t capture or store it, and that the third-party processor is independently validated.
That sounds straightforward. In practice, embedding a donation widget via < iframe > from an unvalidated vendor, or passing donor details through URL parameters for analytics purposes, can quietly expand PCI scope without anyone in the organization realizing it happened.
GDPR exposure is similarly underestimated. Enforcement actions against nonprofits have been issued not for data breaches but for inadequate retention policies, organizations holding donor records longer than necessary with no documented justification.
The fine wasn’t for a hack. It was due to poor hygiene. Collecting donations from EU residents triggers the full GDPR regime regardless of where the nonprofit is incorporated: lawful basis for processing, data minimization, right to erasure, 72-hour breach notification windows, and Data Processing Agreements with every third-party processor in the chain.
Cross-border campaigns make compliance considerably harder. The surge in Ukraine disaster relief fundraising after February 2022 is the clearest recent example.
Organizations that tried to scale donation infrastructure quickly discovered that improvised setups collided with OFAC screening requirements, AML checks, and, in some cases, local registration obligations in donor countries.
The “just use PayPal” approach broke down under that volume and scrutiny in ways that were both logistical and regulatory.
Controls That Actually Close Gaps
Most of what gets exploited on nonprofit platforms isn’t exotic. It’s known vulnerabilities that weren’t patched, API keys that ended up somewhere they shouldn’t be, and third-party scripts that nobody audited after initial setup. The fixes aren’t expensive; they just require someone actually looking.
| Control | What it stops | Effort level |
| Content Security Policy headers | Formjacking, injected scripts | Low – config change |
| Subresource Integrity (SRI) on CDN scripts | Compromised CDN resources | Low – add integrity attribute |
| Webhook signature verification (HMAC-SHA256) | Spoofed inbound API calls | Low – one verification step |
| API keys in environment variables only | Key exposure via frontend bundle | Low – discipline issue |
| Infrastructure isolation (CRM/site/payment) | Lateral movement after CMS breach | Medium |
| Automated dependency auditing | Known unpatched CVEs | Infrastructure isolation (CRM / site/payment) |
The exploits hitting nonprofit platforms aren’t exotic. They’re known vulnerabilities that weren’t patched, keys that ended up in the wrong place, and third-party scripts that nobody audited. Fixing that doesn’t require a large budget; it requires someone actually looking.
The Infrastructure Gap Is Not Technical
Philanthropy infrastructure is a fintech problem running on a charity budget. The frameworks exist. PCI DSS is documented. GDPR guidance is extensive. Crypto gateways have matured past the experimental phase. The gap is almost always in implementation, not in what’s technically available.
The organizations getting compromised aren’t facing anything new. They’re leaving the same doors open that have been open for years, and attackers know exactly where those doors are.
(Photo by Austin Distel on Unsplash)
