Handle card testing without blocking real donors

A nonprofit donation card testing incident may first appear as a burst of tiny or failed donations, not a sudden group of new donors. Preserve the pattern, stop automated donor work and payment retries for the suspicious cluster, and ask your platform or payment provider to contain the affected path. Reopen only after the abusive pattern is suppressed and a legitimate payment path still works.

Confirm the pattern before labeling a gift

OWASP defines carding as repeated payment-authorization attempts used to verify stolen card data. One unfamiliar name or one small gift does not establish that pattern.

Look for a cluster within a short period. Stripe's current card-testing guidance names a spike in failed or blocked payments and suspicious low-value payments, sometimes paired with implausible names or email addresses, as common signals. Your processor may expose different fields, so start with the evidence it actually provides.

Open one incident record and capture:

• the first and most recent observed attempt;
• the form, page, campaign, or payment route involved;
• counts of attempted, blocked, failed, and successful payments;
• amount and currency patterns; and
• available decline, block, device, or request signals that do not expose full card data.

This turns hundreds of strange rows into one event your team can hand to a provider. It also prevents a single odd donation from being declared fraudulent by instinct.

Keep suspicious attempts out of donor work

During review, hold the cluster outside welcome series, first-time donor segments, campaign totals, and staff follow-up queues. A payment attempt is evidence about the incident. It is not automatically a donor relationship.

Do not retry failed cards. Stripe warns that retrying cards attached to fraudulent customers can repeat the original attack. Do not bulk-delete the rows either. Charitable's current cleanup guidance warns that bulk removal of failed and pending records can also remove legitimate donations, so audit the set before any cleanup.

Preserve the provider's payment and request identifiers. Keep access limited to the people handling the incident. Your goal is enough evidence to identify the affected path and reconcile the outcome, not a private copy of sensitive payment data.

Give the provider a containment request it can act on

Send your fundraising platform or processor the incident window, affected form, counts by status, representative payment identifiers, and the controls already enabled. Ask four concrete questions:

1. Does this pattern match card testing in your system?
2. Which form, endpoint, integration, or account route is receiving the attempts?
3. Which control can be tightened without blocking every legitimate donor?
4. What evidence will show that the mitigation is working?

The right control depends on where the attempts enter. Stripe documents recommended payment integrations, server-validated CAPTCHA, targeted rate limits, and anomaly monitoring, and it warns that one signal such as IP address is rarely enough by itself. Bloomerang's nonprofit guidance likewise presents monitoring, provider reporting, notifications, CAPTCHA, and minimum amounts as parts of a response rather than a guarantee.

For a hosted form, the vendor may own most of that work. For a custom integration, your developer and processor may need to coordinate. A lean nonprofit operator should own the incident record and the decision to pause or reopen; the technical owner should implement and verify the control.

Resolve successful payments through the original provider

Separate successful suspicious payments from failed and blocked attempts. They can require a real payment action, while a decline does not.

For Stripe users, the active card-testing checklist recommends refunding fraudulent payments to avoid disputes. Other providers may distinguish same-day voids, refunds, fraud reports, or review states differently. Follow the current instructions for the provider that processed the payment, and return money through the original payment path. The void-or-refund decision guide explains why the payment state comes first.

Record the disposition beside each successful payment. If a dispute has already arrived, move it into the separate donation chargeback response instead of mixing dispute evidence with attack containment.

Reopen with two proofs

Do not reopen because the alert stopped once. Require two separate proofs.

First, the abuse proof: the platform or processor confirms the relevant controls are active, and the abnormal attempt pattern stays suppressed through a review window your team records. Second, the donor proof: a supported test or supervised legitimate payment completes through each affected path and reaches the expected confirmation, receipt, payment status, and staff record.

Write down who checked each proof and when. If the form passes for donors but the suspicious velocity returns, containment failed. If the attack stops but a real donor cannot complete a gift, the control is too blunt. The incident closes only when both paths behave as intended.