Stripe Early Fraud Warnings and Your QuickBooks Records

A sale closed three weeks ago. The money is in your Stripe balance, the sales receipt is in QuickBooks, and the month it belongs to is closed. Then Stripe tells you the cardholder's bank thinks that payment was fraudulent.

Nothing has been taken back. There is no dispute, no fee, no hold. There is only a message, and a decision that is now yours: refund the charge yourself, or wait and see what happens.

That window is the subject of this post. It is the one fraud event that is neither "nothing happened" nor "money moved", and it is the only one where your own choice determines which records your books end up with. Most of the advice written about it is wrong in the same specific way, and Stripe's own documentation is what corrects it.

If you want the QuickBooks side of Stripe refunds and disputes to land without hand-keying, you can start a free trial.

An early fraud warning is a report, not an action

Stripe's Early Fraud Warning object is small enough to read in one go. It carries an id, the charge it relates to, the PaymentIntent, a creation timestamp, a boolean called actionable, and a field called fraud_type.

Where the message comes from matters more than the shape of it. On how disputes work, Stripe describes early fraud warnings as "messages sourced from reports that card issuers on the Visa, Mastercard, and JCB networks generate to flag payments they suspect might be fraudulent. These include Visa TC40 reports and Mastercard's System to Avoid Fraud Effectively (SAFE) reports."

So this is not Stripe's own risk engine talking. Radar screens payments at authorization time and either lets them through or blocks them, and by the time an early fraud warning arrives, Radar has already made its decision and been overruled by events. The warning comes from the issuer, through the network, after the fact.

One sentence in Stripe's documentation is the key to the whole topic, and it is easy to read past: "The networks require issuers to report fraud, but that requirement doesn't affect an issuer's decision about whether to initiate a dispute."

Two separate systems. The issuer has to file the fraud report. The issuer separately decides whether to chargeback. The report is not the chargeback, and neither one causes the other.

The fraud_type field names what the issuer said, and Stripe documents the full set: card_never_received, fraudulent_card_application, made_with_counterfeit_card, made_with_lost_card, made_with_stolen_card, misc, and unauthorized_use_of_card. Most warnings land in the last two. It is worth reading the value before acting, because a stolen-card report and a "the cardholder does not recognise this" report are different situations wearing the same label.

The actionable flag tells you where you are in the timeline

actionable is the field that does real work. Stripe defines it precisely: "An EFW is actionable if it has not received a dispute and has not been fully refunded. You may wish to proactively refund a charge that receives an EFW, in order to avoid receiving a dispute later."

Read the first sentence as a state test rather than a recommendation. Actionable is true while both doors are still open. It goes false when one of them closes, either because you refunded the charge in full or because the dispute you were worried about has already arrived.

There is a wrinkle that catches integrations. Stripe notes that "it's possible to receive an EFW even after you receive a fraud dispute on a charge. This is generally because the systems the networks use to process EFWs are separate from the systems they use to process disputes, and the two aren't necessarily in sync."

So an early fraud warning is not reliably early. Anything that treats an incoming warning as proof that no dispute exists yet will eventually be wrong, and the honest way to check is the flag rather than the arrival time.

What happens if you do nothing

Stripe publishes the base rate, and it is higher than most people guess. On charges not covered by the 3D Secure liability shift, "80% of EFWs convert into a fraud dispute if you do nothing."

That number reframes the decision. This is not a low-probability warning you can file and forget. Four out of five of these become chargebacks, and Stripe describes exactly what a chargeback does to your account: the card network pulls the funds from your Stripe balance, Stripe debits your balance for "the disputed amount plus a dispute fee", the funds are held for the entire duration, you cannot issue a refund outside the dispute process while it is open, and your dispute rate with that network increases.

The fee is the part that does not come back. Stripe states that for businesses outside Mexico "the fee for receiving a dispute is non-refundable", and separately that "unless otherwise stated in your Stripe contract, we never return the dispute received fee". Winning a dispute returns the disputed amount. It does not return the fee you paid to be in the fight.

If the payment was covered by liability shift, Stripe says "you might still receive a dispute", and in that case Stripe automatically supplies some evidence on your behalf, including 3D Secure data.

The fact that changes the decision, and almost nobody states it

Here is where most writing on this topic goes wrong, including writing that is otherwise careful. The intuitive model is that a proactive refund makes the problem go away: refund the charge, the fraud report is satisfied, your metrics stay clean.

Stripe says the opposite, in one sentence:

Proactively refunding a flagged payment doesn't affect the fraud warning. The only time a refund can prevent a fraud report is when it's processed as a reversal, which usually happens within 2 hours of the payment capture.

The warning has already been filed. A refund three days later does not unfile it. The only refund that prevents the report is one processed as a reversal, and Stripe puts that window at roughly two hours after capture, which is not a window any human review process operates inside.

That matters because the fraud report is itself a metric the networks watch. On its measuring disputes page, Stripe is explicit that early fraud warnings "aren't informational notes from the card networks", and that they are "equally as important when used as a metric by the networks to measure a business's propensity for fraudulent transactions. Visa in particular counts these fraud warnings toward identification in their VAMP monitoring program."

So refunding buys you one thing and not the other. It very likely avoids the chargeback, the dispute fee and the increase in your dispute rate. It does not remove the fraud warning from the count Visa is keeping.

Anyone who tells you that proactive refunds keep your fraud numbers clean is describing a mechanism that does not exist. The refund protects your dispute rate. The fraud warning count is already spent.

Stripe's own refund threshold is an accounting calculation

Because the refund does not erase the report, the only thing left to optimise is money, and Stripe does the arithmetic in public.

First, the warning against blanket policies: "Automatically refunding all EFWs regardless of the likelihood of escalation isn't a good strategy. If you're too aggressive in issuing refunds for all EFWs, you'll inevitably refund some transactions that would never have become disputes."

Then the threshold: "All other things being equal, our analysis suggests that the optimal point for issuing a refund on early fraud warnings is on charges that are roughly less than or equal to your dispute fee. It's likely not worthwhile to refund EFWs on charges more than 35 percent higher than your dispute fee."

Sit with the shape of that. On a small charge, the dispute fee alone can exceed the sale, so refunding costs you the revenue and saves you a fee that is larger than the revenue. On a large charge, refunding means giving up the whole amount to avoid a fixed fee plus a probability-weighted loss, and past roughly 1.35 times your dispute fee the arithmetic stops favouring the refund.

Stripe names one exception. If you have "reason to worry about the effect of the dispute itself on your business or account", meaning you are near a monitoring-program threshold or under scrutiny, it makes sense to refund more aggressively. For context on where those thresholds sit, Stripe notes that "the credit card processing industry standard recognizes dispute activity above 0.75% as excessive", and that a sudden spike can trigger placement in a program before you reach it.

This is a bookkeeping decision dressed as a fraud decision. It has a fee, a probability and a threshold, and the answer changes with the size of the charge.

What each choice writes in QuickBooks

Now the part that belongs to your books, because the two paths do not produce mirror images of each other. They produce structurally different records, and knowing which one you are creating is the difference between a clean reconciliation and an afternoon of confusion.

Nothing in Acodei's product documentation covers early fraud warnings, and Acodei is not documented as reading them, surfacing them, or reacting to them. The warning is a Stripe Dashboard and API event, and it produces no accounting record on its own, correctly: no money has moved. What the two outcomes produce is documented, and they are worth setting side by side.

If you refund proactively. A charge.refunded event produces a QuickBooks Refund Receipt. Acodei detects whether the refund is full or partial by comparing the refund amount to the original charge amount, and creates the Refund Receipt against the customer, drawing from the holding account, with line items mirroring what was refunded. On a resync of an already-booked refund, Acodei updates the existing record rather than creating a second one.

The documented action here is the creation of a record. That is the contrast worth holding onto, because the dispute path below is documented as doing the opposite, and the difference is not cosmetic. One route adds a document describing a second real event. The other route goes back and changes the first one.

Two caveats belong with that. Refunds of invoice payments take their own branch, as do refunds interacting with post-payment credit notes, so a refund against a synced Stripe invoice is not identical to a refund of a standalone sale. And a refund that itself fails produces an adjustment, which lands on the second path rather than the first.

If the dispute arrives instead. This path is different in kind. A dispute reaches your balance as an adjustment balance transaction, and Acodei's documented handling of adjustments is not to post a standalone QuickBooks transaction. Instead it reverses or adjusts the original associated entry.

In real-time sync, that means voiding or removing the original sales receipt or payment. In daily summary mode, the deduction is incorporated into that day's summary and reduces that day's net deposit. For a charge that paid a synced Stripe invoice, Acodei deletes the linked payment in QuickBooks, and the invoice reopens as unpaid.

That last outcome is the one that generates support tickets, and it is designed behavior rather than a fault. A disputed invoice payment leaves an open receivable, because as far as your books are now concerned the customer has not paid.

One more documented detail belongs here, because it is the half people miss. If you later win the dispute and Stripe returns the funds, Acodei does not automatically re-post the won dispute as a new payment. The invoice stays open, or the sale stays reversed, until somebody records the money coming back. Plan for that step rather than discovering it during a reconciliation.

Why the difference is bigger than it looks

Put the two shapes next to each other and the practical consequence appears.

	Proactive refund	Dispute
Fee	None from the dispute process	Disputed amount plus a non-refundable dispute fee
Cash	Returned to the customer by you	Pulled by the network and held for the dispute
QuickBooks effect	A Refund Receipt is added	The original record is reversed, removed, or netted on the daily summary
Fraud warning count	Unchanged	Unchanged
Dispute rate	Unaffected	Increases

A refund adds a record. A dispute subtracts one. If you are comparing a month's Stripe activity to a month's QuickBooks activity by counting rows, those two events move the count in opposite directions, and neither is a sync problem.

The timing makes it worse. Card networks typically allow cardholders 120 days to dispute, and Stripe notes some situations allow longer. An early fraud warning on a charge from six weeks ago, followed by a dispute two weeks after that, reaches back into a period you have already closed and reverses a record inside it. The refund path has the same reach but a friendlier shape: a new dated record in the current period rather than a change to a closed one.

For a business that closes months tightly, that asymmetry is a real argument, and it is separate from Stripe's fee arithmetic. A refund you choose is a current-period event you control. A reversal you did not choose lands wherever it lands.

What an early fraud warning is not

Three neighbouring events get confused with this one, and each has a different answer.

A blocked payment is not a fraud warning. Radar stopping a payment before authorization means no charge, no revenue and no record, and the customer may still see an authorization hold on their statement that is not a charge. That whole situation, including what to tell the customer, is covered in why declined Stripe payments never reach QuickBooks.

A Radar fee is not connected to any of this. Radar bills per screened transaction, so screening happens whether or not a sale results, and the fee posts on its own rather than against a sale. Where Stripe's non-transactional fees land is the treatment of that.

A dispute is its own object with its own lifecycle. If you are past the warning stage and into an actual chargeback, the accounting for Stripe chargebacks and the Stripe dispute entry are the right places, and the prevention angle, particularly for cardholders who do not recognise a charge, is in statement descriptors and disputes.

A policy that survives contact with a real month

The decision is repeatable, so write it down once instead of re-arguing it each time.

Find your dispute fee and put it on the wall. Every threshold in Stripe's guidance is expressed as a multiple of that number, and it varies by country. Without it, none of the arithmetic is available.

Set a refund line at roughly your dispute fee, and stop refunding well before 1.35 times it. That is Stripe's own analysis rather than a rule of thumb, and it gives your team an answer that does not require a meeting.

Read the fraud type before deciding. A counterfeit or stolen card report on a physical-goods order that has not shipped yet is a different decision from a misc report on a delivered digital product.

Check actionable rather than assuming. A warning can arrive after a dispute already exists, and refunding a charge that is already in dispute is not available to you anyway, since Stripe blocks refunds outside the dispute process while one is open.

Expect the accounting shape to differ. A refund adds an offsetting record in the current period. A dispute reverses the original one, wherever it sits. Reconcile against your Stripe balance rather than row counts, and neither will surprise you.

Do not promise anyone that refunds keep your fraud numbers clean. They do not. Stripe says the refund does not affect the fraud warning, and Visa counts the warning regardless.

FAQ

What is a Stripe early fraud warning?

It is a message from the cardholder's issuing bank, relayed by Stripe, saying the issuer suspects a payment was fraudulent. Stripe sources them from reports that issuers on the Visa, Mastercard and JCB networks generate, including Visa TC40 and Mastercard SAFE reports. The charge already succeeded, the money is in your balance, and no dispute exists yet.

Does refunding an early fraud warning prevent the chargeback?

Usually, yes, and that is the point of refunding. Stripe documents the object's actionable flag with the note that you "may wish to proactively refund a charge that receives an EFW, in order to avoid receiving a dispute later". What it does not do is remove the fraud report itself.

Does a proactive refund clean up my fraud numbers?

No, and this is the most common mistake made about early fraud warnings. Stripe states plainly that "proactively refunding a flagged payment doesn't affect the fraud warning", and that the only refund which prevents a fraud report is one processed as a reversal, usually within about two hours of capture. Stripe also notes that Visa counts fraud warnings toward its VAMP monitoring program. The refund protects your dispute rate, not your fraud warning count.

Should I refund every early fraud warning?

No. Stripe advises against it directly: "Automatically refunding all EFWs regardless of the likelihood of escalation isn't a good strategy", because you will refund transactions that would never have become disputes. Its stated optimum is to refund charges roughly less than or equal to your dispute fee, and it says refunding is "likely not worthwhile" on charges more than 35 percent above that fee.

What happens in QuickBooks if I refund the charge?

A refund produces a Refund Receipt. Acodei compares the refund amount to the original charge to determine whether it is full or partial, then creates the Refund Receipt against the customer, drawing from the holding account, with lines mirroring what was refunded. The original sales record stays in place and the refund offsets it, so both events remain visible.

What happens in QuickBooks if the dispute arrives instead?

A dispute reaches your Stripe balance as an adjustment, and Acodei's documented handling of adjustments is to reverse or adjust the original record rather than post a separate transaction. In real-time sync the original sales receipt or payment is voided or removed. In daily summary mode the deduction reduces that day's net deposit. If the disputed charge paid a synced Stripe invoice, the linked payment is deleted and the invoice reopens as unpaid.

If I win the dispute, does the QuickBooks record come back automatically?

No. Acodei does not automatically re-post a won dispute as a new payment. An invoice that reopened after a chargeback stays open until someone records the returned money, so treat the win as a prompt to make an entry rather than as a state that repairs itself.

How likely is an early fraud warning to become a dispute?

Stripe publishes the figure: on payments not covered by the 3D Secure liability shift, "80% of EFWs convert into a fraud dispute if you do nothing." If the payment was covered by liability shift you might still receive a dispute, and Stripe automatically provides some evidence in that case.

Can an early fraud warning arrive after the dispute?

Yes. Stripe notes that the systems the networks use to process warnings are separate from the ones they use for disputes, and the two are not necessarily in sync. Check the actionable flag rather than inferring the state from when the warning arrived.

Does Acodei do anything with early fraud warnings?

Nothing is documented. Acodei's product documentation does not cover early fraud warnings, and there is no documented behavior for surfacing, reading or reacting to them. That is consistent with what the event is: a warning moves no money, so there is nothing to record. What is documented is what happens next, on either path, and that is covered above.

The short version

An early fraud warning is a report from an issuer about a payment you have already booked. It moves no money, so it writes nothing to your books on its own, and it hands you a decision with a documented base rate: four in five become disputes if you do nothing.

The refund is worth making on small charges and stops being worth it above roughly 1.35 times your dispute fee, which is Stripe's own arithmetic rather than a guess. What the refund cannot do is unfile the fraud report, because that was already sent, and the networks count it either way.

In your books the two paths diverge more than the arithmetic suggests. A refund adds an offsetting record in the period you are in. A dispute reverses the original one in the period it belongs to, and if it paid an invoice, leaves that invoice open. Knowing which of those you are choosing is most of the value of reading the warning at all.

If you would rather Stripe refunds, disputes and payouts arrived in QuickBooks already keyed to the records they belong to, start a free trial or see how the pricing works.