Stripe Radar protects the front door — ML fraud screening at authorization. Axiru governs the exit door — refunds, credits, and adjustments before they execute. Different surfaces, different problems, and most teams with real refund volume run both.
Axiru
Stripe Radar
Partial means the capability is possible but not turnkey. Our read based on public docs and onboarding conversations; corrections welcome.
| Capability | Axiru Refund decision layer | Stripe Radar ML fraud screening at auth |
|---|---|---|
Stops refunds before the API call Axiru evaluates at intake; Radar acts on the inbound payment, not the outbound refund. | ||
Focus: authorization-time fraud screening Radar's home turf. It blocked over $2.3B in fraud in 2026. | ||
Focus: refund / credit / adjustment governance | ||
Governs human reps and AI agents identically Same policy whether a CS agent or an LLM initiates the refund. | ||
Approval routing with full request context + diff Edge cases to the right approver with the policy reason attached. | ||
Shadow mode on your last 90 days of Stripe activity Replay your history against a proposed policy — no enforcement risk. | ||
ML-driven risk score on payment attempts | ||
LLM-assisted rule authoring (Radar Assistant) | ||
Versioned, plain-language policies with decision receipts Every decision cites the exact rule version that governed it. | ||
Immutable, replayable decision ledger Append-only history sealed with policy version and approver identity. | ||
Structured evidence exports for SOX / ICFR audit | ||
Built into Stripe — no separate vendor | ||
Per-screened transaction pricing Radar for Fraud Teams is $0.02/screened transaction; Axiru shadow mode is free and live pricing is usage-based. |
We build Axiru. We also know when the other answer is the right answer. Here it is.
Pick Stripe Radar when the question is “is this inbound payment fraud?” — card testing, stolen cards, risky authorizations. Their ML was trained on the payment graph itself; nothing a third party builds will catch what Radar catches at authorization.
If you are starting from zero on fraud prevention and you are on Stripe, turning on Radar (and, at scale, Radar for Fraud Teams) is usually the right first move.
Radar Assistant is a real force multiplier for fraud-ops teams writing rules in natural language — there's no reason not to use it for fraud work.
Pick Axiru when the question is “should this refund go out, and who signed off?” — refund leakage, duplicate refunds, CS agents (human or AI) over-crediting, goodwill getting out of hand, SOX-style controls around outbound payouts.
You get pre-execution policy, approval routing, and a decision ledger that finance and audit actually ask for — none of which Radar was built to provide. Shadow mode on the last 90 days means you quantify the problem before you commit to enforcement.
Teams running an AI support agent with refund permissions get this specifically: Axiru governs the AI and the human identically, with the same receipt trail.
The clean architecture is Radar at the front door, Axiru on the refund exits. Radar evaluates the inbound payment; if it flags a charge as risky, it writes that signal to the payment metadata. Axiru's refund policy can then read that metadata and, for example, always require approval on refunds tied to Radar-flagged payments.
Your Radar spend keeps doing its job. Axiru adds the policy, approvals, and audit trail on the outbound side — and you can see exactly what it would have done on your last 90 days before you turn enforcement on.
No. Radar screens inbound payments for fraud at authorization — different surface, different problem. Axiru governs outbound refunds, credits, and adjustments before they execute. Most companies with meaningful refund volume run both: Radar at the front door, Axiru on refund exits.
Smart Refunds is Stripe helping with refund-fraud detection (catching customers who game refund claims). It does not give your team a policy engine, approval routing, or an audit trail attached to the decision. Axiru sits upstream of the Stripe refund call with your own rules, your own approvers, and a receipt for every decision.
Yes — the two are complementary. Radar can flag a risky authorization and tag the payment metadata; Axiru can then use that metadata as a policy input on any downstream refund (e.g., 'refunds on Radar-flagged orders always require approval'). Your Radar spend keeps working; Axiru adds the outbound-decision layer on top.
Radar Assistant is great for authoring Radar rules in natural language. Axiru's policies are plain-language by design and versioned — every policy edit creates a new immutable version, so auditors can see exactly which rule was in effect when a given refund was decided. Different surface; same spirit of readable rules.
Yes. Axiru connects to Stripe directly through a standard read/write integration — no Radar required. If you are on Stripe, Axiru can pull your last 90 days of refunds for shadow mode and intercept new ones going forward.
Radar for Fraud Teams is $0.02 per screened transaction (all payment attempts). Axiru's shadow mode is free; live enforcement is usage-based on governed decisions (refunds, credits, adjustments you choose to route through us). The two are priced on different volume bases and are not directly comparable line-for-line.
Connect Stripe in minutes, upload history, and watch shadow mode replay every refund against the policy you would have run. No code, no enforcement risk, no cost.
Start in shadow mode first. Move to live enforcement later.
Sources: Stripe Radar pricing and 2026 fraud-blocked figures from stripe.com/radar/pricing. Comparison reflects public information as of April 22, 2026; we update this page when either product changes meaningfully.