Donation Forms Attract Card Testing Attacks
A charity notices something odd in its payment dashboard. Hundreds of one dollar donations attempted overnight. Almost all declined. A handful approved.
Nobody donated anything. The organization was being used as a validation service.
Donation forms have become a preferred target for card testing, and the reasons are structural rather than accidental. Here is how the attack works, why nonprofit payment pages are disproportionately attractive, and what actually stops it.
The Attack Has a Formal Name
This is not an emerging or exotic threat. It is cataloged.
OWASP defines OAT-001 Carding as multiple payment authorization attempts used to verify the validity of bulk stolen payment card data. Lists of stolen card details are tested against a merchant's payment process to identify which ones still work.
The economics are simple. Stolen card data is bought in bulk and its quality is unknown. Much of it is dead. Carding separates the working numbers from the useless ones, and validated cards carry far higher resale value than untested ones.
There is a related variant worth knowing. When the attacker holds a card number but lacks the expiry date or security code, OWASP classifies the brute-force attempt to fill those gaps as OAT-010 Card Cracking.
Both are automated. Both need a payment endpoint that will accept repeated attempts without complaint.
Why Payment Processing for Nonprofits Presents a Softer Target
Several characteristics of donation pages combine into an unusually attractive target, and most of them exist for good reasons.
The amount field is open. Retail checkouts have fixed prices. A donation form lets the visitor choose, so an attacker selects the smallest permitted value. Low amounts attract less scrutiny and cost less if a charge sticks.
There is no account requirement. Donation flows deliberately avoid registration friction, which removes an authentication layer that would otherwise slow automation.
Verification is often relaxed. Address verification and security code checks are sometimes loosened to reduce failed legitimate donations, particularly for international givers.
Security resourcing is thin. Most nonprofits have no fraud analyst and no one watching authorization patterns at three in the morning.
This is where platform choice becomes a security decision rather than an administrative one. Wild Apricot's guidance on software for donation processing walks through how payment processing for nonprofits is structured, and the relevant question when evaluating any option is what anti-automation controls sit in front of the payment endpoint by default.
A donation form assembled from a generic embed with no rate limiting is an open authorization endpoint. That is the underlying problem, whatever the branding on the page.
What It Actually Costs
Organizations often assume the damage is limited to a few small refunds. It is considerably worse.
Per-attempt fees. Many processors charge for authorization attempts regardless of outcome. Ten thousand declines is ten thousand billable events.
Chargebacks. The successful test charges belong to real cardholders who did not authorize them. Each dispute carries a fee on top of the reversal.
Merchant account risk. Payment processors monitor decline ratios and chargeback thresholds. Breach them and the account can be placed under review, restricted, or terminated. For an organization whose fundraising runs through that account, this is an availability incident.
Reputational exposure. Cardholders who see a charge from a charity they have never supported form a specific and unflattering impression.
Staff time. Reconciliation, refunds, processor correspondence, and donor explanations consume days.
Detection Signals Worth Monitoring
Card testing produces a distinctive traffic signature. The problem is that almost nobody is watching for it.
The clearest indicator is a decline rate inversion. Normal donation traffic approves the large majority of attempts. During an attack the ratio flips, and a sudden move from single-digit declines to a majority is unambiguous.
Other signals that cluster together:
Repeated identical amounts, usually at the form's minimum. Submissions arriving faster than a human could type. Sequential or clustered card numbers sharing an issuer prefix. Bursts concentrated outside your normal donor hours. A high volume of attempts producing negligible total revenue.
Treat authorization decline rate as a monitored metric with alerting, not as a number someone reviews monthly. The attack window is measured in hours.
Controls That Actually Work
Layering matters here, because any single control is brittle.
OWASP's bot management guidance makes the point directly: the objective is not blocking all automation but raising the cost of abusive automation while leaving legitimate users unaffected. Applied to donation forms, that means:
Rate limiting per IP and per session. The single highest-value control, and frequently absent.
A challenge on the payment step. Invisible or risk-based challenges avoid punishing genuine donors while breaking naive automation.
Enforce AVS and CVV. Yes, this rejects some legitimate donations. Weigh that against an account termination.
Set a sensible minimum. OWASP lists increasing the minimum transaction value among its countermeasures for carding. A one dollar floor is an invitation.
Push velocity rules to the processor. Most gateways support attempt limits per card, per IP, and per time window. Many nonprofits have never enabled them.
Outsource the payment surface. OWASP also notes that fully delegating payment handling to a provider with its own carding countermeasures is a legitimate mitigation, and for a small organization it is usually the pragmatic choice.
Underpinning all of it, the PCI Security Standards Council maintains the requirements governing how cardholder data must be handled, and any donation implementation should be assessed against them rather than assumed compliant because a third party renders the form.
The Practical Summary
Card testing against donation pages is not a sophisticated attack, and that is precisely what makes it frustrating. It succeeds because the endpoint accepts unlimited attempts, the minimum amount is trivial, and nobody is monitoring the decline rate.
All three of those are fixable in an afternoon.
The organizations that get hit hardest are rarely the ones with the worst overall security posture. They are simply the ones who never considered that a donation form is, functionally, a public API for testing whether a stolen card still works.