# Donation Pages and Free Trials: The Card Testing Endpoints Nobody Watches

Source: https://bondproof.com/blog/2026-11-09-card-testing-donation-pages-free-trials.html

[Home](../index.md) / [Blog](index.md)


**Short answer:** Card testers look for the cheapest place to learn whether a stolen card works, and that is rarely your checkout. Donation pages take $1 to $5 without questions, card-save forms validate silently, and free trials collect a card with no charge at all. Guard the quiet endpoints first, because that is where the testing happens.

## Why the checkout is the last place they test

Card testing is simple: a bot pushes stolen card numbers through a payment form and reads the approval or decline to learn which cards are live. The cards that approve get sold or cashed out elsewhere. The whole attack depends on finding a form that answers the question cheaply, and your checkout is the most expensive place to ask it. It has fraud checks, it has velocity limits, and it is the page you actually watch.

So testers go where you are not looking. Stripe's own documentation says they prefer card-save flows, because validating a card at setup usually does not appear on the cardholder's statement, so the real owner never notices. Donation pages are the other favorite: a $1 to $5 payment looks normal, and a donation form rarely has the same bot checks as a checkout. A free trial that collects a card with a SetupIntent is the same shape, a validation with no charge attached.

## The endpoints to audit this week

Walk your site like a tester would. Every form that touches a card is a target, not just the checkout. Card-save and card-update flows in the account area. The donation page, if you have one. The free trial signup. The gift card balance check. The "add a payment method" step in onboarding. [BIN attacks work the same way](https://bondproof.com/blog/2026-11-08-bin-attacks-card-testers-targets.md), generating numbers from a known bank prefix and testing them in bulk, and they will use whichever endpoint answers fastest.

For each endpoint, ask three questions. Does it run a bot check before it validates the card? Does it have a velocity limit per IP, per device, and per email, or only per IP? And does a failed validation show up in a dashboard anyone reads? If the answer to any of those is no, that endpoint is the one being tested right now.

## What to put on the quiet endpoints

The fix is not to remove the forms. A donation page that demands a CAPTCHA on every visit loses real donors. Put the friction where the attack lives instead. A CAPTCHA that triggers after the first failed validation from a session, not before the first attempt, costs real users nothing and costs a bot everything. Visa's June 2026 guidance points the same way: velocity limits on amounts and counts by IP, device, and email, plus mandatory CVV and address checks on card-not-present payments.

Stripe's Radar rules give a concrete shape for this. Block an IP with more than one successful authorization in the past hour, block a card number with more than one blocked payment in the past hour, and block an IP that tries more than three cards in an hour. [The costs after a card testing attack](https://bondproof.com/blog/2026-11-07-after-card-testing-attack-costs.md) include the authorization fees on thousands of attempts and the acquirer scrutiny that follows, and both are worse than the friction of a triggered CAPTCHA. The quiet endpoints are quiet because nobody watches them. Watch them.

## Frequently asked questions

### What is card testing?

Card testing is when a bot pushes many stolen card numbers through a payment form to learn which ones are still live. It is also called carding, enumeration, or account testing. The cards that approve get sold or used elsewhere.

### Why do testers prefer donation pages?

A $1 to $5 donation looks like a normal payment, and donation forms rarely carry the same bot checks as a checkout. Card-save flows are preferred for a different reason: the validation usually does not appear on the cardholder's statement.

### How do I find my unguarded card endpoints?

List every form on your site that touches a card: checkout, card-save, card-update, donation, free trial signup, gift card balance check, and onboarding payment steps. Check each one for a bot check, a velocity limit, and whether failures show up in a dashboard.

### What velocity rule stops card testing?

Stripe's Radar examples block an IP with more than one successful authorization in the past hour, and block a card with more than one blocked payment in the past hour. A practical starting rule is 10 checkout attempts in five minutes from one IP, device, or session.

[Get a free bot-traffic audit](mailto:hello@bondproof.com?subject=Free%20free%20bot-traffic%20audit)