Card Testing on Stripe: The Cost and What QuickBooks Shows

You wake up to 400 new payments in Stripe. Almost all of them are red. A handful are green, each for exactly one dollar, from customers named things like "dfgh sdfg" with email addresses nobody would type on purpose.

That is a card testing attack on your Stripe account, and the bookkeeping question comes right behind the security one. What did it cost, and what, if anything, did it leave in QuickBooks?

The short answer is that QuickBooks sees far less of the attack than Stripe does, and the part it does see is the part that costs money. Hundreds of declined attempts leave no accounting record at all. The few that got through are real sales of real money that you will almost certainly refund, and the Stripe fees on them stay spent. This post walks through what card testing is, what each kind of attempt leaves behind, and how to clean up the books afterwards without making it worse.

Start a free trial and see which Stripe events turn into QuickBooks records.

What is card testing on Stripe?

Card testing is fraud aimed at someone else's cards, run through your checkout. Stripe defines it as activity "where someone tries to determine whether stolen card information is valid so that they can use it to make purchases." Stripe also lists the other names you will see in forums: "carding", "account testing", "enumeration", and "card checking."

Your business is not the target. It is the instrument. The fraudster has a list of card numbers, bought or generated, and needs to know which ones still work. Running them through a real merchant's payment form answers that question cheaply, and the confirmed cards get used or resold somewhere else.

According to Stripe's card testing guide, testers work through two doors:

• Card setup. Saving a card triggers a validation, and Stripe notes that "card validation and authorizations during card setup don't typically show up on cardholder statements." That makes it the method testers prefer, because cardholders are less likely to notice.
• Payments. "Card testers create small amount payments, which cardholders are less likely to notice and report as fraudulent."

Stripe's overview of common fraud types adds who gets hit hardest: "Sites with free text fields, such as donation sites and 'pay what you like' e-commerce businesses, are predominately the targets of card testing." If your form lets the payer pick the amount, you are a convenient place to try a card for the minimum.

What each attempt leaves behind in Stripe

An attack looks like one event in the Dashboard. In the data it is three different kinds of object, and they behave very differently in your books.

What happened	Charge status	Money moved?	Typical fee exposure
Blocked by Stripe or Radar before reaching the bank	failed	No	None on standard card pricing; see the Radar note below
Declined by the issuing bank	failed	No	Authorization fees on some custom pricing plans
Approved and captured	succeeded	Yes	The full processing fee, plus any later dispute fees

Every failed attempt is still a Charge object with an amount, a card and a timestamp, which is why the Dashboard fills up. What separates it from a sale is the status field, which Stripe documents as "either succeeded, pending, or failed", and the paid flag, which is "true if the charge succeeded, or was successfully authorized for later capture." A failed attempt has paid set to false and no effect on your balance. Our post on why a declined Stripe payment never reaches QuickBooks goes through that object in detail, including how the outcome field tells a bank decline apart from a Radar block.

The third row is the one to watch. Stripe's own description of how testing works says "many types of card testing involve payments, some of which succeed." Those successes are not test data. They are captured payments from real, stolen cards, and they sit in your balance like any other sale until you do something about them.

One detail limits how small those successes can be. Stripe's Charge object documentation sets "the minimum amount is $0.50 US or equivalent in charge currency." A tester running cards through a pay-what-you-like form in US dollars cannot go below fifty cents, which is why the successful rows in an attack so often show 50 cents or a round dollar.

What a card testing attack costs, in real numbers

Here is the uncomfortable part. Most of the cost of an attack sits on the small number of attempts that succeed, and refunding them does not get the fees back.

Stripe's pricing page lists the standard US domestic card rate as "2.9% + 30¢" "per successful transaction for domestic cards." Stripe's refund documentation is explicit about what happens to that fee when you send the money back: "Stripe's processing fees from the original transaction aren't returned."

Take a realistic overnight attack:

• 400 attempts in total.
• 380 blocked or declined.
• 20 approved at $1.00 each.

The 20 successes bring in $20.00. On standard pricing, each carries a fee of 2.9 cents plus 30 cents, so about 33 cents, and the 20 together cost about $6.58. You refund all 20 the next morning. The $20.00 goes back to the cardholders. The $6.58 does not come back to you.

Now suppose you miss three of them, and the real cardholders dispute those charges instead. Stripe's pricing page lists a "$15.00" dispute received fee "for each dispute you receive", and a second $15.00 countered fee "for each dispute you respond to manually", which comes back only if you win. Three missed one-dollar charges can turn into $45.00 in dispute fees before you have decided whether to fight them, on top of the dollar each and the processing fee each.

Stripe's card testing guide names the other costs directly: "Card testing activity can result in additional fees, such as authorization fees for custom pricing plans, and dispute fees." If your account is on custom pricing, the 380 declines can carry a cost of their own. Check your contract rather than assuming they are free.

The Radar line on your fee report

Radar is the one fee that can scale with attempts rather than successes, depending on how you pay for it. Stripe's pricing page lists Radar on a pay-as-you-go basis "starting at $0.05" "per screened transaction", alongside a monthly option. The page does not say whether a blocked attempt counts as screened, so do not estimate this line from the attempt count. Look at the fees Stripe actually charged for the period.

Those charges arrive as their own entries in your Stripe balance, separate from any payment. Acodei treats Radar and other Stripe service fees as non-transactional fees, which post either as lines on the daily balance summary or as a separate expense, depending on how your fee categories are configured. Our guide to Stripe's non-transactional fees in QuickBooks explains where each kind lands.

Why QuickBooks shows almost none of the attack

Accounting records money that moved. A card testing attack is mostly attempts where no money moved, so most of it has nothing to record.

For an Acodei account, sales records start from a successful charge: Stripe's charge.succeeded or charge.captured events. A blocked or declined attempt never succeeds, so the 380 red rows produce nothing for that path to pick up. Nothing is missing. The books are right, and they are answering a different question from the Dashboard.

The 20 green rows are a different story. On a real-time account, each successful charge becomes a Sales Receipt by default, deposited into your Stripe holding account. With the default fee setting, the Stripe fee appears on that receipt as a negative line, so the receipt nets to what reached your balance. If your account records fees as an expense instead, the receipt stays at the gross dollar and the fee posts as its own expense.

When you refund those charges, each refund (Stripe's charge.refunded event) becomes a Refund Receipt against the same customer, drawing from the holding account. After the cleanup, a real-time account typically shows:

1. 20 Sales Receipts for $1.00 each.
2. 20 Refund Receipts for $1.00 each.
3. The processing fees on those 20 charges, which Stripe kept.
4. Any Radar or other service fees for the period.

On a daily-summary account, there are no per-charge records at all. The day's charges roll up into one summary receipt, so the 20 successes show up as a slightly larger sales figure for that day. In Stripe, a refund is its own balance activity dated when you issue it, not when the charge happened. An attack at 2 a.m. and refunds the next afternoon are activity on two different days, which is worth knowing before anyone reads a single day's numbers in isolation.

The customer list is where the attack shows up

The quieter damage is in your customer list. Card testers fill in whatever the form asks for, and Stripe's card testing guide describes the result as "suspicious payments with low transaction amounts, often with nonsensical customer names and emails."

When Acodei posts a sale on an account set to use individual customer names, it looks for a QuickBooks customer to post it against. It takes the name from the Stripe Customer object or, failing that, from the billing name on the charge, and matches it to an existing QuickBooks customer whose display name is identical character for character (capitalization aside). When nothing matches, it creates a new customer record. Twenty successful charges with twenty invented names can therefore mean twenty new customers in QuickBooks. Acodei does not update a customer record after creating it, so those names stay exactly as the tester typed them.

What you do with them is a QuickBooks decision, not a Stripe one:

• Leave them alone. Each one carries a sale and a refund that net to zero, which is an accurate history of a real event.
• Make them inactive. They drop out of everyday lists and reports while the history stays intact.
• Do not merge them into a real customer. Intuit describes a customer merge as permanent, and it would put fraudulent activity on a legitimate account's history. Our glossary entry on the QuickBooks customer display name covers what merging does and why it cannot be undone.

If your customer list matters for reporting, our post on how Stripe customers are matched to QuickBooks customers explains the matching rules in more depth.

Cleaning up after a card testing attack

Stripe's guide gives an "active card testing checklist" that starts with identifying the activity and then says to "refund fraudulent payments to avoid disputes." The order matters, because each step changes what lands in your books.

1. Stop the attack first. Stripe's guide recommends using its Payment Element or Checkout, where it applies "rate limiters, AI models, CAPTCHA triggers" and marks suppressed payments "Blocked by Stripe." Custom forms need CAPTCHA, rate limits, or login before payment. Refunding while the attack is still running only adds rows.
2. Find every success. Filter Stripe payments for succeeded charges in the attack window, then look for the pattern: identical small amounts, junk names, many cards from one IP. Stripe's risk insights view lists related payments that share a card number, IP address or customer, which is how the Stripe Radar tooling surfaces a testing run.
3. Refund them in full, quickly. Stripe states that "a customer can't dispute fully refunded payments", but "they can dispute partially refunded payments." A partial refund leaves the full amount open to a dispute.
4. Watch for early fraud warnings. Some cardholders report before you refund. Our post on Stripe early fraud warnings in QuickBooks explains what refunding at that stage writes to your books.
5. Do not retry the cards. Stripe warns that retrying "cards set up on fraudulent customers after a card testing attack" repeats the original attack. If testers created saved cards or subscriptions, cancel them.
6. Reconcile the fee line. Compare the processing and Radar fees for the period with what you expected. That number is the real cost of the attack, and it belongs in your fees expense, not in a write-off against sales.
7. Decide on the customer records. Leave or deactivate. Do not merge.

If a dispute does arrive, it is a separate event with its own records. Our guide to Stripe chargeback accounting in QuickBooks covers what a lost or won dispute writes to your books.

Mistakes that make the books worse

Some of the most common reactions to an attack create cleanup work of their own.

Deleting the Sales Receipts in QuickBooks. It feels tidy. It also removes the record of money that really did enter your Stripe balance and really did leave again, so your holding account no longer reconciles to Stripe. Acodei's guidance is to fix synced records by resyncing from its Data Feed rather than hand-editing them in QuickBooks, because manual edits break the link Acodei uses for reconciliation and reversal. Refund in Stripe and let the refund produce its own record.

Writing the fees off against sales. The fees are a cost of processing payments, even fraudulent ones. Booking them as negative sales understates both your revenue and your fees.

Expecting declines to appear. No integration should post a declined attempt as a sale, so a gap of hundreds of rows between the Dashboard and QuickBooks is expected. Compare successful charges with sales records instead, and the two should line up.

Treating it as a one-time event. Stripe's guide warns that a high decline rate "might damage the reputation of your business with card issuers and card networks", which "can result in an increased decline rate for legitimate payments, even after card testing ceases." If real customers start getting declined the following week, the attack may be the reason.

Frequently asked questions

Do declined card testing attempts show up in QuickBooks?

No. A declined or blocked attempt is a Stripe Charge with a status of failed and no money moved, so there is nothing to record. With Acodei, sales records start from a successful charge, so only the attempts that succeeded produce QuickBooks records. Hundreds of red rows in Stripe against a handful of records in QuickBooks is the expected result of an attack, not a sync gap.

Does Stripe charge fees on failed card testing attempts?

On standard pricing, Stripe's card rate applies "per successful transaction", so declined attempts do not carry the processing fee. Stripe's card testing guide notes that attacks can still bring "authorization fees for custom pricing plans, and dispute fees." Radar on pay-as-you-go is priced per screened transaction, so check the fees Stripe actually charged rather than estimating from attempts.

If I refund the successful test charges, do I get the Stripe fees back?

No. Stripe's refund documentation states that "Stripe's processing fees from the original transaction aren't returned." Refunding still matters, because a customer cannot dispute a fully refunded payment, and avoiding a $15.00 dispute fee is worth far more than the processing fee you lose on a one-dollar charge.

Why do I have new junk customers in QuickBooks after an attack?

Testers fill in made-up names. On an account that uses individual customer names, Acodei matches the Stripe name to a QuickBooks customer by display name and creates a new customer when there is no match. Each successful test charge with an invented name can therefore create a new customer. Make them inactive if they clutter your lists, and do not merge them into real customers.

Should I record card testing losses as bad debt?

Usually not. A refunded test charge is not an uncollected receivable. It is a sale and a refund that net to zero, plus a processing fee you paid. The real loss is the fees, which belong in your Stripe fees expense. Bad debt fits money a real customer owed you and never paid, which is a different situation.

Card testing is a Stripe problem with a QuickBooks receipt

Card testing fills your Dashboard and barely touches your books, and both of those are correct. The work is to stop the attack, refund every success in full before anyone disputes it, and then read the fee line honestly. That line is the bill for the attack.

What keeps the cleanup simple is a sync that posts what actually happened: successful charges as sales, refunds as refunds, and fees as fees. When the Stripe side is clean, QuickBooks follows.

Start a free trial and see how Acodei posts Stripe sales, refunds and fees to QuickBooks.