Start here
Define the job before comparing the tools
Fraud prevention is a tradeoff, not a contest for the highest risk score. Blocking a stolen-card order prevents a loss. Blocking a good repeat customer creates a different loss that may never appear in the fraud report.
Before comparing vendors, build a simple baseline: orders, approved dollars, fraud losses, chargebacks, manual reviews, canceled good orders, and customer complaints. Without that baseline, a tool can look successful just because it blocks more people.
The starting point
List the fraud and abuse the business actually sees—stolen payments, account takeover, promotion abuse, refund abuse, reshipping, or another pattern. Then name the point where the tool may advise, review, block, cancel, or challenge the customer.
The process
Work through the decision in a sensible order
Measure the current problem
Use a representative period and separate fraud loss from friendly fraud, operational error, customer disputes, and ordinary refunds.
- • Approved order value
- • Confirmed fraud and chargebacks
- • Manual-review hours
- • Known false declines and complaints
Define allowed decisions
Start with advice or shadow mode where possible. Automatic blocking, cancellation, refunding, or account action needs a named owner and an emergency stop.
- • Approve, review, decline, or challenge
- • Who can override
- • Fallback during an outage
- • Customer appeal or recovery path
Review signals and explanations
A score is not enough for a small team. Staff need to understand the useful signals, rule result, and reason an order reached review.
- • Payment and order context
- • Device or network signals
- • Customer history
- • Readable reasons and audit trail
Limit data and access
Document every field sent to the provider, why it is needed, how long it is retained, who can view it, and how deletion or access requests are handled.
- • Minimum fields
- • Regional data path
- • Retention and deletion
- • Reviewer and administrator permissions
Model the operating cost
Compare fees with fraud loss, chargebacks, review labor, false declines, integration work, guarantee terms, and ongoing rule maintenance.
- • Transactions or API calls
- • Modules and support
- • Guarantee exclusions
- • Internal review capacity
Run a measured shadow test
Use historical or mirrored decisions without affecting live customers. Compare results by channel and customer segment, then approve only rules the team can explain and monitor.
- • Known outcomes
- • Good-order approval
- • False-positive review
- • Rollback and monitoring
Owner worksheet
Write down these decisions
| Item | What to record |
|---|---|
| Fraud pattern | The exact loss or abuse this purchase is meant to reduce. |
| Decision point | Where the system advises, reviews, challenges, blocks, or cancels. |
| Business measures | Fraud dollars, approval rate, false declines, review time, chargebacks, and customer friction. |
| Data boundary | Fields shared, purpose, access, retention, deletion, and regional handling. |
| Emergency stop | How automatic action is disabled and safe payment behavior is restored. |
Red flags
Slow down when any of these appear
- The sales case celebrates blocks without showing good-order approval or false declines.
- The vendor cannot explain which data is collected and retained.
- A guarantee is discussed without eligible orders, exclusions, evidence, deadlines, and liability in writing.
- Manual review volume is estimated without using the store's actual order mix.
- The product will take automatic action before a shadow test.
- Nobody owns rule changes, incident response, customer recovery, and monthly outcome review.
Action plan
Turn the guide into a short piece of work
- Create a 90-day baseline with finance, support, and payments data.
- Choose a representative sample with known good and bad outcomes.
- Review security, privacy, contract, and payment requirements.
- Run candidates in shadow mode with the same sample.
- Compare net loss, approval, review work, explanations, and cost.
- Launch narrow rules first with monitoring, override, and rollback.
If a self-service rules and screening product fits the shadow test, review FraudLabs Pro's current options (opens in a new tab) as part of the same controlled comparison.
Editorial method
How this guide was prepared
Commerce Stack Guide reviewed the official sources below and translated the decision into a small-business workflow. The guide does not claim hands-on testing and does not replace accounting, legal, privacy, security, or other professional advice where those reviews are needed.
Product prices and limits change. Use the worksheet to verify current details with representative data and a reversible test before committing.
Sources
Official references used for this guide
- Stripe: Radar pricing and payment-stack model (opens in a new tab)
- FraudLabs Pro: Fraud screening plans (opens in a new tab)
- SEON: SEON plans and platform scope (opens in a new tab)
- Signifyd: Commerce protection pricing process (opens in a new tab)
- PCI Security Standards Council: Payment Card Industry document library (opens in a new tab)
