Ecommerce fraud prevention: run manual reviews without losing good orders

What does a risk signal establish?

Use indicators to trigger a reasoned review rather than treating them as proof that a person is committing fraud.

Shopify distinguishes individual indicators from the overall risk recommendation. Its documentation also identifies order types without that recommendation, including B2B orders and subscription renewals. Do not assume coverage for every store workflow because a tool evaluates ordinary online card purchases.

Reference: Shopify: reviewing orders with fraud analysis

A different delivery address can describe a genuine gift. A technical or geographical discrepancy therefore needs context before being recorded as confirmed abuse. Keep the specific reason for review and the information used so another authorised person can understand the decision rather than simply seeing a red label.

Separate payment fraud, account takeover and post-delivery abuse as different problems. This guide concerns the operating review of orders and payments before release. Returns investigation can follow, but it needs evidence about the parcel and goods rather than an assumption carried over from a payment flag.

Does a review status actually stop payment and fulfillment?

Demonstrate the real hold; a queue entry or warning badge is not enough.

Stripe explains that payments placed in review are commonly already processed unless the integration authorises first and captures later. Review therefore does not automatically provide an unpaid investigation window. Establish the actual payment state before designing the next step.

Reference: Stripe: review payments

In Stripe’s separate authorisation-and-capture flow, approving a review and capturing funds are different actions. The authorisation window also varies by payment method and other conditions. Set an owned review deadline for the integration you use rather than assuming a universal period.

Reference: Stripe: review uncaptured payments

Follow the hold into the warehouse or digital delivery system. An order can be paid while still awaiting review. If a warehouse has already accepted the task, changing a store label may not stop it. Identify the earliest effective hold and the process for work that has already started.

Check release and cancellation across the Shopify-to-3PL boundary

What should a reviewer have and be responsible for?

Give each case a reason, owner, deadline and permitted next action.

Create a short decision path instead of an unstructured list of suspicious orders. What can the existing order and payment information resolve? When is customer clarification appropriate, when is a second internal decision needed, and when is the issue actually a technical outage? Name cover for periods without the usual reviewer.

Use the intended secure support channel and ask only for information needed to clarify the order. Passwords or full card details are not suitable evidence. Record the result neutrally. A customer who has not replied leaves an unresolved decision, not an automatic finding of fraud.

Limit case visibility and action permissions to the responsible team. Support, finance and fulfillment should share the decision without unnecessarily copying payment details. Have two reviewers open the same case and show how conflicting approval and cancellation actions are prevented.

How should approval, cancellation and refunds change the order?

Confirm the review outcome and each resulting payment or delivery operation separately.

Stripe’s Approve action closes the review without changing the payment. With separate capture, collection remains another action. Verify the exact meaning of approval in any proposed product and identify the extra behaviour supplied by your integration.

Reference: Stripe: review payments

When the decision is not to proceed, the correct operation depends on the current state: release an uncaptured authorisation, refund a processed payment or request a stop through the warehouse’s agreed route. Retain each result and any remaining work. Refunding money does not establish that a shipment was stopped.

Report a case to the payment provider according to the decision actually supported by the evidence. A precautionary goodwill refund is not automatically confirmed fraud. Preserve the relationship between review, payment, order and any later dispute so that staff can explain what changed and why.

Keep refunds, fulfillment and stock consequences distinct

How do you recognise excessive false alarms?

Compare decisions, later outcomes and review effort using a consistent population and observation period.

Shopify exposes separate reports for matters such as acceptance, high-risk orders and chargebacks. These measure different events. Fewer risky shipments alone does not reveal how many genuine customers a rule turned away.

Reference: Shopify: fraud reports

Track open cases, time waiting, approvals after clarification and later evidence of mistaken decisions. Manual approval is initially a decision, not final proof of a legitimate payment. Disputes can arrive later, so compare order groups with a similar age and a suitable observation period rather than treating yesterday’s clean group as conclusive.

Stripe offers testing of proposed rules against past payments. Use that as an indication of reach and possible side effects, not a promise of future detection. Change rules in a controlled way and retain the prior version, expected effect and the decision to keep or reverse the change.

Reference: Stripe: fraud prevention rules

Which review acceptance cases should be demonstrated?

Exercise the whole operating path, including a genuine order that initially looks unusual.

Use provider-supported test data in an approved environment. A simulated risk recommendation can show whether the workflow reacts correctly, but it cannot establish real-world detection accuracy. Follow launch with controlled observation of actual outcomes.

Adapt this editorial matrix. Retain the reason, payment state, effective hold, decision and final result for every case. Include out-of-hours handling so the queue cannot sit indefinitely without a responsible next step.