Card testing, bot submissions, and credential attacks hit nonprofit donation forms every day. Here's how Manna stops them at every layer.
The threat landscape nonprofits don't talk about enough
When most people think about nonprofit cybersecurity, they think about donor records — names, emails, giving history. That's a real concern. But the more immediate and operationally damaging threat is what happens at the checkout layer: the moment a donor submits a gift and payment changes hands.
Nonprofit donation forms are disproportionately targeted for two reasons. First, they're often less hardened than commercial e-commerce checkouts — built on generic plugins or embedded forms without layered defenses. Second, small donations go largely unnoticed until the damage accumulates. A fraudster running a card testing operation wants to know which stolen card numbers are valid. A $1 or $5 donation to a charity is an easy, low-visibility way to find out.
The consequences fall on the organization. Chargeback fees. Stripe account flags. Potential holds on payouts. Damage to the organization's payment reputation that takes months to recover from. We've seen it happen. It's why checkout security is built into Manna's architecture from the ground up — not added on afterward.
The organizations running on Manna shouldn't have to think about card testing attacks. That's our problem to solve, not theirs.
The three threats that matter most
How the layers work together
No single defense is sufficient. The architecture that protects a Manna checkout is layered — each layer catches what the previous one doesn't, and none of them depend on the organization's team doing anything manually to keep them active.
The first layer runs at the network edge, before a request reaches the Manna application at all. Vercel BotID analyzes incoming requests using browser telemetry, behavioral signals, and known bot fingerprints. Requests that fail the check are blocked before they touch the payment flow.
Requests that pass the edge check hit rate limiting at the application layer. Submission attempts are tracked per IP address and per session. Patterns consistent with automated testing — rapid sequential submissions, repeated small amounts — trigger a block before Stripe is ever called. This protects both the organization's payment account and Stripe's view of the organization's traffic quality.
Manna uses Stripe Checkout Sessions rather than embedded Stripe Elements or a custom payment form. The distinction matters: Stripe Checkout is a Stripe-hosted payment page, which means Stripe's own fraud detection — trained on transaction data from millions of businesses — applies to every submission. Stripe sees patterns across its entire network that no individual platform can see on its own.
Every Stripe event that Manna receives is validated against a webhook signature before it's processed. Stripe signs each webhook payload with a secret key. Manna verifies that signature on every inbound event. Payloads that fail signature validation are rejected and logged. This prevents webhook spoofing — attempts to inject fraudulent payment confirmation events into the system.
What this means for the donor experience
Every one of these defenses is invisible to a legitimate donor. A real person navigating to a donation form, selecting an amount, and completing a gift encounters none of the friction that traditional CAPTCHA-based protection creates. No "I am not a robot" checkbox. No distorted text to decipher. No accessibility barriers for donors using screen readers or assistive technology.
The protections are behavioral and architectural — they distinguish real donors from automated threats based on how requests behave, not by putting friction in front of every user to weed out the bad ones.
Manna previously used Cloudflare Turnstile for bot protection at checkout. It's a good tool. But it required a client-side challenge that added a step to the donation flow and introduced occasional friction for legitimate donors on certain browsers and device configurations. Vercel BotID operates entirely at the infrastructure level — no client-side challenge, no donor-facing friction, and tighter integration with the deployment environment Manna already runs on.
What organizations are responsible for
The checkout protections described here are maintained at the platform level — they apply to every organization on Manna and don't require configuration or upkeep from the organization's team. But there are a few things on the organizational side that matter alongside them.
Admin access hygiene. The Manna admin dashboard uses OTP authentication — no passwords to phish or compromise. But access should be limited to the people who genuinely need it. Reviewer roles exist for a reason. The fewer accounts with full admin privileges, the smaller the attack surface.
Watching the right signals. The Manna admin dashboard surfaces donation volume trends, recurring donor activity, and refund rates. Unusual spikes in small transactions, a sudden increase in refund requests, or a pattern of abandoned checkouts at the payment step can all be early signals of a card testing event. Knowing what normal looks like makes the abnormal visible faster.
Keeping contact information current. Stripe communicates directly with the account owner when it detects unusual activity on a Connect account. The email address on file for your Stripe account should be monitored. Stripe's warnings about elevated dispute rates or unusual transaction patterns are worth acting on immediately.
Security at the checkout layer isn't a feature Manna offers — it's a condition of how the platform operates. Every donation form on every client's platform runs through the same layered defenses. The organizations we work with should be thinking about their missions, not about whether their checkout is being scraped by a card testing bot at 3am.
That's our problem to have already solved.
