Stripe Radar Reviews and the Sale Already in QuickBooks

Open your Stripe Radar review queue and you are looking at a list of payments that need a decision. It is easy to read that list as a waiting room: transactions held at the door while you decide whether to let them in.

That is not what it is. Almost every payment in that queue has already succeeded. The card was charged, the money is in your Stripe balance, and if your books sync in real time, the sales receipt is already sitting in QuickBooks. The review queue is not a gate in front of your accounting. It is a to-do list standing behind it.

That distinction changes what the queue costs you. A decision you make on Thursday is not deciding whether a sale happens. It is deciding whether a sale you already booked gets reversed. (If you want Stripe activity landing in QuickBooks without hand-keying any of it, you can start a free trial.)

Elevated risk and high risk are different events

Stripe Radar scores every eligible payment and assigns it a risk level. Stripe's transaction risk prevention documentation sets out the scale: "each payment also includes a risk score that ranges from 0-99 to indicate the risk level on a more granular level. By default, a score of 65 or above indicates elevated risk, while a score of 75 or above indicates high risk."

There are five documented values for risk_level, not two. normal, elevated, highest, not_assessed, and unknown. The two that matter for your books are the middle ones, and the gap between them is the whole subject of this post.

A high risk payment is blocked. Stripe states it directly: payments of this risk level "are blocked by default", and the outcome hash on the resulting Charge object reads like this:

"outcome": {
  "network_status": "not_sent_to_network",
  "reason": "highest_risk_level",
  "risk_level": "highest",
  "risk_score": 92,
  "seller_message": "Stripe blocked this charge as too risky.",
  "type": "blocked"
}

Read network_status. The request never reached the card network. No authorization, no charge, no balance transaction, nothing for a sync to relay. We have written about that branch separately in why a declined Stripe payment never reaches QuickBooks, and the short version is that there is nothing to record because nothing happened.

An elevated risk payment is a different animal entirely:

"outcome": {
  "network_status": "approved_by_network",
  "reason": "elevated_risk_level",
  "risk_level": "elevated",
  "risk_score": 68,
  "seller_message": "Stripe evaluated this charge as having elevated risk, and placed it in your manual review queue.",
  "type": "manual_review"
}

Same object, same field names, opposite reality. approved_by_network means the issuer said yes. Stripe is explicit that "Stripe Radar allows payments of this risk level by default." The payment went through. It was then flagged for your attention, and Stripe put it in a queue so that a human could look at it.

Four points of risk score separate a payment that never existed from a payment that is now revenue on your profit and loss.

The sentence that decides the whole topic

Stripe's review payments guide contains one line that answers most bookkeeping questions about the review queue before they are asked:

Payments placed into review are typically already successfully processed, unless you capture authorized payments later.

Already successfully processed. Not held, not pending, not provisional. The charge exists, it has a balance transaction, and it will appear in the payout that sweeps that day's activity.

Which means that by the time you open the review queue, your accounting has already happened. If you sync Stripe to QuickBooks in real time, a successful charge becomes a QuickBooks sales receipt deposited into your holding account, with line items resolved through your product mapping. That record was created when the charge succeeded, not when you finished reviewing it, because the sync is reacting to charge.succeeded and Radar review status is not part of that signal.

If you sync on a daily summary instead, there is no per-charge record at all, and the reviewed payment is simply one of the amounts inside that day's aggregate. It is still in your books. It is just harder to point at. The difference between the two sync modes matters here, because it determines whether a later reversal is a visible line or a change in a total.

Either way, the review is not a checkpoint your revenue passes through. It is a question asked about revenue you already have.

What Acodei does and does not do with a review

Worth being precise about, because the honest answer is narrower than people expect.

Acodei's product documentation covers what happens to a settled charge. A successful Stripe charge becomes a sales receipt against the customer, deposited into the resolved holding account for that Stripe account and currency, with lines drawn from Product Mapping and the Stripe fee recorded either as a negative line on the receipt or, depending on your fee configuration, as a separate purchase. A refunded charge becomes a refund receipt against the customer, drawing from the same holding account, with lines mirroring what was refunded, and full versus partial is determined by comparing the refund amount against the original charge amount.

Nothing in that documentation covers reading outcome.risk_level, watching for review.opened, or holding a record back while a review is open. The sync sees settled charges. It does not see risk decisions upstream of them, and it does not wait for one.

That is the correct behaviour, and it is worth understanding why rather than treating it as a gap. Stripe has already decided to accept the payment. Your accounting records what happened, and what happened is that a customer paid you. If you subsequently refund that payment because the review went badly, the refund is itself a real event with its own date, and it books on the day it occurs. Two events, two records, both true.

The alternative would be worse. A sync that held revenue back pending human review would leave your books lagging behind your bank balance by however long the queue takes to clear, and it would post revenue on a date that has nothing to do with when the customer paid.

The eight ways a review closes

The Radar Review object carries a closed_reason field, and the enum is more informative than it first appears. It is one of approved, refunded, refunded_as_fraud, disputed, redacted, canceled, payment_never_settled, or acknowledged.

Every one of those is an accounting outcome, and only one of them leaves your books untouched.

Approved. Nothing changes. Stripe describes it as closing "the review with no changes made to the payment". The sales receipt you already have stays exactly as it is. This is the common case and it is the reason the queue feels harmless.

Refunded. You decided against the payment and sent the money back. That is a refund like any other, and it books as one on the day you issue it. Our guide to recording Stripe refunds in QuickBooks covers the full and partial cases.

Refunded as fraud. Same money movement, different signal. More on this below, because the accounting is identical and the consequences are not.

Disputed. The customer got there first. Stripe notes that "if a customer disputes a payment that's currently in your review queue, the review is automatically closed", which means this closed_reason appears without you doing anything. The books path is the dispute path, not the review path, and Stripe chargeback accounting in QuickBooks is the relevant one.

Canceled. This is the auth-and-capture case. If you had authorized without capturing, there was no capture to refund, so the payment is cancelled instead.

Payment never settled. The payment did not complete on its own. Nothing to reverse.

Redacted and acknowledged are administrative closures rather than money movements.

The useful way to hold this: a review has one outcome that costs you nothing, several that produce a reversal, and one that is taken out of your hands by the customer. When you are estimating how much a review backlog matters, that ratio is the thing to know, not the size of the queue.

Refund and report fraud is two decisions wearing one button

Stripe offers three actions on a completed payment in review. Approve, Refund, and Refund and report fraud. The third one is worth separating out, because from your ledger's point of view it is indistinguishable from the second, and everywhere else it is not.

Stripe describes the difference: refunding and reporting fraud "adds the associated card fingerprint and customer email to your block lists and further increases the effectiveness of our fraud prevention." The risk evaluation documentation is more specific about the mechanism, noting that supplying fraudulent as the refund reason "adds the email address and card fingerprint associated with the payment to the default email address and card fingerprint block lists."

So the accounting is the same either way. A refund receipt for the refunded amount, against the customer, on the day of the refund. What changes is everything downstream: that customer's card and email are now blocked, and Stripe's models have been told this payment was fraud.

One more thing worth knowing before you click. Stripe states plainly that "a completed refund is permanent, you can't undo it, you must process a new payment." If the review was a false positive and the customer was legitimate, there is no reversal available. They have to buy again, on a card you may have just blocked.

That combination is why a reviewer's error rate matters more than a reviewer's speed. An approved fraudulent payment costs you the disputed amount and a dispute fee, and you find out weeks later through an early fraud warning or a chargeback. A refunded legitimate payment costs you the sale and the customer, immediately and irreversibly, and it never shows up in a fraud statistic because from Stripe's side it looks like a win.

The exception: authorize now, capture later

The one case where the review queue really is a gate is when you are not capturing at authorization time.

Stripe's own qualifier is "unless you capture authorized payments later", and the mechanics follow from that. An authorized but uncaptured payment has not moved money. There is no balance transaction and no revenue, so there is nothing in QuickBooks yet either. Stripe notes that in this configuration the review queue's Refund button "changes to Cancel", and that a Capture button appears, because capture is now a decision you make rather than something that already happened.

For businesses in this mode, the ordering is the intuitive one: review, then capture, then the record appears. If you ship physical goods and authorize at checkout, this is probably you, and most of this post describes a problem you do not have.

For everyone taking payment at checkout in the ordinary way, which is the large majority of Stripe Billing and Stripe Checkout traffic, capture happens at authorization and the record exists before the review does.

What a review open across a month end actually does

Here is where this becomes a close-process question rather than a fraud question.

A payment reviewed and refunded within the same month is invisible in your reporting. Revenue up on the fifth, revenue down on the ninth, and the month closes with a net figure that is correct.

A payment that succeeds on the twenty-eighth and gets refunded on the third of the following month is a different story. January closes with that revenue in it. February carries the refund. Both months are individually correct and the pair of them is correct, but if the amount is large enough to matter, January overstates and February understates, and the explanation lives in a queue in the Stripe dashboard rather than anywhere in your accounting.

Nothing about that is a sync error, and it is worth naming because it looks like one. Somebody comparing a Stripe report against a QuickBooks report for January will find them agreeing, then find the February refund and wonder why a January sale is reversing. The answer is that the review took six days and one of them was a month boundary.

The practical response is not complicated. Clear the review queue before you close the month, or at least clear the material amounts in it. A review that is going to end in a refund is better resolved on the twenty-ninth than the third. This is the same discipline that applies to unreconciled Stripe payments at a period boundary, and it has the same fix: deal with the open items before the period closes rather than explaining them afterwards.

Finding the payment in QuickBooks

If you have decided to refund a reviewed payment and you want to see what it did to your books, the record you are looking for depends on how the charge came in.

In real-time mode, the charge is a sales receipt, and our breakdown of sales receipt versus payment for a Stripe charge covers which one you will actually find, because the routing depends on an account setting rather than on the charge itself. In daily summary mode, the charge is inside the day's aggregate and the refund will be inside another day's.

The Stripe side is easier to search than the QuickBooks side. Stripe supports searching by risk level directly in the dashboard, using terms like risk_level:elevated, which gives you the population of payments that went through a review. Cross-referencing that list against a date range is usually faster than trying to identify reviewed payments from the QuickBooks end, where nothing distinguishes them from ordinary sales. That is not a shortcoming of your books. A reviewed payment is an ordinary sale, and the review is metadata Stripe holds about it.

For the terminology underneath all of this, Stripe charge and Stripe refund define the two objects the whole flow moves between.

Frequently asked questions

Does a Stripe Radar review stop the payment from reaching QuickBooks?

No. Stripe states that payments placed into review are typically already successfully processed, so the charge has succeeded and any real-time sync will have created its record already. The review is a decision about a payment you have, not a gate in front of one you might get. The exception is if you authorize payments and capture them later, in which case nothing has moved and nothing has synced.

What is the difference between a blocked payment and a payment in review?

A blocked payment never reached the card network. Its outcome shows network_status of not_sent_to_network and a type of blocked, and no charge, balance transaction or accounting record exists. A payment in review shows approved_by_network and a type of manual_review. The issuer approved it and the money moved. One is an absence and the other is a completed sale.

What risk score puts a payment into review?

Stripe documents a risk score range of 0 to 99, with 65 and above indicating elevated risk and 75 and above indicating high risk, by default. High risk payments are blocked by default. Elevated risk payments are allowed by default and can be sent to the review queue if your Radar plan supports it. You can also write rules that place payments in review on criteria of your own, such as amount or country.

Does Acodei do anything special with payments in review?

No, and its documentation does not claim otherwise. Acodei syncs settled Stripe activity: a successful charge becomes a sales receipt into your holding account, a refund becomes a refund receipt against the customer. Nothing documented reads the risk level, listens for review events, or holds a record back while a review is open. If you refund a reviewed payment, the refund syncs as a refund, on the day it happens.

If I refund a payment as fraudulent, does QuickBooks record it differently?

No. The accounting is identical to any other refund of the same amount. What differs is on the Stripe side: reporting fraud adds the card fingerprint and the customer's email address to your block lists and feeds Stripe's fraud models. Your ledger cannot see that distinction and does not need to.

Can I undo a refund I issued from the review queue?

No. Stripe is explicit that a completed refund is permanent and cannot be undone, and that recovering the sale means processing a new payment. If the customer was legitimate, that new payment may also be harder to take, because reporting the original as fraud will have added their card and email to your block lists.

What happens if the customer disputes a payment while it is still in review?

The review closes automatically with a closed_reason of disputed, and the situation becomes a dispute rather than a review. The accounting follows the dispute path, which is a different set of records with a different timeline. Reviews and disputes can also be confused with the pre-dispute stage, and Stripe dispute inquiries covers that separately.

Which payments can Stripe not place in review?

Stripe documents that you cannot manually review ACH or SEPA direct debit payments. For payment methods that reviews do not support, Stripe recommends creating an allow or block rule instead. Radar also evaluates rules for Charges, PaymentIntents and SetupIntents, but the review action is only available for Charges and PaymentIntents.

The short version

The Stripe Radar review queue looks like a filter and behaves like a receipt drawer. The payments in it succeeded. Their records exist. Your decision is about whether to reverse a sale, not whether to make one.

That reframing fixes most of the confusion it causes. Reviews do not explain a missing sale in QuickBooks, because reviewed payments are not missing. They explain a refund that arrives days after a sale with no customer complaint attached to it, and they explain why a month can close with revenue that a later month gives back.

If you want that whole chain landing in QuickBooks without hand-keying any of it, from the sale to the refund that may follow it, start a free trial and see it run against your own Stripe account.