Stripe Radar vs Forter

Agent detection

1. ai-native userThe product distinguishes malicious bots from legitimate AI buying agents, so agent-driven purchases aren't blanket-blocked as fraud

   weight 2 · round to Forter
   Stripe Radar—none0/10

   The evidence describes Radar's general fraud rules, risk scoring, reviews, and lists, but nothing addresses distinguishing legitimate AI purchasing agents from malicious bots — an axis specific to agentic commerce that is plausible for a fraud-prevention product but unevidenced here. Community feedback even shows false positives blocking legitimate low-risk customers, with no mention of agent-specific allowlisting or detection.

   • [claimed-docs] “Radar Standard: Out-of-the-box fraud protection for all payment methods to detect and prevent transaction fraud, and identify fraudulent acc…”
   • [claimed-docs] “Risk settings let you balance authorization and fraud on your account by using risk controls.”
   • [community] “We are seeing an opposite side: customers using Stripe that had very low fraud rates previously are now getting more false positives causing…”
   • [community] “We got a couple cases of false positives ourselves, and the Stripe UI wasn't very clear that we couldn't override the 'block' (the button wa…”

   proof ↗⚑ flag

   Forter~partialprobed7/10

   Forter's agentic-orders docs show a dedicated orderType=AI_AGENT field that flags agent-driven purchases so Forter's risk engine can treat them distinctly rather than blanket-blocking, which directly targets this story. However, the evidence is entirely first-party documentation with no independent testing or detail on the underlying bot-vs-legitimate-agent classification logic. Missing for 10: independent/hands-on validation of accuracy, technical detail on how malicious bots are distinguished from legitimate agents beyond a merchant-set flag.

   • [claimed-docs] “Set orderType to AI_AGENT”
   • [claimed-docs] “Set orderType to AI_AGENT ... This additional data improves Forter's risk decisions and provides the merchant better reporting on agentic tr…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.forter.com/llms.txt # docs.forter.com ## Overviews - [Agentic Orders](https://docs.forter.com/age…”

   proof ↗⚑ flag

Agent identity

1. developerPass verified agent identity — agentic-payment protocols, signed agent tokens, delegated spending scopes — into the risk decision as a first-class signal

   weight 2 · round to Forter
   Stripe Radar—none0/10

   No evidence that Radar accepts verified agent identity, agentic-payment protocol tokens, signed agent tokens, or delegated spending scopes as first-class risk inputs; Radar's documented signals are card, customer, IP, and rule/list based, not agent-identity based.

   • [claimed-docs] “you can also set up rules that are unique to your business using the supported attributes”
   • [claimed-docs] “Value lists allow you to group values together which can then be referenced in rules.”
   • [claimed-docs] “Risk settings let you balance authorization and fraud on your account by using risk controls.”

   proof ↗⚑ flag

   Forter~partialclaimed5/10

   Forter's agentic-orders API lets developers set orderType to AI_AGENT so the risk engine treats agent-originated traffic differently and improves decisioning/reporting, which shows agent identity is ingested as a factor. However, the evidence only shows a coarse flag, not verified signed agent tokens, delegated spending scopes, or support for specific agentic-payment protocols (e.g., AP2/Visa/Mastercard agent tokens) as first-class structured signals. missing for 10: schema/fields for signed agent credentials or delegation scopes, explicit protocol support for agentic-payment standards, independent confirmation these fields are cryptographically verified rather than self-declared.

   • [claimed-docs] “Set orderType to AI_AGENT”
   • [claimed-docs] “Set orderType to AI_AGENT ... This additional data improves Forter's risk decisions and provides the merchant better reporting on agentic tr…”
   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”

   proof ↗⚑ flag

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round drawn
   Stripe Radar✓fullprobed9/10

   Probes confirm a live llms.txt at docs.stripe.com/llms.txt (HTTP 200) and markdown-rendered agent-friendly docs pages (e.g. radar.md), directly enabling an agent to be pointed at agent-oriented docs. Missing for 10: no independent/community confirmation of agents actually consuming these docs successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stripe.com/llms.txt # Stripe Documentation When installing Stripe packages, always check the npm r…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/radar.md # Radar Use Stripe Radar to protect your business against fraud. ## Get starte…”

   proof ↗⚑ flag

   Forter✓fullprobed9/10

   Forter has a confirmed live llms.txt at docs.forter.com/llms.txt (HTTP 200, forter-probe-1) listing agent-oriented doc overviews, plus explicit agent-facing docs like the MCP getting-started guide for connecting to Claude Desktop and agentic-orders docs — all markdown-served for agent consumption. Missing for 10: independent third-party confirmation that agents successfully consume the llms.txt in practice beyond the probe check.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.forter.com/llms.txt # docs.forter.com ## Overviews - [Agentic Orders](https://docs.forter.com/age…”
   • [claimed-docs] “Connect Forter MCP to Claude Desktop app for conversational AI workflows.”
   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Stripe Radar
   Stripe Radar~partialprobed5/10

   Radar exposes REST API endpoints (rules, value lists, reviews approve/decline) and has dedicated testing docs with test card numbers for automated fraud-rule verification, and Stripe ships an official CLI — all of which support headless/CI use. However, there's no explicit CI/automation guide, and a community report explicitly flags 'lack of easy programmatic control' as a pain point for adjusting Radar decisions. missing for 10: dedicated CI/headless workflow documentation, explicit automation examples, and resolution of the programmatic-control complaint.

   • [claimed-docs] “POST /v1/reviews/:id/approve”
   • [claimed-docs] “4000000000004954 | Results in a charge with a risk level of `highest`”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”
   • [community] “We are seeing an opposite side: customers using Stripe that had very low fraud rates previously are now getting more false positives causing…”

   proof ↗⚑ flag

   Forter~partialprobed4/10

   Forter is a REST/webhook-based fraud API (order submission, status updates, webhooks, sandbox/test environment) which can technically be called from scripts or CI pipelines, and it offers an MCP server for programmatic/agentic access. However, there is no evidence of a CLI tool, CI/CD integration examples, headless testing harness, or automation-focused tooling explicitly designed for CI pipelines. missing for 10: dedicated CLI, CI/CD pipeline examples or GitHub Actions integration, headless test automation docs, explicit 'run in CI' guidance beyond generic sandbox API testing.

   • [claimed-docs] “Forter has both a production and a sandbox environment for your development process.”
   • [claimed-docs] “The main objective of the TEST site is to allow you to verify the integration prior to its deployment in the production environment.”
   • [claimed-docs] “Send order information at checkout to receive a fraud or abuse decision.”
   • [probe] “official MCP server documented at https://docs.forter.com/mcp”
   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round drawn
   Stripe Radar✓fullprobed8/10

   Stripe documents an official MCP server (docs.stripe.com/mcp) that lets AI agents connect to Stripe, which as a platform encompasses Radar functionality via its API. Missing for 10: Radar-specific MCP tool examples/independent hands-on corroboration of agent use.

   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   proof ↗⚑ flag

   Forter✓fullprobed8/10

   Forter documents an official MCP server enabling AI agents to review decisions, manage disputes, and update policies via natural language, with a getting-started guide for connecting to Claude Desktop. missing for 10: independent/third-party corroboration of real-world MCP usage and broader client compatibility beyond Claude Desktop.

   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Connect Forter MCP to Claude Desktop app for conversational AI workflows.”
   • [probe] “official MCP server documented at https://docs.forter.com/mcp”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Stripe Radar
   Stripe Radar✓fullprobed8/10

   Stripe ships an official Stripe CLI (docs.stripe.com/stripe-cli) that covers Radar-related API/webhook workflows, giving AI-native users a scriptable interface. Missing for 10: no direct evidence the CLI has Radar-specific commands or independent hands-on confirmation of its use in agentic workflows.

   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”

   proof ↗⚑ flag

   Forter—none0/10

   Evidence shows Forter offers REST APIs, webhooks, and an MCP server for conversational AI workflows, but no official CLI tool is documented anywhere in the evidence pack.

   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Connect Forter MCP to Claude Desktop app for conversational AI workflows.”
   • [probe] “official MCP server documented at https://docs.forter.com/mcp”

   proof ↗⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round drawn
   Stripe Radar✓fullprobed8/10

   Stripe Radar exposes documented REST API endpoints (e.g. reviews, early_fraud_warnings, value_lists) and is part of Stripe's broader public API with an official CLI and MCP server, confirming programmatic/agentic access. missing for 10: no discoverable OpenAPI/swagger spec file was found (probe 404s) and no independent hands-on report of an AI agent driving Radar specifically via the API.

   • [claimed-docs] “POST /v1/reviews/:id/approve”
   • [claimed-docs] “An early fraud warning indicates that the card issuer has notified us that a charge may be fraudulent.”
   • [claimed-docs] “Value lists allow you to group values together which can then be referenced in rules.”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/radar.md # Radar Use Stripe Radar to protect your business against fraud. ## Get starte…”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”

   proof ↗⚑ flag

   Forter✓fullprobed8/10

   Forter publishes a documented public REST API (Order v3, Order Status, Evidence API, webhooks) with sandbox/production environments, giving AI-native users a clear path to drive the product programmatically; this is reinforced by an official MCP server enabling natural-language/agentic control of decisions and disputes. Missing for 10: independent/hands-on corroboration beyond vendor docs, and more detail on auth/rate limits or SDK coverage.

   • [claimed-docs] “Send order information at checkout to receive a fraud or abuse decision.”
   • [claimed-docs] “Inform of updates to the status of an order, including payment authorization, fulfillment, shipping details, and compensation granted.”
   • [claimed-docs] “Webhooks provide a way to configure Forter to send real-time notifications to your web store server or another service (ERP/OMS) whenever ce…”
   • [claimed-docs] “Forter has both a production and a sandbox environment for your development process.”
   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Connect Forter MCP to Claude Desktop app for conversational AI workflows.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.forter.com/llms.txt # docs.forter.com ## Overviews - [Agentic Orders](https://docs.forter.com/age…”
   • [probe] “official MCP server documented at https://docs.forter.com/mcp”

   proof ↗⚑ flag

6. ai-native userBuild against official SDKs

   weight 2 · round drawn
   Stripe Radar~partialprobed5/10

   The evidence shows official API endpoints (e.g., POST /v1/reviews/:id/approve, early_fraud_warnings API) and an official CLI, implying SDK-compatible API access, but there is no explicit documentation pack entry naming or linking official language SDKs (e.g., stripe-node, stripe-python) for Radar-specific features. missing for 10: explicit SDK documentation/references, code samples showing SDK usage for Radar rules/reviews, independent developer confirmation of SDK coverage.

   • [claimed-docs] “POST /v1/reviews/:id/approve”
   • [claimed-docs] “An early fraud warning indicates that the card issuer has notified us that a charge may be fraudulent.”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/radar.md # Radar Use Stripe Radar to protect your business against fraud. ## Get starte…”

   proof ↗⚑ flag

   Forter~partialprobed5/10

   Forter provides extensive REST API references (Order v3, Order Status, Evidence API, webhooks), a sandbox/production environment, and even a documented MCP server for agentic workflows, which together give an AI-native developer solid material to build against. However, none of the evidence explicitly names or links to official client-language SDKs (e.g., Python/Node/Java packages) — only API/reference docs and an MCP integration are shown. Missing for 10: explicit official SDK packages/libraries, versioned SDK release notes, and independent corroboration of SDK usage in production.

   • [claimed-docs] “Send order information at checkout to receive a fraud or abuse decision.”
   • [claimed-docs] “Inform of updates to the status of an order, including payment authorization, fulfillment, shipping details, and compensation granted.”
   • [claimed-docs] “Webhooks provide a way to configure Forter to send real-time notifications to your web store server or another service (ERP/OMS) whenever ce…”
   • [claimed-docs] “Forter has both a production and a sandbox environment for your development process.”
   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Connect Forter MCP to Claude Desktop app for conversational AI workflows.”
   • [probe] “official MCP server documented at https://docs.forter.com/mcp”

   proof ↗⚑ flag

7. ai-native userSubscribe to events via webhooks

   weight 2 · round to Forter
   Stripe Radar—none0/10

   The evidence pack documents Radar's REST APIs (reviews, early fraud warnings, value lists) but never mentions webhook event subscriptions for these Radar events, so there's no evidence of an AI-native webhook subscription capability despite this being a plausible axis for an API-driven fraud product.

   ⚑ flag

   Forter✓fullclaimed7/10

   Forter documents a dedicated webhooks system for real-time event notifications (order status, chargeback forwarding, dispute webhooks) that can be configured to notify external services, directly matching the subscribe-to-events story; this is a well-documented first-party capability. missing for 10: independent/hands-on corroboration of webhook reliability, and a comprehensive list of subscribable event types/payload schema beyond the examples shown.

   • [claimed-docs] “Webhooks provide a way to configure Forter to send real-time notifications to your web store server or another service (ERP/OMS) whenever ce…”
   • [claimed-docs] “Inform of updates to the status of an order, including payment authorization, fulfillment, shipping details, and compensation granted.”
   • [claimed-docs] “Webhook-based forwarding enables: - Real-time claim ingestion - Faster transaction matching - Immediate eligibility assessment for dispute h…”
   • [claimed-docs] “How to provide Forter access to your Stripe Dispute Webhooks.”
   • [claimed-docs] “Webhook-based forwarding enables: Real-time claim ingestion - Faster transaction matching - Immediate eligibility assessment for dispute han…”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to Forter
   Stripe Radar—none0/10

   Radar's docs describe rule-based fraud controls, risk scoring, and dashboard analytics/visualizations (docs-4, docs-12), but there is no evidence of AI-generated natural-language insights or suggestions (e.g., an assistant summarizing fraud trends or recommending rule changes) surfaced inside the product.

   ⚑ flag

   Forter~partialclaimed6/10

   Forter provides an AI-driven recommendation engine that suggests additional evidence to bolster dispute win rates and a 'team of Forter Agents' concept, plus MCP-enabled natural language interactions for reviewing decisions and managing disputes. This shows some AI-generated insight/suggestion capability embedded in the product, but evidence is thin on broader analytics/insights (e.g., fraud trend explanations, risk scoring rationale) beyond the dispute-evidence use case. Missing for 10: broader in-product AI insights beyond dispute evidence suggestions, independent/hands-on corroboration of the recommendation engine's quality, and detail on what other 'Forter Agents' actually surface to users.

   • [claimed-docs] “our recommendation engine will suggest additional evidence to add to your dispute to bolster your win rate.”
   • [claimed-docs] “Once chargebacks are ingested into Forter, our recommendation engine will suggest additional evidence to add to your dispute to bolster your…”
   • [claimed-docs] “Meet your new team of Forter Agents, so you can spend more time on what matters most.”
   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Connect Forter MCP to Claude Desktop app for conversational AI workflows.”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Stripe Radar
   Stripe Radar~partialcommunity6/10

   Radar rules engine runs autonomously in the background on every transaction (auto 3DS requests, auto-pause payouts, custom rules, auto-allow trusted customers, risk settings) per docs-1/2/3/13/14, which is genuine unattended automation. However community feedback notes limited programmatic control over these automations and friction when trying to override or fine-tune them (stripe-radar-comm-2, stripe-radar-comm-3), suggesting the autonomy is somewhat constrained/dashboard-centric rather than fully agent-friendly. missing for 10: evidence of API-driven/programmatic rule creation or agent-triggered automation workflows, and resolution of the 'lack of easy programmatic control' complaint.

   • [claimed-docs] “Request 3D Secure (3DS) for all payments that support it and are made by a new customer”
   • [claimed-docs] “Review and automatically pause payouts on accounts that have a high dispute rate”
   • [claimed-docs] “you can also set up rules that are unique to your business using the supported attributes”
   • [claimed-docs] “Risk settings let you balance authorization and fraud on your account by using risk controls.”
   • [claimed-docs] “Customer IDs for trusted customers: Use this list to automatically allow payments by these customers.”
   • [community] “We are seeing an opposite side: customers using Stripe that had very low fraud rates previously are now getting more false positives causing…”
   • [community] “We got a couple cases of false positives ourselves, and the Stripe UI wasn't very clear that we couldn't override the 'block' (the button wa…”

   proof ↗⚑ flag

   Forter~partialprobed5/10

   Forter's fraud automation (webhooks, chargeback forwarding, evidence recommendation, MCP for reviewing decisions/managing disputes) provides background automation of fraud/dispute workflows, and the MCP server lets AI agents trigger actions, but this is not framed as user-configurable 'set up automations that run autonomously' in the sense of scheduled/triggered workflows the AI-native user builds themselves. missing for 10: explicit user-facing automation builder/scheduler, evidence of autonomous background runs initiated by the user rather than reactive webhook/event responses, and independent confirmation of real-world autonomous operation.

   • [claimed-docs] “Webhooks provide a way to configure Forter to send real-time notifications to your web store server or another service (ERP/OMS) whenever ce…”
   • [claimed-docs] “Webhook-based forwarding enables: - Real-time claim ingestion - Faster transaction matching - Immediate eligibility assessment for dispute h…”
   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Once chargebacks are ingested into Forter, our recommendation engine will suggest additional evidence to add to your dispute to bolster your…”
   • [claimed-docs] “Connect Forter MCP to Claude Desktop app for conversational AI workflows.”
   • [probe] “official MCP server documented at https://docs.forter.com/mcp”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to Forter
   Stripe Radar—none0/10

   No evidence of a built-in AI assistant within Stripe Radar to which users can delegate tasks; the product offers rules, lists, reviews, and analytics but no conversational/agentic assistant feature is documented.

   ⚑ flag

   Forter~partialclaimed3/10

   Forter's marketing mentions a 'team of Forter Agents' suggesting built-in AI-driven automation, but the evidence pack gives no detail on how a user interacts with or delegates tasks to such an assistant inside the product UI. The only detailed AI-interaction evidence (MCP) is about connecting external assistants like Claude Desktop to Forter, not a built-in assistant. Missing for 10: documentation of an in-product conversational assistant UI, examples of task delegation, and how 'Forter Agents' are invoked/configured.

   • [claimed-docs] “Meet your new team of Forter Agents, so you can spend more time on what matters most.”
   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to Forter
   Stripe Radar—none0/10

   Radar's rule configuration is a structured DSL (attributes/expressions) rather than natural-language commands, and while Stripe has a generic MCP server (stripe-radar-probe-4), there is no evidence it exposes Radar-specific fraud rule management or that Radar can be operated via free-form NL instructions.

   • [claimed-docs] “you can also set up rules that are unique to your business using the supported attributes”
   • [claimed-docs] “Value lists allow you to group values together which can then be referenced in rules.”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   proof ↗⚑ flag

   Forter✓fullprobed8/10

   Forter documents a first-party MCP server enabling natural-language commands to review decisions, manage disputes, and update policies, with a getting-started guide for connecting to Claude Desktop for conversational workflows. Missing for 10: independent/hands-on corroboration beyond vendor docs, and broader coverage of which actions are NL-operable vs API-only.

   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Connect Forter MCP to Claude Desktop app for conversational AI workflows.”
   • [probe] “official MCP server documented at https://docs.forter.com/mcp”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.forter.com/llms.txt # docs.forter.com ## Overviews - [Agentic Orders](https://docs.forter.com/age…”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   Stripe Radar—none0/10

   No evidence of an interactive API reference with runnable examples; the OpenAPI probe returned 404s and docs listed are static markdown pages describing endpoints without runnable/interactive playground features. missing for 10: interactive API explorer/playground, runnable code examples, OpenAPI spec availability.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”

   proof ↗⚑ flag

   Forter—none0/10

   The evidence pack shows Forter has API reference documentation (order-v3, order-status, webhooks, environments) but nothing indicates the docs are interactive with runnable/try-it examples—no mention of an embedded API console, code sandbox, or 'try it' functionality typical of interactive API references.

   ⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Stripe Radar—none0/10

   The evidence pack includes a direct probe for OpenAPI/swagger spec files at common Stripe docs paths, all returning 404, and no other citation shows a downloadable machine-readable spec for Radar's API. Only docs pages and llms.txt-style markdown are confirmed, not an OpenAPI/Swagger file.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”

   proof ↗⚑ flag

   Forter—none0/10

   Forter publishes REST API reference docs (order-v3, order-status, webhooks) but none of the evidence mentions a downloadable OpenAPI/Swagger spec or machine-readable API definition file; the llms.txt probe lists doc pages, not an API spec.

   • [claimed-docs] “Send order information at checkout to receive a fraud or abuse decision.”
   • [claimed-docs] “Inform of updates to the status of an order, including payment authorization, fulfillment, shipping details, and compensation granted.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.forter.com/llms.txt # docs.forter.com ## Overviews - [Agentic Orders](https://docs.forter.com/age…”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Forter
   Stripe Radar~partialprobed7/10

   Stripe Radar's testing docs explicitly provide test card numbers (e.g., 4000000000004954) that simulate specific risk levels, enabling developers to validate fraud rules and review logic without using real transactions or production data. However, the evidence doesn't detail a full sandbox environment (e.g., test-mode API key isolation, sandbox dashboards) beyond these test cards, and there's no independent/hands-on confirmation of sandbox fidelity for AI-native workflows. Missing for 10: explicit documentation of test-mode/live-mode key separation for Radar, broader sandbox environment description, and independent corroboration of safe non-production testing.

   • [claimed-docs] “4000000000004954 | Results in a charge with a risk level of `highest`”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/radar.md # Radar Use Stripe Radar to protect your business against fraud. ## Get starte…”

   proof ↗⚑ flag

   Forter✓fullclaimed8/10

   Forter explicitly documents both production and sandbox (TEST) environments, stating the sandbox's purpose is to verify integration before production deployment, allowing testing without touching production data. Missing for 10: no independent/hands-on corroboration of sandbox behavior or details on sandbox data parity/limitations.

   • [claimed-docs] “Forter has both a production and a sandbox environment for your development process.”
   • [claimed-docs] “The main objective of the TEST site is to allow you to verify the integration prior to its deployment in the production environment.”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Stripe Radar—none0/10

   The evidence pack contains no mention of Stripe API versioning scheme, version pinning, or a documented deprecation policy for Radar's API endpoints; only generic docs and community pricing/false-positive discussions are present.

   ⚑ flag

   Forter—none0/10

   Evidence shows versioned API endpoints (e.g. order-v3) and sandbox/production environments, but there is no documentation of a versioning scheme, version support lifecycle, or a deprecation policy anywhere in the pack.

   • [claimed-docs] “Send order information at checkout to receive a fraud or abuse decision.”
   • [claimed-docs] “Forter has both a production and a sandbox environment for your development process.”
   • [claimed-docs] “The main objective of the TEST site is to allow you to verify the integration prior to its deployment in the production environment.”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Stripe Radar
   Stripe Radar~partialclaimed5/10

   Radar rules, value lists, and targeted transaction-review lists let a rule or list apply automatically across many transactions/customers at once (stripe-radar-docs-1,2,3,10,11,14), which is a form of bulk automation, but the documented Review API only exposes per-item actions (POST /v1/reviews/:id/approve) with no bulk/batch endpoint or explicit multi-item API call shown. missing for 10: evidence of a bulk API endpoint for approving/declining multiple reviews or disputes at once, and any AI-native tooling for programmatic multi-item operations.

   • [claimed-docs] “Request 3D Secure (3DS) for all payments that support it and are made by a new customer”
   • [claimed-docs] “you can also set up rules that are unique to your business using the supported attributes”
   • [claimed-docs] “Value lists allow you to group values together which can then be referenced in rules.”
   • [claimed-docs] “You can create a targeted list of payments to review with criteria that you specify, and review them in the Dashboard.”
   • [claimed-docs] “Customer IDs for trusted customers: Use this list to automatically allow payments by these customers.”
   • [claimed-docs] “POST /v1/reviews/:id/approve”

   proof ↗⚑ flag

   Forter—none0/10

   Forter's docs describe per-order/per-dispute APIs (Order v3, Evidence API, webhooks, MCP natural-language actions) but no evidence of a bulk/batch endpoint or mechanism for acting across many items simultaneously. The axis is applicable (merchants would plausibly want bulk dispute/evidence submission or bulk order review), but no such capability is documented.

   • [claimed-docs] “Send order information at checkout to receive a fraud or abuse decision.”
   • [claimed-docs] “Save time and effort by using our Evidence API endpoint to automatically send post-order evidence for chargeback disputes.”
   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Stripe Radar
   Stripe Radar~partialcommunity6/10

   Radar's rule engine clearly supports defining conditional rules that trigger automatic actions (3DS challenge, block, review, allow, pause payouts) based on transaction attributes, and value lists let rules be parameterized (docs-1, docs-2, docs-3, docs-10, docs-13, docs-14). However, rule authoring is Dashboard-centric with no documented rules-creation API, and community feedback explicitly flags a 'lack of easy programmatic control' plus restricted access to Allow Rules for newer accounts (comm-2, comm-7), limiting fit for an AI-native/automated workflow. Missing for 10: a documented API/SDK for programmatically creating or updating rules, and evidence of unrestricted automation access for all account types.

   • [claimed-docs] “Request 3D Secure (3DS) for all payments that support it and are made by a new customer”
   • [claimed-docs] “Review and automatically pause payouts on accounts that have a high dispute rate”
   • [claimed-docs] “you can also set up rules that are unique to your business using the supported attributes”
   • [claimed-docs] “Value lists allow you to group values together which can then be referenced in rules.”
   • [claimed-docs] “Risk settings let you balance authorization and fraud on your account by using risk controls.”
   • [claimed-docs] “Customer IDs for trusted customers: Use this list to automatically allow payments by these customers.”
   • [community] “We are seeing an opposite side: customers using Stripe that had very low fraud rates previously are now getting more false positives causing…”
   • [community] “Allow Rules, if not implemented properly, could open a vector for fraud. That's why it's not enabled for newer businesses on Stripe—we ask b…”

   proof ↗⚑ flag

   Forter~partialclaimed5/10

   Forter supports event-driven automation via webhooks (real-time notifications on events like disputes/chargebacks) and configurable decision behaviors (e.g., Auto Invoice triggering capture), and its MCP interface lets an AI agent perform actions like reviewing decisions or updating policies via natural language. However, there is no evidence of a user-facing rule-definition engine (e.g., 'if X then Y' conditions) that AI-native users can author themselves. Missing for 10: explicit rule-builder/conditional logic UI or API, examples of user-defined trigger-action pairs beyond fixed webhook events and preset decision toggles.

   • [claimed-docs] “Webhooks provide a way to configure Forter to send real-time notifications to your web store server or another service (ERP/OMS) whenever ce…”
   • [claimed-docs] “If the Auto Invoice option is set to YES, then the payment capture amount operation is executed and order is placed”
   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Webhook-based forwarding enables: - Real-time claim ingestion - Faster transaction matching - Immediate eligibility assessment for dispute h…”

   proof ↗⚑ flag

3. ai-native userVersion, review, and roll back my automations

   weight 1 · round drawn
   Stripe Radar—none0/10

   No evidence of version history, rule change review/audit trail, or rollback capability for Radar rules/automations; rules are managed via dashboard/API but no versioning or rollback mechanism is documented. Missing for 10: rule version history, diff/review UI, rollback/restore functionality.

   ⚑ flag

   Forter—none0/10

   No evidence of any versioning, review, or rollback mechanism for automations/workflows in Forter's docs; the MCP and agentic-order features cover fraud decisioning and dispute automation, not automation lifecycle management like version history or rollback.

   ⚑ flag

Guarantee

1. finance leadShift fraud liability to the vendor — a chargeback guarantee that reimburses approved-then-disputed orders, with clear coverage terms

   weight 2 · round drawn
   Stripe Radar—none0/10

   The evidence pack covers Radar's fraud-scoring, rules, reviews, and dispute-rate monitoring features, but contains no mention of a chargeback guarantee, reimbursement for approved-then-disputed orders, or liability shift terms — that is a distinct Stripe product (Chargeback Protection), not documented here as part of Radar.

   ⚑ flag

   Forter—none0/10

   The evidence pack details dispute automation, evidence submission, webhook forwarding, and win-rate optimization tools, but none of it documents an actual chargeback guarantee, reimbursement mechanism, or liability-shift terms — the core of this finance-lead story. Missing for 10: explicit guarantee/reimbursement policy language, coverage terms, or liability-shift contract details.

   • [claimed-docs] “Webhook-based forwarding enables: - Real-time claim ingestion - Faster transaction matching - Immediate eligibility assessment for dispute h…”
   • [claimed-docs] “our recommendation engine will suggest additional evidence to add to your dispute to bolster your win rate.”
   • [claimed-docs] “Once chargebacks are ingested into Forter, our recommendation engine will suggest additional evidence to add to your dispute to bolster your…”
   • [claimed-docs] “Save time and effort by using our Evidence API endpoint to automatically send post-order evidence for chargeback disputes.”
   • [claimed-docs] “Fight fraud, increase approvals, reduce chargebacks”
   • [claimed-docs] “Automate disputes, streamline operations, improve win rates”

   proof ↗⚑ flag

Outcome reporting

1. finance leadSee the numbers that matter — dispute rate, false-positive rate, approval-rate lift, review workload — and export them for the board

   weight 2 · round to Stripe Radar
   Stripe Radar~partialclaimed4/10

   Docs show dispute-rate calculation on the Radar dashboard (stripe-radar-docs-7) and fraud-rate/volume trend visualizations (stripe-radar-docs-4), plus reviewable queues (stripe-radar-docs-11, docs-8) that imply review workload tracking. However there is no evidence of a false-positive-rate metric, approval-rate lift measurement, or any export/reporting feature for board consumption. missing for 10: false-positive rate metric, approval-rate lift metric, CSV/board export capability, independent confirmation of dashboard completeness.

   • [claimed-docs] “We show this calculation on the Radar page in the Dashboard.”
   • [claimed-docs] “Visualize trends in transaction volume and fraud rates over time.”
   • [claimed-docs] “You can create a targeted list of payments to review with criteria that you specify, and review them in the Dashboard.”
   • [claimed-docs] “POST /v1/reviews/:id/approve”

   proof ↗⚑ flag

   Forter—none0/10

   The evidence pack covers APIs, webhooks, MCP, and dispute automation but contains no mention of a reporting dashboard, board-level metrics (dispute rate, false-positive rate, approval-rate lift, review workload), or any export/reporting feature aimed at finance leads. Only a vague reference to 'better reporting on agentic traffic' exists, which does not address the specific KPIs in the story.

   • [claimed-docs] “Set orderType to AI_AGENT ... This additional data improves Forter's risk decisions and provides the merchant better reporting on agentic tr…”

   proof ↗⚑ flag

Representment

1. ops userChargeback responses are automated — evidence compiled from order, delivery, and session data and submitted to the issuer without manual copy-paste

   weight 3 · round to Forter
   Stripe Radar—none0/10

   Radar's documented capabilities are fraud scoring, rules, reviews, and dispute-rate monitoring/analytics (docs-2, docs-4, docs-7, docs-9) — none of the evidence describes compiling order/delivery/session evidence and auto-submitting it to card issuers for chargeback responses. This is a distinct dispute-evidence-automation capability that the evidence pack simply does not show Radar performing.

   • [claimed-docs] “We show this calculation on the Radar page in the Dashboard.”
   • [claimed-docs] “An early fraud warning indicates that the card issuer has notified us that a charge may be fraudulent.”
   • [claimed-docs] “Review and automatically pause payouts on accounts that have a high dispute rate”

   proof ↗⚑ flag

   Forter~partialclaimed6/10

   Forter documents automated evidence workflows: chargebacks are ingested via webhook forwarding, matched to transactions, and a recommendation engine suggests additional evidence, plus an Evidence API to 'automatically send post-order evidence for chargeback disputes' without manual copy-paste of transaction data. However, the evidence is described as 'suggested' by a recommendation engine rather than fully autonomous compilation and submission, and there's no explicit mention of session data being incorporated into evidence packages. Missing for 10: explicit confirmation that session-level data is included in compiled evidence, and independent/hands-on validation that submission is fully automatic without ops review step.

   • [claimed-docs] “Webhook-based forwarding enables: - Real-time claim ingestion - Faster transaction matching - Immediate eligibility assessment for dispute h…”
   • [claimed-docs] “our recommendation engine will suggest additional evidence to add to your dispute to bolster your win rate.”
   • [claimed-docs] “Once chargebacks are ingested into Forter, our recommendation engine will suggest additional evidence to add to your dispute to bolster your…”
   • [claimed-docs] “Save time and effort by using our Evidence API endpoint to automatically send post-order evidence for chargeback disputes.”
   • [claimed-docs] “Map Stripe's PaymentIntent ID (the value that starts with pi_) to the processorTransactionId field ... This is required to map the dispute b…”

   proof ↗⚑ flag

Agent operations

1. ai-native userAn agent can read my fraud posture and manage rules and lists programmatically — propose a velocity rule, update a blocklist — with human approval gates

   weight 3 · round to Forter
   Stripe Radar!disputedcontradicted4/10

   Stripe exposes APIs for value lists (blocklists/allowlists) and review approval (a human-approval gate: POST /v1/reviews/:id/approve), plus a documented MCP server, which together could let an agent read fraud data and manage lists with approval steps. However, rule creation/velocity-rule authoring is Dashboard-centric with no documented rules-create API, and community evidence directly contradicts the 'agent manages rules programmatically' premise: users report 'the lack of easy programmatic control is an issue for us' and that Allow Rules are disabled by default for newer accounts requiring a manual support request to enable. Missing for 10: a documented API/MCP tool to create or propose new velocity/fraud rules, and independent confirmation that programmatic rule/list management works smoothly without support intervention.

   • [claimed-docs] “POST /v1/reviews/:id/approve”
   • [claimed-docs] “Value lists allow you to group values together which can then be referenced in rules.”
   • [claimed-docs] “Customer IDs for trusted customers: Use this list to automatically allow payments by these customers.”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”
   • [community] “We are seeing an opposite side: customers using Stripe that had very low fraud rates previously are now getting more false positives causing…”
   • [community] “Allow Rules, if not implemented properly, could open a vector for fraud. That's why it's not enabled for newer businesses on Stripe—we ask b…”

   proof ↗⚑ flag

   Forter~partialprobed5/10

   Forter documents an official MCP server that lets an AI system 'review decisions, manage disputes, or update policies through natural language commands' and can connect to Claude Desktop for conversational workflows, which supports agentic read/manage access to fraud posture. However, there is no explicit documentation of proposing a velocity rule, updating a blocklist, or any human-in-the-loop approval gate mechanism for these programmatic changes. Missing for 10: explicit velocity-rule/blocklist management examples, documented approval-gate workflow, and independent/hands-on corroboration of MCP write actions.

   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Connect Forter MCP to Claude Desktop app for conversational AI workflows.”
   • [probe] “official MCP server documented at https://docs.forter.com/mcp”

   proof ↗⚑ flag

Agent triage

1. ai-native userAn agent can work the review queue — pull flagged cases with their context, summarize the evidence, and recommend a decision for a human to confirm

   weight 2 · round to Stripe Radar
   Stripe Radar~partialprobed6/10

   Radar exposes a Reviews API (list/retrieve/approve reviews), risk-insights showing related-payment networks, and early-fraud-warning data that an agent could pull as 'flagged case context,' and Stripe documents an official MCP server that could expose these APIs to an agent. However there's no first-party feature for automated evidence summarization or a recommend-then-human-confirm workflow — that logic would have to be built by the integrator, and community reports note UI/override friction around review decisions. Missing for 10: a documented agent/summarization workflow for reviews, evidence the MCP server actually exposes the reviews/early-fraud-warning endpoints, and independent confirmation of an agent successfully working the queue end-to-end.

   • [claimed-docs] “POST /v1/reviews/:id/approve”
   • [claimed-docs] “You can create a targeted list of payments to review with criteria that you specify, and review them in the Dashboard.”
   • [claimed-docs] “You can also view the network of related payments, which includes any other payments made to your business using the same customer ID, IP ad…”
   • [claimed-docs] “An early fraud warning indicates that the card issuer has notified us that a charge may be fraudulent.”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”
   • [community] “We got a couple cases of false positives ourselves, and the Stripe UI wasn't very clear that we couldn't override the 'block' (the button wa…”

   proof ↗⚑ flag

   Forter~partialprobed5/10

   Forter's MCP server explicitly lets an AI agent 'perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural language commands' via Claude Desktop, showing agent access to review/decision workflows. However, there is no explicit documentation of pulling a flagged-case queue, summarizing evidence, or producing a recommendation for human confirmation as a distinct workflow. missing for 10: explicit queue-pulling UI/API for flagged cases, evidence-summarization output, human-confirm approval step.

   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Connect Forter MCP to Claude Desktop app for conversational AI workflows.”
   • [probe] “official MCP server documented at https://docs.forter.com/mcp”

   proof ↗⚑ flag

Builtin ai

1. risk analystThe product ships its own AI assistant — natural-language queries over my fraud data, drafted rules, investigation summaries — built into the console

   weight 2 · round to Forter
   Stripe Radar—none0/10

   No evidence of a built-in AI assistant in the Radar console for natural-language queries, drafted rules, or investigation summaries; documentation covers rules engine, reviews, analytics, and lists but nothing about an AI/NLP assistant feature.

   ⚑ flag

   Forter~partialprobed3/10

   Forter markets 'Forter Agents' and ships an MCP server letting external AI systems (e.g., Claude Desktop) issue natural-language commands to review decisions, manage disputes, or update policies, which gestures at the AI-assistant theme. However, the evidence never describes a native, embedded console assistant with NL querying over fraud data, rule drafting, or investigation summaries — the MCP approach is an integration layer for external AI clients rather than a first-party in-console assistant. Missing for 10: concrete documentation of a built-in console chat/assistant UI, evidence of drafted-rule generation, and investigation-summary generation features.

   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Meet your new team of Forter Agents, so you can spend more time on what matters most.”
   • [claimed-docs] “Connect Forter MCP to Claude Desktop app for conversational AI workflows.”
   • [probe] “official MCP server documented at https://docs.forter.com/mcp”

   proof ↗⚑ flag

Abuse coverage

1. risk analystProtection extends beyond checkout — account takeover, fake account creation, promo and policy abuse are scored and managed in the same system

   weight 2 · round drawn
   Stripe Radar~partialclaimed5/10

   Radar Pro docs explicitly extend beyond checkout fraud to 'multi-account, free trial, and pay-as-you-go abuse,' covering fake-account and promo/policy abuse in the same platform, but there is no evidence of dedicated account-takeover detection or scoring — the docs focus on payment/charge risk, reviews, and disputes rather than login/session anomaly detection typical of ATO protection. Missing for 10: explicit account-takeover detection/scoring capability, unified dashboard evidence showing ATO alongside promo-abuse cases, and independent confirmation these abuse types are actually managed in one system rather than just marketed together.

   • [claimed-docs] “Radar Pro: Advanced protection against emerging fraud threats and customer abuse. Detect multi-account, free trial, and pay-as-you-go abuse.”
   • [claimed-docs] “Radar Standard: Out-of-the-box fraud protection for all payment methods to detect and prevent transaction fraud, and identify fraudulent acc…”
   • [claimed-docs] “An early fraud warning indicates that the card issuer has notified us that a charge may be fraudulent.”

   proof ↗⚑ flag

   Forter~partialclaimed5/10

   Forter's marketing copy explicitly claims to 'Stop ATO, block fake accounts, protect account integrity' alongside its checkout/fraud-decision APIs, indicating account-takeover and fake-account protection live in the same platform as order-level fraud scoring. However, there is no documentation of promo abuse or policy abuse detection/management, and no detail on how ATO/fake-account signals are scored or surfaced to analysts beyond a single marketing line. Missing for 10: dedicated docs/API for promo abuse and policy abuse detection, analyst-facing workflow/management details for ATO and fake-account cases beyond marketing claims.

   • [claimed-docs] “Stop ATO, block fake accounts, protect account integrity”
   • [claimed-docs] “Send order information at checkout to receive a fraud or abuse decision.”
   • [claimed-docs] “Fight fraud, increase approvals, reduce chargebacks”

   proof ↗⚑ flag

Integrations

1. ops userThere are maintained integrations for my commerce stack — Shopify, Salesforce Commerce, BigCommerce, and the major PSPs — not just a raw API

   weight 2 · round to Forter
   Stripe Radar—none0/10

   Evidence covers Radar's rules, reviews, risk settings, and API/CLI/MCP tooling, but nothing mentions maintained integrations or plugins for commerce platforms like Shopify, Salesforce Commerce, or BigCommerce, or PSP-specific integrations beyond Stripe's own API. Missing for 10: any documentation of Shopify/BigCommerce/Salesforce Commerce app integrations, partner PSP integrations, or an integrations marketplace listing.

   • [claimed-docs] “Radar Standard: Out-of-the-box fraud protection for all payment methods to detect and prevent transaction fraud, and identify fraudulent acc…”
   • [claimed-docs] “Risk settings let you balance authorization and fraud on your account by using risk controls.”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/radar.md # Radar Use Stripe Radar to protect your business against fraud. ## Get starte…”

   proof ↗⚑ flag

   Forter~partialclaimed5/10

   Evidence confirms a maintained Shopify integration (quickstart-shopify.md) and Stripe dispute webhook support, indicating some pre-built commerce/PSP connectors exist. However, there is no evidence of maintained integrations for Salesforce Commerce, BigCommerce, or other major PSPs (Adyen, Braintise, PayPal, etc.), leaving the breadth of the 'commerce stack' claim largely unsubstantiated. missing for 10: documented Salesforce Commerce Cloud integration, BigCommerce integration, coverage of additional major PSPs beyond Stripe, and any partner/marketplace integration directory confirming maintenance status.

   • [claimed-docs] “You implement: Nothing - Forter handles everything”
   • [claimed-docs] “How to provide Forter access to your Stripe Dispute Webhooks.”
   • [claimed-docs] “Map Stripe's PaymentIntent ID (the value that starts with pi_) to the processorTransactionId field ... This is required to map the dispute b…”

   proof ↗⚑ flag

Psp coverage

1. developerUse the product across whatever payment stack I run — multiple PSPs, gateways, and platforms — rather than being locked to one processor's rails

   weight 3 · round to Forter
   Stripe Radar—none0/10

   All evidence describes Radar as a feature built directly into Stripe's own payments processing (rules, reviews, risk settings, session tokenization, testing tied to Stripe test cards) with no mention of usable integration with other PSPs, gateways, or platforms. Fraud-detection tools in general could plausibly support multi-processor use, but nothing in the pack shows Radar operating outside Stripe's own rails — it is described purely as a Stripe-native capability.

   • [claimed-docs] “Radar Standard: Out-of-the-box fraud protection for all payment methods to detect and prevent transaction fraud, and identify fraudulent acc…”
   • [claimed-docs] “By using Radar Sessions, you can capture critical fraud information without tokenizing on Stripe.”
   • [claimed-docs] “4000000000004954 | Results in a charge with a risk level of `highest`”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/radar.md # Radar Use Stripe Radar to protect your business against fraud. ## Get starte…”

   proof ↗⚑ flag

   Forter~partialclaimed5/10

   Forter is payment-agnostic in principle (works off order/checkout data, not tied to a specific processor's rails), and evidence shows Stripe-specific dispute webhook integration plus a Shopify quickstart, implying multi-platform support. However there is no explicit documentation enumerating support across multiple PSPs/gateways beyond Stripe and Shopify, nor guidance for other major processors (Adyen, Braintree, PayPal, etc.). missing for 10: explicit list/documentation of supported PSPs and gateways beyond Stripe/Shopify, evidence of platform-agnostic integration guides for other processors, independent confirmation of multi-PSP deployments.

   • [claimed-docs] “How to provide Forter access to your Stripe Dispute Webhooks.”
   • [claimed-docs] “Map Stripe's PaymentIntent ID (the value that starts with pi_) to the processorTransactionId field ... This is required to map the dispute b…”
   • [claimed-docs] “You implement: Nothing - Forter handles everything”
   • [claimed-docs] “Forter has both a production and a sandbox environment for your development process.”

   proof ↗⚑ flag

Explainability

1. risk analystEvery score comes with its top risk factors — why this transaction looks risky — not just an opaque number

   weight 3 · round to Stripe Radar
   Stripe Radar~partialclaimed4/10

   Radar's Reviews/Risk Insights docs show a 'network of related payments' (same customer ID, IP, card) and analytics trends, suggesting some contextual signals behind a score, but the evidence never describes an explicit list of 'top risk factors' or feature-level explanation attached to each transaction's score. Missing for 10: explicit per-transaction factor breakdown/SHAP-style explanation, quantified factor weighting, independent confirmation that risk-insights actually enumerates specific risk drivers rather than just related-payment context.

   • [claimed-docs] “You can also view the network of related payments, which includes any other payments made to your business using the same customer ID, IP ad…”
   • [claimed-docs] “Visualize trends in transaction volume and fraud rates over time.”
   • [claimed-docs] “Risk settings let you balance authorization and fraud on your account by using risk controls.”

   proof ↗⚑ flag

   Forter—none0/10

   No evidence describes score explainability, reason codes, or risk-factor breakdowns accompanying Forter's fraud decisions; the evidence pack covers order submission, webhooks, disputes, and agentic order tagging but nothing about transparency into why a score was assigned.

   ⚑ flag

Model evaluation

1. finance leadMeasure the model itself — precision and recall on my traffic, shadow-mode trials of new models or rules before they take over decisions

   weight 2 · round drawn
   Stripe Radar—none0/10

   Docs mention fraud-rate analytics and dispute measurement (fraud insights, risk settings) but nowhere describe precision/recall metrics on the merchant's own traffic or a shadow-mode mechanism to trial new models/rules before they affect decisions. Rules can be created and reviewed, but there's no evidence of a non-blocking 'test' or 'shadow' deployment mode for models.

   • [claimed-docs] “Visualize trends in transaction volume and fraud rates over time.”
   • [claimed-docs] “We show this calculation on the Radar page in the Dashboard.”
   • [claimed-docs] “Risk settings let you balance authorization and fraud on your account by using risk controls.”

   proof ↗⚑ flag

   Forter—none0/10

   No evidence of model-level metrics (precision/recall), shadow-mode trials, or A/B testing of models/rules before rollout; evidence covers order decisioning, webhooks, disputes, and agentic orders but nothing about model performance measurement or staged rollout tooling for finance leads.

   ⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Forter
   Stripe Radar!disputedcontradicted4/10

   Stripe exposes API endpoints for some Radar objects (reviews approve/reject, early fraud warnings, value lists) but the core capability of authoring/editing Radar Rules and risk settings is documented only via Dashboard-oriented docs (stripe-radar-docs-3, docs-13) with no corresponding rules-API endpoint evidenced. Community feedback explicitly calls out this gap ('The lack of easy programmatic control is an issue for us', stripe-radar-comm-2) and notes Allow Rules require manual support intervention rather than self-service API access (stripe-radar-comm-7), directly contradicting full API/UI parity. missing for 10: documented API endpoints for creating/editing Radar rules, programmatic risk-settings control, independent confirmation that all dashboard actions have API equivalents.

   • [claimed-docs] “you can also set up rules that are unique to your business using the supported attributes”
   • [claimed-docs] “Risk settings let you balance authorization and fraud on your account by using risk controls.”
   • [claimed-docs] “POST /v1/reviews/:id/approve”
   • [claimed-docs] “An early fraud warning indicates that the card issuer has notified us that a charge may be fraudulent.”
   • [claimed-docs] “Value lists allow you to group values together which can then be referenced in rules.”
   • [community] “We are seeing an opposite side: customers using Stripe that had very low fraud rates previously are now getting more false positives causing…”
   • [community] “Allow Rules, if not implemented properly, could open a vector for fraud. That's why it's not enabled for newer businesses on Stripe—we ask b…”

   proof ↗⚑ flag

   Forter~partialprobed6/10

   Forter exposes core actions via API/webhooks (order decisions, order status, evidence submission, chargeback forwarding) and an MCP server that lets AI agents review decisions, manage disputes, and update policies via natural language, suggesting broad API/agent coverage of UI functions. However, there is no explicit documentation stating full feature parity between the UI dashboard and API/MCP, and some UI-only configuration (e.g., policy setup screens, analytics dashboards) isn't shown as API-accessible. Missing for 10: explicit parity statement, evidence that every UI configuration/reporting feature is also API-exposed, independent confirmation of MCP completeness.

   • [claimed-docs] “It enables an AI system to perform real actions—such as reviewing decisions, managing disputes, or updating policies through natural languag…”
   • [claimed-docs] “Set orderType to AI_AGENT”
   • [claimed-docs] “Save time and effort by using our Evidence API endpoint to automatically send post-order evidence for chargeback disputes.”
   • [claimed-docs] “Send order information at checkout to receive a fraud or abuse decision.”
   • [claimed-docs] “Inform of updates to the status of an order, including payment authorization, fulfillment, shipping details, and compensation granted.”
   • [claimed-docs] “Webhooks provide a way to configure Forter to send real-time notifications to your web store server or another service (ERP/OMS) whenever ce…”
   • [probe] “official MCP server documented at https://docs.forter.com/mcp”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round drawn
   Stripe Radar—none0/10

   No evidence of any data export feature or open-format data portability for Radar; docs cover rules, reviews, analytics, and APIs but nothing about exporting all account/fraud data to leave the platform. missing for 10: bulk/full data export tooling, open-format (CSV/JSON) export docs, any account-closure/data-portability guarantee.

   ⚑ flag

   Forter—none0/10

   Forter is a fraud-detection/risk B2B API platform; no evidence of any end-user data export feature or open-format data portability for merchants or consumers to 'leave' with their data. Missing for 10: any documented data export tool, open format (CSV/JSON) export capability, or account-closure data portability process.

   ⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round drawn
   Stripe Radar—none0/10

   Stripe Radar is a closed, proprietary SaaS fraud service; no evidence of any open-source license or public source repository for Radar itself. Documentation, pricing, and CLI/MCP references exist, but nothing indicates the product's source is available under an open license.

   ⚑ flag

   Forter—none0/10

   Forter is a closed, proprietary fraud-prevention SaaS; no evidence of any open-source license or public source code repository for the core product. Missing for 10: any open-source license grant, public source repository, or licensing terms permitting source inspection/modification.

   ⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   Stripe Radar—none0/10

   No evidence in the pack addresses data residency, regional storage options, or data location controls for Stripe Radar; the documentation covers fraud rules, reviews, and risk settings but not where data is stored.

   ⚑ flag

   Forter—none0/10

   No evidence in the pack addresses data residency, regional storage options, or geographic controls over where customer data is held; all evidence concerns fraud decisioning, disputes, webhooks, and agentic order tagging.

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Stripe Radar—none0/10

   The evidence pack contains no mention of data retention policies, deletion controls, or privacy/data lifecycle management features for Radar; documentation covers fraud rules, reviews, testing, and pricing but nothing about controlling how long data is kept or deleting it.

   ⚑ flag

   Forter—none0/10

   No evidence pack items address data retention policies, deletion controls, or user-facing privacy/data-management settings; the docs focus on fraud detection, disputes, and MCP integration.

   ⚑ flag

Residency

1. ops userControl where fraud data lives and how long it's kept — regional residency options and retention controls that survive a privacy review

   weight 2 · round drawn
   Stripe Radar—none0/10

   No evidence pack item addresses data residency options, regional storage location controls, or configurable retention periods for fraud/Radar data; the docs cover rules, reviews, lists, and testing but nothing about compliance/residency controls.

   ⚑ flag

   Forter—none0/10

   No evidence pack items address data residency options, regional data storage, or retention/deletion controls; documentation covers order APIs, webhooks, disputes, PCI scope, and MCP/agent features but nothing about where fraud data is stored or how long it is kept.

   ⚑ flag

Sca

1. developerEuropean traffic is routed intelligently through SCA — 3DS triggered when required or risky, exemptions requested when safe — to protect both compliance and conversion

   weight 2 · round to Stripe Radar
   Stripe Radar~partialclaimed4/10

   Radar rules docs show it can trigger 3DS for specific conditions (e.g., new customers) via custom rules, but there is no evidence of intelligent SCA-wide routing that automatically requests exemptions (TRA, low-value, etc.) to preserve conversion — the exemption side of the story is unaddressed and this Radar-specific capability differs from Stripe's core SCA/Payment Intents engine. missing for 10: evidence of automated exemption requests (TRA/low-value/trusted-beneficiary), evidence of end-to-end SCA compliance logic beyond manual rule authoring, and independent confirmation of conversion impact.

   • [claimed-docs] “Request 3D Secure (3DS) for all payments that support it and are made by a new customer”
   • [claimed-docs] “you can also set up rules that are unique to your business using the supported attributes”

   proof ↗⚑ flag

   Forter—none0/10

   No evidence in the pack mentions SCA, 3DS, PSD2 exemptions, or European payment authentication routing at all; Forter's docs focus on fraud decisioning, disputes, chargebacks, and agentic order tagging, none of which address SCA/3DS logic.

   ⚑ flag

Case review

1. risk analystFlagged transactions land in a review queue that shows the full context — customer history, signals, similar cases — so I can decide quickly and consistently

   weight 3 · round to Stripe Radar
   Stripe Radar~partialcommunity7/10

   Stripe's docs show a genuine review queue workflow: targeted transaction reviews (docs-11), an approve/reject API (docs-8), and a 'risk insights' view showing related payments across customer ID, IP, or card number for spotting similar cases (docs-12). However, evidence doesn't explicitly confirm a unified single screen combining full customer history + fraud signals + similar-case surfacing in one glance, and community feedback notes UI friction when analysts try to act on flagged transactions (comm-3, unclear override controls). missing for 10: explicit documentation of a consolidated 'customer history' panel within the review UI, and independent/hands-on confirmation that the queue enables fast, consistent decisions without friction.

   • [claimed-docs] “You can create a targeted list of payments to review with criteria that you specify, and review them in the Dashboard.”
   • [claimed-docs] “POST /v1/reviews/:id/approve”
   • [claimed-docs] “You can also view the network of related payments, which includes any other payments made to your business using the same customer ID, IP ad…”
   • [community] “We got a couple cases of false positives ourselves, and the Stripe UI wasn't very clear that we couldn't override the 'block' (the button wa…”

   proof ↗⚑ flag

   Forter—none0/10

   Evidence covers order decisioning APIs, webhooks, chargeback/dispute automation, and MCP/agentic order tagging, but there is no mention of a review queue UI showing flagged transactions with customer history, signals, or similar cases for analyst decisioning.

   ⚑ flag

Feedback loop

1. risk analystMy review decisions and confirmed fraud outcomes feed back into the model and rules, so the system learns from every case we work

   weight 2 · round drawn
   Stripe Radar~partialclaimed4/10

   Radar lets analysts approve/decline reviews (docs-8) and maintain allow/block value lists that then drive future rule evaluation (docs-10, docs-14), which is a manual feedback mechanism, and early fraud warnings feed dispute-rate risk signals (docs-9, docs-7). However there is no documented evidence that confirmed fraud outcomes or review decisions automatically retrain Radar's underlying ML model — the docs describe rules/lists as merchant-configured, not an automated learning loop tied to case outcomes. Missing for 10: explicit documentation of the ML model being retrained from analyst decisions/fraud confirmations, and independent/hands-on confirmation that outcomes measurably change future scoring.

   • [claimed-docs] “POST /v1/reviews/:id/approve”
   • [claimed-docs] “Value lists allow you to group values together which can then be referenced in rules.”
   • [claimed-docs] “Customer IDs for trusted customers: Use this list to automatically allow payments by these customers.”
   • [claimed-docs] “An early fraud warning indicates that the card issuer has notified us that a charge may be fraudulent.”
   • [claimed-docs] “We show this calculation on the Radar page in the Dashboard.”

   proof ↗⚑ flag

   Forter~partialclaimed4/10

   Forter's docs show data flowing back to Forter post-decision (order status updates including compensation granted, chargeback/dispute webhook ingestion, Evidence API) which implies outcome data reaches Forter's systems, but there is no explicit documentation that a risk analyst's manual review decisions or confirmed-fraud outcomes are used to retrain models or update rules. Missing for 10: explicit description of a feedback/learning loop tying analyst review outcomes to model or rule updates, and any mention of an analyst review queue at all.

   • [claimed-docs] “Inform of updates to the status of an order, including payment authorization, fulfillment, shipping details, and compensation granted.”
   • [claimed-docs] “Webhook-based forwarding enables: - Real-time claim ingestion - Faster transaction matching - Immediate eligibility assessment for dispute h…”
   • [claimed-docs] “Webhook-based forwarding enables: Real-time claim ingestion - Faster transaction matching - Immediate eligibility assessment for dispute han…”
   • [claimed-docs] “How to provide Forter access to your Stripe Dispute Webhooks.”
   • [claimed-docs] “Map Stripe's PaymentIntent ID (the value that starts with pi_) to the processorTransactionId field ... This is required to map the dispute b…”
   • [claimed-docs] “Save time and effort by using our Evidence API endpoint to automatically send post-order evidence for chargeback disputes.”

   proof ↗⚑ flag

Team workflows

1. ops userReview work is a team workflow — assignment, escalation, SLAs, and a decision audit trail that shows who approved what and why

   weight 2 · round to Stripe Radar
   Stripe Radar~partialclaimed3/10

   Radar's reviews API supports approve/decline actions on flagged payments and lets teams build custom review queues, which implies some decision logging, but there is no documented support for assignment to specific reviewers, escalation paths, or SLA tracking, and no explicit 'who approved what and why' audit trail beyond the approve/reject call itself. missing for 10: reviewer assignment, escalation workflow, SLA tracking, structured decision-rationale audit trail.

   • [claimed-docs] “POST /v1/reviews/:id/approve”
   • [claimed-docs] “You can create a targeted list of payments to review with criteria that you specify, and review them in the Dashboard.”
   • [claimed-docs] “You can also view the network of related payments, which includes any other payments made to your business using the same customer ID, IP ad…”

   proof ↗⚑ flag

   Forter—none0/10

   The evidence pack covers order decisioning, webhooks, chargeback/dispute automation, and AI-agent/MCP integrations, but contains no mention of a human team review workflow with case assignment, escalation rules, SLAs, or an approval audit trail for ops reviewers. missing for 10: case assignment/queue management, escalation rules, SLA tracking, and a decision audit trail showing reviewer approvals and rationale.

   ⚑ flag

Custom signals

1. developerFeed the model my own signals — device fingerprints, behavioral data, custom metadata — so scoring reflects my business, not just network defaults

   weight 2 · round to Stripe Radar
   Stripe Radar~partialcommunity5/10

   Radar lets developers write custom rules against 'supported attributes' and value lists (docs-3, docs-10, docs-14), and Radar Session captures device/browser signals for fraud evaluation without full tokenization (docs-15) — this shows some capacity to incorporate custom signals. However, there's no evidence that arbitrary custom metadata or behavioral data actually feeds into or retrains Radar's core ML risk score itself (rather than just triggering rule-based overrides), and community commentary notes a 'lack of easy programmatic control' over scoring (comm-2). missing for 10: explicit documentation that custom metadata/behavioral inputs alter the underlying risk score model, first-party guidance on feeding proprietary signals into scoring, and independent confirmation this works as intended.

   • [claimed-docs] “you can also set up rules that are unique to your business using the supported attributes”
   • [claimed-docs] “Value lists allow you to group values together which can then be referenced in rules.”
   • [claimed-docs] “Customer IDs for trusted customers: Use this list to automatically allow payments by these customers.”
   • [claimed-docs] “By using Radar Sessions, you can capture critical fraud information without tokenizing on Stripe.”
   • [community] “We are seeing an opposite side: customers using Stripe that had very low fraud rates previously are now getting more false positives causing…”

   proof ↗⚑ flag

   Forter~partialclaimed4/10

   Forter's Order API accepts order data and metadata at checkout (forter-docs-1) and supports custom decision configuration (forter-docs-18), implying some ability to send custom signals, but there is no documented schema or capability for developers to submit their own device fingerprints, custom behavioral signals, or arbitrary metadata that directly influences scoring weights. missing for 10: explicit API fields/documentation for submitting custom device fingerprint or behavioral data, evidence that custom signals are actually weighted in scoring versus Forter's own network-derived signals, and any tuning/configuration interface for business-specific signal weighting.

   • [claimed-docs] “Send order information at checkout to receive a fraud or abuse decision.”
   • [claimed-docs] “If the Auto Invoice option is set to YES, then the payment capture amount operation is executed and order is placed”

   proof ↗⚑ flag

Network effects

1. founderScoring benefits from a cross-merchant network — a card or identity seen across thousands of other businesses informs the risk decision on mine

   weight 2 · round to Stripe Radar
   Stripe Radar~partialclaimed5/10

   Docs show Radar surfaces a 'network of related payments' across customer ID, IP, or card number (docs-12) and ingests card-issuer signals via Early Fraud Warnings (docs-9), implying some cross-account risk signal, and docs-6 describes 'out-of-the-box' pre-trained fraud detection. However, none of the evidence explicitly states the model is trained on or scores against Stripe's full cross-merchant network of thousands of businesses. Missing for 10: explicit documentation of the network-wide ML training/scoring claim, and independent confirmation that cross-merchant signals (not just same-business history) drive individual risk scores.

   • [claimed-docs] “You can also view the network of related payments, which includes any other payments made to your business using the same customer ID, IP ad…”
   • [claimed-docs] “An early fraud warning indicates that the card issuer has notified us that a charge may be fraudulent.”
   • [claimed-docs] “Radar Standard: Out-of-the-box fraud protection for all payment methods to detect and prevent transaction fraud, and identify fraudulent acc…”

   proof ↗⚑ flag

   Forter—none0/10

   The evidence pack covers order submission, webhooks, disputes, chargebacks, PCI scope, and agentic/MCP features, but none of it describes a cross-merchant network effect, shared identity/card risk signals, or network-wide fraud intelligence informing decisions. Missing for 10: any documentation or claim about network-level data sharing, identity graph across merchants, or aggregated fraud signals from other businesses.

   ⚑ flag

Score actions

1. ops userMap score ranges to actions — allow, review, block, step-up 3DS — and tune thresholds to my own risk appetite instead of a fixed cutoff

   weight 2 · round to Stripe Radar
   Stripe Radar~partialcommunity6/10

   Stripe Radar's docs clearly support mapping risk levels to actions (block, review, request 3DS, allow via value lists) and tuning via risk-settings/rules with custom attributes, directly matching the story. However, community evidence shows real friction: allow rules are gated behind manual support enablement for newer accounts (comm-7), an ops user hit a 'block' override button that silently did nothing requiring a support ticket (comm-3), and another reports 'lack of easy programmatic control' over false positives (comm-2), indicating the threshold-tuning experience isn't as self-service as docs imply. Missing for 10: independent verification that threshold-to-action mapping is fully self-serve without support intervention, and resolution of the UI override bug.

   • [claimed-docs] “Request 3D Secure (3DS) for all payments that support it and are made by a new customer”
   • [claimed-docs] “Risk settings let you balance authorization and fraud on your account by using risk controls.”
   • [claimed-docs] “Customer IDs for trusted customers: Use this list to automatically allow payments by these customers.”
   • [claimed-docs] “you can also set up rules that are unique to your business using the supported attributes”
   • [community] “We are seeing an opposite side: customers using Stripe that had very low fraud rates previously are now getting more false positives causing…”
   • [community] “We got a couple cases of false positives ourselves, and the Stripe UI wasn't very clear that we couldn't override the 'block' (the button wa…”
   • [community] “Allow Rules, if not implemented properly, could open a vector for fraud. That's why it's not enabled for newer businesses on Stripe—we ask b…”

   proof ↗⚑ flag

   Forter—none0/10

   The evidence pack covers order decisions, webhooks, disputes, PCI scope, and agentic order tagging, but contains no mention of score-range-to-action mapping, configurable thresholds, or step-up 3DS logic that ops users could tune. Forter's docs reference binary/decision-based order outcomes (fraud/abuse decision) rather than a threshold-tuning console. Missing for 10: any documentation of score bands, adjustable thresholds, or 3DS step-up configuration UI/API.

   • [claimed-docs] “Send order information at checkout to receive a fraud or abuse decision.”
   • [claimed-docs] “If the Auto Invoice option is set to YES, then the payment capture amount operation is executed and order is placed”

   proof ↗⚑ flag

Scoring api

1. developerGet a machine-learning risk score for a transaction in real time — synchronously, before authorization completes — through a documented API

   weight 3 · round drawn
   Stripe Radar~partialclaimed6/10

   Docs confirm Radar attaches a risk level/score to each charge (e.g. test card 4000000000004954 'Results in a charge with a risk level of highest') and that rules/reviews act on this score, implying the score is computed as part of normal payment processing and exposed on the charge object via the API. However, the pack never explicitly documents the exact API field (e.g. charge.outcome.risk_score) or explicitly states the score is available synchronously before authorization completes, and no independent/hands-on confirmation of real-time synchronous scoring is present. missing for 10: explicit API reference/schema for risk_score/risk_level field, explicit documentation stating the score is returned before/at authorization time, independent corroboration of real-time synchronous behavior.

   • [claimed-docs] “4000000000004954 | Results in a charge with a risk level of `highest`”
   • [claimed-docs] “Radar Standard: Out-of-the-box fraud protection for all payment methods to detect and prevent transaction fraud, and identify fraudulent acc…”
   • [claimed-docs] “Request 3D Secure (3DS) for all payments that support it and are made by a new customer”
   • [claimed-docs] “POST /v1/reviews/:id/approve”

   proof ↗⚑ flag

   Forter~partialclaimed6/10

   Forter's Order API (order-v3) is documented as a synchronous checkout-time call returning a fraud/abuse decision, and order-status/webhooks show authorization events are tracked separately, implying the decision precedes authorization — consistent with real-time pre-auth scoring. However, the docs describe a categorical 'decision' rather than an explicit numeric ML risk score, and there's no independent/hands-on latency or scoring-format confirmation. Missing for 10: explicit documentation of a numeric/probabilistic risk score field, and independent verification of real-time performance.

   • [claimed-docs] “Send order information at checkout to receive a fraud or abuse decision.”
   • [claimed-docs] “Inform of updates to the status of an order, including payment authorization, fulfillment, shipping details, and compensation granted.”
   • [claimed-docs] “Forter has both a production and a sandbox environment for your development process.”

   proof ↗⚑ flag

Backtesting

1. risk analystBacktest a rule against my historical traffic before deploying it, seeing exactly what it would have blocked, flagged, and cost

   weight 2 · round drawn
   Stripe Radar—none0/10

   The evidence pack covers rule creation, value lists, risk settings, reviews, and analytics dashboards, but no documentation or community evidence describes a backtesting/simulation feature that shows what a new rule would have blocked/flagged/cost against historical traffic before deployment.

   • [claimed-docs] “you can also set up rules that are unique to your business using the supported attributes”
   • [claimed-docs] “Visualize trends in transaction volume and fraud rates over time.”
   • [claimed-docs] “Risk settings let you balance authorization and fraud on your account by using risk controls.”

   proof ↗⚑ flag

   Forter—none0/10

   No evidence of any rule backtesting, historical simulation, or cost/impact preview capability in the evidence pack — coverage is about order decisioning, webhooks, disputes, and MCP/agentic orders, none of which address testing rules against historical traffic before deployment.

   ⚑ flag

Lists

1. ops userMaintain allow and block lists — emails, cards, devices, IPs — and velocity limits, managed through the dashboard and programmatically

   weight 2 · round to Stripe Radar
   Stripe Radar!disputedcontradicted5/10

   Stripe documents value lists for allow/block lists (customers, cards, emails, IPs) manageable via API and dashboard (stripe-radar-docs-10, docs-14) plus rules for velocity/custom attributes (docs-3, docs-1), giving vendor-side coverage of the story. However hands-on community reports contradict smooth programmatic control: one user cites 'lack of easy programmatic control' causing false-positive grief, and another found the dashboard's block-override button non-functional, requiring a support email to whitelist transactions; Stripe itself confirms Allow Rules are gated behind manual support enablement for newer accounts, not self-serve. Missing for 10: clear documentation of dedicated device/IP allow-and-block management (only cards/customers/emails are explicit), and no evidence the programmatic control gap or override bug has been resolved.

   • [claimed-docs] “Value lists allow you to group values together which can then be referenced in rules.”
   • [claimed-docs] “Customer IDs for trusted customers: Use this list to automatically allow payments by these customers.”
   • [claimed-docs] “you can also set up rules that are unique to your business using the supported attributes”
   • [claimed-docs] “Request 3D Secure (3DS) for all payments that support it and are made by a new customer”
   • [community] “We are seeing an opposite side: customers using Stripe that had very low fraud rates previously are now getting more false positives causing…”
   • [community] “We got a couple cases of false positives ourselves, and the Stripe UI wasn't very clear that we couldn't override the 'block' (the button wa…”
   • [community] “Allow Rules, if not implemented properly, could open a vector for fraud. That's why it's not enabled for newer businesses on Stripe—we ask b…”

   proof ↗⚑ flag

   Forter—none0/10

   The evidence pack contains no mention of allow/block lists (emails, cards, devices, IPs) or velocity limit configuration, either via dashboard or API — only order decisioning, webhooks, disputes, and agentic order APIs are documented. This is a fair capability to expect from a fraud-rules platform, but no evidence supports it.

   ⚑ flag

Rule authoring

1. risk analystAuthor custom rules that combine model scores, velocity counters, list matches, and transaction attributes into allow, block, or review decisions

   weight 3 · round to Stripe Radar
   Stripe Radar~partialcommunity7/10

   Stripe docs show a rich rules engine — custom rules using risk score, transaction attributes, value lists (for list matches), and allow/block/review outcomes (docs-1,3,10,13,14) — which covers most of the story. However, community evidence shows secondary caveats: Allow Rules are disabled by default for newer businesses and require manual support enablement (comm-7), and users report inability to override block decisions via UI plus false positives (comm-2,3), indicating real friction in the rule-authoring/decisioning workflow. Missing for 10: explicit documentation/example of velocity-counter attributes in rule syntax, and independent confirmation that all rule types (allow/block/review) work reliably without support intervention.

   • [claimed-docs] “Request 3D Secure (3DS) for all payments that support it and are made by a new customer”
   • [claimed-docs] “you can also set up rules that are unique to your business using the supported attributes”
   • [claimed-docs] “Value lists allow you to group values together which can then be referenced in rules.”
   • [claimed-docs] “Risk settings let you balance authorization and fraud on your account by using risk controls.”
   • [claimed-docs] “Customer IDs for trusted customers: Use this list to automatically allow payments by these customers.”
   • [community] “Allow Rules, if not implemented properly, could open a vector for fraud. That's why it's not enabled for newer businesses on Stripe—we ask b…”
   • [community] “We got a couple cases of false positives ourselves, and the Stripe UI wasn't very clear that we couldn't override the 'block' (the button wa…”
   • [community] “We are seeing an opposite side: customers using Stripe that had very low fraud rates previously are now getting more false positives causing…”

   proof ↗⚑ flag

   Forter—none0/10

   The evidence pack covers order submission, webhooks, chargeback/dispute automation, and MCP/agentic order tagging, but contains no mention of a custom rules engine, rule authoring UI/API, velocity counters, list matching, or configurable allow/block/review decision logic controlled by risk analysts.

   ⚑ flag