Card Testing and Fake Donations: Defending Your Donation Form From Bot Fraud

Recognizing an Attack in Progress

The good news is that card testing is loud. It does not look like a clever imitation of normal giving, because the attacker is optimizing for throughput rather than for blending in. Once you know the signature you can usually identify an attack from a single screen of transaction data, and the signature is consistent enough that it is worth writing down and putting somewhere your finance and development staff will find it.

A burst of small, nearly identical amounts. Real giving produces a scattered distribution: twenty five, fifty, a hundred, the occasional thirty seven dollars from a peer to peer page. Card testing produces one dollar, one dollar, one dollar, or a tight cluster of tiny amounts submitted minutes or seconds apart. If your average gift is eighty five dollars and your last four hundred transactions were all under five, you are not experiencing a surge of micro-generosity.

A decline rate that has gone vertical. This is the most reliable indicator, and it is the one most organizations never look at because dashboards emphasize successful revenue. A card testing run is mostly failures by design, since the whole point is that the attacker does not know which numbers work. A form that normally declines a small percentage of attempts and is suddenly declining the majority of them is being used as a validation service.

Names and emails that pattern-match rather than read. Automated submissions produce automated identities. You will see the same first name with rotating surnames, obviously generated strings, keyboard-adjacent nonsense, or a run of addresses at the same disposable domain. Watch also for the opposite tell, which is plausible names attached to email addresses with the same structure repeated dozens of times, because a competent script generates names from a dictionary rather than from randomness.

Shared opening digits across many cards. If you can see the first six digits of the card numbers in your processor dashboard, check whether a suspicious batch shares them. A legitimate donation stream draws from a wide spread of issuing banks. A BIN attack draws from one, because it was generated from one. This is the single most conclusive signal available to a non-technical reviewer.

Timing that does not match your audience. Most nonprofits have a recognizable giving rhythm shaped by when their emails go out and where their donors live. A dense cluster of activity at three in the morning local time, with no campaign running and no mailing sent, is a strong prompt to look closer. Timing alone proves nothing, since you may have donors in other time zones or a piece of content circulating overseas, but combined with any of the signals above it removes most of the doubt.

Repeated attempts from the same origin. Sophisticated operations rotate their network addresses, so a single address hammering your form is a sign of an unsophisticated attacker rather than the absence of one. Still, it is worth checking, along with the pattern where the same card number is attempted repeatedly with different expiration dates, which is exactly what a tester does when guessing the missing field.

The practical move is to stop relying on noticing. Set an alert that fires on transaction count rather than dollar volume, since an attack is enormous in count and trivial in dollars, and set a second one on decline rate. Nearly every giving platform and payment processor can email you when a threshold is crossed, and if yours cannot, a weekly export reviewed against last month's baseline is a workable substitute. High traffic moments deserve extra attention, because attackers know an unusual volume spike is easier to hide inside. If you are planning a campaign at the scale described in our guide to running Giving Tuesday at scale, tighten your monitoring before the day rather than after it.

Defense in Layers, and the Order to Apply Them

No single control stops card testing. Stripe says this plainly in its guidance, noting that attackers use varied techniques and that simple filters based on a single heuristic such as network address are usually not sufficient on their own. What works is a stack of small obstacles, each cheap, each imposing a different kind of cost on an automated attacker, and collectively making your form a worse target than the next one on the attacker's list. That last point is the realistic goal. You are not trying to be impenetrable. You are trying to be inconvenient.

Layer one: bot detection at the form. Invisible challenge systems such as Cloudflare Turnstile or reCAPTCHA Enterprise evaluate browser and behavioral signals and only present a visible challenge when something looks automated. Most legitimate donors see nothing at all. This is the highest value single control because scripts are what make card testing economical, and it is also the one most likely to already be available in your platform as a setting you have not turned on. Stripe reported that adding a managed CAPTCHA across Checkout reduced card testing by 80 percent with less than two basis points of impact on authorization rates, which is an unusually favorable trade. Two implementation notes matter: validate the challenge on the server, not only in the browser, and apply it to every endpoint that can create a charge or save a card, because a form protected on its main path and open on its recurring gift path is not protected.

Layer two: a minimum gift amount. Removing the open-ended amount field, or setting a floor beneath it, directly attacks the economics of small validation charges. Some fraud guidance in the sector recommends floors as high as fifty or a hundred dollars, which is far too aggressive for most organizations and would cost more in lost small gifts than it saves. A floor in the range of five to ten dollars is a reasonable starting point for a general donation page: it eliminates the one dollar probe while keeping almost every real gift, since very few genuine donors give less than five dollars outside specific peer to peer contexts. Set the floor in the platform, not only in the front end, so it cannot be bypassed by posting directly to the endpoint.

Layer three: address and security code enforcement. Address verification compares the billing postal code and street number the donor enters against what the issuing bank has on file, and the security code check confirms the three or four digits printed on the card. Collecting them is not the same as enforcing them. Many forms request the fields, pass them to the processor, and then accept the payment regardless of whether the checks came back matched or unchecked. Configuring your processor to block charges where the security code fails, and to block or flag where the postal code fails, defeats a large share of card testing, because a tester with a card number harvested from a data breach frequently does not have the security code at all. Be aware this costs you a small number of real gifts from donors who mistype their code or whose billing address is genuinely stale, so most organizations block on security code failure and merely flag on address mismatch.

Layer four: rate limits and velocity rules. Velocity controls cap how much can happen in a window: attempts from one network address per hour, attempts against one card, failed attempts before a source is blocked, new saved cards per session. Stripe Radar supports custom velocity rules on its paid tier, and most giving platforms expose some version of this even if they call it something else. The values should reflect your actual traffic. If your form normally sees three gifts an hour, a limit of twenty attempts per address per hour is generous to donors and fatal to a script. Blanket limits set too low will eventually block a legitimate office, school, or community center where many people share one network address.

Layer five: fraud rules in the processor. Stripe Radar and its equivalents at other processors apply machine learning scoring to every payment and let you layer your own rules on top. Useful rules for a donation context include blocking when the security code check fails, blocking or reviewing charges under your minimum, reviewing an unusual concentration of attempts from one address, and blocking currencies and countries you have no reason to accept. That last one is quietly effective. If every donor you have ever had paid in dollars, accepting eleven other currencies gains you nothing and gives an attacker more paths to try.

Layer six: quiet mechanical defenses. A honeypot field, meaning a form input hidden from human eyes that bots fill in anyway, costs nothing and catches unsophisticated scripts. A minimum time-to-submit rejects anything completed in under a second or two, since no human fills in a card number that fast. Cross-site request forgery tokens, which your platform probably already uses, prevent the form from being submitted from somewhere other than your own page. None of these stop a determined attacker and all of them are free, which is the right profile for a bottom layer.

Applied in that order, most organizations get the majority of the benefit from the first three layers and can implement them in an afternoon with no developer, because they are platform settings rather than code. That pattern holds across most nonprofit security work, and it is the same argument made in our piece on strengthening cybersecurity on a small budget: the meaningful wins are usually configuration you already own rather than tooling you need to buy.

The Donor Experience Tradeoff, Chosen Deliberately

Every control in the previous section costs you some legitimate revenue. This is not a caveat to be waved away at the end of a security article, it is the central design decision, and organizations that ignore it tend to overreact after an attack and quietly lose more money to friction than they ever lost to fraud. A required security code loses the donor who is giving from memory without the card in hand. A visible challenge loses the donor on a slow connection and the one using assistive technology that interacts badly with it. A twenty five dollar minimum loses the student, the fixed income donor, and the person testing whether your organization is real before committing more.

The useful way to think about this is that different controls have very different friction-to-protection ratios, and they are not close. Invisible bot detection is nearly free to donors and removes most automated traffic. A five dollar minimum is invisible to nearly everyone and removes the one dollar probe. Enforcing the security code costs a small number of gifts and blocks a large share of stolen card attempts. At the other end, a visible puzzle CAPTCHA on every submission, a required account, or a fifty dollar floor will each cost you real money for protection you could have obtained more cheaply. Work down the ratio, not down a checklist.

Segment your forms rather than applying one policy everywhere. Your main donation page, a peer to peer fundraising page where five dollar gifts are the point, an event registration form, and a memorial giving page have genuinely different risk profiles and different tolerable friction. A peer to peer page cannot carry a twenty five dollar floor, but it can carry strong bot detection and tight velocity limits. Conversely a high value page tied to a major gift appeal can afford a little more verification because the gifts arriving through it are large enough to justify it. Our discussion of the premium a well built donation form earns is worth reading alongside this, because the same conversion mechanics that produce the premium are the ones you are spending when you add friction.

Then measure what you spent. Record your conversion rate and average gift for a few weeks before you change anything, make one change at a time where you can, and check the numbers afterward. Most organizations find the first three layers cost them almost nothing measurable, which is useful evidence when somebody proposes going further. If a control does cost you noticeably, you now have a real number to weigh against a real risk instead of two anxieties arguing with each other. And revisit the settings periodically, because an emergency measure adopted during an attack, such as disabling the open amount field entirely, has a way of becoming permanent policy that nobody has re-examined in three years.

What AI Adds Here, and What It Does Not

It is worth being blunt about this, because the honest answer is narrower than the topic might suggest. The controls that actually stop card testing are platform settings and processor rules. A language model does not sit in your payment path, cannot block a charge, and adds nothing to the moment of the attack itself. The fraud scoring that does operate in real time is machine learning, but it is machine learning built into Radar and its equivalents by the processor, not something you assemble. If you read this article and implement only one thing, make it a setting, not a model.

That said, there is real work around the edges where AI assistance genuinely reduces effort, and most of it is analysis and writing rather than detection. The useful frame is that the model works on exports and documents, not on live traffic.

Anomaly detection on transaction exports. Export a few months of transactions, including declines, and ask a model to characterize the normal distribution of gift amounts, hours, and decline rates, then identify clusters that deviate. This is genuinely useful because it catches slow, low-volume testing that never trips a threshold alert: thirty attempts a day for three weeks rather than three thousand in an hour. It also surfaces patterns a human scanning rows will miss, such as a recurring weekly cluster or a set of records sharing an email structure. Treat the output as a list of things to look at, not a verdict, and remember to strip or avoid uploading full card data and donor personal information, which belongs nowhere near a general purpose tool.

Drafting the runbook and the internal communications. The incident memo to the finance committee, the runbook, the note to the auditor, the short explanation for the board, and the internal instructions telling staff what to do if they see the pattern are all documents that get skipped because they are boring and nobody is waiting for them. Describing the incident and having a model produce a structured first draft removes the reason they go unwritten. You edit for accuracy, which takes minutes rather than the hour the blank page was going to cost.

Summarizing logs and dashboards. Payment processor logs and webhook event streams are dense and repetitive, and most nonprofit staff have never been trained to read them. Pasting a slice of failure data and asking for a plain language summary of what the decline codes mean and what they suggest is a reasonable use, particularly when you are trying to explain to a board member why the organization is paying fees on transactions that never happened.

Preparing for the vendor conversation. Feeding a model your platform's documentation and asking it to list which of the controls in this article exist, where they are configured, and what your plan tier includes turns a vague afternoon of help center browsing into a specific list of settings and questions. Verify what it tells you in the actual dashboard, since documentation goes stale and models state outdated details confidently, but as a way to arrive at the support conversation prepared it works well.

Cleaning the contaminated cohort. Identifying which constituent records came from the attack, writing the query or the filter criteria, and producing the corrected campaign figures is pattern matching across a dataset, which is squarely in scope. What stays human is the decision about what to delete, suppress, or keep, because a wrongly deleted real donor is a worse outcome than a retained fake one.

What it does not do. It does not decide your risk tolerance or your minimum gift amount, both of which are fundraising decisions with revenue consequences that belong to your development lead. It does not configure your processor. It should not be the thing standing between an attacker and your payment endpoint. And it should not be fed cardholder data, full donor exports with personal information, or anything covered by your donor privacy commitments without checking the vendor's data handling terms first, a point our guide to donor data privacy and AI works through in more detail.