sipi.bot vs Stripe Radar: agent policy engine meets card fraud detection
Stripe Radar blocks suspicious payments. sipi.bot blocks purchases that violate YOUR rules. They operate at different layers and solve different problems.
| What it does | Stripe Radar | sipi.bot |
|---|---|---|
| When it fires | After the charge is attempted | Before the spend, in the agent's decision loop |
| What it blocks | Fraudulent payments (stolen cards, chargeback risk) | Unwanted purchases (runaway loops, bad merchants, over-budget) |
| Who configures it | The Stripe account owner; rules are about payment risk | The developer deploying the agent; rules are about spend policy |
| Rule types | Risk score thresholds, CVV/3DS checks, IP/location, velocity of card use | Per-tx limit, daily total, merchant allow/block, category limit, time window, velocity, approval threshold |
| Can it distinguish between vendors? | No — Radar blocks by risk signal, not by merchant name | Yes — merchant allowlist/blocklist per agent |
| What happens when blocked | Charge is declined; user may retry or use another card | Agent gets a reason string; stops and explains to the user |
| Human-in-the-loop | No — binary approve/decline | Yes — FLAGGED decision means a human reviews and approves or denies |
They're built for different buyers
Stripe Radar is built for businesses accepting payments from end-users and protecting against payment fraud — a security layer on the payment rail. sipi.bot is built for developers who deploy autonomous agents that spend money, and who need a policy layer on the *decision to spend at all* — before the payment even hits Stripe.
Use both
The best setup is sipi.bot as the agent-side guardrail (approve/block/flag before the agent calls the payment API) and Stripe Radar as the payment-side safety net (catch actual fraud if someone bypasses the agent layer). They operate at different points in the stack and neither replaces the other.
Frequently asked
Does sipi.bot replace Stripe Radar?
No. Radar catches payment fraud (stolen cards, chargebacks); sipi.bot catches unwanted spending (runaway agents, bad merchants, over-budget). Use both.
If I use Stripe, do I still need sipi.bot?
Yes. Radar doesn't know your agent's intent, doesn't enforce merchant allowlists, and doesn't have a human-approval path for borderline purchases. sipi.bot is the agent's spend firewall; Stripe is the payment rail's fraud guard.
Can sipi.bot work with a non-Stripe payment processor?
Yes. sipi.bot is independent of the payment rail — it evaluates the spend decision before any payment API is called, whether that's Stripe, a cloud billing API, or an ad platform.