P2P Fraud Prevention for Nonprofits: What Actually Works

Peer-to-peer fundraising pages get hit by fraudsters more often than direct donation forms, and when they do, your charity wears the chargebacks.

Why Are P2P Pages a Target?

The short answer: low friction by design. A P2P page is meant to be created in two minutes by a supporter with no relationship to your organisation. That same low barrier is exactly what a fraudster wants.

Card testers use P2P campaigns to validate stolen card numbers. The attack is mechanical. A script runs hundreds of small charges (often A$1 to A$5) against a fundraising page to find which cards are live before selling them or using them for larger purchases. Your charity processes the charges. You get a wave of chargebacks three to six weeks later. Stripe's dispute fee is currently A$25 per chargeback, regardless of the original amount. A batch of 200 test charges at A$2 each can cost you A$5,000 in dispute fees alone, plus the staff hours to respond.

There's a second, less-discussed attack: money laundering through legitimate-looking fundraiser pages. A bad actor creates a P2P page, donates to themselves with a stolen card, then requests a payout or charity cheque. If your platform processes payouts to fundraisers, this is a real exposure.

What Does a Card-Testing Attack Actually Look Like?

Here's a concrete pattern your finance team can recognise in a Stripe dashboard or export.

You'll see a cluster of transactions in a short window: 50 to 300 charges arriving within 30 to 90 minutes, most between A$1 and A$10, all hitting the same fundraising page. The card BIN numbers (the first six digits of the card number) will vary, but the IP address or device fingerprint often doesn't. Or the opposite: one BIN but dozens of different IP addresses cycling through a VPN range.

Decline codes tell a story too. A normal donation session might see one card_declined in a hundred charges. A card-testing session shows do_not_honor, insufficient_funds, and stolen_card responses at rates above 30%. Stripe logs all of this. The problem is that by the time a human reviews it, the tester has already found their live cards and moved on.

The other signal: donation amounts cluster at exactly A$1.00 or A$2.00 with no variation. Real donors round up, use odd amounts, or follow a suggested giving ladder. Fraudsters pick a flat amount and repeat it.

How Does Stripe Radar Help, and Where Does It Fall Short?

Stripe Radar evaluates card-not-present transactions at the point of charge. It does a reasonable job on first-time donations. The gap is recurring transactions and P2P-specific patterns.

For P2P specifically, Radar scores each charge in isolation. It doesn't know that 40 other charges hit the same fundraising page in the last 20 minutes from different cards. It has no view across your platform's fundraiser pages as a group. That cross-page velocity signal is exactly what card testers exploit.

Recurring renewals are a separate problem. A donor might pass Radar's checks on signup in January, then their card gets compromised in June. Radar does not re-score renewals. The fraudulent charge goes through, and you find out weeks later when the cardholder disputes it.

What Should Your Team Actually Do?

Four things, in order of effort.

First, check your P2P platform's per-page donation limits. Most platforms (Raisely, Funraisin, Classy) let you cap individual donation amounts or set velocity rules per page. A cap of A$500 per single donation stops high-value card tests cold. A rate limit of 10 donations per page per hour catches batch scripts. These settings are usually in the campaign configuration, not the platform's main settings. Check them this week.

Second, review your Stripe dashboard for the patterns above. Export the last 30 days of charges to CSV. Sort by created timestamp. If you see more than 15 charges to the same metadata source within any 60-minute window, look at the decline rate for that window. Above 20% failures, something is wrong.

Third, set up email alerts for charge volume spikes. Stripe's built-in radar rules can trigger on velocity. A rule like charge_count > 20 where metadata.fundraiser_page_id = :same_value in 60 minutes is configurable in Radar's rule editor without writing code. This won't stop the attack, but it gets your team notified in near-real-time instead of three weeks later.

Fourth, look at your chargeback response process. If a card tester succeeds and disputes come in, you need documentation: IP addresses, device fingerprints, donation timestamps. Stripe stores all of this per charge. Pull it before the dispute window closes (typically 21 days from the dispute notification).

If you want to automate the cross-page velocity monitoring and get plain-English explanations on every flagged transaction, that's what Cause Shield's fraud scoring layer does. It sits on top of Stripe, re-scores recurring renewals that Radar ignores, and threads P2P fundraiser activity into a single supporter view so you can see whether a fundraising page and its donor list look normal or not. No card numbers pass through it; Stripe stays the system of record.

Start with the platform settings and Stripe rules this week. They cost nothing and cut your exposure immediately.

See how Cause Shield connects to your fundraising platform at /features/fraud-scoring