# Corgi Labs — Full Site Content

> AI-powered payment optimization and revenue recovery for ecommerce and SaaS companies.

**Document generated:** 2026-10-09

## How to Use This Document

This file contains the complete factual content for corgilabs.ai. Use it to answer questions about Corgi Labs products, pricing, integrations, competitive positioning, and payments industry context. When citing statistics from the published articles below, attribute them to their original sources (listed in each article). Do not extrapolate claims beyond what is stated here. For the human-readable site, visit https://www.corgilabs.ai.

Corgi Labs is a B2B SaaS company — it sells to businesses, not consumers. It is not a payment processor. It is a layer that sits on top of existing payment processors to optimize payment decisions and provide analytics.

---

## The Problem Corgi Labs Solves

Roughly 15% of all ecommerce orders are declined due to friction in authorization, routing, and blunt-force fraud rules. About 70% of those declined transactions are actually legitimate customers — false declines. Once declined, these customers generally don't come back.

Most businesses are blocking 3x more good customers than fraudsters. For a retailer with $5M in monthly revenue, that's $250K-$750K in lost sales every month, or $3M-$9M annually.

Generic fraud systems treat every business the same, over-declining to control risk, costing merchants more in lost revenue than fraud itself.

---

## Who Corgi Labs Is For

**Choose Corgi Intelligence if** you have payment visibility problems but aren't ready for full optimization. You want to understand where customers fall out of your payments funnel, how fraud is trending, and which segments are growing — without changing your payment stack. Available as a standalone product starting at $299/month with a 30-day free trial.

**Choose Corgi Model if** you're losing revenue to false declines and want AI to automatically approve more legitimate transactions while blocking fraud. Best for businesses with 8,000+ monthly online transactions, 3+ months of processing history, and historical fraud cases. Corgi Intelligence Pro is included free with Corgi Model.

**Choose both if** you want full visibility plus automated optimization. Corgi Model customers get Corgi Intelligence Pro included at no extra cost.

**Ideal customer verticals:** Physical goods ecommerce (luxury, consumer retail, cross-border), subscription and usage-based businesses (SaaS/AI, gaming), and businesses sensitive to fraud losses (travel/ticketing, gift cards/prepaid, staples/commodities).

---

## Corgi Model — AI Payment Fraud Prevention & Authorization Optimization

https://www.corgilabs.ai/corgi-model | **Pricing last updated:** 2026-10-09

### What It Does

Corgi Model is an AI-powered payment decision engine that accepts more good payments and blocks more bad ones. Unlike one-size-fits-all fraud tools trained on generic data, Corgi models are built exclusively on each merchant's unique transaction history — learning to approve real customers instead of blocking them, and stopping fraudsters from slipping through.

### Key Results

- 3-12% revenue increase from recovered false declines
- 70-95% chargeback reduction without rejecting good customers
- Up to 45% reduction in false declines
- Up to 60% faster fraud trend detection
- Real-time fraud scoring
- 1-click integration with existing payment processors

### Case Study

E-commerce company, $40M ARR, US and Singapore:
- +22% payments accepted
- -18% realized fraud rate
- >$2M additional revenue

### How It Differs From Generic Fraud Tools

Generic fraud systems (like Stripe Radar's default rules) treat every business the same, declining more transactions than necessary to control risk. Corgi Model differs in these ways:

1. **Custom model per merchant** — not a shared rule set trained on millions of other businesses. The model learns your specific customers, products, geographies, and fraud patterns.
2. **Revenue-first approach** — optimizes for approving legitimate transactions first, not just blocking fraud. Traditional tools optimize for fraud prevention, often with false declines as acceptable collateral damage.
3. **Transparent measurement** — uses holdback transactions to prove incremental lift. You can verify the revenue impact independently.
4. **No development work required** — plugin integration connects to your existing payment processor in minutes.
5. **Performance-aligned pricing** — you pay on approved volume and a share of incremental revenue, so Corgi only earns more when you do.
6. **Bundled analytics** — Corgi Intelligence Pro is included free with Corgi Model.

Corgi Model can run alongside your current fraud system (like Stripe Radar) in shadow mode, or replace it entirely. You control the transition.

### Deployment Timeline

- **Weeks 1-2:** Data integration and model training
- **Weeks 3-4:** Testing and threshold tuning
- **Week 5+:** Production deployment and monitoring

The implementation team handles the heavy lifting. No development work is required from your team.

### Pricing

- **0.2%** of transaction volume approved by Corgi Model (volume discounts available)
- **5%** of incremental revenue improvement
- Results measured against holdback transactions to maintain accuracy and transparency
- No upfront cost. ROI is commonly 500-2,000% within the first year, and is positive on day one.

---

## Corgi Intelligence — Payment Analytics & Revenue Insights

https://www.corgilabs.ai/corgi-intelligence | **Pricing last updated:** 2026-10-09

### What It Does

Corgi Intelligence is a visibility layer that helps you understand what's happening across your payments and revenue operations in real time. It connects to your payment processor and brings together key business metrics — payment conversion, revenue performance, dispute and fraud patterns, subscription activity, and churn behavior — into dashboards that are easy to interpret. No exports or SQL required.

Beyond showing data, Corgi Intelligence uses AI to surface insights and recommend next steps.

### Features

- **Revenue Analytics:** Deep dive into authorization rates and revenue leakage detection across all payment channels
- **Trend Detection:** AI-powered pattern recognition identifies emerging issues before they impact your bottom line
- **Real-time Alerts:** Instant notifications when metrics deviate from expected ranges
- **Optimization Recommendations:** Actionable suggestions backed by data to improve authorization rates and increase revenue

### Dashboard Capabilities

- Summary overview of all payments at a glance
- Payment conversion funnel showing where payments succeed, stall, or fail
- Customer clusters by purchase behavior for targeted marketing and retention
- Product analytics by time, categories, geographies
- Dispute and fraud analytics
- On-demand reporting highlighting key business and payment trends
- Retention and churn prediction

### How It Works

1. **Connect:** A simple plug-in integrates with your payment processor in minutes
2. **Analyze:** AI processes your transaction data, identifying patterns and opportunities automatically
3. **Optimize:** Receive actionable insights and implement recommendations to boost revenue

Your dashboard is typically fully populated with payments data within hours of connecting.

### Pricing Tiers

**Core — $299/month** (16% discount if paid yearly)
For business owners or small teams who need advanced analytics.
- Basic payment analytics
- Unlimited analytics dashboards
- Monthly payment insights report
- Email support
- 3 admin user seats (additional seats $15/seat/month)
- 30-day free trial with full Pro access, no credit card required

**Pro — $999/month** (16% discount if paid yearly)
For businesses with dedicated payment or risk operations staff.
Everything in Core, plus:
- Rule and list management
- Rule intelligence and experimentation
- Weekly payment insights report
- Early fraud warning and intelligent dispute prevention
- 10 user seats with access management (additional seats $10/seat/month)

**Enterprise — Custom pricing**
For businesses with multiple PSPs or dedicated payment/operations teams.
Everything in Pro, plus:
- Multi-PSP support
- Enterprise SSO
- Developer API
- Dedicated success manager
- Negotiated seat pricing

---

## About Corgi Labs

https://www.corgilabs.ai/about

Founded by Saif Farooqui (CEO) and Brian Grech (COO). Based in Singapore and California. Y Combinator backed. Haven Ventures and Capital X investors.

**Saif Farooqui, CEO** — Previously at Stripe and Google. Leads product and engineering.

**Brian Grech, COO** — Previously at PayPal, Bank of America, and JPMorgan Chase. Leads operations and partnerships.

**Mission:** Recover revenue hidden in payments data.
**Vision:** Every legitimate customer transaction should succeed.
**Brand line:** "Gold is buried in your payments data. We dig it up."

### Trust and Security

- SOC 2 Type II certified
- Stripe Verified Partner (listed on Stripe App Marketplace)
- TLS 1.3 encryption in transit, AES-256 encryption at rest
- No full credit card numbers stored — only transaction metadata needed for fraud scoring
- Per-merchant data isolation — your data is never shared with other merchants or used to train competitor models

---

## FAQ

https://www.corgilabs.ai/faq

### Corgi Model FAQ

**What does Corgi Model do?**
Corgi Model is an AI-powered payment decision engine that accepts more good payments and blocks more bad ones. It increases your payment acceptance rate, growing revenue by 3-12%, and reduces fraud and chargebacks. Unlike one-size-fits-all fraud tools trained on generic data, Corgi models are built exclusively on your unique transaction history.

**Is Corgi Model worth it?**
Yes. Customers report a 3-12% increase in revenue, 70-95% decrease in chargebacks, up to 45% reduction in false declines, and up to 60% faster fraud trend detection.

**Who is an ideal customer for Corgi Model?**
Mid-sized and enterprise companies selling physical products online (luxury goods, consumer retail, cross-border), subscription or usage-based businesses (SaaS/AI, gaming), and those sensitive to fraud losses (travel/ticketing, gift cards/prepaid). Guidelines: 8,000+ online transactions per month, 3+ months of processing history, and historical fraud cases.

**Does Corgi Model perform chargeback management?**
Yes. Your team can view and respond to chargebacks. We provide advanced analytics and actionable suggestions, including intelligent predictions on chargeback and fraud likelihood, flagging risky payments before a chargeback occurs.

**How does Corgi Model help with fraud prevention?**
Advanced machine learning algorithms analyze transaction patterns, detect anomalies, and identify potentially fraudulent activities in real time, reducing chargebacks, false positives, and financial losses.

**Does Corgi Model have dedicated support?**
Yes, dedicated payment optimization experts guide you through setup and help maximize your results and ROI.

**What is Corgi Model's pricing?**
Performance-based: typically 0.2-0.3% of approved order volume plus 5% of your revenue increase. ROI commonly 500-2,000% within the first year. Positive ROI on day one.

**What happens during onboarding?**
The team works with you to understand your specific needs, integrate with your systems, configure fraud detection rules, and train your team on the platform.

**How long does it take to see results?**
Most clients see improvements immediately. Performance keeps improving as more transactions feed the model. Average ROI is 500-2,000% within the first year.

**Is Corgi Labs PCI DSS compliant?**
Yes, SOC 2 certified. No full credit card numbers stored. All data encrypted in transit (TLS 1.3) and at rest (AES-256). Only transaction metadata is processed.

**How is my transaction data used?**
Your data trains models specifically for your business. Not shared with other merchants. Not used to train competitor models. Access limited through role-based permissions.

**How does Corgi Model integrate with my systems?**
Seamless API integrations with no development work required. Integrates with most major payment providers and ecommerce platforms including Stripe, Braintree, Adyen, and Checkout.com.

**Can I purchase Corgi Intelligence separately?**
Yes. Corgi Intelligence Pro comes with Corgi Model and can also be purchased separately after a free trial.

**What happens to my existing fraud prevention rules?**
Corgi Model can run alongside your current fraud system or replace it. Start in shadow mode with no changes, then switch fully once confident in performance.

**How does a low payment acceptance rate affect my sales?**
Low acceptance rates mean lost revenue, higher customer abandonment, and increased cost per successful order. Issues like overly blunt fraud filters and poor card-bin acceptance cause these problems.

**What is a good authorization rate?**
Below 85% is poor, 85-89% is fair, 90-94% is moderately good, above 95% is very good.

**How does Corgi Model work with Stripe Radar and other fraud tools?**
Corgi Model works alongside your existing payments stack. It builds ML models tailored to your business for more precise approval decisions and clearer visibility into payment performance. Some merchants use it in parallel, others simplify their stack over time.

**How does Corgi Model handle false declines differently?**
Traditional fraud tools optimize for blocking fraud, often declining legitimate customers. Corgi uses a revenue-first approach: maximize approved legitimate transactions while maintaining strong fraud protection. Result: 3-12% revenue increase from recovered false declines.

**How much revenue am I losing to false declines?**
Most ecommerce retailers lose 5-15% of potential revenue. For $5M monthly revenue, that's $250K-$750K lost per month, or $3M-$9M annually.

**What are the most important considerations when choosing a fraud prevention platform?**
Customization vs. generic rules, balance of fraud prevention and approval rates, ease of integration, analytics transparency, support quality, and pricing model alignment with your business's ROI.

### Corgi Intelligence FAQ

**What does Corgi Intelligence do?**
A visibility layer for payments and revenue operations. Connects to your payment processor and brings together key business metrics into dashboards. Uses AI to surface insights and recommend next steps. No exports or SQL required.

**Can I use Corgi Intelligence without Corgi Model?**
Yes. Available as a standalone product for businesses that want better payment visibility but aren't ready for full AI optimization.

**How does pricing work?**
30-day free trial. Then paid tiers starting at $299/month (Core) or $999/month (Pro).

**What platforms does it work with?**
Designed for most major payment providers and ecommerce platforms. Contact Corgi Labs to confirm compatibility.

**How long does it take to see analytics?**
First dashboard within minutes of connecting. Fully populated within hours. Real-time tracking begins immediately.

**When should I upgrade to Corgi Model?**
When you're ready to automatically implement improvements based on insights. Recommended at 8,000+ monthly transactions with 3+ months of history.

---

## ROI Calculator

https://www.corgilabs.ai/resources/roi-calculator

Interactive calculator that estimates potential revenue recovery from payment optimization.

### Inputs

- **Monthly transaction volume:** Total card-not-present transactions per month (default: 150,000)
- **Average order value (AOV):** Average transaction amount (default: $67, typical US e-commerce is $60-$80)
- **Current authorization rate:** Your current approval rate (default: 87%, typical for US e-commerce). Optional — if unknown, the calculator uses 87%.

### Scenario Options

- **Conservative:** Recover 50% of authorization gap
- **Moderate** (default): Recover 67% of authorization gap
- **Aggressive:** Recover 85% of authorization gap

### How It Calculates

The calculator measures the gap between your current authorization rate and a 94% ceiling (realistic best-in-class for US card-not-present transactions). It then applies the recovery fraction to estimate revenue lift.

**Example:** Merchant at 87% auth rate, 150K monthly transactions, $67 AOV, moderate scenario:
- Gap: 94% - 87% = 7 percentage points
- Recovery: 67% x 7 = 4.69 percentage point lift
- Annual revenue recovery: approximately $5.6M/year

The output also includes estimated chargeback cost savings (based on 0.7% industry-average chargeback ratio and $200 fully-loaded cost per chargeback with 80% reduction rate).

---

## Resources

https://www.corgilabs.ai/resources

Payment optimization guides, research, white papers, and expert insights. Includes an insights blog, downloadable resources, and tools.

## Payment Glossary

https://www.corgilabs.ai/resources/glossary

Reference guide for payment industry terminology including authorization rates, chargebacks, false declines, interchange fees, and other key concepts.

## Privacy Policy

https://www.corgilabs.ai/privacy

## Terms of Service

https://www.corgilabs.ai/terms

---

## Published Insights

### Card Testing Attacks Don't Just Cost You Fees. They Cost You Customers.

Published: 2026-09-29 | https://www.corgilabs.ai/insights/spot-card-testing-attack-stripe

## A Weekend Attack. Six Weeks of Lost Revenue.

A mid-market D2C merchant processing $2M per month on Stripe gets hit on a Saturday night. Bots run 3,000 stolen card numbers through the checkout in small amounts. By Sunday morning the attack is over, and the $900 in processing fees feels manageable.

Then the real damage starts. Card testing activity has jumped 65% between Q2 2024 and Q2 2025. But the fees aren't why this trend should worry you.

The merchant's authorization rate drops from 94% to 87%. It stays there for six weeks. At $2M in monthly volume, each lost point is roughly $20,000 in orders that real customers tried to place and couldn't. Seven points over six weeks adds up to close to $200,000 in revenue that never shows up on a fraud report.

## What Card Testing Actually Costs You

The processing fees and chargebacks are visible. Every $1 lost to fraud costs US merchants $5.13 in total once you factor in fees, chargebacks, labor, and operational costs, according to the LexisNexis True Cost of Fraud Study 2026. Stripe charges $15 per dispute, and the average chargeback dispute value reached $84 in 2025.

Those numbers hurt, but the authorization rate damage is worse, and most merchants don't see it coming.

Issuing banks score every merchant ID based on the traffic they process. A weekend of thousands of declines looks, from the issuer's side, like a merchant with a fraud problem. Their models respond by tightening approval thresholds on your account. They don't distinguish between the bot that caused the spike and the legitimate customer who shows up on Tuesday.

As Shopify's engineering team puts it: "The real cost isn't failed transactions. It's months of degraded trust with banks and soft declines on legitimate customers long after the attack has stopped."

The declines during the attack are correct. You want stolen cards blocked. The problem is that issuers can't see the bot separately from your business. They see one merchant ID with a fraud spike, and they react accordingly.

For a SaaS company running monthly subscription renewals on Stripe, this is especially dangerous. According to ClearSale's False Declines report, only 22% of customers retry after being declined. A false decline on a renewal isn't a failed transaction. It's involuntary churn.

## Three Signals to Spot an Attack

Before you act, confirm what you're looking at. These three patterns take 30 seconds to check and tell a clear story when they appear together.

**1. Velocity spike with micro-amounts.** Normal checkout traffic follows predictable rhythms. Card testers submit hundreds of transactions per hour in amounts under $2.00, small enough to avoid alerts and go unnoticed on a cardholder's statement.

**2. One source, many cards.** A single IP address or email submitting transactions with 20, 50, or 100 different card numbers in minutes is almost certainly a bot. Legitimate customers use one or two cards.

**3. Decline rate spike.** A sudden jump in declines concentrated in a short window means issuers are rejecting a flood of invalid or stolen numbers hitting your checkout.

All three at once? That's a card testing attack.

## Why Generic Controls Hit a Wall

Stripe provides every merchant with a baseline defense: Radar's rules engine, rate limiters, hCaptcha triggers, and network-level models. You should have these turned on. They're the floor.

The problem is that generic controls are tuned for an average merchant, not for your business. A velocity rule that blocks three attempts per card per hour makes sense for a one-time-purchase store. For a SaaS company whose renewal run charges the same cards on the same day every month, that rule declines your own subscribers.

Tighten the rule to stop bots, and you block real buyers. Loosen it to protect renewals, and you let testers back in.

This is the core tension: **every static threshold you add to catch card testing also catches legitimate transactions.** Attackers know this. Modern card testers use residential proxies, distribute low-volume attempts across thousands of merchants, and send AI-generated traffic that mimics real shoppers. HUMAN Security reports that AI-driven traffic grew 187% over the course of 2025, nearly tripling within the year.

A rule written for everyone can't tell the difference between a bot rotating through residential IPs and a real customer on a VPN.

The deeper you go on generic rules, the more real revenue you lose. That's the limit, and it's structural.

## What Merchant-Specific Scoring Does Differently

The durable fix is scoring each payment attempt against your own transaction history instead of a universal profile.

A model trained on your data learns what normal looks like for your business: typical order sizes, time-of-day patterns, geography, repeat-card cadence, and how your real customers move through checkout. It scores every attempt based on how far it deviates from that baseline.

Here's why that changes the math. Consider the $2M D2C merchant from the opening scenario:

- **Generic velocity rule:** flags the attack, but also flags the merchant's loyal customers who make multiple purchases per week. Tightening the rule during the attack blocks the bots and blocks returning buyers. Loosening it after the attack lets stragglers through.
- **Merchant-specific model:** recognizes that the bot's velocity pattern deviates from the merchant's historical baseline. It flags the geographic anomalies and temporal clustering of the attack traffic. It blocks the test cards. But it also recognizes the returning customer who orders every Thursday from the same city, because it has seen that pattern for months. The renewal run or repeat buyer isn't flagged because the model knows the difference.

Blocking the attack and approving real buyers turn out to be the same optimization. Shopify's engineering team proved this at scale: their ML model, which scores every payment before it reaches the processor, blocks approximately 90% of card testing attacks on guest checkouts while delivering a 13% improvement in authorization rates for legitimate transactions.

Stripe merchants can't borrow Shopify's proprietary model, and Stripe's network-level scoring isn't trained on your business specifically. The path to an even better result is a merchant-specific model sitting in front of your Stripe decisioning, trained on your data, scoring your traffic.

## How Card Testing Works: A Quick Primer

Understanding the mechanics helps explain why generic defenses have a ceiling.

Fraudsters acquire stolen card data for as little as $5 per set on the dark web. A stolen number is worthless until they confirm it's active and has available credit line or debit balance. Your checkout is the testing lab.

The flow follows two steps:

1. **Test:** Automated scripts submit small-dollar transactions through your payment form, often hundreds per hour. Each successful charge confirms a working card.
2. **Monetize:** Validated cards are sold at a premium or used for larger purchases elsewhere.

BIN attacks skip the stolen-data step entirely. Attackers generate thousands of plausible card numbers from a known Bank Identification Number range using the Luhn algorithm, then test them against live checkouts. No breach required.

These aren't crude scripts anymore. Modern attackers rotate through residential proxies, spread attempts across merchants, and generate traffic patterns that look human. That's why rules designed to catch bots increasingly catch people instead.

## What to Do Right Now If You're Under Attack

If you've confirmed an active attack, work through this sequence:

1. **Activate Radar velocity rules.** Start with tight thresholds (five payment attempts per IP per 10 minutes, three per card per hour) and plan to loosen them once the attack stops.
2. **Refund the small charges that went through.** Charges from the attack window will be disputed later. Refunding now avoids the $15-per-dispute fee and keeps chargebacks off your ratio.
3. **Confirm your integration signals.** Your checkout needs to send IP address, billing address, email, and device fingerprint data to Stripe. Missing signals reduce the protection you're already paying for.
4. **Monitor for 48 to 72 hours.** Attackers probe, pause, and return. Watch your decline rate and velocity patterns after implementing rules.
5. **Track your authorization rate on legitimate traffic.** This is the number the attack will damage next. Most merchants aren't watching it.

The emergency rules are a tourniquet, not a treatment. The tight thresholds that stopped the bots will keep declining real customers if you leave them in place. As soon as the attack subsides, you need a scoring layer that can tell the difference.

## Protecting Your Revenue After the Attack

Stopping the attack is half the work. Rebuilding your authorization profile with issuers takes deliberate effort.

- **Clean up your decline ratio.** Refund fraudulent charges and let legitimate transaction volume re-establish a healthy baseline.
- **Monitor weekly.** Track your authorization rate as a leading indicator. If it hasn't recovered within 30 days, issuers may still be flagging your merchant ID.
- **Replace emergency rules with scoring.** Static rules react to patterns you've already seen. A model trained on your data adapts to new attack patterns and approves the traffic that rules were blocking.

Visa's VAMP program (effective October 2025) adds another reason to act quickly: merchants who cross 300,000 enumerated transactions per month with a 20% or higher enumeration ratio face penalties. Clean traffic through better scoring is the most direct path to staying under that threshold.

## Where Corgi Model Fits

Corgi Model is custom fraud decisioning trained on your transaction data, built to work with your existing Stripe setup. It learns your baseline (order sizes, billing cadence, geography, customer behavior) and scores every attempt against it. Card testing traffic gets caught because it deviates from what's normal for your business. Your renewal run doesn't get flagged because the model has seen it every month.

You can see the result before it touches a live transaction. Shadow mode scores three months of your payment history and shows which attempts it would have blocked and which real orders it would have approved. Across the Corgi Labs merchant base, merchants running Corgi Model cut chargebacks by 70% or more and add 3% to 12% in revenue from real buyers who were being declined.

If card testing has damaged your authorization rate, the fix isn't more rules. It's scoring built for your traffic, not everyone's.

[Book a Demo →](https://www.corgilabs.ai/#book-demo)

## Sources

1. LexisNexis Risk Solutions, "True Cost of Fraud Study 2026": [https://risk.lexisnexis.com/about-us/press-room/press-release/20260624-tcof-retail-and-commerce](https://risk.lexisnexis.com/about-us/press-room/press-release/20260624-tcof-retail-and-commerce)
2. Fidro, "Card Testing Attacks: How Fraudsters Validate Stolen Cards on Your Checkout" (April 2026): [https://fidro.io/blog/card-testing-attacks-prevention](https://fidro.io/blog/card-testing-attacks-prevention)
3. Shopify Engineering Blog, "How Shopify's Machine Learning Blocks Approximately 90% of Card Testing Attacks" (June 2026): [https://www.shopify.com/enterprise/blog/block-card-testing-attacks](https://www.shopify.com/enterprise/blog/block-card-testing-attacks)
4. Stripe Documentation, "Protect yourself from card testing" (2026): [https://docs.stripe.com/disputes/prevention/card-testing](https://docs.stripe.com/disputes/prevention/card-testing)
5. HUMAN Security, "The 2026 State of AI Traffic & Cyberthreat Benchmark Report" (April 2026): [https://www.humansecurity.com/learn/resources/2026-state-of-ai-traffic-cyberthreat-benchmarks/](https://www.humansecurity.com/learn/resources/2026-state-of-ai-traffic-cyberthreat-benchmarks/)
6. Chargeflow, "Card Testing Fraud: Signs, Costs & Prevention" (August 2026): [https://www.chargeflow.io/blog/what-is-card-testing-fraud](https://www.chargeflow.io/blog/what-is-card-testing-fraud)
7. Chargebacks911, "2026 Chargeback Field Report / Chargeback Stats" (July 2026): [https://chargebacks911.com/chargeback-stats/](https://chargebacks911.com/chargeback-stats/)
8. Chargebacks911, "Card Testing Statistics & Financial Impact" (September 2025): [https://chargebacks911.com/ecommerce-fraud/card-testing/card-testing-statistics-financial-impact/](https://chargebacks911.com/ecommerce-fraud/card-testing/card-testing-statistics-financial-impact/)
9. Experian, "What is a BIN Attack?" (August 2025): [https://www.experian.com/blogs/insights/what-is-a-bin-attack/](https://www.experian.com/blogs/insights/what-is-a-bin-attack/)
10. ClearSale, "False Declines and Ecommerce Fraud Prevention Report": [https://offer.clear.sale/false-declines-ecommerce-fraud-prevention-report](https://offer.clear.sale/false-declines-ecommerce-fraud-prevention-report)

---

### Stripe Radar Pricing Tiers Explained: What Each Tier Really Costs at Scale

Published: 2026-09-08 | https://www.corgilabs.ai/insights/stripe-radar-pricing-change

## Stripe Radar Is Not All Paid, but the Free Tier Has Limits

A U.S. merchant processing 100,000 screened transaction attempts per month on Stripe Radar Standard will pay $5,000 in fraud prevention costs alone. At 500,000, that number hits $25,000. And Standard is the cheapest paid tier.

Stripe restructured Radar in mid-2026, splitting it into four tiers: Lite, Standard, Plus, and Pro. Radar Lite remains available at no additional charge for businesses on standard Stripe Payments pricing. But the features most mid-market merchants depend on, including custom rules, granular risk scores, and manual transaction reviews, now sit behind paid tiers with per-transaction usage meters.

The headline subscription prices ($10, $14, and $20 per month) tell a fraction of the story. Your actual cost depends on how many transaction attempts Radar screens, which tier you need, and whether you choose subscription or pay-as-you-go billing.

## What Each Tier Actually Includes

The four tiers are not minor variations on the same product. Each unlock represents a distinct set of capabilities, and the feature boundaries matter more than the price gaps suggest.

**Radar Lite (included with standard Stripe Payments pricing):** AI-based card-fraud prevention, card-testing protection, and fraud alerts. No custom rules, no custom lists, no granular risk scores, no manual transaction reviews, no account-fraud tools.

**Radar Standard ($10/month or $0.05 per screened transaction):** Out-of-the-box fraud prevention across supported payment methods, fraud analytics, default rules and lists, fraud signals, and categorical risk levels.

**Radar Plus ($14/month or $0.07 per screened transaction):** Everything in Standard, plus 0–99 risk scores, custom rules and lists, backtesting, manual transaction reviews, risk preferences, Adaptive 3D Secure, Smart Refunds, Radar Assistant, and advanced analytics.

**Radar Pro ($20/month or $0.09 per screened transaction + $0.005 per screened customer):** Everything in Plus, plus dynamic risk thresholds and abuse prevention for free-trial, bot, multi-account, account-sharing, and pay-as-you-go abuse.

One detail that catches merchants off guard: the custom rules, risk scores, and manual reviews that many businesses relied on under the previous Radar pricing are **Plus features**, not Standard. A merchant moving from the old free Radar to Standard will not get those capabilities back. They need Plus at $0.07 per screened transaction attempt.

## Two Billing Models, One Critical Distinction

Stripe offers two ways to pay for each paid tier, and the difference is easy to misunderstand.

**Pay-as-you-go** charges from the first screened event. There is no monthly commitment. You pay $0.05 (Standard), $0.07 (Plus), or $0.09 (Pro) for every transaction attempt Radar evaluates.

**Subscription** starts at $10, $14, or $20 per month and includes a defined usage entitlement. Once you exceed that entitlement, overage charges apply.

Here is why this matters: the subscription is not a flat fee that covers unlimited screening. Stripe's subscription policy states that each plan includes a defined number of screens measured across transactions, active accounts, and customers. The monthly fee covers usage up to that allowance.

Simple arithmetic suggests each tier's starting subscription covers roughly 200 transaction screens (dividing $10 by $0.05, $14 by $0.07, or inferring from Pro's structure). That is an illustration, not a confirmed entitlement. But any merchant processing meaningful volume will exceed a few hundred screens within the first days of the month.

For most mid-market merchants, the effective cost is the per-transaction rate, not the subscription headline.

## The Real Cost at Scale

The per-transaction rates compound quickly. Here is what U.S. pay-as-you-go pricing looks like across all three paid tiers:

| Monthly screened transaction attempts | Standard at $0.05 | Plus at $0.07 | Pro at $0.09 |
| --- | --- | --- | --- |
| 10,000 | $500 | $700 | $900 |
| 50,000 | $2,500 | $3,500 | $4,500 |
| 100,000 | $5,000 | $7,000 | $9,000 |
| 500,000 | $25,000 | $35,000 | $45,000 |
| 1,000,000 | $50,000 | $70,000 | $90,000 |

For Pro, add $0.005 per screened customer on top of the transaction rate. A Pro merchant with 50,000 monthly customers and 100,000 screened transaction attempts would pay $9,000 in transaction fees plus $250 in customer-screening fees.

**Annual costs at 100,000 monthly screened transaction attempts:**

- Standard: $60,000/year
- Plus: $84,000/year
- Pro: $108,000/year, plus screened-customer charges

These are pay-as-you-go calculations. A subscription customer's actual invoice depends on the selected entitlement, included usage, negotiated pricing, and overage terms.

## Why "Screened Transaction Attempts" Is the Right Unit

Notice the table uses "screened transaction attempts," not "payments" or "successful transactions." That distinction matters.

Radar can screen successful payment attempts, declined attempts, blocked attempts, and transactions routed to manual review. It screens one-time payments, recurring payments, invoices, and subscription-related payment events.

Consider a card-testing attack. A fraudster submits 5,000 card numbers against your checkout in a single afternoon. Radar blocks every attempt. None result in a successful payment. But each blocked attempt is a screened transaction, and on Standard pay-as-you-go pricing, that attack could cost you up to $250 in screening fees (though Stripe's card-testing protection may intercept the attack before all attempts are individually billed).

For recurring billing, there is a partial relief: the first subscription payment and the first payment after a payment-method change are screened, but merchants can configure how many successful renewal cycles Radar continues to screen. Renewals that skip screening do not incur a charge.

## The January 2027 Deadline: What It Means and What It Doesn't

Affected U.S. merchants who received Stripe's migration notice in 2026 are on a trial of Radar Standard through January 22, 2027. According to the notice, accounts that do not switch to Lite will continue on Standard at $0.05 per screened transaction after the trial ends.

Two important clarifications.

First, this is a pay-as-you-go transition, not automatic enrollment in Stripe's separate $10 monthly subscription. Merchants who do nothing will begin paying per-transaction rates, not a subscription fee.

Second, available rollout notices indicate this applies to affected U.S. accounts. It should not be generalized to every Stripe merchant worldwide. Markets outside the U.S. have their own pricing structures and timelines.

The merchant reaction has been sharp. One user on a community forum wrote: "They've moved me to a 'Standard' Radar plan because it's 'closest' to the free plan I was on. It's free until January 2027, after which they start charging me a per transaction fee, unless I opt out."

Another Reddit r/stripe user put it more bluntly: "I didn't realize I even used Radar and archived the email after seeing the subject line." The frustration is less about the price itself and more about opt-out enrollment with a delayed billing start.

## What Radar Lite Covers and What You Lose

Downgrading to Lite is free. But "free" has boundaries.

Lite includes AI-based card-fraud prevention, card-testing protection, and fraud alerts using Stripe's default fraud logic. For a founder running a straightforward ecommerce store with low fraud rates, that baseline may be sufficient.

Here is what becomes unavailable on Lite:

- **Custom rules and custom lists** (available starting with Plus)
- **Granular 0–99 risk scores** (Plus)
- **Manual transaction reviews** (Plus)
- **Risk preferences** (Plus)
- **Adaptive 3D Secure** (Plus)
- **Backtesting and advanced analytics** (Plus)
- **Account-fraud prevention** (Standard for platforms, Plus for full capability)
- **Abuse prevention** (Pro only)

If you have built custom rules and curated block lists over months or years, those controls become unavailable on Lite. Default lists and rules remain, but merchant-configured logic does not carry over.

For a SaaS company processing thousands of recurring subscriptions on Stripe, losing custom rules and risk scores can mean losing the fraud logic tuned to your specific billing patterns. Recurring transactions look different from one-time purchases, and network-wide models may misinterpret merchant-specific renewal patterns as suspicious activity in some cases.

## Platform and Marketplace Pricing

Platform merchants face a steeper cost structure. Subscription starting prices for platforms:

| Tier | Business starts at | Platform starts at |
| --- | --- | --- |
| Standard | $10/month | $20/month |
| Plus | $14/month | $44/month |
| Pro | $20/month | $70/month |

Standard doubles for platforms. Plus is approximately 3.1 times the business price. Pro is 3.5 times.

Standard for platforms includes basic connected-account risk capabilities: AI account-fraud detection, account-risk levels, default account rules, and manual account reviews. Note that manual **account** reviews (for connected-account risk on Standard) are distinct from manual **transaction** reviews (which require Plus).

For a marketplace with thousands of connected accounts, the combination of per-transaction screening fees and platform subscription pricing can add up to a substantial fraud-prevention line item.

## When Merchant-Specific Models Add Value

Radar combines network-trained AI models, cross-merchant signals, and default or merchant-configured rules to evaluate transaction, account, and customer risk. It sees patterns across millions of Stripe merchants, and that network breadth is powerful for catching known fraud types.

But network-wide models optimize for average behavior across all merchants. If your fraud patterns diverge from the network average, a merchant-specific model captures signals that broad models miss.

In a first-party retrospective evaluation of one Stripe Connect merchant, Corgi Labs analyzed approximately 1.33 million transactions across 19 rolling out-of-time test windows. In the 10 of 19 windows that produced actionable signal, Corgi Model reduced the modeled dispute rate from 0.41% to 0.17%, a 59.5% dispute reduction. The model also recovered 5.6% of good transaction volume that would otherwise have been blocked as false declines.

Corgi Labs estimates the net revenue impact at $508,000 ($525,000 in dispute savings minus $17,000 in false-decline margin loss). Results are merchant-specific and should not be generalized without a prospective evaluation.

The practical question is whether your fraud profile looks like everyone else's or whether your business has unique transaction patterns, high-value orders, subscription billing, or category-specific risk. In the first case, Radar's network training performs well. In the second, merchant-specific models capture what network averages miss.

## A Practical Decision Framework

Your next move depends on three variables: your screened transaction volume, your current fraud rate, and which tier's features your fraud stack actually requires.

1. **Fewer than 10,000 monthly screened transaction attempts with low fraud rates:** Radar Lite is likely sufficient. If you were not actively using custom rules or risk scores, you will not notice their absence. Save the $500/month in Standard pay-as-you-go costs.
2. **10,000 to 100,000 monthly screened transaction attempts:** The $500 to $5,000 monthly Standard cost is real but manageable at this scale. Evaluate whether you need the Plus features (custom rules, risk scores, manual reviews) that many merchants assumed Standard would include. If you need them, Plus at $0.07 per screened transaction is the minimum viable tier.
3. **Over 100,000 monthly screened transaction attempts:** At $5,000/month on Standard and $7,000/month on Plus, fraud prevention becomes a significant budget line. This is the volume range where comparing the total cost of Radar against merchant-specific ML models or alternative scoring providers makes financial sense.
4. **Platform or marketplace operators:** Factor in the higher platform subscription rates and any connected-account screening charges when calculating total cost.
5. **Chargebacks consistently above 0.5%:** In Corgi Labs' experience, merchants consistently above this threshold have often outgrown what any single processor-included tool can handle. Layered approaches, including merchant-specific models, start to show measurable ROI at this level.

Whatever your situation, do not let the January 2027 deadline make the decision for you. Review your Stripe dashboard, audit which Radar features you actually use, and choose a tier deliberately.

If you want to see how a custom model performs on your specific Stripe transaction data with no development work, Corgi Labs runs evaluations on your existing data.

[Book a Demo →](https://www.corgilabs.ai/#book-demo)

## Sources

1. Stripe Radar Pricing. stripe.com/radar/pricing. Accessed August 2026.
2. Stripe Radar. stripe.com/radar. Accessed August 2026.
3. Stripe Docs: How Radar Works. docs.stripe.com/radar/how-radar-works. Accessed August 2026.
4. Stripe Subscription Policy. stripe.com/legal/subscription-policy. Accessed August 2026.
5. Stripe Pricing. stripe.com/pricing. Accessed August 2026.
6. Stripe Blog: Expanding Stripe Radar to Protect More of Your Business. stripe.com/blog/expanding-stripe-radar-to-protect-more-of-your-business. May 2026.
7. Squarespace Forum: New Stripe Radar Plans and Pricing. forum.squarespace.com/topic/349568. July 2026.
8. Reddit r/stripe: Stripe Is About to Start Making You Pay for Your Free Radar Protection. July 2026.
9. Reddit r/stripe: Carding Attempts Getting Charged per Failed Attempt. 2026.
10. Corgi Labs: Custom Fraud Model Evaluation on Top of Stripe Radar Connect. corgilabs.ai/insights/corgi-custom-fraud-model-stripe-radar-connect-2. May 19, 2026.

---

---

### What Is Visa's VAMP Program? A Guide to the 2026 Threshold, Fines, and Compliance

Published: 2026-08-24 | https://www.corgilabs.ai/insights/vamp-for-dummies

## A Merchant at 1.8% Was Compliant in March. By April, They Weren't.

On April 1, 2026, Visa lowered the threshold for its merchant monitoring program by 32%, dropping the line from 2.2% to 1.5% for merchants in the US, Canada, EU, and APAC (CEMEA remains at 2.2%). No grace period for merchants already over the line. The change took effect immediately, reclassifying thousands of previously compliant merchants as "Excessive."

As Justt Co-Founder and Chief Risk Officer Roenen Ben-Ami put it: "A merchant who was comfortably within limits at a 1.8% ratio is now in excess of Visa's threshold."

If you're a CFO or payments leader at a mid-market ecommerce or SaaS company, you've probably heard the acronym VAMP floating around. Maybe your acquirer mentioned it. Maybe your fraud vendor sent a worried email. This guide breaks down what the program actually measures, where the real risks hide, and what you can do about it.

## What VAMP Actually Is

VAMP stands for Visa Acquirer Monitoring Program. Visa launched it in April 2025 to replace two older programs: the Visa Fraud Monitoring Program (VFMP) and the Visa Dispute Monitoring Program (VDMP). Instead of tracking fraud and chargebacks separately, VAMP combines them into a single ratio.

The name is a clue to the real story. Notice it says "Acquirer," not "Merchant." Visa's primary enforcement target is your acquirer (the bank or payment processor that connects you to the Visa network). Your acquirer, in turn, enforces compliance on you.

That distinction matters more than most merchants realize.

VAMP applies only to card-not-present (CNP) Visa transactions, meaning online and digital purchases. In-store, card-present transactions aren't part of the calculation.

## The VAMP Ratio: How Visa Counts

The formula itself is straightforward:

**VAMP Ratio = (TC40 fraud reports + TC15 chargebacks) ÷ TC05 settled CNP transactions**

Three codes drive the math:

- **TC40:** The check-engine light of payments. The cardholder’s bank flags a transaction as suspected fraud early—before any chargeback is filed—so you get a warning instead of an immediate hit.
- **TC15:** The formal undo button. The issuer reverses the charge and pulls the funds back. This is the chargeback that actually lands on your ledger.
- **TC05:** Your settled card-not-present sales is the full odometer reading. Every completed transaction that forms the denominator against which fraud and chargeback rates are measured.

Two features of this ratio regularly ambush even seasoned merchants.

First, it’s a pure headcount, not a dollar scoreboard. A $12 subscription renewal counts exactly the same as a $3,000 luxury handbag. High-volume, lower-AOV merchants therefore carry heavier ratio exposure for every revenue dollar than those selling fewer, larger tickets.

Second, Visa sets a monthly floor. They only start watching once you hit 1,500 combined TC40 and TC15 events in a month. Stay under that threshold and your ratio can look ugly—the program simply doesn’t notice.

## One Transaction, Two Counts

The detail that surprises most payment teams is a single transaction can count twice in the VAMP numerator.

When a cardholder flags a purchase as fraud, the issuer files a TC40 early warning. If that same transaction later becomes a formal chargeback, a TC15 follows. Both events count separately. One fraudulent sale therefore generates two strikes against your ratio.

At the Excessive tier, Visa charges $8 for every TC40 or TC15 event in any month you breach the threshold. A single transaction that produces both costs you $16: $8 for the warning plus $8 for the chargeback.

For a merchant running 60,000 CNP transactions a month, the math is unforgiving. At 2.2% you could absorb 1,320 combined events. At 1.5% that ceiling drops to 900 which is a cut of 420 allowable incidents. Layer on the double-counting, and the real operating margin shrinks even faster.

## Your Acquirer's Threshold Is Tighter Than Yours

This is where VAMP gets genuinely complicated, and where most guides stop too early.

Visa sets the merchant threshold at 1.5%. Your acquirer’s portfolio thresholds sit far lower:

- **Above Standard**: 0.50%
- **Excessive**: 0.70%

Those numbers apply to their entire book of merchants, not your single account. Once an acquirer crosses 0.70%, Visa fines land across the whole portfolio and regulatory scrutiny follows.

The practical result is blunt. Even if you’re running a clean 1.2%—comfortably under the 1.5% merchant line—your acquirer can still restrict the account, demand cash reserves, or terminate the relationship. If their portfolio is drifting toward 0.50%, you become a liability they cannot afford to keep.

As the Forter team noted: "Your acquirer might not be able to afford you if you're too much above 0.7%, no matter how safely below 1.5% you are."

This is why conversations with your acquirer about their risk appetite matter as much as monitoring your own ratio.

## Where to Find Your VAMP Data

You can't manage what you can't measure, and TC40 visibility remains a real gap in the industry.

**Stripe** provides both TC40 and TC15 data. Check Radar for Early Fraud Warnings and the Payments section for disputes.

**Adyen** surfaces TC40 data through the Customer Area under card monitoring programs.

**Braintree and Worldpay** expose TC15 chargeback data but offer limited or no native TC40 visibility.

Pagos has noted that "only Adyen and Stripe provide the TC40 data necessary to calculate the VAMP chargeback rate accurately." If your processor doesn't provide TC40 data, you may need to purchase a separate Verifi feed to see the full picture. Without it, you're monitoring only half your VAMP exposure.

## CE3.0: The Primary Way to Reduce Your Ratio

Compelling Evidence 3.0 is Visa's program for removing TC40 fraud reports from your VAMP ratio. When you successfully dispute a TC40 using CE3.0 evidence, that event is excluded from the numerator.

But CE3.0 has strict requirements:

1. You must capture **Device ID** and **IP address** on the disputed transaction.
2. You need at least **two prior undisputed transactions** from the same cardholder.
3. Those prior transactions must be **between 120 and 365 days old**.
4. At least **two data elements must match** between the disputed and prior transactions (IP address, Device ID, User ID, or shipping address).
5. At least one of the matching elements must be **IP address or Device ID**.

The critical point: you can't build this evidence retroactively. If you aren't already capturing Device ID and IP address on every transaction, you can't file CE3.0 disputes on today's fraud reports.

An important expansion is coming. On October 24, 2026, Visa will allow cross-merchant qualifying transactions and related card credentials to count as prior evidence. This could significantly broaden CE3.0 eligibility, but the practical details for routing cross-merchant data through the acquirer chain are still being worked out.

## Pre-Dispute Tools and the Timing Trap

Beyond CE3.0, pre-dispute resolution tools can keep TC15 chargebacks out of your VAMP ratio. Three tools are worth knowing:

- **RDR (Rapid Dispute Resolution)**: Automatically resolves disputes before they become chargebacks.
- **CDRN (Cardholder Dispute Resolution Network)**: Alerts you to incoming disputes so you can refund before a chargeback is filed.
- **Order Insight**: Shares order details with issuers to help them resolve cardholder inquiries before disputes are initiated.

There's a catch. For a pre-dispute resolution to exclude a TC15 from your VAMP ratio, both the dispute and its resolution must fall within the same calendar month. VAMP evaluates each month in isolation. Resolve a dispute in May that was filed in April, and the TC15 still counts in April's ratio.

Speed matters. The faster you respond to dispute alerts, the more likely you are to resolve within the same month the dispute was filed.

## The False Decline Problem Inside VAMP

Here's the trap that doesn't appear in most VAMP compliance guides: over-blocking legitimate buyers to protect your fraud ratio can actually make the ratio worse.

Remember, your VAMP ratio is a fraction. The numerator is fraud reports and chargebacks. The denominator is settled CNP transactions. When you aggressively decline orders to keep fraud out, you shrink the denominator at the same time. Fewer approved transactions means each fraud event carries more weight in the ratio.

The numbers are unforgiving. False declines cost merchants roughly $50 billion a year in lost revenue, according to Riskified. Globally the damage reaches an estimated $443 billion—about nine times the $48 billion lost to actual fraud (Aite-Novarica).

The better move is dual optimization: grow the denominator by approving more real buyers while shrinking the numerator through sharper fraud detection and CE3.0 evidence. It’s two levers, not one.

## A Practical Compliance Checklist

Whether you're well under the threshold or uncomfortably close, these steps build a defensible VAMP position:

1. **Calculate your current VAMP ratio.** Pull your TC40 and TC15 counts alongside your settled CNP volume. If your processor doesn't provide TC40 data, get a Verifi feed or talk to your acquirer.
2. **Audit your CE3.0 readiness.** Confirm you're capturing Device ID and IP address on every transaction today. Check how many months of historical transaction data you retain with matching elements.
3. **Talk to your acquirer.** Ask directly about their portfolio ratio and their internal merchant thresholds. Understand their risk appetite before they enforce it.
4. **Review your billing descriptors.** Confusing descriptors drive friendly fraud. Roughly 75% of all disputes originate as friendly fraud, according to Chargebacks911 citing Visa data. Clear descriptors reduce the disputes that never should have happened.
5. **Set up real-time monitoring.** Monthly surprises are expensive. Track your ratio weekly or daily so you can respond before month-end calculations lock in.
6. **Check your enumeration exposure.** VAMP includes a separate track for card-testing attacks. Merchants exceeding a 20% enumeration ratio with 300,000 or more enumerated authorization attempts per month trigger separate monitoring.

## What to Do If You're Close to the Line

First-time violators who have been out of VAMP for 12 or more months on a rolling basis get a three-month grace period. As Chief Sales Officer Oscar Bello of Chargeback Gurus explained to the Merchant Risk Council: "First-time violations within a rolling twelve-month period qualify for a three-month grace period during which enrollment will be delayed."

That grace period is a window, not a reprieve. If the ratio remains over threshold when the window closes, enrollment and fines begin. Use it to implement the checklist above aggressively.

If you're between 1.0% and 1.5%, the math is clear: you need fewer events in the numerator, more legitimate transactions in the denominator, or both. This is where understanding whether to fight a chargeback or refund proactively via an alert becomes a financial decision, not a gut call.

As Ben-Ami noted: "The right approach isn't to resolve every alert automatically. It's to understand your own situation: How close are you to your threshold? What does your acquirer expect? What's the win rate on your chargebacks?"

## Where Corgi Labs Fits

VAMP compliance is a visibility problem before it's a fraud problem. You need to see your full ratio in real time, understand which transactions carry the highest risk of generating both TC40 and TC15 events, and approve more real buyers to keep your denominator healthy.

Corgi Labs helps merchants do exactly that. Corgi Intelligence surfaces your VAMP-relevant transaction data in one place, while Corgi Model uses merchant-specific machine learning to block fraud without blocking buyers. The result: a healthier ratio built on better decisions, not blanket declines.

If you want to see where your VAMP ratio stands and what levers you have to improve it, [book a demo →](https://www.corgilabs.ai/#book-demo).

---

## Sources

- Basis Theory, "VAMP 2026: What Changes on April 1 and Who Will Start Pushing on Merchants" (February 18, 2026). [https://blog.basistheory.com/visa-acquirer-monitoring-program-2026-updates](https://blog.basistheory.com/visa-acquirer-monitoring-program-2026-updates)
- Chargebacks911, "Visa Acquirer Monitoring Program: Major Visa Updates in 2026" (February 13, 2026). [https://chargebacks911.com/vamp-enforcement/](https://chargebacks911.com/vamp-enforcement/)
- Chargebacks911, "Compelling Evidence 3.0 Update — April 2026, Explained" (April 16, 2026). [https://chargebacks911.com/compelling-evidence-3-0-update-april-2026/](https://chargebacks911.com/compelling-evidence-3-0-update-april-2026/)
- Chargeback Gurus / MRC, "Stricter VAMP Ratio Thresholds Are Now in Effect. Here's How to Stay Compliant" (April 1, 2026). [https://merchantriskcouncil.org/learning/resource-center/member-news/blog/2026/stricter-vamp-ratio-thresholds-are-now-in-effect-heres-how-to-stay-compliant](https://merchantriskcouncil.org/learning/resource-center/member-news/blog/2026/stricter-vamp-ratio-thresholds-are-now-in-effect-heres-how-to-stay-compliant)
- Corgi Labs, "Visa VAMP 2026: New Merchant Compliance Thresholds" (May 17, 2026). [https://www.corgilabs.ai/insights/vamp-2026-merchant-compliance](https://www.corgilabs.ai/insights/vamp-2026-merchant-compliance)
- Equifax, "The Visa Acquirer Monitoring Program (VAMP): What New Rules Mean for Acquirers and Merchants" (February 5, 2026). [https://www.equifax.com/newsroom/all-news/-/story/the-visa-acquirer-monitoring-program-vamp-what-new-rules-mean-for-acquirers-and-merchants/](https://www.equifax.com/newsroom/all-news/-/story/the-visa-acquirer-monitoring-program-vamp-what-new-rules-mean-for-acquirers-and-merchants/)
- Forter, "Visa's Updated VAMP Program: What Merchants Need to Know" (March 25, 2026). [https://www.forter.com/blog/visas-updated-vamp-program/](https://www.forter.com/blog/visas-updated-vamp-program/)
- Justt, "Visa VAMP's Tighter Threshold Is Now Live: What Merchants Need to Know" (March 31, 2026). [https://justt.ai/blog/visa-vamp-threshold-changes-april-2026/](https://justt.ai/blog/visa-vamp-threshold-changes-april-2026/)
- Pagos, "Monitor Your VAMP Risk Exposure with Pagos" (July 30, 2025). [https://pagos.ai/blog/monitor-your-vamp-risk-exposure-with-pagos](https://pagos.ai/blog/monitor-your-vamp-risk-exposure-with-pagos)
- Riskified, "False Declines: What They Cost You and How to Reduce Them" (2025), citing Aite-Novarica Group for global $443B estimate. [https://www.riskified.com/learning/ecommerce-checkout-optimization/false-declines/](https://www.riskified.com/learning/ecommerce-checkout-optimization/false-declines/)
- Stripe Documentation, "Dispute and fraud card monitoring programs" (2026). [https://docs.stripe.com/disputes/monitoring-programs](https://docs.stripe.com/disputes/monitoring-programs)
- Visa, "Compelling Evidence 3.0 Merchant Readiness" (March 2023). [https://usa.visa.com/content/dam/VCOM/regional/na/us/support-legal/documents/compelling-evidence-3-0-merchant-readiness-mar2023.pdf](https://usa.visa.com/content/dam/VCOM/regional/na/us/support-legal/documents/compelling-evidence-3-0-merchant-readiness-mar2023.pdf)
- Visa Business News AI16011, Updates to Remedy Rule (CE3.0) for Dispute Condition 10.4 (January 29, 2026). Cited in Forter, March 2026.

---

### Why One Approval Rate Can't Explain Your Hotel Bookings

Published: 2026-08-10 | https://www.corgilabs.ai/insights/hotel-booking-platform-approval-rate

## The card said yes. The hotel said no.

Picture a guest booking a $620 prepaid room through your platform. The card is approved, the money moves, and your payment dashboard logs a win. Then the supplier comes back: that rate sold out an hour ago.

Now the guest is calling support about a charge with no room attached, and your payment numbers insist nothing went wrong.

The reverse happens too. A guest reserves a pay-at-the-hotel rate, hands over a card only as a guarantee, and walks away with a perfectly valid confirmation. No charge appears at checkout, so a payment-only dashboard counts the booking as nothing at all.

**One approval rate can't describe both stories.** You need two views that talk to each other: what happened to the payment, and what happened to the reservation. Both examples here are illustrations, but the gap they describe is real on every hotel platform.

## One checkout, four ways the money can move

To the guest, your checkout looks like one storefront. Behind it, the money takes different paths depending on the property, the supplier, the rate, and the cancellation policy.

Four setups show up across the industry:

- Your platform charges the guest directly and owns the transaction.
- The hotel charges the guest at check-in.
- Your platform charges the guest, then pays the supplier with a single-use virtual card.
- Nobody charges anything at checkout. The card is stored to guarantee the booking.

The industry term for that first case is **merchant of record**: the company whose name sits on the charge and who answers for it. On a hotel platform, that role can change from one booking to the next.

This isn't theoretical. Expedia Group's developer documentation splits bookings into Expedia Collect and Property Collect. Under Property Collect, the hotel may preauthorize the card, run a small validation charge, take a deposit, or charge a cancellation penalty before the guest ever arrives.

Booking.com documents another version. A travel platform charges the traveler, generates a virtual card, and Booking.com charges that card on the reservation's schedule.

Different setups mean different companies make the payment decision, at different times, in different systems. When a booking fails, the explanation lives wherever the decision was made.

## Follow the booking from click to check-in

Before touching a single fraud rule, write down the full journey a booking takes:

1. The guest picks a rate, which locks the price, currency, payment timing, and cancellation terms.
2. Your platform determines who will charge the guest, and when.
3. The guest pays, or hands over a card as a guarantee.
4. Your fraud checks, any extra verification, and the guest's bank each say yes or no.
5. Your platform sends the reservation to the supplier.
6. The supplier accepts it, rejects it, or comes back with a new price.
7. The confirmation reaches the guest and the property.
8. The booking survives until check-in, or gets canceled along the way.
9. Refunds, payouts, and any disputes settle over the following weeks.

At each step, record who acted, when, and why. Without that trail, every lost booking gets filed under "declined," even when no bank ever said no.

## "Declined" is doing too much work

A payment can fail because your own rules blocked it, because the guest's bank turned it down, because the guest gave up mid-verification, or because a request timed out. Those are payment problems, and each has a different fix.

A booking can fail for none of those reasons. The supplier rejects the rate, the reservation never arrives, the confirmation fails to send, or the property cancels after saying yes.

Expedia's documentation calls out that last case directly. Properties sometimes cancel a confirmed booking, often over an invalid card, and a broken notification feed can keep the guest from ever finding out.

An approved payment answers exactly one question: did the charge go through? It says nothing about whether a room is waiting.

## Compare bookings that are actually alike

Averages hide problems. Prepaid rooms and pay-at-the-hotel rooms will never show the same checkout numbers, because one charges money today and the other charges nothing for weeks. Mix them together and a healthy business can look broken.

So split your bookings into groups that behave the same way:

- Who charges the guest, and when
- Which supplier provides the room
- How far ahead the booking was made
- Whether the trip crosses borders
- Which currencies are involved
- Whether the guest is new or returning
- Whether the guest completed extra verification

Stick to data you lawfully collect, and give traveler, device, and location details proper access controls and retention limits.

Then attach the reservation outcomes to each group. Did the supplier accept? Did the confirmation land? Was the room still there at check-in?

## Watch the gaps between your systems

The most revealing numbers sit where your payment records and your reservation records disagree. Two deserve their own names:

**Paid but unconfirmed.** The guest's money moved, but no usable reservation exists. This is the charge-with-no-room case, and it needs a clear owner and a recovery process.

**Confirmed but unresolved.** A reservation is live, but the payment behind it hasn't settled the way it should. Different risk, same need for an owner.

Around those, track how often payments get approved, how often suppliers confirm, how often confirmations reach guests, and how refunds and disputes settle out over time. No single number gets a veto. A better approval rate isn't a win if supplier confirmations drop at the same time.

## Change one thing, then check both sides

When one group of bookings looks unhealthy, resist the urge to loosen rules broadly. Same-day bookings can be great customers, but urgency alone doesn't tell you who's paying, whether the supplier has the room, or whether the guest is who they claim.

Pick one narrow change instead. For example, adjust one rule for returning guests on devices you've seen before. Then watch the whole chain: approvals, supplier confirmations, check-ins, refunds, and disputes once they've had time to arrive.

Expand only if both the payment side and the booking side stay healthy.

## See the half of the picture that lives in Stripe

If your platform processes guest payments on Stripe, that's the half Corgi Labs can help you read: which payments your rules blocked, which ones banks declined, and where patterns in your transaction data point to lost revenue. Corgi Intelligence surfaces those payment decisions. Your booking and supplier events complete the story.

That boundary is worth keeping honest. It stops a payment fix from taking credit for a room that never confirmed, and it stops a supplier failure from being blamed on a bank.

Curious where your booking payments actually stop? [Book a Demo](https://www.corgilabs.ai/#book-demo) and we'll dig into your payments data with you.

## Sources

- Expedia Group Developer Hub. **Property Collect Payments.** [https://developers.expediagroup.com/rapid/lodging/booking/property-collect](https://developers.expediagroup.com/rapid/lodging/booking/property-collect)
- Expedia Group Developer Hub. **Invoices and Booking Receipts.** [https://developers.expediagroup.com/rapid/lodging/manage-booking/booking-receipts](https://developers.expediagroup.com/rapid/lodging/manage-booking/booking-receipts)
- Booking.com Developers. **Partners Collect the Payment (VCC Flow).** [https://developers.booking.com/demand/docs/payments/models/partner-collects](https://developers.booking.com/demand/docs/payments/models/partner-collects)
- Booking.com Developers. **Understanding Payouts.** [https://developers.booking.com/connectivity/docs/payments-by-booking-onboarding-api/understanding-payouts](https://developers.booking.com/connectivity/docs/payments-by-booking-onboarding-api/understanding-payouts)

---

### When Real Travelers Look Like Fraud (and What to Do About It)

Published: 2026-08-07 | https://www.corgilabs.ai/insights/last-minute-travel-bookings-false-declines

## The $1,400 flight that sets off every alarm

Ten hours before takeoff, a longtime customer books a $1,400 international flight for a family member. The name on the ticket doesn't match the card, and the card, the airport Wi-Fi, and the destination all point to different countries. To a fraud filter, this looks terrible.

It's also a completely ordinary travel purchase. The example is invented, but the pattern is one every travel business recognizes.

When a rule blocks a real customer like this, the industry calls it a **false decline**: a legitimate payment stopped because it looked risky. Before you can fix false declines, though, you have to answer a more basic question. Who actually said no?

## Booking late is normal now

Waiting until the last minute isn't fringe behavior. Expedia Group reported that in the second quarter of 2025, the share of searches for trips zero to 13 days out grew 20% quarter over quarter, with international searches in that window up 30%.

Those numbers describe searches, not completed bookings or fraud, and they cover one season. But they make a simple point: booking close to departure is something real customers do all the time.

Travel businesses aren't wrong to be careful, either. Back in 2019, IATA estimated that card-not-present fraud (fraud on purchases where no physical card is present) cost airlines close to $1 billion a year. That figure is dated and says nothing about how many good customers get blocked, but the risk behind it is real.

So the mistake is treating urgency as a verdict in either direction. A last-minute booking isn't proof of fraud, and it isn't proof of innocence. It's a segment worth measuring on its own.

## Why good travelers trip the wire

Travel purchases naturally stack up signals that look suspicious one at a time:

- A bigger charge than your typical order
- A card, billing address, and destination in three different countries
- A new device, or airport Wi-Fi
- Someone paying for someone else's trip
- Several travelers or flight segments on one order
- A departure only hours away

Real fraud can look like this too. That overlap is exactly why a single yes-or-no threshold throws away information.

The card networks know it. EMVCo, the standards body behind card security, worked with IATA and Amadeus on a way for travel businesses to pass ticket, itinerary, and traveler details into the bank's verification process. It doesn't guarantee approvals. Its existence simply confirms that travel purchases need travel context to be judged fairly.

A payer who isn't the traveler is a good example. On its own, that mismatch adds risk. Next to an established account, past successful trips, a familiar device, and a completed verification step, it reads very differently.

## Find out who said no

When a booking dies at payment, one of several things happened, and Stripe's documentation separates them for good reason. Your own fraud rules blocked it, the customer's bank declined it, a technical call failed, or the customer gave up. Each has a different fix, so one blended decline rate points your team at the wrong problem.

Walk the funnel in order:

1. The customer reaches the payment page.
2. They attempt to pay.
3. Your rules, risk model, or review team weigh in.
4. Any extra verification step completes, fails, or gets abandoned.
5. The bank approves or declines.
6. The booking confirms, or a technical error eats it.
7. Weeks later, the real outcome arrives: a completed trip, a refund, a cancellation, or a dispute.

Keep the raw record of who decided what at each step. A rule change can't fix a bank decline, and checkout polish can't fix an overzealous rule.

## Compare like with like

Once you can tell the failure types apart, group similar bookings and compare them. Start with how far ahead people book. Then add whatever your business lawfully tracks: order size, domestic or international, new or returning customer, device history, verification results, and who's paying for whom.

Traveler and location data is sensitive, so keep collection minimal, access controlled, and retention short.

Here's an invented example of what the comparison looks like. Say bookings made within 24 hours of departure get blocked by your rules 12% of the time, while bookings made a month ahead get blocked 3% of the time. That 9-point gap is a lead, not a conviction.

The follow-up questions do the real work. Were the blocked customers new or returning? Did they finish verification? Did they come back and pay another way? And months later, how many of the approved last-minute bookings actually turned into disputes?

## Give the answers time to arrive

An approved booking isn't a proven-good booking until disputes, refunds, and cancellations have had time to show up. How long that takes depends on your product, your routes, and your customers. There's no universal waiting period.

Blocked payments are harder still. You can't watch what would have happened to a booking that never existed. Later successful attempts, support recoveries, manual reviews, and carefully governed holdout tests give you evidence, never certainty.

That's why no single number settles the question. A Merchant Risk Council session for its 2026 conference lists approval rate, false declines, fraud rate, precision, and review workload as measures that only work together, and it's cross-industry guidance rather than a travel benchmark. Watch recovered revenue and fraud at the same time, always.

## Change one control at a time

When a group of bookings looks over-blocked, make one narrow change and hold everything else still. Stripe's guidance points the same way: review the history a rule would have matched before creating it, and don't force extra verification on everyone, because blanket verification costs you sales.

A working sequence:

1. Preview what the change would have caught historically.
2. Define the one rule, model, or verification change you're testing.
3. Ship it, and touch nothing else.
4. Track approvals, completed bookings, verification completion, and, once they've had time to arrive, disputes and refunds.
5. Expand only if both revenue and fraud stay inside your tolerance.

Skip universal thresholds. A returning customer on a known device isn't the same risk as a brand-new account, even when both book the same flight at the same hour.

## When your own data becomes the answer

Generic rules judge your travelers by everyone else's fraud. Once you have enough transaction history and enough settled outcomes, your own patterns can do better, because they show what your legitimate last-minute customers actually look like.

Corgi Labs builds that kind of merchant-specific analysis and decisioning inside your existing Stripe setup. The goal isn't to declare last-minute travel safe. It's to show you where your own controls block real buyers, with the fraud numbers kept in plain view.

Want to see what your last-minute segment is really doing? [Book a Demo](https://www.corgilabs.ai/#book-demo).

## Sources

- Expedia Group. **Travel trends Q3 2025: global search and booking insights for travellers.** August 13, 2025. [https://partner.expediagroup.com/en-gb/resources/blog/q3-2025-travel-trends-insights](https://partner.expediagroup.com/en-gb/resources/blog/q3-2025-travel-trends-insights)
- International Air Transport Association. **Fraud prevention: Strengthening the defences.** March 6, 2019. [https://airlines.iata.org/2019/03/06/fraud-prevention-strengthening-defences](https://airlines.iata.org/2019/03/06/fraud-prevention-strengthening-defences)
- EMVCo. **Supporting the Travel Sector's Fight Against Transaction Fraud.** [https://www.emvco.com/knowledge-hub/supporting-the-travel-sectors-fight-against-transaction-fraud/](https://www.emvco.com/knowledge-hub/supporting-the-travel-sectors-fight-against-transaction-fraud/)
- EMVCo. **Travel Industry Message Extension.** [https://www.emvco.com/dynamic/emv-3-d-secure-whitepaper-v2/3ds-message-extensions/travel-industry-message-extension/](https://www.emvco.com/dynamic/emv-3-d-secure-whitepaper-v2/3ds-message-extensions/travel-industry-message-extension/)
- Stripe. **Fraud prevention rules.** [https://docs.stripe.com/radar/rules](https://docs.stripe.com/radar/rules)
- Stripe. **Radar for Platforms.** [https://docs.stripe.com/radar/radar-for-platforms](https://docs.stripe.com/radar/radar-for-platforms)
- Merchant Risk Council. **Don't Say Maybe: Refining Your Decision Accuracy for a New Era of Fraud.** March 18, 2026. [https://merchantriskcouncil.org/learning/resource-center/events/vegas/26/dont-say-maybe-refining-your-decision-accuracy-for-a-new-era-of-fraud](https://merchantriskcouncil.org/learning/resource-center/events/vegas/26/dont-say-maybe-refining-your-decision-accuracy-for-a-new-era-of-fraud)

---

### AI Agents Are Learning to Buy. What About Fraud?

Published: 2026-07-28 | https://www.corgilabs.ai/insights/agentic-commerce-fraud

## The customer who never gets emotional

Last holiday season, AI agents placed $262 billion in online orders by Salesforce's count. Somewhere in that number, an agent compared prices across dozens of stores, picked a merchant, and checked out at 4am in under a second. No hesitation, no browsing, none of the messy human signals your fraud stack was trained to read.

That customer is not going away. The question I keep hearing from founders is how agents will pay. The question almost nobody asks is the one I care about: what does fraud look like when they do?

## The rails got built in seven months

The payments industry moved on this faster than on anything in recent memory. Four separate agent-payment frameworks shipped between April and October 2025:

- **Mastercard Agent Pay** (April): Agentic Tokens that bind a card credential to a specific agent, merchant scope, and consent policy.
- **Agentic Commerce Protocol** (September): the open standard from Stripe and OpenAI behind Instant Checkout in ChatGPT.
- **Google AP2** (September): an open protocol both card networks joined.
- **Visa Trusted Agent Protocol** (October): signed agent credentials and intent passed with the transaction.

Each answers "how does an agent pay?" at a different layer of the stack. Notice what's missing from that sentence: none of this, by itself, answers what happens to fraud detection when the buyer stops being human.

And the traffic is already here. Adobe's analytics show AI-driven visits to US retail sites up 393% year over year in early 2026, converting better than traditional channels. This stopped being a thought experiment about a year ago.

## Your fraud model has never met an agent

Fraud models learn what "normal" looks like from years of human behavior: session patterns, time on page, typing rhythms, the 1am impulse buy. An agent breaks nearly all of those signals at once. It moves too fast, too cleanly, and too consistently, which is exactly what fraud models were taught to flag.

Machine learning people call this distribution drift: the traffic the model scores stops resembling the traffic it trained on. In practice it means a model that was excellent against human fraudsters starts making confident mistakes in both directions.

The uncomfortable part is how thin the line is. DataDome logged nearly 8 billion AI agent requests in the first two months of 2026, and separate analysis puts the behavioral gap between legitimate automation and fraud at about half a percentage point. Blocking everything that looks automated used to be a safe default. Now it means declining real buyers who happen to shop through an agent, and if you read our last post, you know what false declines cost.

## Machine versus machine might actually be easier

Here's the counterintuitive thing I keep coming back to: fraud detection against machines could end up easier than against humans.

Any agent transacting at scale has an underlying probability distribution. It behaves consistently, because it's software. Humans don't. A guy gets into a fight with his girlfriend in the morning and buys something expensive by noon, and no model saw it coming.

Consistency is something you can model tightly, and deviation from consistency becomes a clean fraud signal. It's early, and this thesis still has to be borne out at scale, but the shape of it is promising. The chaos was always the hard part.

## The new fraud patterns are already here

The attackers didn't wait for the standards to settle. Stripe has framed its new Radar defenses around a threat it says is already real: a few thousand humans operating millions of agents to steal payment tokens from AI products. Card testing was always automated; now the automation reasons, adapts, and imitates legitimate agents.

Impersonation is measurable today. DataDome found about 2.4% of traffic claiming to be PerplexityBot was spoofed, with millions of forged requests wearing other agents' names.

And a new dispute category is emerging: "the AI bought it without my permission." That's friendly fraud in a new costume, and sometimes it's even true, which makes consent records suddenly load-bearing. Subscription merchants already know how this movie goes.

## Scoped tokens are the early answer

The common thread across every framework is replacing inference with attestation. Instead of your fraud model guessing who's behind a checkout, the payment itself carries proof.

Stripe's shared payment token is a good example of the mechanism: the agent never holds raw card credentials, and the token is scoped to one merchant and one cart total. Stolen, it's nearly worthless. Mastercard's Agentic Tokens and Visa's signed intent payloads make the same move at the network layer: identity and consent travel with the transaction instead of being reconstructed after the fact.

For merchants, that turns "is this bot good or bad?" from a behavioral guess into a credential check, with fraud models focusing on what credentials can't prove.

## What to do before your first agent customer

You likely already had one. Four things worth doing this quarter:

1. Measure what share of your checkout traffic is agent-driven, even roughly. You can't reason about a segment you haven't sized.
2. Stop hard-blocking known agents by default, and classify them instead. A blanket bot rule now declines real revenue.
3. Watch your dispute reasons for "I didn't authorize my agent." Keep consent and intent records where you can get them.
4. Ask your payment provider what agent identification they support today, such as Stripe's shared payment tokens, and what signals they pass you.

This is the frontier we're building on: we're already working with Stripe's shared payment tokens in beta to understand how agent traffic differs platform to platform, and Corgi Model is trained on your transactions, so as your traffic shifts toward agents, the model shifts with it instead of defending a world that no longer exists. Corgi Intelligence shows you the funnel either way, humans and agents alike.

The buyers are changing faster than the defenses. Being early here is cheap. Being late won't be.

[Book a Demo →](https://www.corgilabs.ai/#book-demo)

## Sources

- Salesforce holiday shopping data via commercetools, "Agentic Commerce Stats 2026: Enterprise Guide" [https://commercetools.com/blog/agentic-commerce-stats-enterprise-guide](https://commercetools.com/blog/agentic-commerce-stats-enterprise-guide)
- Adobe Analytics AI traffic data via Elogic, "ChatGPT Commerce & Agentic Shopping Statistics 2026" [https://elogic.co/blog/chatgpt-commerce-statistics/](https://elogic.co/blog/chatgpt-commerce-statistics/)
- Stripe, "Stripe powers Instant Checkout in ChatGPT and releases Agentic Commerce Protocol codeveloped with OpenAI" [https://stripe.com/newsroom/news/stripe-openai-instant-checkout](https://stripe.com/newsroom/news/stripe-openai-instant-checkout)
- Stripe, "Introducing our agentic commerce solutions" [https://stripe.com/blog/introducing-our-agentic-commerce-solutions](https://stripe.com/blog/introducing-our-agentic-commerce-solutions)
- Stripe Documentation, "Shared payment tokens" [https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens](https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens)
- Visa, "Visa Unveils Trusted Agent Protocol for AI Commerce" [https://corporate.visa.com/en/sites/visa-perspectives/newsroom/visa-unveils-trusted-agent-protocol-for-ai-commerce.html](https://corporate.visa.com/en/sites/visa-perspectives/newsroom/visa-unveils-trusted-agent-protocol-for-ai-commerce.html)
- Stellagent, "Mastercard Agent Pay Explained: Agentic Tokens and Verifiable Intent for AI Agent Payments" [https://stellagent.ai/insights/mastercard-agent-pay-agentic-tokens](https://stellagent.ai/insights/mastercard-agent-pay-agentic-tokens)
- DataDome, "The Agentic Threats & Industry Trends Defining 2026 (So Far)" [https://datadome.co/threat-research/agentic-threats-and-industry-trends-defining-2026-so-far/](https://datadome.co/threat-research/agentic-threats-and-industry-trends-defining-2026-so-far/)
- PPC Land, "AI agents are now buying things - and fraud looks identical" [https://ppc.land/ai-agents-are-now-buying-things-and-fraud-looks-identical/](https://ppc.land/ai-agents-are-now-buying-things-and-fraud-looks-identical/)
- Saif's talk at the Founder Meetup, San Francisco, May 2026 (internal recording)

---

### How to Calculate Your VAMP Ratio: A Monthly Self-Audit Checklist

Published: 2026-07-27 | https://www.corgilabs.ai/insights/vamp-self-audit-checklist

## You Probably Know Your Chargeback Rate. But Do You Know Your VAMP Ratio?

A June 2026 Chargebacks911 survey of enterprise merchants found that only 26.8% actively monitor TC40 fraud records. That means roughly three out of four payment operations teams are calculating their fraud exposure with incomplete data.

And they're doing it under a tighter threshold than ever before.

On April 1, 2026, Visa reduced the merchant "Excessive" threshold in its Acquirer Monitoring Program (VAMP) from 2.2% to 1.5%, a 32% reduction in the margin for error. There is no warning tier. There is no "Above Standard" level for merchants. You are either below 1.5% or you are in the Excessive category, facing $8 fines per violation.

Oscar Bello, Chief Sales Officer at Chargeback Gurus, put it plainly: "That adjustment narrows the margin for error and increases the likelihood that more businesses will fall into enforcement categories if their current practices remain unchanged."

This article walks you through the exact VAMP formula, shows you where to pull the numbers from your payment processor, and gives you a monthly checklist to catch problems before Visa (or your acquirer) does.

## The VAMP Formula: Simple Math, Hidden Complexity

The VAMP ratio looks straightforward on paper:

**VAMP Ratio = (TC40 Fraud Reports + TC15 Disputes) ÷ TC05 Settled CNP Transactions**

Three numbers. One division. But each component carries nuance that changes your result.

**TC40 (Fraud Reports):** These are early fraud warnings. When a cardholder tells their issuing bank a transaction is fraudulent, the issuer files a TC40 with Visa. No chargeback has been initiated yet. The issuer is simply flagging the transaction. You may never hear about it unless you actively check.

**TC15 (Disputes/Chargebacks):** These are formal chargebacks. The cardholder has disputed the charge, and the issuer has reversed the funds. Most payment teams track these closely because they hit your balance directly.

**TC05 (Settled CNP Transactions):** This is your denominator. It includes all card-not-present transactions that settled through VisaNet in the measurement month, both domestic and cross-border.

Two details matter here. First, this is a **count-based** calculation, not dollar-based. A $9 dispute counts exactly the same as a $9,000 dispute. Second, there is a volume floor: Visa only flags merchants whose combined TC40 plus TC15 count exceeds 1,500 per month (except in the CEMEA region, where the threshold is 150 disputes plus $75,000 in volume).

## A Worked Example (With the Trap Built In)

Let's run the numbers with a realistic scenario.

Suppose your company settled 10,000 Visa CNP transactions last month. Your dashboard shows 70 chargebacks, and your Radar or fraud alerts show 120 early fraud warnings. At first glance, you might calculate:

- Chargeback rate: 70 ÷ 10,000 = **0.70%**
- Fraud report rate: 120 ÷ 10,000 = **1.20%**

Both numbers look manageable. But VAMP combines them:

**(120 + 70) ÷ 10,000 = 1.90%**

That puts you squarely in the Excessive tier, above the 1.5% threshold.

What most merchants miss, the double-counting trap.

## The Double-Counting Trap

A single fraudulent transaction can generate **both** a TC40 and a TC15. The issuer files the fraud report (TC40) when the cardholder first complains. Then, if the dispute proceeds, the same transaction produces a chargeback (TC15). Both land in the VAMP numerator.

As Chargeback Gurus explains: "VAMP ratio effectively double-counts fraud-related disputes, and counts TC40 reports for transactions that were too small for the issuing bank to bother with a chargeback. This means most merchants see much higher ratios under the VAMP formula."

Metzli Sampat of ChargebackStop illustrates this clearly: "Imagine you have 10,000 settled transactions, 120 TC40 fraud reports and 70 chargebacks. Visa would calculate this as (120 + 70) ÷ 10,000 = 1.9%. But what if 50 of those 70 chargebacks actually originated from the same fraud reports?"

In that scenario, only 140 unique fraud events produced 190 VAMP-numerator entries. Your "true" unique fraud rate would be 1.4%, below threshold, but VAMP reports 1.9%.

**Friendly fraud amplifies this problem.** Visa data indicates that approximately 75% of all disputes originate as friendly fraud, where a legitimate cardholder falsely claims fraud to obtain a refund. When this happens, the issuer files a TC40, which typically becomes a TC15 as well. Both count against your VAMP ratio for the same underlying event.

## Where to Find Your Data (By Processor)

You cannot calculate your VAMP ratio from a single dashboard screen. Here's where each data point lives in the major processors.

### Stripe

Stripe provides three separate locations for the data you need:

1. **TC15 (Chargebacks):** Navigate to **Payments → Disputes** in your Stripe Dashboard. Filter for Visa disputes in the measurement month.
2. **TC40 (Early Fraud Warnings):** Navigate to **Radar → Early Fraud Warnings**. These are separate from disputes and easy to miss if you only check the Disputes tab.
3. **VAMP Dashboard:** Stripe offers a dedicated VAMP view accessible from **Radar → Card Brand Monitoring Programs → VAMP** in your Stripe Dashboard (navigation path may vary by account configuration).

For Stripe Sigma or Data Pipeline users, you can query the `early_fraud_warnings` and `disputes` tables and join them against settled charges for a precise monthly count (verify exact table names in your Stripe Sigma schema, as names may vary by configuration). Most mid-market merchants without Sigma access should use the VAMP dashboard for estimates and manually cross-reference the two report locations.

### Braintree

- **TC40 (Fraud Reports):** Available via SFTP data feeds. Check with your Braintree account team if you haven't enabled this.
- **TC15 (Chargebacks):** Use the Dispute reports filtered for open Visa chargebacks. Note that Braintree's documentation states the full TC15 log "isn't available at this time" via SFTP, so the Dispute reports are your best approximation.
- **TC05 (Settled transactions):** Pull from your transaction reports filtered for settled Visa CNP transactions.

### Adyen

Navigate to **Insights → Risk & dispute management → Card monitoring programs**. Adyen surfaces your VAMP ratio and projections directly in this view, consolidating the TC40, TC15, and TC05 data into a single dashboard.

### Other Processors (Worldpay, Checkout.com, etc.)

If your processor doesn't offer a built-in VAMP dashboard, request your monthly TC40, TC15, and TC05 reports directly from your acquirer. You are entitled to this data, and most acquirers can provide it within a standard reporting cycle.

## The Acquirer Squeeze: Why 0.5% Matters More Than 1.5%

Your acquirer has its own VAMP problem, and their thresholds are dramatically tighter than yours.

Visa enforces two acquirer-level thresholds:

- **0.50% (Above Standard):** $4 per violation fines, enforced since January 1, 2026
- **0.70% (Excessive):** $8 per violation fines

These are portfolio-level calculations. Your acquirer's VAMP ratio aggregates every merchant on their platform. If a handful of high-ratio merchants push the portfolio above 0.50%, the acquirer pays fines on every excess violation across their entire book.

**This creates a math problem your acquirer will solve at your expense.**

Industry observers report that payment providers are already terminating merchants with historically acceptable rates of 0.8% to 1.0%, well below Visa's 1.5% merchant threshold. An acquirer whose portfolio sits at 0.48% cannot afford to keep merchants running at 1.2%, even though those merchants are technically compliant with their own threshold.

First-time merchant violators do get a three-month grace period within a rolling 12-month window before fines begin. But your acquirer's grace period for their own portfolio ratio may not extend to you. By the time Visa notifies you directly, your acquirer may have already decided to restrict your account.

The takeaway: don't benchmark yourself against 1.5%. Ask your acquirer what internal threshold they expect from merchants on their portfolio.

## What Gets Excluded: CE3.0 and RDR

Not every TC40 or TC15 has to count against your ratio. Visa provides three exclusion mechanisms that can reduce your VAMP numerator.

### Rapid Dispute Resolution (RDR)

Disputes resolved through RDR before Visa's monthly data cutoff are excluded from your TC15 count. RDR automates the resolution of qualifying disputes by issuing a refund before the chargeback is formally processed.

**Important caveat:** RDR removes the TC15 (dispute) from your VAMP numerator, but any TC40 fraud report already filed by the issuer for that transaction still counts. RDR is most effective when the issuer has not yet filed a TC40 at the time of dispute resolution, which typically requires very fast response to pre-dispute alerts.

### Verifi CDRN (Chargeback Dispute Resolution Network)

Similar to RDR, alerts resolved through the CDRN network before the monthly extract can be excluded.

### Compelling Evidence 3.0 (CE3.0)

CE3.0 allows you to submit historical transaction data proving a disputed transaction is legitimate. If your evidence qualifies, the TC40 or chargeback is excluded from your VAMP ratio.

Effective April 18, 2026, Visa expanded CE3.0 to cover **non-disputed TC40s**. Previously, if an issuer filed a TC40 on a $15 transaction but never initiated a formal chargeback (because the transaction value was too low to justify processing costs), that TC40 still counted against your VAMP ratio with no way to contest it. Now, you can submit historical transaction evidence to prove the transaction's legitimacy and exclude the TC40.

**Note on CE3.0 costs:** Visa has signaled that a fee may be introduced for successful CE3.0 qualifications. Confirm the current fee structure with your acquirer or chargeback management provider before building a high-volume CE3.0 submission workflow.

### The Timing Caveat

All three exclusion mechanisms come with a critical timing clause. Visa's fact sheet specifies that exclusions are "contingent on the timing of the data extract." If a TC40 is resolved via CE3.0 or a dispute is handled via RDR **after** the monthly data cutoff, it may still appear in your VAMP numerator for that month.

Speed matters. Set up automated RDR rules and prepare CE3.0 evidence packages proactively so resolutions land before the monthly extract.

## Action Plan: What to Do If You're Approaching 1.5%

If your self-audit reveals a VAMP ratio above 1.0%, or trending upward month over month, take these steps now.

### 1. Get Your Baseline Right

Pull three months of TC40, TC15, and TC05 data from your processor. Calculate your ratio for each month. Look for trends, not just snapshots. A single bad month may be an anomaly. Three consecutive months of increases signals a structural problem.

### 2. Quantify the Double-Count

Cross-reference your TC40 and TC15 records to identify transactions that appear in both. This tells you the gap between your "reported" VAMP ratio and your "unique event" ratio. You cannot change how Visa counts, but understanding the overlap helps you prioritize which fraud vectors to address first.

### 3. Audit Your Billing Descriptors

Unclear billing descriptors are one of the most common drivers of friendly fraud. When customers don't recognize a charge, they call their bank instead of you. Review your descriptor for clarity:

- Does it include your company name (as customers know it)?
- Does it include a phone number or URL for support?
- Is it consistent across all product lines?

### 4. Tighten Your Refund and Cancellation Flows

Make it easier for customers to get a refund from you than from their bank. Every dispute that becomes a self-service refund is one fewer TC15 in your numerator. For subscription businesses, this means:

- Clear cancellation flows (no dark patterns)
- Proactive dunning emails before retry failures
- Transparent billing schedules

### 5. Enable RDR and CDRN

If you haven't set up automated dispute resolution through RDR or CDRN, do it now. These tools resolve qualifying disputes before they hit your VAMP numerator. Remember: **RDR removes the TC15, but any associated TC40 already filed still counts.** Pair RDR with fast pre-dispute alert response for maximum impact.

### 6. Build Your CE3.0 Evidence Library

Start collecting the historical transaction data CE3.0 requires:

- Device fingerprints and IP addresses for prior successful orders
- Shipping confirmation and delivery tracking from previous transactions
- Account login history showing consistent customer activity

Having this data ready means faster submissions, which means exclusions land before the monthly data cutoff.

### 7. Monitor Weekly, Not Monthly

A monthly check gives you one data point. By the time you spot a spike, you've already reported a bad month to Visa. Move to weekly VAMP ratio estimates (even rough ones) so you can catch anomalies while you still have time to act.

## Your Monthly VAMP Self-Audit Checklist

Use this checklist at the start of each month to track your exposure.

**Data Collection:**

- Pull TC40 count from your fraud alerts or early warning reports
- Pull TC15 count from your disputes/chargebacks reports (Visa only)
- Pull TC05 count of settled Visa CNP transactions
- Calculate: (TC40 + TC15) ÷ TC05 = your VAMP ratio

**Threshold Check:**

- Is your ratio below 1.5%? (Visa merchant threshold)
- Is your ratio below your acquirer's internal threshold? (Ask if you don't know it)
- Is your combined TC40 + TC15 count above 1,500? (Below this, Visa doesn't flag you, but your acquirer still might. CEMEA merchants: threshold is 150 combined + $75,000 volume.)

**Trend Analysis:**

- Compare this month's ratio to the prior two months
- Flag any month-over-month increase greater than 0.1 percentage points
- Identify the top five products or transaction types generating TC40s

**Exclusion Verification:**

- Confirm RDR is active and resolving disputes before the monthly data cutoff (note: RDR removes qualifying TC15s from VAMP, but associated TC40s already filed still count)
- Check CE3.0 submission queue for any pending or late submissions
- Verify CDRN alerts are configured and connected

**Escalation Triggers:**

- If ratio exceeds 1.2%: escalate to payments team lead for review
- If ratio exceeds 1.4%: implement emergency fraud rule tightening and contact acquirer
- If ratio exceeds 1.5%: assume you are in Visa's Excessive tier and activate remediation plan

## What Comes Next

Tracking your VAMP ratio manually is a solid first step. It puts you ahead of the nearly three out of four merchants who aren't monitoring TC40s at all.

But manual tracking has limits. It's retrospective, it's slow, and it can't catch mid-month spikes before they lock in. If your business processes meaningful Visa volume, you need real-time visibility into both fraud signals and chargeback patterns, correlated against your settled transactions, updating continuously.

Corgi Intelligence surfaces exactly this kind of payments data. It pulls your fraud alerts, chargebacks, and transaction volume into a single view, highlights the double-count overlap, and flags ratio movement before the monthly cutoff, with no development work required.

If calculating your own VAMP ratio made you want better tooling, [Book a Demo →](https://www.corgilabs.ai/#book-demo).

## Sources

1. Visa Official VAMP Fact Sheet (2025): [https://corporate.visa.com/content/dam/VCOM/corporate/visa-perspectives/security-and-trust/documents/visa-acquirer-monitoring-program-fact-sheet-2025.pdf](https://corporate.visa.com/content/dam/VCOM/corporate/visa-perspectives/security-and-trust/documents/visa-acquirer-monitoring-program-fact-sheet-2025.pdf)
2. Merchant Risk Council, Stricter VAMP Ratio Thresholds Are Now in Effect (April 2026): [https://merchantriskcouncil.org/learning/resource-center/member-news/blog/2026/stricter-vamp-ratio-thresholds-are-now-in-effect-heres-how-to-stay-compliant](https://merchantriskcouncil.org/learning/resource-center/member-news/blog/2026/stricter-vamp-ratio-thresholds-are-now-in-effect-heres-how-to-stay-compliant)
3. Chargeback Gurus, Visa Acquirer Monitoring Program (VAMP) Guide (2026): [https://www.chargebackgurus.com/visa-acquirer-monitoring-program-vamp](https://www.chargebackgurus.com/visa-acquirer-monitoring-program-vamp)
4. Chargebacks911, Visa Acquirer Monitoring Program 2026: [https://chargebacks911.com/visa-acquirer-monitoring-program/](https://chargebacks911.com/visa-acquirer-monitoring-program/)
5. Chargebacks911/BusinessWire, Friendly Fraud Enterprise Survey (June 2026): [https://www.businesswire.com/news/home/20260630978374/en/Friendly-Fraud-is-Rising-for-More-Than-83-of-Enterprise-Merchants-New-Chargebacks911-Study-Finds](https://www.businesswire.com/news/home/20260630978374/en/Friendly-Fraud-is-Rising-for-More-Than-83-of-Enterprise-Merchants-New-Chargebacks911-Study-Finds)
6. ChargebackStop, How Double Counting (TC40 + TC15) in VAMP Inflates Your Risk: [https://www.chargebackstop.com/blog/how-double-counting-tc40-tc15-in-visas-vamp-inflates-your-risk](https://www.chargebackstop.com/blog/how-double-counting-tc40-tc15-in-visas-vamp-inflates-your-risk)
7. Corgi Labs, Visa VAMP 2026 New Merchant Compliance Thresholds: [https://www.corgilabs.ai/insights/vamp-2026-merchant-compliance](https://www.corgilabs.ai/insights/vamp-2026-merchant-compliance)
8. Stripe Documentation, Dispute and Fraud Card Monitoring Programs: [https://docs.stripe.com/disputes/monitoring-programs](https://docs.stripe.com/disputes/monitoring-programs)
9. Braintree Developer Docs, Visa Acquirer Monitoring Program: [https://developer.paypal.com/braintree/articles/risk-and-security/card-brand-monitoring-programs/visa-programs/visa-dispute-monitoring-program](https://developer.paypal.com/braintree/articles/risk-and-security/card-brand-monitoring-programs/visa-programs/visa-dispute-monitoring-program)
10. Adyen Docs, Monitor Risk Performance / Card Monitoring Programs: [https://docs.adyen.com/risk-management/dispute-and-fraud-monitoring](https://docs.adyen.com/risk-management/dispute-and-fraud-monitoring)
11. Equifax/Kount, The Visa Acquirer Monitoring Program: What New Rules Mean: [https://kount.com/blog/insight-visa-acquirer-monitoring-program-vamp](https://kount.com/blog/insight-visa-acquirer-monitoring-program-vamp)
12. Ballerine, Faster Terminations Due to VAMP: [https://ballerine.com/glossary/visa-acquirer-monitoring-program-vamp](https://ballerine.com/glossary/visa-acquirer-monitoring-program-vamp)
13. Visa Corporate Blog, Evolving the Visa Acquirer Monitoring Program: [https://corporate.visa.com/en/sites/visa-perspectives/security-trust/visa-vamp-program-update-fraud-disputes.html](https://corporate.visa.com/en/sites/visa-perspectives/security-trust/visa-vamp-program-update-fraud-disputes.html)
14. Chargebacks911, Compelling Evidence 3.0 Update (April 2026): [https://chargebacks911.com/compelling-evidence-3-0-update-april-2026/](https://chargebacks911.com/compelling-evidence-3-0-update-april-2026/)
15. Adaptiv Payments, Visa VAMP Guide 2025+2026: [https://adaptivpayments.com/blog/visa-vamp-2025](https://adaptivpayments.com/blog/visa-vamp-2025)

---

### Your Fraud Model Wasn't Built for Buyers That Aren't Human

Published: 2026-07-27 | https://www.corgilabs.ai/insights/fraud-detection-agentic-commerce

## One in Six Purchases Won't Come From a Human

By 2028, Gartner projects that 15% of all e-commerce transactions will involve some form of AI agent assistance. That means one in roughly six purchases on your platform could be initiated by software acting on a consumer's behalf.

Your fraud model was trained on humans. It watches for human browsing speeds, human typing patterns, and human purchase cadences. When the buyer isn't human, those signals stop working.

This isn't hype. In the last week of April 2025, both major card networks made their moves. Mastercard unveiled Agent Pay on April 29, followed a day later by Visa launching its Intelligent Commerce platform with partners including Anthropic, Microsoft, OpenAI, Samsung, and Stripe. Meanwhile, Stripe itself is building delegated authorization infrastructure. The message is clear: **agentic commerce is arriving, and it's arriving fast.**

## What Is Agentic Commerce, Exactly?

Agentic commerce is when an AI agent makes purchases on behalf of a consumer. The consumer delegates authority ("buy me running shoes under $150 from a reputable brand") and the agent handles research, selection, and checkout autonomously.

Think of it as the difference between a consumer clicking "buy" and a consumer telling their AI assistant to handle it. The payment still uses the consumer's credentials. But the entity initiating the transaction is software, not a person.

That distinction changes everything about how fraud detection works.

## Five Fraud Vectors Your Current Stack Doesn't See

Agentic commerce introduces attack surfaces that traditional fraud rules weren't designed to catch.

**1. Credential misuse that looks human.** When a fraudster uses stolen credentials through an AI agent, the agent mimics natural browsing behavior. It browses catalogs at realistic speeds and adds items to carts over hours. Traditional bot detection flags these interactions as low risk because they don't match typical scraping or bulk-purchase patterns.

**2. Agent spoofing and session hijacking.** Fraudsters can create fake agent identities or hijack legitimate agent sessions to make unauthorized purchases. Because agents operate through APIs and cloud infrastructure, verifying whether an agent is "real" requires entirely new authentication frameworks.

**3. Synthetic agent identities.** Just as synthetic human identities have plagued 'Know Your Customer' processes, synthetic agent profiles with fabricated transaction histories are emerging. These agents build credibility over time before conducting fraud.

**4. Proxy purchases through mule networks.** Agents can be configured to make purchases on behalf of mule accounts, distributing fraudulent transactions across hundreds of seemingly unrelated buyers. Each individual transaction looks clean.

**5. Agent-to-agent collusion at scale.** Coordinated rings of compromised agents can conduct distributed fraud across multiple merchants simultaneously. The volume and coordination possible with automated agents dwarfs what human fraud rings can achieve.

Based on fraud patterns reported at industry events in early 2025, a representative scenario illustrates the risk: a fraud ring deployed AI agents on fashion e-commerce sites that created accounts with AI-generated profile photos, browsed at human speeds, and used stolen cards at checkout. **Traditional bot detection scored them as low risk.** The operation was only discovered when a merchant noticed identical writing patterns in customer service inquiries across "different" accounts.

## Why Traditional Fraud Detection Breaks Down

Rule-based fraud systems assume the buyer is human. That assumption is embedded in nearly every signal they use.

**Velocity rules assume human purchase patterns.** A rule that flags three purchases in five minutes makes sense for a person. For an AI agent authorized to comparison-shop and buy across multiple merchants, three purchases in five minutes is normal behavior.

**Device fingerprinting fails on cloud infrastructure.** Legitimate agents run from cloud environments, often sharing IP ranges and device characteristics with thousands of other services. An agent running on AWS looks identical to a fraud bot running on AWS.

**Behavioral biometrics models break.** These models are trained on mouse movements, scroll patterns, and typing cadence. An agent interacting through APIs produces none of those signals. The model doesn't flag it as suspicious; it simply can't see it. (Agents using browser automation may produce some mouse and scroll signals, but most current agent architectures interact at the API level.)

**3D Secure assumes a human will respond.** Step-up authentication prompts ("enter your code") require a person on the other end. When an agent initiates the purchase, there may be no human available to respond, forcing merchants to choose between blocking legitimate agent purchases or bypassing their strongest authentication layer.

According to Ethoca/Verifi network data, the false decline rate for transactions from cloud-hosted environments (where many agents operate) is already 3.2x higher than residential IP transactions. As agentic volume grows, this problem compounds.

## How ML-Based Fraud Models Adapt

The same machine learning capabilities that make agents possible also make detecting agent-based fraud possible. The key is **training models on agent-specific behavioral data** rather than retrofitting human-behavior models.

Here's what that looks like in practice:

1. **Agent behavioral signatures.** Instead of mouse movements, track API call patterns, decision latency, and prompt structures. A legitimate agent has consistent behavioral fingerprints. A compromised or spoofed one doesn't.
2. **Cryptographic identity verification.** Visa's Intelligent Commerce platform assigns each agent a scoped token specifying merchant, amount limits, and product categories. Visa's own pilot data shows a 60% reduction in agent-related fraud compared to traditional card-not-present transactions when these tokens are enforced.
3. **Graph-based collusion detection.** Graph neural networks can map relationships between agents, transactions, and merchants to spot coordinated fraud rings. One suspicious transaction in isolation looks clean. Hundreds of related transactions across a network reveal the pattern.
4. **Preference-model anomaly detection.** A legitimate agent develops consistent purchasing preferences based on its consumer's behavior. A sudden shift (an agent that always buys running gear suddenly purchasing luxury electronics) signals compromise or hijacking.
5. **Merchant-specific training data.** Network-level fraud rules apply the same thresholds across all merchants. Models trained on your specific transaction patterns learn what "normal" looks like for your business, including what normal agent behavior looks like on your platform.

## What Payment Ops Teams Should Do Now

Agentic commerce volumes are still small, but the infrastructure is being built today. Waiting until agent transactions represent a meaningful percentage of your volume means retrofitting your fraud stack under pressure.

Start with these steps:

- **Audit your fraud rules for agent-specific blind spots.** Test your current velocity rules, device fingerprinting, and behavioral models against simulated agent transactions. Identify which rules would fire on legitimate agent activity and which would miss fraudulent agents.
- **Request documentation from your PSP.** Ask your payment processor about their agentic commerce roadmap. Specifically, ask about agent identity verification, tokenization support, and what new data fields will be available for fraud decisioning.
- **Prepare for new data points.** Agent attestations, permission scopes, and delegated authority tokens are becoming standard fields in transaction payloads. Your fraud models need to ingest and weight these signals.
- **Evaluate your model architecture.** Rule-based systems will struggle with agentic commerce. ML models trained on merchant-specific data can adapt to new transaction patterns as they emerge, learning what legitimate agent behavior looks like on your platform rather than applying network-wide averages.

## The Architecture Is Changing

Agentic commerce is not a future problem. Visa and Mastercard are live with agent frameworks. Visa projects tokenized payment credentials for agent use will reach 500 million or more by end of 2026. Stripe, Adyen, and Checkout.com are building agent-aware capabilities into their infrastructure.

The fundamental shift is clear: fraud detection is moving from "verify the human" to "verify the algorithm." Your fraud model needs to understand not just whether a transaction is legitimate, but whether the entity initiating it has proper authorization, consistent behavioral patterns, and valid cryptographic credentials.

Corgi Model trains on your merchant-specific transaction data, learning what normal looks like for your business. As agentic transactions enter your payment flow, that same approach applies: custom ML that adapts to new buyer types without waiting for network-level rule updates. No development work required.

**The buyers are changing. Your fraud model should too.**

[Book a Demo →](https://www.corgilabs.io/demo)

---

## Sources

1. "Visa and Mastercard unveil AI-powered shopping," [TechCrunch, April 30, 2025](https://techcrunch.com/2025/04/30/visa-and-mastercard-unveil-ai-powered-shopping/).
2. Visa Intelligent Commerce announcement materials, [Visa Press Center, 2025](https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.21361.html).
3. Mastercard Agent Pay announcement, [Mastercard Newsroom, April 2025](https://www.mastercard.com/global/en/news-and-trends/press/2025/april/mastercard-unveils-agent-pay-pioneering-agentic-payments-technology-to-power-commerce-in-the-age-of-ai.html).
4. [Stripe Sessions 2025 presentations](https://stripe.com/blog/top-product-updates-sessions-2025) and API documentation on agentic payment infrastructure.
5. [Gartner research on AI agent e-commerce projections, 2025](https://www.gartner.com/en/newsroom/press-releases/2025-10-21-gartner-unveils-top-predictions-for-it-organizations-and-users-in-2026-and-beyond).
6. [Akamai](https://www.akamai.com/blog/security-research/online-fraud-abuse-2025-ai-drivers-seat) and [Imperva](https://www.imperva.com/blog/2025-imperva-bad-bot-report-how-ai-is-supercharging-the-bot-threat/) reports on bot traffic and automated login attempt statistics, 2024-2025.
7. [Ethoca/Verifi network data on false decline rates by IP type](https://www.ethoca.com/blog/how-the-right-data-can-help-you-prevent-fraud-and-reduce-false-declines-and-chargebacks).
8. [Visa pilot program materials on tokenized agent architecture results, 2025](https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.21961.html).

---

### Want Zero Payment Fraud? Accept Zero Payments

Published: 2026-07-24 | https://www.corgilabs.ai/insights/payment-metrics-founders-should-know

## The fastest way to zero fraud

Ask how to get payment fraud to zero and there's one guaranteed answer: accept zero payments. Block everything, and nothing bad ever happens. I opened a recent talk to a room of founders in San Francisco with that line, and it landed because half the room was quietly running a version of that strategy without knowing it.

Fraud tools love one half of the story. "We blocked 1,000 fraudulent orders" makes a great slide. "We blocked 100,000 good orders along the way" does not, so nobody puts it on a slide.

That second number is where your hidden revenue lives. Across the merchants we analyze, roughly an extra 3% of revenue is sitting in payments that were blocked or failed for bad reasons, waiting for someone to look.

## Three rates decide what you keep

Every payment that comes in runs a gauntlet with two gates, and each gate has a rate you should know:

1. **Acceptance rate**: of all attempted payments, how many your own fraud model and rules let through.
2. **Authorization rate**: of the ones you let through, how many the banks and card networks approve.
3. **Payment success rate**: how many survive end to end, including payments people abandoned at checkout.

These compound. Say 90% of payments get past your rules, and the banks trim another 10%: you keep about 80% of attempted revenue, which is actually a decent funnel.

At the talk I asked who knew their payment success rate. The best answer in the room was "we know how to look it up." That's the norm, and it means most founders are running growth experiments on top of a leak they've never measured.

## Blocks you control, declines you mostly don't

The terminology varies by processor, but the useful split is this: a **block** is you saying no, through your own rules or fraud model. A **decline** is the bank or card network saying no after you already said yes.

Blocks are fully in your control, which is exactly why they're where the self-inflicted damage hides. One merchant we spoke with had an old rule that said, in effect, "if Brazil, then block." Nobody remembered writing it. Their revenue in that market was half what it should have been, and everyone assumed the market was just soft.

Declines are trickier because banks don't explain themselves. But there's a pattern we see repeatedly: when your fraud rate improves, your authorization rate tends to improve with it. Issuers score your traffic too. Send them cleaner payments and they say yes more often.

## False declines are the expensive kind of safety

A false decline is a real customer you turned away. It feels free because nothing bad shows up in your fraud reports, but it's the most expensive outcome in payments.

Research reported by Digital Commerce 360 found that 33% of US consumers won't shop again with a merchant that falsely declined them. You paid to acquire that customer, and one bad checkout ended the relationship for good.

The math gets worse over time. For every $100 in false payment declines, our analysis puts the lifetime value lost at over $750, because you lose every future order along with the first one.

Verification friction does the same damage in slow motion. One of our customers was expanding into the US with 3D Secure (the "enter the code we texted you" step, common in Europe) switched on for everything. Adyen's analysis found that applying 3DS to all US transactions cuts conversion by an average of 43%, and sure enough, this merchant was losing roughly half their US revenue to a single setting. Their US expansion looked like a product failure. It was a checkout configuration.

## Not all fraud looks like fraud

Professional fraud is loud and mechanical. A ring buys a batch of stolen cards, tests them against a low-friction checkout (cloud providers are a favorite target), and the cards that survive go buy five handbags each. Machines are good at catching machines: that pattern shows up clearly in your data.

The harder problem is friendly fraud, and it doesn't look like fraud at all. Picture a customer who signs up for your gym, uses it for 11 months, then disputes the whole year with "I never used this service and couldn't cancel."

Javelin Strategy & Research estimates friendly fraud now accounts for 60% to 80% of all chargebacks. Most of your dispute problem isn't shadowy card rings. It's real customers with buyer's remorse and a bank's phone number.

## A dispute costs you even when you did nothing wrong

Quick definitions, because these get conflated: a **dispute** is a customer telling their bank a charge was wrong. A **chargeback** is you losing that fight: the money goes back, the product is already gone, and a fee lands on top. Stripe, for example, passes through a $15 fee per dispute.

For a $20 per month subscription, one dispute erases most of that month's revenue even when the customer is wrong. And merchants lose most of these fights: industry data compiled by Chargeback.io puts overall win rates at 20% to 30%. Prevention beats representment, every time.

The card networks raised the stakes in April 2025. Visa consolidated its fraud and dispute programs into VAMP, the Visa Acquirer Monitoring Program, with enforcement starting that October. The excessive-dispute threshold started at 2.2% of transactions and tightened to 1.5% in April 2026. Cross it and you're in the naughty corner: monitoring, fines, and an acquirer suddenly very interested in your business.

Inside the program, the fines are per item: roughly $10 for every disputed transaction, stacked on the processor fee you were already paying. The dispute doesn't have to be your fault, and you pay whether or not you'd have won it.

One counterintuitive note: not every dispute is an enemy. "Product not as described" disputes are free product feedback. If orders aren't arriving, that's your logistics partner failing, not your fraud model. Read your disputes before you fight them.

## Start with one number

You don't need a payments team to act on this. You need an afternoon:

1. Find your payment success rate, and the acceptance and authorization rates behind it.
2. Map the funnel: where exactly do payments die? Blocks, bank declines, 3DS friction, or abandonment.
3. Audit any fraud rule older than a year, and ask what good revenue it's blocking, not just what bad revenue it stops.
4. Track your dispute ratio monthly against Visa's 1.5% VAMP line, and treat 1% as your early warning.

If you'd rather have this dug up for you, that's what we built Corgi Intelligence to do: it connects to your Stripe account, shows you these exact metrics and the funnel behind them, and flags the insights worth acting on. Corgi Model then works the other side, blocking fraud instead of buyers, and merchants typically recover about 3% of revenue.

Your payments data already knows where the leak is. Go look.

[Book a Demo →](/#book-demo)

## Sources

- Digital Commerce 360, "33% of US consumers drop retailers after a false decline. Here's how to prevent those losses." [https://www.digitalcommerce360.com/2020/07/16/33-of-us-consumers-drop-retailers-after-a-false-decline-heres-how-to-prevent-those-losses/](https://www.digitalcommerce360.com/2020/07/16/33-of-us-consumers-drop-retailers-after-a-false-decline-heres-how-to-prevent-those-losses/)
- Adyen, "Adyen analysis reveals worldwide impact of 3D Secure on transaction conversion rates" [https://www.adyen.com/press-and-media/adyen-analysis-reveals-worldwide-impact-of-3d-secure-on-transaction-conversion-rates](https://www.adyen.com/press-and-media/adyen-analysis-reveals-worldwide-impact-of-3d-secure-on-transaction-conversion-rates)
- Mastercard Insights, "Friendly Fraud Explained: Risks and Prevention" (Javelin Strategy & Research estimate) [https://www.mastercard.com/us/en/news-and-trends/Insights/2024/what-is-friendly-fraud.html](https://www.mastercard.com/us/en/news-and-trends/Insights/2024/what-is-friendly-fraud.html)
- Visa, "Visa Acquirer Monitoring Program fact sheet (2025)" [https://corporate.visa.com/content/dam/VCOM/corporate/visa-perspectives/security-and-trust/documents/visa-acquirer-monitoring-program-fact-sheet-2025.pdf](https://corporate.visa.com/content/dam/VCOM/corporate/visa-perspectives/security-and-trust/documents/visa-acquirer-monitoring-program-fact-sheet-2025.pdf)
- Chargeflow, "Visa VAMP Rules 2025: New Dispute Thresholds Explained" [https://www.chargeflow.io/blog/what-are-visas-new-vamp-rules-a-2025-guide-for-merchants](https://www.chargeflow.io/blog/what-are-visas-new-vamp-rules-a-2025-guide-for-merchants)
- Chargeback Gurus, "Visa Acquirer Monitoring Program (VAMP)" (per-item enforcement fees) [https://www.chargebackgurus.com/visa-acquirer-monitoring-program-vamp](https://www.chargebackgurus.com/visa-acquirer-monitoring-program-vamp)
- Chargeflow, "Chargeback Fees by Processor (Stripe, PayPal, Square, More)" [https://www.chargeflow.io/blog/chargeback-fees](https://www.chargeflow.io/blog/chargeback-fees)
- Chargeback.io, "Chargeback Statistics 2026: 25+ Facts on Fraud, Costs & Trends" [https://www.chargeback.io/blog/chargeback-statistics](https://www.chargeback.io/blog/chargeback-statistics)
- Saif's talk at the Founder Meetup, San Francisco, May 2026

-->

---

### False Declines Cost 13x More Than Fraud: How to Approve More Real Buyers

Published: 2026-07-23 | https://www.corgilabs.ai/insights/false-decline-tax

## The VAMP Squeeze Has Changed the Math

On April 1, 2026, Visa cut every merchant's margin for error by nearly a third. The VAMP threshold dropped from 2.2% to 1.5%, and now every fraud decision carries two price tags: what you lose to fraud, and what you lose to the customers you accidentally turn away. The second bill is almost always bigger.

Merchants above the new threshold face roughly $8 per disputed transaction, mandatory remediation plans, potential account termination, and placement on the MATCH list. The message is clear: bring your fraud rate down or risk losing the ability to process cards.

The natural response? Tighten everything. Add more rules, flag more transactions, decline anything remotely suspicious.

That instinct is understandable. It's also the most expensive mistake you can make right now. As Adyen's 2026 Fraud Report puts it: "The question is no longer how much fraud a business is willing to tolerate. The question is how much legitimate revenue it's willing to lose trying to stop it."

## The Cost Nobody Budgets For

Here's the number that should reshape how you think about fraud prevention: **false declines cost roughly 13 times more than actual fraud**. Industry research has quantified this gap, and the scale is staggering.

US merchants lost approximately $81 billion to false declines in 2023. That same year, actual ecommerce fraud totaled roughly $48 billion globally. When a single country's false decline losses approach the entire world's fraud total, the priorities are clearly misaligned.

This isn't a rounding error. It's the largest invisible cost in most merchants' payments stack.

Riskified estimates the average merchant loses up to **5.5% of annual revenue** to false declines. For a $100 million merchant, that's $5.5 million in real revenue vanishing because fraud controls worked too well in the wrong direction.

And nearly half of all businesses know it's happening. Forty-seven percent estimate that up to 5% of their legitimate orders are falsely declined. They see the problem. Most just don't know how to fix it without increasing fraud exposure.

## What Happens When You Turn Away a Real Customer

A false decline doesn't just cost you one sale. It costs you a customer.

Forty percent of shoppers boycott a merchant entirely after being falsely declined. According to Signifyd, even the customers who do come back spend **17% less over their lifetime** compared to buyers who were never wrongly turned away. The financial damage compounds long after the original transaction fails.

And it keeps getting worse. Twenty-seven percent of loyal customers never return at all, and 32% share their negative experience online.

Imagine running a marketplace with $200 million in annual GMV. Your fraud controls decline 5% of legitimate orders, translating to $10 million in rejected revenue per year. Of those declined customers, 40% never shop with you again. That's not just $10 million in lost transactions: it's years of repeat purchases, referrals, and brand equity erased by a model that couldn't distinguish a loyal buyer from a fraudster.

That's the false decline tax. It compounds silently, quarter after quarter, while your fraud dashboard shows everything under control.

## Why Tighter Rules Make the Problem Worse

The post-VAMP instinct to crank up fraud controls has a predictable outcome: more blocked legitimate customers. Adyen's 2026 Fraud Report, covering $1.6 trillion in platform transactions, confirms the pattern.

**Static controls block up to 10% of legitimate customers.** Half of the businesses Adyen surveyed reported an increase in false declines.

The counterintuitive truth? **Tighter rules don't produce better fraud outcomes.**

The Merchant Risk Council's 2026 survey of 1,278 professionals across 37 countries revealed a striking pattern. MRC members with mature fraud programs reject only 2.8% of orders while maintaining a fraud rate of just 0.6% by revenue.

Non-MRC enterprises tell a different story: a 5.2% rejection rate paired with a 3.9% fraud rate. The merchants with the best fraud outcomes reject fewer orders, not more. Better data and better calibration beat aggressive thresholds every time.

As Jeff Hallenbeck, VP of Customer Advocacy at Adyen, noted: "The businesses leading in this environment aren't the ones with the most aggressive controls. They're the ones making more deliberate decisions about where and how to apply them."

## Six Strategies to Approve More Real Buyers

Authorization rate optimization isn't about accepting more risk. It's about making **smarter decisions at the point of transaction**. Here are six strategies that work.

1. **Replace static rules with ML scoring.** Rules-based fraud systems flag patterns. Machine learning models trained on your specific transaction data learn what "normal" looks like for your business. A $2,000 order from a new IP address might be suspicious for a coffee subscription but routine for a luxury retailer.
2. **Send cleaner data to issuers.** Many declines happen because the issuing bank doesn't have enough context to approve. Providing complete billing information, device signals, and transaction metadata helps issuers make confident decisions instead of defaulting to decline.
3. **Adopt 3DS2 with background authentication.** Only about 32% of merchants currently use 3D Secure 2, despite the full liability shift it provides. For low-risk buyers, 3DS2 authenticates in the background without adding checkout steps, while shifting chargeback liability to the issuer.
4. **Implement network tokenization.** Solidgate reports that network tokenization improves acceptance by up to 15 percentage points. Tokens replace raw card numbers with network-managed credentials, reducing false declines caused by outdated or mismatched card data.
5. **Build intelligent retry logic.** Not every decline is final. Soft declines from temporary issuer issues can often be recovered through smart retry timing and routing. This alone delivers measurable revenue recovery on transactions that would otherwise be lost.
6. **Use local acquiring and smart routing.** Cross-border transactions face higher decline rates due to currency, issuer geography, and risk scoring differences. Routing transactions through in-country processors gives issuers more confidence to approve.

These strategies compound. Stripe's Authorization Boost recovers 20% of false declines, delivering a 3.8% average lift in approval rates.

Riskified's partnership with Capital One reduced false declines by up to 25%. The gains across these approaches are real and measurable.

## The Measurement Problem

Here's a statistic that explains why false declines persist: **only about 64% of merchants track their false decline rate**. More than a third don't measure the single most financially damaging metric in their fraud stack.

You can't optimize what you don't measure. If your fraud dashboard shows chargebacks, fraud rate, and authorization rate but not false decline rate, you're missing your biggest cost.

Payment operations leaders should track a focused set of metrics:

- **Authorization rate** by card type, geography, and channel
- **False decline rate**, estimated or measured through post-decline analysis
- **Fraud rate by revenue**, not just by order count
- **Chargeback ratio trending** against the VAMP 1.5% threshold
- **Customer LTV impact** of declines, comparing declined-then-returning customers to never-declined cohorts

The goal isn't more data. It's the right data to make precise decisions instead of blanket rules.

## Finding the Balance

VAMP demands lower fraud. Your P&L demands higher approval rates. These aren't opposing goals. They're two halves of the same optimization problem.

The merchants winning in the post-VAMP environment aren't the ones with the tightest controls. They're the ones with the most precise controls: ML models trained on their own transaction patterns, clean data flowing to issuers, and measurement systems that track both fraud and the revenue lost to false declines.

Precision beats aggression. Every time.

Corgi Model trains custom ML fraud decisioning on your merchant-specific data, so it learns what "legitimate" looks like for your business rather than applying one-size-fits-all thresholds. Corgi Intelligence surfaces the payments analytics you need to see your true false decline rate, your authorization performance by segment, and the revenue you're leaving on the table.

If you're losing more to false declines than to fraud (and the data says you probably are), it's worth seeing what merchant-specific optimization looks like for your business.

[Book a Demo →](https://www.corgilabs.ai/#book-demo)

## Sources

- Chargeflow, "VAMP: What It Is and How to Stay Compliant" (July 2026). [https://www.chargeflow.io/blog/vamp-visa-acquirer-monitoring-program](https://www.chargeflow.io/blog/vamp-visa-acquirer-monitoring-program)
- Digital Applied, "Ecommerce Fraud & Chargeback Prevention: 2026 Playbook" (June 2026). [https://www.digitalapplied.com/blog/ecommerce-payment-fraud-chargeback-prevention-2026-playbook](https://www.digitalapplied.com/blog/ecommerce-payment-fraud-chargeback-prevention-2026-playbook)
- Adyen, "2026 Fraud Report: Fraud's Identity Crisis" (2026). [https://www.adyen.com/knowledge-hub/fraud-report-2026](https://www.adyen.com/knowledge-hub/fraud-report-2026)
- Shopify Enterprise Blog, "Ecommerce Fraud Management in the AI Era: A 2026 Guide" (June 2026). [https://www.shopify.com/enterprise/blog/ecommerce-fraud-management](https://www.shopify.com/enterprise/blog/ecommerce-fraud-management)
- Merchant Risk Council, "2026 Global eCommerce Payments and Fraud Report" (2026). [https://merchantriskcouncil.org/learning/mrc-exclusive-reports/global-payments-and-fraud-report](https://merchantriskcouncil.org/learning/mrc-exclusive-reports/global-payments-and-fraud-report)
- Chargeback Gurus, "Key Fraud Takeaways From the 2026 MRC Report" (April 2026). [https://www.chargebackgurus.com/blog/fraud-statistics-from-mrc-report](https://www.chargebackgurus.com/blog/fraud-statistics-from-mrc-report)
- Riskified, "How Much Does a False Decline Cost Your Business?" (May 2026). [https://www.riskified.com/blog/reduce-false-declines/](https://www.riskified.com/blog/reduce-false-declines/)
- Riskified, "False Declines: What They Cost You & How to Reduce Them" (April 2026). [https://www.riskified.com/learning/ecommerce-checkout-optimization/false-declines/](https://www.riskified.com/learning/ecommerce-checkout-optimization/false-declines/)
- Riskified, "Unlock Revenue by Optimizing Payment Authorization Rates" (March 2024). [https://www.riskified.com/blog/payment-authorization-rates/](https://www.riskified.com/blog/payment-authorization-rates/)
- Signifyd, "Retail Fraud Prevention: 2026 Guide" (June 2026). [https://www.signifyd.com/blog/retail-fraud-prevention/](https://www.signifyd.com/blog/retail-fraud-prevention/)
- Signifyd, "How the Top Retailers Measure Fraud False Declines" (September 2025). [https://www.signifyd.com/blog/how-the-top-retailers-measure-fraud-false-declines/](https://www.signifyd.com/blog/how-the-top-retailers-measure-fraud-false-declines/)
- Signifyd, "5 Strategies to Increase Bank Authorization Rates" (February 2026). [https://www.signifyd.com/blog/increase-authorization-rates/](https://www.signifyd.com/blog/increase-authorization-rates/)
- Solidgate, "Authorization Rate Optimization: The 2026 Playbook" (May 2026). [https://solidgate.com/blog/authorization-rate-optimization/](https://solidgate.com/blog/authorization-rate-optimization/)
- Stripe, "Authorization Boost" (2026). [https://stripe.com/authorization-boost](https://stripe.com/authorization-boost)
- PYMNTS Intelligence, "47% of Merchants Say False Declines Cost Them Sales" (January 2026). [https://www.pymnts.com/fraud-prevention/2026/47-percent-of-merchants-say-false-declines-cost-them-sales/](https://www.pymnts.com/fraud-prevention/2026/47-percent-of-merchants-say-false-declines-cost-them-sales/)
- Corgi Labs, "False Payment Declines" (April 2026). [https://dev.corgilabs.ai/insights/false-declines](https://dev.corgilabs.ai/insights/false-declines)
- NoFraud, "False Declines Cost More Than Fraud in Ecommerce" (January 2026). [https://www.nofraud.com/blog/the-value-of-false-declines-is-more-than-13-times-the-total-amount-lost-to-actual-card-fraud/](https://www.nofraud.com/blog/the-value-of-false-declines-is-more-than-13-times-the-total-amount-lost-to-actual-card-fraud/)
- Eightx.co, "Average Chargeback Rate by Vertical: 2026 Benchmarks" (June 2026). [https://eightx.co/blog/average-chargeback-rate-by-vertical](https://eightx.co/blog/average-chargeback-rate-by-vertical)

---

### TC40 Descriptor Mismatch: Why Merchants Get VAMP Fines for Fraud They Didn't Process

Published: 2026-07-10 | https://www.corgilabs.ai/insights/tc40-descriptor-mismatch

## A Cloned Website Could Be Costing You $8 Per Transaction

Imagine opening your VAMP report and finding 500 TC40 fraud alerts you can't trace to any transaction in your system. At $8 each, that's $4,000 in monthly fines. The transactions are real, the fraud is real, but none of it happened on your platform.

This is the TC40 descriptor mismatch problem, and it's one of the most underreported risks in Visa's Acquirer Monitoring Program.

## What VAMP Changed About Fraud Fines

Visa's VAMP launched in April 2025, replacing the legacy Visa Fraud Monitoring Program (VFMP) and Visa Dispute Monitoring Program (VDMP). The threshold tightened to a **1.5% dispute ratio** effective April 1, 2026. Unlike its predecessors, VAMP assesses $8 per TC40 and $8 per chargeback for Excessive-tier merchants. If a TC40 later results in a chargeback (TC15), the same transaction can be fined twice, totaling $16.

There's no grace period for repeat violators. If you've been cited within the past 12 months, fines start from month one. First-time offenders get a three-month remediation window before fees kick in, but there's no early warning category, no 90-day runway to clean things up before you're classified.

For most merchants, the math is straightforward. Track your chargebacks, manage your fraud, stay under the threshold. But VAMP introduced a vulnerability that has nothing to do with the fraud you're processing, and everything to do with how TC40 reports identify merchants.

## How TC40 Reports Actually Identify You

When a cardholder reports a fraudulent transaction to their issuer, the issuer files a TC40 fraud report. That report doesn't reference your merchant identification number (MID). It references the **merchant descriptor**, the text string that appears on the cardholder's statement.

Karisse Hendrick, a fraud prevention expert and host of the [Fraudology podcast](https://fraudology-podcast.captivate.fm/), described the problem plainly in a July 2026 episode: "The TC40 goes to the descriptor. It doesn't go to the MID. So if somebody clones your site and uses a descriptor that starts with your brand name, you get the TC40."

That distinction matters. Your MID is unique to your merchant account. Your descriptor is a text string that someone else can approximate, copy, or spoof.

A cloned website calling itself "NikeDeals" or "Nike-Outlet-Store" generates transactions under a descriptor that starts with "Nike." When cardholders file fraud reports on those transactions, the TC40s can be routed to the legitimate merchant whose descriptor matches, not to the fraudster's actual processing account.

## The Notification Gap That Shrinks Your Response Window

Even if you catch these misattributed TC40s, responding in time is harder than it should be.

Per Visa's VAMP rules, merchants have a 10-day window to dispute a TC40 after the acquirer is notified. That sounds reasonable. The problem is the gap between when your acquirer knows and when you know.

As Hendrick explained: "The acquirer gets notified, and then the acquirer notifies the merchant. That can typically take two to three business days. Now your 10-day window is seven days."

**Roughly seven calendar days to investigate fraud you didn't process.** That's the effective window most merchants are working with, though the exact lag varies by acquirer. For a payment ops team already managing legitimate disputes, adding misattributed TC40 investigations to a compressed timeline is a significant operational burden.

The practical sequence looks like this:

1. A cloned site processes a fraudulent transaction using a descriptor similar to yours
2. The cardholder reports it as fraud, triggering a TC40
3. The TC40 is routed to your acquirer based on descriptor matching
4. Your acquirer receives the TC40 and starts the 10-day clock
5. Typically two to three business days later, your acquirer notifies you
6. You have roughly seven days left to investigate and dispute a transaction you can't find in your records

Each step in that chain adds friction. None of it is within your control.

## Agentic Commerce Makes This Worse

Cloned merchant websites aren't new. What's new is how they reach consumers.

A June 2026 investigation by The Guardian found cloned versions of legitimate retailer websites appearing in ChatGPT search results. In one case, a fake version of Russell & Bromley, a UK shoe retailer, showed up when users searched for the brand through an AI assistant. The fake site used a similar domain and branding, making it difficult for even attentive shoppers to distinguish from the original. ChatGPT subsequently removed the fraudulent sites from its search index after the Guardian investigation, but the underlying technique remains available to fraudsters. (The specific Guardian-documented cases, including Russell & Bromley, were remediated after publication. The vulnerability class persists.)

**Now extend that scenario to AI shopping agents.**

Agentic commerce, where AI agents browse, compare, and purchase on behalf of consumers, is accelerating. These agents optimize for the lowest price and fastest delivery. They don't yet have a reliable mechanism to verify that a site is legitimate.

Hendrick put it directly: "AI agents are optimizing for the lowest price. They don't have a mechanism to verify that the site is legitimate."

A human shopper might notice a slightly off URL, a missing padlock icon, or an unusually low price. An AI agent running a purchase flow won't apply that judgment. It will find the cheapest listing, complete the transaction, and move on. If that transaction happens on a cloned site using your brand's descriptor, the resulting TC40 lands on your account.

While human consumers following AI-recommended cloned sites is well-documented, fully autonomous AI purchasing agents are still in early deployment. The risk is directional: as these agents scale, so does the exposure. The infrastructure for it already exists:

- **Cloned sites have already been indexed** by AI search tools (and removed reactively, not proactively)
- **AI purchasing agents** are in early deployment
- **TC40 descriptor routing** doesn't distinguish between legitimate and cloned merchants

The combination creates a fraud vector that scales without the fraudster needing to do anything beyond maintaining a convincing clone.

## What This Costs at Scale

The financial impact of descriptor misattribution compounds quickly. VAMP's $8 per-TC40 fine is only the starting point. If a TC40 results in a chargeback (TC15), the combined fine can reach $16 per transaction.

Consider a hypothetical mid-market merchant processing $50 million annually. If, for example, cloned-site fraud generates 1,200 misattributed TC40s per month, the fine alone is **$9,600 monthly, or $115,200 annually**. That number doesn't include:

- Chargeback fees on transactions that convert from TC40s (potentially doubling the per-transaction fine to $16)
- Staff time spent investigating transactions that don't exist in your system
- Representment costs for disputes you choose to fight
- Revenue lost when your dispute ratio pushes you closer to the VAMP threshold

At higher volumes, the math gets worse:

| Monthly Misattributed TC40s | Monthly VAMP Fine | Annual VAMP Fine |
| --- | --- | --- |
| 500 | $4,000 | $48,000 |
| 2,000 | $16,000 | $192,000 |
| 5,000 | $40,000 | $480,000 |

These are fines for fraud you didn't process, on transactions you never saw, from customers who never visited your site. For a payment ops team measured on dispute ratios and chargeback costs, misattributed TC40s are a budget line item with no corresponding revenue.

## Why Existing Tools Don't Catch This

Most fraud prevention and chargeback management tools focus on transactions you processed. They analyze your authorization data, score your orders, and help you fight chargebacks on transactions in your system.

Descriptor misattribution sits outside that frame entirely.

A competitive review of nine fraud and payments vendors (including Pagos, Signifyd, Checkout.com, Forter, Riskified, Sift, Sardine, Primer, and Spreedly) found **zero coverage of TC40 descriptor misattribution** or any form of merchant early-alert system specifically designed for VAMP disputes. This audit did not include dedicated chargeback management platforms such as Chargebacks911, Midigator, or CB-ALERT, which may have partial capabilities in this area.

That gap exists because the problem isn't about your fraud. It's about someone else's fraud being attributed to you based on a text match. Traditional fraud tools look inward at your transaction stream. This vulnerability requires looking outward at what's being reported under your descriptor.

## What You Can Do About It

While there's no single fix for descriptor misattribution, there are practical steps payment ops teams can take now:

1. **Audit your descriptor regularly.** Know exactly what appears on cardholder statements. Search for variations, typos, and similar strings that a cloned site might use.
2. **Monitor your TC40 reports at the descriptor level.** Don't just track totals. Look for TC40s that reference transaction amounts, dates, or patterns that don't match your processing records.
3. **Establish a rapid dispute workflow.** With only seven effective days to respond, your process for flagging and disputing misattributed TC40s needs to be faster than your standard chargeback workflow.
4. **Communicate proactively with your acquirer.** Ask about their notification timeline. If they're consistently taking three days to notify you, that's a conversation worth having. Some acquirers can set up faster alert routing.
5. **Track brand impersonation.** Monitor for cloned sites using your brand name, especially those appearing in AI search results and shopping agent indexes.

These steps won't eliminate the risk, but they give you visibility into a problem that most merchants don't know they have until the fines arrive.

## Turning Payments Data Into Early Detection

The core challenge with descriptor misattribution is timing. By the time a TC40 shows up in your monthly report, the dispute window may already be closing. What merchants need is near-real-time visibility into what's being reported under their descriptor.

This is where payments analytics moves from reporting to prevention. Tools that surface TC40 activity as it happens, rather than in batch reports, give payment ops teams the window they need to investigate and dispute before fines lock in. Corgi Intelligence is built to dig into your payments data at this level of granularity, connecting transaction-level signals to dispute patterns so your team can act on misattributions before they become line items.

No tool can stop a fraudster from cloning your site. But the right analytics can tell you it's happening before the VAMP fines pile up.

If your team is managing VAMP compliance and wants earlier visibility into TC40 patterns, including descriptor-level monitoring, [Book a Demo →](#book-demo) to see how Corgi Intelligence surfaces these signals.

---

## Sources

- Fraudology Podcast, Karisse Hendrick, "[The Agentic Era: Visa’s OpenAI Partnership, VAMP Pitfalls, and the Threat of Cloned Sites](https://fraudology-podcast.captivate.fm/episode/the-agentic-era-visas-openai-partnership-vamp-pitfalls-and-the-threat-of-cloned-sites)" July 7, 2026.
- The Guardian, "[Cloned sites: the shopping scams that lead ChatGPT to fake stores](https://www.theguardian.com/money/2026/jun/07/ai-chatgpt-shopping-scams-fake-websites)," June 7, 2026.
- [Visa Core Rules and Visa Product and Service Rules, April 2026](https://usa.visa.com/dam/VCOM/download/about-visa/visa-rules-public.pdf) (VAMP amendments effective April 2026).

---

### Network Tokenization Delivers a 2% to 6% Authorization Rate Lift. Here's Why Most Merchants Still Miss It.

Published: 2026-06-29 | https://www.corgilabs.ai/insights/tokenization-as-a-service

One merchant on Reddit's r/ecommerce recently reported that network tokenization lifted their authorization rate from 88% to 93%. Their cost: five cents per transaction. Their caveat: "The implementation was a pain."

That single, self-reported account captures the entire tokenization opportunity for mid-market merchants: the lift is real, but the barrier is technical complexity. Most merchants processing between 8,000 and 500,000 transactions per month are stuck on the wrong side of it. They have enough volume for tokenization to matter meaningfully, but not enough engineering headcount to build and maintain it in-house.

If you rely on Stripe Checkout or Payment Links, your processor already handles tokenization for you, so this article is not about your setup. But if you run a custom payments stack, process through multiple PSPs, or manage stored credentials directly, network tokenization is likely revenue you're leaving on the table.

## The Lift Is Documented, Not Theoretical

Network tokenization replaces stored card numbers with secure tokens issued directly by Visa and Mastercard. When an issuer sees a network token instead of a raw card number, it recognizes a trusted credential. The result: higher approval rates and lower fraud.

The data is consistent across sources:

**Visa** reports a 4.6% global authorization rate lift for tokenized transactions, with 30% less fraud

**Industry benchmarks** consistently report 2 to 6 percentage point improvements for tokenized transactions

**Dwayne Gefferie, Stripe's former head of payments optimization,** puts the lift at roughly 6% for eligible merchants in his 2026 analysis

For a mid-market merchant processing $120M annually, even a two-percentage-point improvement recovers $2.4M per year in revenue that was quietly disappearing into declined transactions, based on Corgi Labs' revenue recovery model.

## Half of Merchants Haven't Claimed This Yet

Despite clear ROI, the Merchant Risk Council's 2025 Global eCommerce Payments and Fraud Report found that only 47% of merchants had adopted network tokenization by 2024, up from 44% the prior year. That's incremental progress, not a wave.

Among merchants who have tokenized, six in 10 cite authorization rate improvement as the primary benefit. They know it works. The other half of the market hasn't yet captured this lift.

The gap isn't awareness. It's execution.

## Why Adoption Stalls at Mid-Market

Large enterprises have dedicated payments engineering teams. They can allocate sprints to API integration, vault management, and token lifecycle handling. Smaller merchants on Shopify or similar platforms get tokenization bundled into their processor's tooling.

Mid-market merchants fall into a gap. They process enough volume for tokenization to matter significantly, but they typically lack the engineering bandwidth to implement it. The barriers stack up:

**Technical complexity.** Network tokenization requires API integration with card networks, credential vault migration, and ongoing token lifecycle management (provisioning, updating, de-provisioning).

**PCI scope uncertainty.** Merchants worry that handling tokenization expands their compliance footprint. In most implementations, network tokens reduce PCI scope by removing raw card numbers from your environment, but the path feels ambiguous without expert guidance.

**Competing priorities.** Payment infrastructure projects compete against product features, marketing launches, and customer-facing work. Authorization rate optimization rarely wins that sprint planning battle.

**The "build vs. buy" trap.** Many merchants assume tokenization requires an internal project. They don't realize there's a faster path.

## The Real Cost of Every Missed Authorization

Merchants who have tokenized are pulling ahead. Those who haven't are falling further behind, and the cost compounds in ways that don't show up on a standard payments dashboard.

False declines are the hidden multiplier. According to Fiserv, false declines cost merchants 13 times more than actual fraud.

That means every transaction you incorrectly block doesn't just cost you the sale. It costs you multiples of that sale in downstream damage. Research from Aite-Novarica and ClearSale puts that ratio as high as 75 to one.

PYMNTS reported in 2024 that 56% of U.S. consumers experienced a false payment decline in the prior 90 days. Riskified and ClearSale data shows that 27% to 33% of customers never return after a false decline. You're not losing one sale. You're losing a customer's lifetime value.

For every percentage point of authorization rate you're leaving on the table, the real cost includes the transaction itself, the customer acquisition cost you've already spent, the lifetime revenue from that customer's future purchases, and the word-of-mouth impact of a frustrated buyer.

## Three Paths to Network Tokenization

Not all approaches require the same investment. Here's how the options break down:

Build it yourself. You integrate directly with Visa Token Service and Mastercard Digital Enablement Service, manage your own token vault, and handle lifecycle events. This works if you have a dedicated payments engineering team and months of runway. Most mid-market merchants don't.

Use your processor's built-in option. If you're on Stripe, Adaptive Acceptance bundles network tokens alongside other optimization tools like Card Account Updater and intelligent authorization optimization. Zapier used Stripe's full Adaptive Acceptance suite and saw a combined 4% authorization rate uplift ($3M+ in additional revenue), with Card Account Updater contributing 2.76% and Adaptive Acceptance authorization optimization contributing 1.24%. Network tokens are one component of that toolkit, not the sole driver. If you process through multiple PSPs, or your platform doesn't offer built-in tokenization, gaps remain. Siloed dashboards also hide cross-processor patterns.

Use a tokenization service. Instead of building the infrastructure yourself, you integrate with a service that already manages the network relationships, vault operations, and token lifecycle. You get the authorization rate lift without the engineering burden.

## What the Right Implementation Looks Like

The r/ecommerce merchant who jumped from 88% to 93% illustrated that the outcome is worth chasing. The question is whether capturing that lift needs to consume your engineering team's quarter.

It doesn't. The right implementation path means:

**No development work.** The integration runs on your existing payments stack, not alongside a six-month engineering project.

**Results in days, not quarters.** A multi-channel retailer documented by The Digital Merchant went from 82% to 95% authorization rates after combining tokenization with processor consolidation and 3DS2 implementation. Tokenization was one of several factors in that 13-percentage-point improvement and $2.3M in annual revenue recovery, but the case illustrates what's possible when payment optimization gets dedicated attention.

**Cross-processor visibility.** If you process through more than one PSP, unified analytics surface patterns that siloed dashboards miss. You see where tokens perform differently across processors and geographies, and you optimize accordingly.

Corgi Intelligence gives you the cross-processor visibility to find and capture that lift. Your engineering team stays focused on your product, not your payments plumbing.

## Both Networks Are Raising the Bar on Token Infrastructure

Both Visa and Mastercard are investing heavily in token infrastructure. Mastercard's tokenization now covers more than 90% of Mastercard volume globally, with a new token requestor registry for fintechs launching in Q2 2026.

This signals a shift. Tokenization is moving from competitive advantage to baseline expectation. As Dwayne Gefferie wrote in his 2026 analysis: "The gap for most players isn't access to tools. It's absence of strategy to use them."

The merchants who tokenize now capture the lift as incremental revenue. The merchants who wait will eventually tokenize just to keep pace.

Your payments data is sitting on revenue you haven't captured yet. It's time to dig it up.

---

Sources

Visa Acceptance Solutions, "Why Tokens Are Key to Future Proofing Payments" (2025). [visaacceptance.com](https://www.visaacceptance.com/en-us/blog/article/2025/tokens-are-key-to-future-proofing-payments.html)

MRC, "2025 Global eCommerce Payments and Fraud Report" (2025). ([https://info.merchantriskcouncil.org/hubfs/Documents/Reports/Fraud%20Reports/2025_Global_Fraud_and_Payments_Report.pdf](https://info.merchantriskcouncil.org/hubfs/Documents/Reports/Fraud%20Reports/2025_Global_Fraud_and_Payments_Report.pdf)) Network tokenization delivers 2 to 6 percentage point authorization rate lifts.

Dwayne Gefferie, "The Authorization Rate Battle" (2026). [dwaynegefferie.substack.com](https://dwaynegefferie.substack.com/p/the-authorization-rate-battle)

Stripe Newsroom, "AI Enhancements to Adaptive Acceptance" (2024). [stripe.com](https://stripe.com/blog/ai-enhancements-to-adaptive-acceptance)

Stripe, "Zapier Customer Story" (2024). [stripe.com/customers/zapier](https://stripe.com/customers/zapier)

PYMNTS, "56% of US Consumers Experienced a False Payment Decline in Last 90 Days" (2024) ([https://www.pymnts.com/news/payments-innovation/2024/56-of-us-consumers-experienced-a-false-payment-decline-in-last-90-days/](https://www.pymnts.com/news/payments-innovation/2024/56-of-us-consumers-experienced-a-false-payment-decline-in-last-90-days/)).

Worldpay, "The C-Suite's Guide to Payment Authorization Rates." ([https://www.worldpay.com/en/insights/articles/c-suite-guide-to-auth-rates](https://www.worldpay.com/en/insights/articles/c-suite-guide-to-auth-rates))

Fiserv / Aite-Novarica / ClearSale, false decline cost ratios. Attributed via secondary industry coverage; primary source URLs not publicly available.

The Digital Merchant, multi-channel retailer case study (YouTube, 8,200 views).

---

### VAMP 2026: Two Months Later, the Playbook Is Taking Shape

Published: 2026-05-30 | https://www.corgilabs.ai/insights/vamp-2026-two-months-later

<video src="https://tcogpkjbcipaopdsvkgf.supabase.co/storage/v1/object/public/blog-videos/1779466255881-Balancing_the_VAMP_Ratio_2.mp4" controls playsinline preload="metadata" poster="https://tcogpkjbcipaopdsvkgf.supabase.co/storage/v1/object/public/blog-images/1779465766855-Vamp_Score.webp" style="display: block; margin-left: auto; margin-right: auto"></video>

## A Quiet Expansion Changed the VAMP Equation

On April 18, 2026, Visa expanded Compelling Evidence 3.0 to cover fraud reports that never become chargebacks. Most merchants haven't heard about it yet. But for anyone managing a VAMP ratio, this single change opens a defense mechanism that didn't exist five weeks ago.

Two months after the new 1.5% "Merchant Excessive" threshold took effect, the VAMP conversation has shifted. The panic phase is over. What's replaced it is something more interesting: an emerging operational discipline around fraud management, dispute prevention, and the uncomfortable tension between blocking fraud and blocking revenue.

## Quick Refresher: What Changed in April

If you've been tracking VAMP since its October 2025 enforcement launch, you know the basics. But the April 2026 changes are worth restating because they tightened the screws considerably.

**The threshold dropped.** The "Merchant Excessive" ratio fell to 1.5% for most global regions, with a minimum monthly count of 1,500 combined fraud reports and disputes. CEMEA regions kept a higher 2.2% threshold.

**The ratio formula is what makes VAMP different.** Your VAMP ratio combines TC40 fraud reports and TC15 disputes into a single number: (TC40s + TC15s) / Total Settled Transactions. This matters because TC40 fraud reports can hit your ratio even when they never escalate to a chargeback. A customer's bank flags a transaction as suspicious, Visa records a TC40, and your ratio takes the hit regardless of whether a dispute follows.

**The enforcement timeline is now fully live:**

1. October 1, 2025: "Excessive" level enforcement began
2. January 1, 2026: "Above Standard" level enforcement began
3. April 1, 2026: Merchant threshold dropped to 1.5%

First-time violators get a three-month grace period within a rolling 12-month window. After that, fines start at $8 per event.

## The Hidden Threat: Fraud Reports Without Chargebacks

Here's the scenario that's catching merchants off guard. Imagine you receive 100 TC40 fraud reports in a month but only 40 of those become actual chargebacks. Under older monitoring programs, the 60 non-disputed reports were background noise. Under VAMP, all 100 count against your ratio.

This creates a painful dynamic with friendly fraud, which accounts for roughly 75% of all disputes according to Visa's own data. A single friendly fraud incident can generate both a TC40 and a TC15. Both count. Your ratio absorbs the impact twice (with de-duplication only when both filings reference the exact same transaction).

**Before the CE3.0 expansion, merchants had no mechanism to challenge those 60 non-disputed TC40s.** They simply counted. You could refund them, but they still hit your ratio. That's the gap Visa addressed on April 18.

## CE3.0 Expansion: A New Line of Defense

Compelling Evidence 3.0 now lets you apply historical transaction data to TC40 fraud reports that lack a corresponding chargeback. If you can demonstrate at least two prior undisputed transactions from the same cardholder, with at least one matching data element being device ID or IP address, you can get those TC40s excluded from your VAMP calculation.

The evidence Visa accepts includes:

- Device ID matching a previous undisputed transaction
- IP address from a prior legitimate purchase
- Shipping address tied to past successful orders
- User account ID with transaction history

As Chargebacks911's Zak Matthews put it in April: merchants "finally have a mechanism to push back against TC40 fraud reports that never escalated to chargebacks." For the first time, you can protect your ratio from damage you previously couldn't prevent.

### The Limitations Are Real

CE3.0 isn't a blanket fix. The evidence requirements create meaningful gaps.

**First-time buyers can't be protected.** CE3.0 requires matching against historical transactions between 120 and 365 days old. If someone makes their first purchase and the bank files a TC40, you have no prior data to submit.

**Digital goods and early-cycle subscriptions are underserved.** If your disputes cluster in the first few months of a customer relationship, you won't have the 120-day evidence history CE3.0 demands.

**There's a cost.** Visa is introducing a fee for successful CE3.0 qualifications. Exact pricing isn't public yet, but it means even winning a CE3.0 challenge isn't free.

## Pre-Dispute Tools Are Now Table Stakes

CE3.0 is one layer. But the broader shift under VAMP is that pre-dispute tools have moved from "nice to have" to compliance infrastructure. Disputes resolved through Verifi CDRN, Ethoca, Rapid Dispute Resolution (RDR), and Order Insight are excluded from VAMP ratio calculations.

That exclusion changes the math entirely. **If a dispute never enters the VAMP formula, it's as if it never happened** from a compliance standpoint. This makes enrollment in pre-dispute programs a prerequisite for operating safely under VAMP, not an optimization.

The practical three-layer defense now looks like this:

1. **Pre-dispute deflection:** CDRN, Ethoca, and RDR resolve disputes before they become chargebacks
2. **Post-dispute representment:** CE3.0 challenges disputed transactions with historical evidence
3. **Non-disputed fraud remediation:** The new CE3.0 expansion addresses TC40s that never became disputes

Each layer excludes resolved cases from your VAMP ratio. Together, they give you multiple chances to keep your numbers clean.

## How Acquirers Are Responding

VAMP doesn't just monitor merchants. Acquirers face their own thresholds: 0.5% to 0.7% for "Above Standard" status and 0.7%+ for "Excessive." Fines start at $4 per event at the lower tier and $8 per event at the upper.

This pressure flows downhill. As Chargebacks911 put it: "It's not hyperbole to say that the Visa Acquirer Monitoring Program will reshape — and in some cases, sour — the relationship between merchants and acquirers." What that looks like in practice:

- **Tighter underwriting.** Acquirers are screening new merchants more carefully before onboarding, paying closer attention to industry vertical and historical chargeback patterns.
- **Higher fees for high-risk accounts.** Merchants approaching VAMP thresholds can expect surcharges or penalty pricing.
- **Faster terminations.** Acquirers are quicker to cut merchants who threaten their portfolio-level ratios. A single high-dispute merchant can drag an entire acquiring portfolio toward the threshold.

High-risk verticals feel this most acutely. European iGaming operators, for example, report card chargeback rates around 0.83%. That's well under the 1.5% merchant threshold, but it sits right in the danger zone for acquirer-level monitoring. Some operators are shifting volume to alternative payment methods where card-network chargeback rules don't apply.

## The False-Decline Trap

Here's where VAMP creates an uncomfortable paradox. The instinct when your VAMP ratio creeps up is to tighten your fraud rules. Block more. Decline more. Set lower thresholds on your fraud scoring.

**That instinct will cost you revenue.** Corgi Labs' analysis across merchant portfolios shows that for every $100 in false payment declines, merchants lose over $750 in lifetime value. Customers who get declined don't come back. They don't call support. They just leave and buy from someone else.

Worse, aggressive blocking can feed the cycle of friendly fraud. A customer whose legitimate order gets declined may try again with different details, get flagged again, and eventually dispute the charge out of frustration. That pattern is a recognized risk that compounds both revenue loss and dispute exposure.

The merchants adapting best to VAMP aren't blocking more. They're blocking smarter. They're using merchant-specific fraud models that can distinguish genuine buyers from actual fraud with enough precision to keep approval rates high while keeping chargebacks low. Blunt rules like "decline all orders over $500 from new customers" don't survive in a VAMP world.

## What to Do Now: A Practical Checklist

If you're managing VAMP compliance today, here's what the first two months have taught us about what works.

**Get visibility into your TC40s.** Most merchants track chargebacks. Fewer track the TC40 fraud reports that now feed their VAMP ratio. If you can't see your TC40 volume broken down by reason code and customer segment, you're flying blind.

**Enroll in pre-dispute programs.** If you aren't using CDRN, Ethoca, RDR, or Order Insight, every dispute that could have been deflected is counting against your ratio unnecessarily. The enrollment cost is trivial compared to VAMP fines.

**Audit your fraud rules for false declines.** Run a report on declined transactions from the past 90 days. How many were legitimate buyers? Every false decline is lost revenue today and a potential friendly-fraud dispute tomorrow.

**Monitor your acquirer relationship.** Ask your acquirer where you stand relative to their portfolio-level VAMP thresholds. If they're feeling pressure, you need to know before they make decisions about your account.

## From Compliance Burden to Competitive Advantage

Two months into the new VAMP thresholds, a pattern is emerging. Merchants who treat VAMP as a one-time compliance exercise are struggling. Merchants who've built it into their operational rhythm are finding something unexpected: the same discipline that keeps your VAMP ratio clean also makes your payments operation more profitable.

Precision fraud decisioning, trained on your own transaction data, does both jobs at once. It keeps chargebacks and fraud reports low enough to stay clear of VAMP thresholds. And it approves more real buyers that blunt fraud rules would have turned away. Corgi Model does exactly this: custom machine learning that blocks fraud, not buyers.

Your payments data holds the answer to both problems. [Book a demo](#book-demo) and see what precision looks like.

## Sources

1. Chargebacks911, "Visa Acquirer Monitoring Program: Major Visa Updates in 2026." [https://chargebacks911.com/visa-acquirer-monitoring-program/](https://chargebacks911.com/visa-acquirer-monitoring-program/)
2. Chargebacks911, "Compelling Evidence 3.0 Update, April 2026, Explained" (Zak Matthews, April 15, 2026). [https://chargebacks911.com/compelling-evidence-3-0-update-april-2026/](https://chargebacks911.com/compelling-evidence-3-0-update-april-2026/)
3. Chargebacks911, "VAMP Enforcement October 1, 2025: Merchant Impact Analysis." [https://chargebacks911.com/vamp-enforcement/](https://chargebacks911.com/vamp-enforcement/)
4. Finera, "iGaming Chargeback Protection: Strategies for Licensed Operators." [https://www.finera.com/blog/igaming-chargeback-protection-strategies-for-licensed-operators](https://www.finera.com/blog/igaming-chargeback-protection-strategies-for-licensed-operators)
5. Visa, "Introducing the Visa Acquirer Monitoring Program." [https://usa.visa.com/visa-everywhere/blog/bdp/2024/08/29/introducing-the-visa-1724958906425.html](https://usa.visa.com/visa-everywhere/blog/bdp/2024/08/29/introducing-the-visa-1724958906425.html)
6. Visa, "What Every Merchant Needs to Know About Friendly Fraud." [https://corporate.visa.com/en/sites/visa-perspectives/security-trust/what-every-merchant-needs-to-know-about-friendly-fraud.html](https://corporate.visa.com/en/sites/visa-perspectives/security-trust/what-every-merchant-needs-to-know-about-friendly-fraud.html)

---

### What Corgi Labs Actually Does on Top of Stripe Radar

Published: 2026-05-19 | https://www.corgilabs.ai/insights/corgi-custom-fraud-model-stripe-radar-connect-2

<video src="https://tcogpkjbcipaopdsvkgf.supabase.co/storage/v1/object/public/blog-videos/1779042852981-The_Cost_of_Average__Optimizing_Stripe_Radar_with_CORGI-v2.mp4" controls playsinline preload="metadata" poster="https://tcogpkjbcipaopdsvkgf.supabase.co/storage/v1/object/public/blog-images/1779042831614-Cover_What_a_Corgi_Labs_Actually_Does.webp" style="display: block; margin-left: auto; margin-right: auto"></video>

## A 1.33 Million Transaction Test

Stripe Radar blocks fraud across its entire network. That's its strength and its limitation. When your merchant's fraud profile diverges from the platform average, Radar over-blocks. Good buyers get declined. Revenue disappears.

We evaluated CORGI on a live Stripe Connect merchant across 19 rolling out-of-time windows (May 2024 to December 2025, approximately 1.33 million transactions). The results changed how we think about what "good enough" fraud prevention actually costs. This article walks through 10 questions that cover every technical detail: how the model works, what data it needs, how it isolates lift from Radar, and where it does (and doesn't) add value.

### 1. Measurable Lift Over Radar on Stripe Connect

We evaluated CORGI across the 10 windows where the model produced actionable signal (AUC 82.7% to 96.6%). The numbers tell a clear story:

**Dispute rate reduction:** 0.41% to 0.17% (59.5% reduction, 1,667 disputes prevented)

**Flag rate:** 0.53% of transaction volume, meaning 99.47% of transactions pass untouched

**Aggregate precision:** 45.7% (nearly half of flagged transactions were true disputes)

**Net revenue impact:** +$508K over the evaluation period ($525K in dispute savings minus $17K in margin loss from false declines)

**How We Isolate Lift from Radar**

Three mechanisms ensure we measure incremental lift, independent of attribution overlap.

CORGI trains exclusively on Radar-approved traffic. Its learned signal is, by construction, orthogonal to what Radar already catches. Any dispute CORGI identifies is one Radar missed.

Radar's outcome_risk_score is included as an input feature. SHAP analysis confirms the model's top predictors are merchant-specific behavioral aggregates (card fingerprint dispute velocity, spend spike detection, email-level volume anomalies) rather than the Radar score itself.

We account for blocked-transaction bias using a statistical estimation framework. Radar blocks a subset of traffic before CORGI observes it, creating missing dispute labels. We address this by training a stratifier on approved transactions, bucketing blocked transactions into the same score bins using isotonic calibration, and running 500 bootstrap iterations where synthetic dispute labels are drawn from the calibrated bucket rates. Metrics are reported as mean ± 95% CI. Validation against approved-only real labels shows tight agreement. For example, card fingerprint dispute history >2 shows 39.4% precision on combined traffic versus 40.9% on approved-only (CI [38.5%, 40.6%]), confirming minimal distortion from the imputation.

### 2. Platform-Wide Intelligence Without Cross-Merchant Contamination

CORGI trains separate per-merchant models. Each connected account gets its own feature tables (corgi_features.{account_id}_features), its own model, and its own threshold calibration. There is no shared model across merchants. One merchant's fraud distribution cannot pollute another's.

The "platform-wide intelligence" comes from the feature engineering layer, not model weight sharing. Features like card fingerprint dispute counts across the platform, or cross-merchant velocity signals, are computed as read-only aggregate inputs. A merchant's model can observe that a card has been disputed elsewhere on the platform, but its training labels and decision boundary are scoped entirely to its own transaction history.

This architecture costs more to operate than a single cross-merchant model (which is what Radar does). That's precisely why CORGI captures merchant-specific fraud patterns that Radar cannot.

### 3. Shadow Mode Metrics and Timeline to Statistical Significance

**What We Benchmark**

During shadow mode, CORGI scores every transaction but enforces no decisions. This gives you a direct comparison: you observe the actual outcome of every transaction and can measure exactly which ones CORGI would have blocked, what proportion were true disputes, and what revenue would have been recovered.

**The benchmarked metrics:**

**Approval uplift / good revenue recovered:** transactions Radar would have blocked that CORGI scores as safe, weighted by realized revenue without dispute

**Dispute rate reduction:** disputes CORGI would have prevented among Radar-approved traffic

**Precision and recall** at the selected operating threshold

**Flag rate:** percentage of transaction volume the model would intervene on

**Net revenue impact:** dispute savings minus margin lost on false declines (using a 3× dispute cost multiplier)

**False decline rate:** estimated good transactions blocked

**How Long It Takes**

Using a two-proportion z-test (α=0.05, power=0.80), the required sample sizes per arm are approximately:

- 190,000 payments to detect a 0.1pp absolute change in fraud rate
- 75,000 payments for a 0.2pp change in false positive rate
- 215,000 payments for a 0.1pp change in authorization rate

For a platform processing 60,000 to 80,000 transactions per month, meaningful results on the primary dispute-rate metric typically emerge within 8 to 12 weeks. Higher-volume platforms reach significance faster.

### 4. Where CORGI Sits in the Payment Flow

**The Inference Flow**

CORGI sits between payment method collection and PaymentIntent confirmation. After Stripe tokenizes the card but before authorization is sent to the issuer. Radar still runs at its normal position (during confirmation). Here's the sequence:

1. Customer enters payment details. Payment Element collects and creates a ConfirmationToken.
2. Token is sent to the platform backend, then routed to CORGI's pre-auth endpoint.
3. CORGI runs fraud scoring (LightGBM inference + rule engine, target <2s).
4. If approved: PaymentIntent.create(confirm: true, confirmation_token: token_id). Radar evaluates here as normal.
5. If blocked: PaymentIntent is not created. Decline is returned to the frontend.

**Latency**

The CORGI decision adds 100ms to 500ms depending on whether features are cached (Redis/Memorystore) or require a BigQuery lookup. This falls within the typical customer tolerance for a payment confirmation step. The decision runs server-side, so it does not affect page load or Payment Element rendering.

**Operational Risk**

Minimal. CORGI does not modify Stripe's authorization flow or interact with issuers. If CORGI's scoring service is unavailable, the fallback passes through to Stripe's normal confirm flow (Radar only). The integration requires one backend route change (redirect confirm calls through CORGI's endpoint) and a three-line frontend change (swap stripe.confirmPayment() for stripe.createConfirmationToken() + API call). No changes to Radar rules, webhook handlers, or settlement flows.

### 5. Where Custom Modeling Creates the Most Value (and Where It Doesn't)

**Biggest Impact Areas**

**False-decline reduction (approval uplift)** is typically the largest dollar lever. Our reference merchant recovered an estimated 5.6% of volume in good revenue that Radar was incorrectly blocking. For most merchants we analyze, false declines cost more than fraud losses. Radar's cross-merchant model over-blocks on merchants whose fraud profile diverges from the platform average.

**Fraud and dispute reduction** delivers meaningful but typically second-order impact. The same merchant saw a 59.5% dispute reduction in active model windows. Radar already does some work here, so the marginal lift is meaningful but usually not as large as the false-decline swing.

**Per-merchant custom modeling** unlocks per-entity rolling statistics that Radar cannot compute: z-score of transaction amount versus card's 180-day mean, all-time-max breach detection, card fingerprint dispute history, and spend velocity relative to behavioral baselines. Radar is a real-time rule engine, not a per-merchant feature store.

**Where We Typically Don't Add Value**

**Issuer authorization optimization:** We do not have direct issuer relationships and do not replace network tokenization, auth retries, or Auth Boost-style services.

**3DS routing optimization at the network level:** We decide whether to challenge with 3DS, but we don't optimize 3DS routing across networks.

**Merchants already running an effective custom fraud stack:** If a platform has built in-house ML on top of Radar, the marginal lift over their current stack will be smaller than the lift over Radar alone. We need to understand what's in place today to set expectations accurately.

### 6. How Shadow Mode Works on Stripe Connect

Shadow mode is a scoring-only deployment. CORGI receives webhook events for every transaction on the platform, scores them in real time, and logs the decision (approve/block + score + contributing features) without taking any action. Radar and existing rules remain fully in control.

**Technical Setup**

We subscribe to Stripe webhooks (charge., payment_intent., dispute., refund.) via the platform's Connect account. Feature computation runs against BigQuery on a rolling schedule. Each incoming transaction is scored against the current model, and the decision is stored with a full audit trail.

For live A/B testing after shadow mode, we use a deterministic hash-based allocation system (SHA-256 of the PaymentIntent ID mod a prime) to split traffic into treatment and control arms. This satisfies SUTVA (Stable Unit Treatment Value Assumption) at the payment level and allows clean causal measurement.

**Duration**

We typically run shadow mode for 8 to 12 weeks, depending on volume. The minimum is driven by the label maturity window: disputes typically surface 45 to 90 days after the transaction, so the first month of shadow data only becomes fully labeled two to three months later. For a high-volume platform, statistically significant results on the primary metrics (dispute rate, false decline rate) typically land within this timeframe.

### 7. What Data the Pilot Requires

**Required: Transactional Data**

- Charges and PaymentIntents: amount, currency, status, outcome, card metadata (brand, country, funding, fingerprint), CVC/AVS check results, Radar risk score and risk level
- Disputes: reason, status, amount, evidence submitted, resolution
- Refunds: amount, reason, timing
- Customers: ID, email, creation date (for velocity and behavioral features)

**Required: Merchant-Level Data**

- Connected account IDs to scope feature computation and model training per merchant
- Merchant category or vertical for baseline calibration

**Optional but Valuable**

- Historical data export (six to 12 months): enables backtest before shadow mode begins
- 3DS authentication results: for challenge rate analysis
- Behavioral/session data: we offer Corgi Beacon, a lightweight analytics tag that feeds browsing behavior into the model, but this is not required for the pilot

All data access during shadow mode is read-only.

### 8. Starting with Limited, Read-Only Access

Yes. For the pilot, we require:

- Read-only API key scoped to Payments, Disputes, Customers, and Refunds
- Webhook subscriptions for charge., payment_intent., dispute., refund.
- Optional one-time historical export for backtest (recommended: six to 12 months)

We do not need write permissions or broad account access during shadow mode. Write access is only required if and when we move to live decisioning, and even then it is scoped exclusively to PaymentIntent confirm/cancel via the ConfirmationToken flow. No access to payouts, transfers, account settings, or connected account management.

### 9. Required Versus Optional Merchant Attributes

**Required**

Transaction-level fields: amount, currency, card brand, card country, card funding type, card fingerprint, customer ID, and customer email. Plus dispute/fraud/chargeback labels: which transactions were disputed, reason code, and resolution.

These are the minimum inputs for CORGI's core feature families (velocity aggregates, z-score anomaly detection, card fingerprint dispute history, spend spike detection).

**Optional but High-Value**

- Billing address (postal code): enables geographic anomaly features
- 3DS authentication results: enables challenge rate optimization
- Product/SKU metadata: enables product-level risk profiling
- Session and behavioral data (via Corgi Beacon): browsing patterns, referral source, device fingerprint
- Merchant-level metadata (vertical, average order value, typical customer geography): improves baseline calibration

The model handles missing optional fields natively. LightGBM routes NaN values at each split, so absent features degrade gracefully rather than breaking inference.

### 10. Data Isolation: Your Data Stays Yours

CORGI trains separate, isolated models per merchant (connected account). Your platform's transaction data is used exclusively to build your model. It does not enter any shared training set, and no other customer's data enters your model.

Data isolation is enforced at the infrastructure level. Each connected account's features are stored in dedicated BigQuery tables (corgi_features.{account_id}_*), and model training runs are scoped to a single account's data. There is no cross-account weight sharing, no federated learning, and no aggregate model that blends multiple customers' data.

The one exception (which is opt-in) is platform-level aggregate signals. For example, if a card fingerprint has been disputed across multiple merchants on the same Connect platform, that cross-merchant signal can surface as a read-only feature. This is analogous to what Stripe Radar already does across its network, but scoped to your platform. The model weights remain per-merchant. Only the feature value is shared.

**What This Means for Your Platform**

The pattern is consistent across every evaluation we've run. Radar does good work at the network level, but it leaves money on the table for individual merchants. A custom model trained on your specific transaction data catches what a cross-network model cannot: the behavioral patterns, velocity anomalies, and card-level signals unique to your platform.

For the reference merchant in this evaluation, that gap was worth $508K in net revenue impact and a 59.5% reduction in disputes. Your numbers will differ based on volume, fraud profile, and what you're running today. Shadow mode exists to measure exactly that, with zero risk to your live traffic.

Ready to see what CORGI finds in your data? Book a shadow mode pilot and we'll have your first scoring results within weeks.

---

### Stripe Radar vs Custom ML: Why Network-Wide Fraud Models Miss Your Best Customers

Published: 2026-05-11 | https://www.corgilabs.ai/insights/stripe-radar-vs-custom-ml-fraud

She's bought from you 14 times in the past two years. She just upgraded her phone and is checking out from a hotel in Barcelona. She's shipping a birthday gift to her sister back home. New device. Foreign IP. Billing and shipping address mismatch. Your fraud system fires three rules at once and blocks the transaction.

She doesn't call support. She doesn't retry. She just leaves.

That wasn't a $100 problem. Factor in the lost sale, the lifetime value walking out the door, the wasted acquisition cost, and the brand damage. That single false decline cost you between $978 and $1,028.

Now multiply that across your entire customer base. US merchants lost $81 billion to false declines in 2023. Total global ecommerce fraud losses were $48 billion in the same year. Your fraud prevention system is blocking more legitimate revenue than fraudsters are stealing.

The ratio tells the story: for every $1 lost to actual fraud, merchants forfeit $30 by declining real buyers.

## Generic Fraud Rules Are Built to Over-Decline

Rules-based fraud systems seem logical on the surface. A new fraud pattern appears, so your team adds a rule to catch it. Then another pattern, another rule. Over months and years, the ruleset grows. It never shrinks.

Each rule makes the system more restrictive. The fraud filter gets tighter with every update, blocking more transactions with every new layer.

Here's what those rules actually flag:

- **Billing and shipping mismatch:** Could be fraud. More often, it's a gift.
- **IP and billing country mismatch:** Could be fraud. More often, the customer is traveling.
- **Multiple orders in quick succession:** Could be fraud. More often, it's a repeat buyer restocking.
- **High order value:** Could be fraud. More often, it's your best customer finding a product they love.
- **AVS mismatch:** Could be fraud. Stripe's own documentation notes that a card issuer might still consider a payment that fails CVC or postal code verification legitimate, and therefore approve it.

These rules don't know your business. They're calibrated to generic fraud patterns across all merchants. A supplement company's reorder pattern looks nothing like a luxury fashion brand's weekend splurge. But the same rules evaluate both.

Only 64% of ecommerce merchants even track their false decline rate. The other 36% can't see what their fraud system is doing to real buyers. When you can't measure false declines, you can't price them. Most finance teams model a $100 false decline as a $100 loss. The true cost is 10 times higher.

## Stripe Radar Is Strong. But It's Trained on Millions of Merchants, Not Yours.

Stripe Radar is a genuinely powerful fraud tool. It trains on data from millions of global companies processing more than $1.4 trillion in payments per year. There's a 92% chance any given card has been seen before on the Stripe network. Across all merchants, Radar reduces fraud by 38% on average.

Those numbers are impressive for good reason. Stripe has built one of the most data-rich fraud detection networks in payments.

But "on average" carries a lot of weight. Radar evaluates risk signals against patterns across all merchant verticals. A card that looks suspicious to the network model may be completely normal for your customer base. A luxury retailer's $2,000 Saturday transaction looks different from a SaaS company's $49 monthly renewal. Radar's model scores both against the same cross-merchant patterns.

Stripe knows this, too. Their documentation is direct: "The integration you choose affects the completeness of the risk factors you send to Stripe. The more payment data you capture, the better Radar can detect and prevent fraud".

Stripe Radar does excellent work with network-level signals. What it can't do is learn what YOUR buyers specifically look like. That's not a flaw. It's the nature of a model trained across millions of merchants. The opportunity is adding a layer that fills that gap.

## What "Trained on Your Data" Actually Means

"Custom machine learning trained on your data" isn't a marketing phrase. It describes a specific process.

Here's how it works. Your full transaction history becomes labeled training data. Every transaction carries a signal: was it later confirmed fraudulent? Did it result in a chargeback? Or was it approved, fulfilled, and never disputed? A classification model learns which patterns in YOUR data actually predict fraud for YOUR business.

That model then scores each incoming transaction in real time, alongside Stripe's authorization flow.

What changes when the model knows your buyers:

- A luxury fashion buyer spending $2,000 on a Saturday afternoon from a new device doesn't look like fraud. It looks like a weekend shopping pattern that repeats every 30 days.
- A supplement subscriber placing an identical order from a different country doesn't look like fraud. It looks like a traveler restocking.
- A first-time buyer with a geo mismatch who visited your site 12 times before purchasing doesn't look like fraud. It looks like high purchase intent.
- A long-term customer who upgrades their phone and presents a new device fingerprint doesn't look like fraud. It looks like a phone upgrade.

Generic models score each transaction against population-level patterns. Merchant-specific models score each transaction against YOUR population. The difference matters most for your best customers. Their behavior looks "unusual" to a generic model but completely predictable in the context of your business.

## The Difference in Outcomes: Your Best Customers Pay the Highest Price

False declines don't hit all customers equally. The data on loyal customers is striking.

When you false-decline a customer who has made three or more previous purchases, their future order volume drops by 65%. Even the loyal customers who do return spend 16% less per order. The relationship doesn't fully recover.

Across all customers, 40% to 42% never return after a false decline. And 32% post about the experience publicly online.

Rules-based systems and cross-merchant network models can't factor in customer tenure from your platform. They don't know that the transaction they're about to block is from someone who has purchased from you 14 times. They evaluate each transaction in isolation. Custom ML trained on your data learns that tenure is predictive. A buyer with 14 successful transactions is a fundamentally different risk profile than a first-time buyer, even when both trigger the same flags.

The outcomes from merchant-specific models reflect this. One ecommerce company processes $40 million in annual revenue across US and Singapore markets. After adding Corgi Model alongside Stripe, they saw a 22% increase in payments accepted, an 18% reduction in realized fraud, and more than $2 million in additional revenue.

Across Corgi's merchant base, results include 3% to 12% revenue increases from recovered false declines and 70% to 95% chargeback reductions without rejecting good customers. False declines drop by up to 45%.

## What to Do Next

Start by measuring what you can't currently see.

If you're among the 36% of merchants who don't track false declines, that's step one. Pull your decline data from Stripe and categorize it. How many blocked transactions came from returning customers? How many matched common false-flag patterns like address mismatches or geo discrepancies?

Then do the math with your own numbers. Take your average order value, your customer lifetime value, and your acquisition cost. Apply the $978-per-$100 cost framework. The number will likely surprise you.

If you process on Stripe and want to see what a model trained on your transaction data would catch, Corgi Labs can run that analysis. No development work on your side. Corgi Model works alongside Stripe Radar, adding merchant-specific intelligence on top of Stripe's network-level fraud detection. You keep everything that makes Radar strong and add a layer that learns what your buyers actually look like.

Your fraud system should know your customers as well as you do. When it doesn't, the cost isn't theoretical. It's $1,000 per decline, compounding with every good buyer you turn away.

[Book a Demo →](#book-demo)

---

### Sources

1. PYMNTS Intelligence & Nuvei, "Fraud Management, False Declines and Improved Profitability" (November 2023) — [https://www.pymnts.com/study/fraud-management-false-declines-improved-profitability-ecommerce](https://www.pymnts.com/study/fraud-management-false-declines-improved-profitability-ecommerce)
2. Forter, "2023 Consumer Trust Premium Report" — [https://explore.forter.com/2023trustpremiumreport/p/1](https://explore.forter.com/2023trustpremiumreport/p/1)
3. ClearSale, "State of Consumer Attitudes on Ecommerce, Fraud, & CX 2023-2024" — [https://en.clear.sale/blog/report-state-of-consumer-attitudes-on-ecommerce-fraud-cx-2023-2024](https://en.clear.sale/blog/report-state-of-consumer-attitudes-on-ecommerce-fraud-cx-2023-2024)
4. Stripe Radar product page — [https://stripe.com/radar](https://stripe.com/radar)
5. Stripe Radar documentation, "Optimize Risk Factors" — [https://docs.stripe.com/radar/optimize-risk-factors](https://docs.stripe.com/radar/optimize-risk-factors)
6. Stripe Radar Rules documentation — [https://docs.stripe.com/radar/rules](https://docs.stripe.com/radar/rules)
7. Stripe, "AI Enhancements to Adaptive Acceptance" (2024)
8. Corgi Labs, "Your Fraud System Is Your Most Expensive Revenue Leak" — [https://www.corgilabs.ai/insights/false-declines](https://www.corgilabs.ai/insights/false-declines)
9. Corgi Labs case study and product documentation — [https://www.corgilabs.ai](https://www.corgilabs.ai)

---

### You Can't See Your Agent Channel Yet. Here's How to Fix That.

Published: 2026-04-16 | https://www.corgilabs.ai/insights/agent-payments-intelligence-stripe-visibility

Every agent-initiated purchase on Stripe looks identical to a human-initiated one after settlement. That's becoming an expensive blind spot.

Stripe has shipped the primitives you need to sell through AI agents: Shared Payment Tokens (SPTs), the Agentic Commerce Protocol, agentic network tokens from Visa and Mastercard, BNPL over SPT, and the Agentic Commerce Suite. The first merchants to go live (Coach, URBN, Ashley Furniture, and Kate Spade) are processing agent traffic from confirmed integrations like ChatGPT Instant Checkout and Microsoft Copilot Checkout, with additional partners like Perplexity in earlier stages.

Ask a payments lead at one of those merchants how their agent channel is performing. They can't tell you. The data isn't there.

## The Persistence Problem

Here's the technical reality most teams haven't caught up to yet.

When an agent initiates a purchase, Stripe creates a Shared Payment Token: an `spt_`-prefixed object scoped to a single transaction, time-limited, and carrying Radar risk signals from the agent side. The merchant confirms a PaymentIntent with the SPT.

But at confirmation time, Stripe clones the underlying payment method and sets the PI's `payment_method` field to the clone. The SPT is consumed. The resulting charge object that lands in your Sigma tables, your BigQuery sync, or your data warehouse looks structurally identical to a normal card-on-file transaction.

As of April 2026, there is no `is_agentic` field on the charge. No `channel = "agent"` enum on the PaymentIntent. No agent platform attribution. **The distinction between a checkout inside ChatGPT and one on your own website disappears** in most standard reporting surfaces the moment the PI settles.

This is a defensible engineering choice. It keeps the downstream reporting surface consistent, refunds behave the same way, and legacy integrations don't break. But it leaves every merchant on the Agentic Commerce Suite unable to answer a basic question: *how is my agent channel performing?*

## Why "Just Tag the Metadata" Isn't Enough

The obvious workaround is to tag the PaymentIntent metadata yourself, setting `metadata.channel = "agentic"` at the moment of PI creation. Your backend knows this is an SPT flow because it's running a different code path. One extra line.

In practice, this fails for three reasons:

1. **It requires engineering effort.** Agent traffic is still a small enough share of revenue that it rarely makes the sprint.
2. **Tagging conventions drift.** Some teams use `agentic`, some use `agent`, some use `ai_channel`. Reconciling across them becomes its own cleanup project.
3. **It only covers new integrations.** Every merchant already live on the Suite has a back catalog of agent transactions that were never tagged. You can't retroactively fix that.

The better answer is to detect agent transactions passively, without asking the merchant to change anything.

## What We Built

Corgi's agent payments intelligence layer sits on top of the webhook subscriptions we already maintain on merchant Stripe accounts.

When a merchant confirms a PaymentIntent with an SPT, Stripe fires webhook events related to the shared payment token lifecycle. Our pipeline correlates these events with the resulting PaymentIntent to identify SPT-originated transactions. We write the association to a dedicated table (`agentic_transactions`) with the SPT ID, PaymentIntent ID, merchant account ID, and the event timestamp.

From there, every downstream metric in our pipeline gets an `is_agentic` flag through a join on PaymentIntent ID.

**No merchant code changes. No metadata discipline. No retroactive cleanup.** If we have webhook access to your Stripe account, we detect agentic transactions from the moment we connect. We can't recover pre-integration history, but from that point forward, no agent transaction goes untagged.

The same pipeline captures SPT revocation and expiry events, which matter for a specific class of agent fraud covered below.

## What the Analytics Show You

Once the detection layer is running, the real question becomes: what do agent transactions actually look like compared to human ones?

### Authorization Rates Diverge

Early agent traffic on SPTs tends to authorize higher than card-on-file for two reasons. Many SPT transactions use network tokens, which issuers trust more than raw PANs. Mastercard reports a 2.1% auth rate lift for tokenized transactions, and Visa cites 4.6%.

The risk signals Stripe forwards with the SPT (card testing likelihood, stolen card indicators, chargeback history) are also stronger than what issuers typically see on a standard ecommerce transaction. If your auth rate on agent traffic is *lower* than your card-on-file baseline, something is likely wrong with your integration, not with the channel.

### Decline Distributions Are Expected to Shift

Issuers are rolling out new authorization logic for Visa Intelligent Commerce and Mastercard Agent Pay. Based on early patterns, we expect the mix of `do_not_honor`, `insufficient_funds`, `invalid_account`, and network-declined reasons to look different for agent traffic.

If your retry logic is tuned to human-channel declines, it will likely make the wrong call a meaningful fraction of the time.

### Dispute Rates Are the Headline Metric

Stripe has publicly reported near-zero fraud on the first wave of Suite merchants. That's accurate for the early cohort: enterprise brands with mature fraud programs and a filtered customer base (buyers logged into Copilot or ChatGPT with saved payment methods).

As agent traffic scales past early adopters, expect the chargeback rate to move in ways that differ from human patterns. Two scenarios illustrate why:

- **Scope disputes.** "I didn't authorize this purchase" claims get murkier when a buyer delegated authority to an agent but says the agent exceeded scope.
- **Signal loss.** Traditional fraud signals vanish: no browser fingerprint, no mouse movement, no device telemetry. Fraud models tuned on human traffic will produce false declines on legitimate agents and miss adversarial ones at the same time.

### Platform Attribution Matters for GTM

Consider a merchant processing $50 million annually through the Suite. If 80% of their agent volume comes from ChatGPT and 5% from Copilot, that's a very different partnerships conversation than a 40/40 split. Without channel-level data, these decisions get made on gut feel.

## The Fraud Model Gap

Every fraud model in production today was trained on human payment traffic. Those models rely on signals that don't exist in agentic flows:

- How the user navigated to checkout
- What device they used
- How they typed their card number
- What else they did on the page

In an agentic world, the "user" is an API call. There is no device, no session, no typing cadence.

This creates two failure modes at once. Legitimate agent traffic gets scored as suspicious because it doesn't look human, leading to block rates that cost real revenue. Adversarial agents that *do* look human enough (scripted to mimic human behavior) slip past models never designed to catch them.

The answer isn't to throw out your fraud model. It's to know which transactions need to be scored by which model. That requires three things: a reliable channel flag, a drift monitor that alerts you to distribution shifts on agent traffic, and a retraining trigger indexed on agent volume crossing a threshold. Corgi Intelligence provides all three.

## Why We Built This First

Our merchants started asking. Not in the abstract, but with specific questions.

*"Can you tell me what my chargeback rate looks like on ChatGPT orders versus direct checkout?"*

That question had no answer in Stripe's dashboard. As far as we've been able to determine, it had no answer in other third-party tooling either. We shipped the first version in a week because the lift was small and the need was obvious.

We're among the first fraud intelligence platforms with a production detection layer for agentic commerce transactions on Stripe. Not because the idea was hidden, but because the infrastructure we already had (live webhook ingestion across merchant Stripe accounts) turned out to be the right foundation. We didn't build new plumbing. We recognized that one additional event type closed the analytics gap.

## Where This Goes Next

Agent payments intelligence is the starting point. The longer-term product is a fraud model explicitly trained on agentic traffic, one that uses SPT risk signals, agent platform attribution, and behavior patterns absent from any human-channel dataset.

The detection layer makes that training set possible. Every merchant we onboard adds labeled agent transactions to a growing corpus of agentic commerce data, the foundation for models purpose-built for a channel that barely existed 18 months ago.

If you're running a Stripe integration and you're live on the Agentic Commerce Suite (or about to be), the question worth asking your team this week is simple. *When the board asks how our agent channel is performing, what exactly will we show them?*

If the answer is "we'll figure it out later," we should talk.

[Be part of our CLOSED BETA](/beta/agentic-intelligence)

---

*Corgi Labs is a Y Combinator-backed payments intelligence platform built natively on Stripe. We help merchants detect fraud, recover false declines, and see their agent channel clearly. *

---

## Sources

1. Stripe, "Introducing the Agentic Commerce Suite" — [https://stripe.com/blog/agentic-commerce-suite](https://stripe.com/blog/agentic-commerce-suite)
2. Stripe, "Agentic Commerce Suite" (newsroom announcement) — [https://stripe.com/newsroom/news/agentic-commerce-suite](https://stripe.com/newsroom/news/agentic-commerce-suite)
3. Stripe, "Shared Payment Tokens" (documentation) — [https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens](https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens)
4. Stripe, "Developing an Open Standard for Agentic Commerce" — [https://stripe.com/blog/developing-an-open-standard-for-agentic-commerce](https://stripe.com/blog/developing-an-open-standard-for-agentic-commerce)
5. Stripe, "10 Things We Learned Building for the First Generation of Agentic Commerce" — [https://stripe.com/blog/10-lessons](https://stripe.com/blog/10-lessons)
6. Stripe, "Stripe Powers Instant Checkout in ChatGPT" — [https://stripe.com/newsroom/news/stripe-openai-instant-checkout](https://stripe.com/newsroom/news/stripe-openai-instant-checkout)
7. Stripe, "Microsoft Copilot and Stripe" — [https://stripe.com/newsroom/news/microsoft-copilot-and-stripe](https://stripe.com/newsroom/news/microsoft-copilot-and-stripe)
8. Stripe, "Supporting Additional Payment Methods for Agentic Commerce" — [https://stripe.com/blog/supporting-additional-payment-methods-for-agentic-commerce](https://stripe.com/blog/supporting-additional-payment-methods-for-agentic-commerce)
9. Solidgate, "Network Tokenization and Authorization Rates" — [https://solidgate.com/blog/network-tokenization-authorization-rates/](https://solidgate.com/blog/network-tokenization-authorization-rates/)
10. Mastercard, "Agent Pay: Pioneering Agentic Payments Technology" — [https://www.mastercard.com/global/en/news-and-trends/press/2025/april/mastercard-unveils-agent-pay-pioneering-agentic-payments-technology-to-power-commerce-in-the-age-of-ai.html](https://www.mastercard.com/global/en/news-and-trends/press/2025/april/mastercard-unveils-agent-pay-pioneering-agentic-payments-technology-to-power-commerce-in-the-age-of-ai.html)
11. Y Combinator, "Corgi Labs" — [https://www.ycombinator.com/companies/corgi-labs](https://www.ycombinator.com/companies/corgi-labs)

---

### Japan's Chargeback Rate Looks Perfect. That's the Problem.

Published: 2026-04-14 | https://www.corgilabs.ai/insights/japan-fraud-hidden-crisis

Your Japan PSP dashboard probably looks clean. Clearly Payments data shows Japan's chargeback rate at 0.18%, tied with China for the lowest in the world and less than half the US rate of 0.47%. That number is accurate, and it's also the wrong number to watch.

Behind that reassuring metric, Japan's National Police Agency reported ¥307.5 billion in tracked fraud losses for 2024, an 89.1% increase year over year. Credit card fraud alone set a new record. If you're managing authorization rates and fraud exposure across multiple processors in Asia-Pacific, Japan's chargeback rate is giving you a false signal of safety.

## What Japan's Fraud Numbers Actually Show

The headline figure is striking, but the category breakdown tells you where the risk concentrates.

Japan's NPA tracked 57,324 fraud cases in 2024, up 24.6% from the prior year. The two fastest-growing categories are part of a broader tracked total, and they account for most of the surge: **specialized fraud** (phone scams and impersonation) at ¥71.8 billion, up 58.6%, and **social media investment and romance fraud** at ¥127.2 billion, which nearly tripled.

Credit card fraud, the category most directly relevant to ecommerce merchants, hit ¥55.5 billion in 2024. That's up from ¥54.1 billion in 2023 and ¥43.6 billion in 2022, according to the Japan Consumer Credit Association. The upward trend has been consistent and accelerating.

Here's the detail that matters most for card-not-present merchants: KOMOJU reports that 93.3% of Japan's credit card fraud in 2023 came from card number theft. The vast majority of card fraud is happening online, at checkout, where your fraud models make their decisions.

## Why Chargebacks Stay Low While Fraud Climbs

How does a country post record fraud losses while maintaining the world's lowest chargeback rate? The gap isn't a data error. It's a structural feature of how Japan handles payment disputes.

Consider a merchant processing $10 million annually through a Japan-facing PSP. Your chargeback dashboard shows a rate well under 0.20%. You'd reasonably conclude your fraud exposure is under control. But three things are happening that chargebacks don't capture:

1. **Japanese consumers are culturally less likely to initiate chargebacks.** Stripe's Japan payments guide notes that Japanese issuers are slower to issue chargebacks compared to issuers in other countries, and that each one tends to receive more attention when it does occur. The low rate reflects consumer behavior, not low fraud.
2. **Non-chargeback resolution paths absorb potential disputes.** Japan's consumer protection infrastructure likely routes many fraud complaints through mediation and resolution channels outside the chargeback process, reducing the volume that reaches card networks.
3. **The fastest-growing fraud categories rarely trigger a chargeback.** Social engineering, account takeover, and investment scams involve victims who authorize the transaction themselves under false pretenses. Your fraud rules won't flag it. Your chargeback metrics won't register it.

## The Criminal Infrastructure Has Changed

The fraud operators behind these numbers aren't who you'd expect. Japan's traditional organized crime groups, the yakuza, are no longer the primary fraud infrastructure.

The Japan Times reports that **tokuryuu networks** (anonymous, loosely organized criminal groups) have overtaken yakuza in fraud-related arrests. These groups recruit through social media "dark part-time job" listings, assemble for specific operations, and disband quickly. They drove more than 10,000 arrests in 2024.

For merchants, this matters because tokuryuu operations are fast, distributed, and harder to pattern-match. They run social media investment scams, phone fraud, and card fraud through rapidly assembled teams. The Japan Times and NPA data also link tokuryuu activity to card-not-present fraud schemes. The average loss per investment fraud case reached ¥13.6 million per victim. These are not low-sophistication attacks.

## The Attack Surface Is Growing Fast

Japan's cashless transition is expanding the digital payment volume that fraud actors target. METI reported that cashless payments reached 42.8% of consumer spending in 2024, with the government pushing toward an 80% target.

The QR code payment market alone hit ¥21.5 trillion in FY2024, up 23.9% year over year according to Yano Research. PayPay, the dominant mobile wallet, reached 70 million registered users as of July 2025, commanding roughly 64% of QR and barcode payment volume.

More digital payment volume means more surface area for fraud. And the expansion isn't just domestic.

Japan welcomed a record 36.87 million inbound tourists in 2024, per the Japan National Tourism Organization. Cross-border card-not-present transactions introduce authentication patterns that generic fraud models handle with blunt, region-agnostic rules. Industry analysis consistently shows that region-specific risk patterns rarely generalize, which forces effective detection to rely on localized models.

## The 3DS Mandate: Compliance That Creates a New Problem

Japan's April 2025 EMV 3DS mandate added urgency to all of this. The JCA Credit Card Security Guidelines now require 3D Secure authentication for all online credit card transactions. Merchants who haven't implemented 3DS bear full liability for fraud-related chargebacks.

That's the compliance side. The conversion side is the problem you need to watch.

The risk is real: 3DS can disrupt the checkout experience and suppress conversions if your implementation relies on challenge flows rather than risk-based authentication. Every transaction that hits a challenge screen is a chance for a legitimate buyer to abandon the purchase.

There's a precedent worth noting. When the EU implemented Strong Customer Authentication under PSD2, merchants initially saw conversion drops. But over time, many saw fraud decrease, trust grow, and acceptance rates improve after proper implementation. **The outcome depends entirely on how well 3DS is configured**, and that configuration depends on having accurate risk signals for Japan-specific transactions.

## Why Generic Fraud Models Miss Japan

If your fraud detection runs on pooled data from a global processor, it wasn't trained on the patterns that define Japan's payment landscape.

JCB, Japan's domestic card network, illustrates the problem. In 2022, JCB launched the **FARIS Joint Scoring Service** with IWI and PKSHA Technology, the first shared fraud data scoring service built specifically for Japanese card issuers. JCB built FARIS because existing rule-based and generic detection tools were insufficient for Japanese transaction patterns.

Japan's payment mix includes behaviors that look anomalous to models trained on US or European data:

- **JCB-specific authentication flows** that differ from Visa and Mastercard protocols
- **Konbini (convenience store) payments** where customers complete online orders with cash at 7-Eleven or Lawson
- **Domestic mobile wallets** like PayPay that process outside traditional card rails
- **Seasonal spending spikes** during Golden Week, Obon, and year-end gift-giving periods that generic models read as velocity anomalies

A fraud model trained on pooled global data will either miss Japan-specific fraud patterns or over-flag legitimate Japanese buying behavior. Both outcomes cost you revenue.

## What Merchant-Specific Modeling Changes

The alternative is a model trained on your transaction data, learning the patterns specific to your Japan-facing business.

As Ravelin's fraud research notes, it's best to use your own customer data for your business, since different business models can have very different customer order cycles and amounts. A merchant-specific model learns what normal looks like for your Japan customers, not for a global average.

This approach changes three things:

1. **Fraud detection improves** because the model recognizes Japan-specific attack patterns (card number theft at checkout, tokuryuu-driven account takeover) rather than applying global thresholds.
2. **False declines drop** because the model understands that a ¥150,000 order during Golden Week from a JCB cardholder is normal for your business, not a risk flag.
3. **3DS configuration gets smarter** because accurate risk scoring lets you route low-risk transactions through low-friction 3DS flows, maintaining conversion rates while staying compliant with the JCA mandate.

Your data also stays isolated to your business, which aligns with Japan's strict data handling expectations and financial regulatory standards.

## Three Things to Audit Now

Japan's fraud numbers are climbing, chargebacks aren't reflecting it, and the 3DS mandate is changing the rules. Here's where to start:

1. **Stop using chargeback rate as your Japan fraud indicator.** Look at fraud-related declines, authorization rate gaps between Japan and your other markets, and transaction velocity anomalies that your current tooling might classify as normal.
2. **Audit your 3DS implementation for conversion impact.** If you're running challenge flows on all Japan transactions rather than risk-based authentication, you're likely losing real buyers. Measure your Japan authorization rate before and after the April 2025 mandate.
3. **Evaluate whether your fraud model understands Japan.** If your detection is processor-locked or trained on pooled global data, it's not seeing JCB-specific patterns, konbini payment flows, or domestic wallet behavior.

Getting visibility into what's actually happening in your Japan payments data is the first step. Corgi Labs builds custom fraud models trained on merchant-specific data and cross-processor analytics that surface the patterns generic tools miss. If your Japan exposure is growing and your chargeback rate looks too clean, it's worth digging into what that number isn't telling you.

[Book a demo](#book-demo)

---

## Sources

1. Clearly Payments, "Chargeback Rate by Country in Payments" (April 2024) — [https://www.clearlypayments.com/blog/chargeback-rate-by-country-in-payments/](https://www.clearlypayments.com/blog/chargeback-rate-by-country-in-payments/)
2. Nippon.com, "Crime Figures in Japan Rise Again in 2024" — [https://www.nippon.com/en/japan-data/h02649/](https://www.nippon.com/en/japan-data/h02649/)
3. Japan Consumer Credit Association (JCA), Credit Card Fraud Survey 2024 — via Statista: [https://www.statista.com/statistics/1232728/japan-credit-card-fraud-losses/](https://www.statista.com/statistics/1232728/japan-credit-card-fraud-losses/)
4. KOMOJU, "E-Commerce Fraud Protection Guide 2025" — [https://en.komoju.com/blog/payment-method/e-commerce-fraud-protection/](https://en.komoju.com/blog/payment-method/e-commerce-fraud-protection/)
5. Stripe, "How to Accept Payments in Japan" — [https://stripe.com/resources/more/payments-in-japan-an-in-depth-guide](https://stripe.com/resources/more/payments-in-japan-an-in-depth-guide)
6. Japan Times, "New Tokuryuu Crime Groups Outpace Yakuza in Arrests" — [https://www.japantimes.co.jp/news/2025/04/03/japan/crime-legal/npa-organized-crime/](https://www.japantimes.co.jp/news/2025/04/03/japan/crime-legal/npa-organized-crime/)
7. METI, "2024 Ratio of Cashless Payment" (March 2025) — [https://www.meti.go.jp/english/press/2025/0331_001.html](https://www.meti.go.jp/english/press/2025/0331_001.html)
8. Yano Research, "QR Code Payment Market Reached 21 Trillion Yen in FY2024" — [https://www.yanoresearch.com/en/press-release/show/press_id/3896](https://www.yanoresearch.com/en/press-release/show/press_id/3896)
9. PayPay Corporation, "70 Million Registered Users" (July 2025) — [https://about.paypay.ne.jp/en/pr/20250715/01/](https://about.paypay.ne.jp/en/pr/20250715/01/)
10. Japan National Tourism Organization, 2024 Visitor Statistics — [https://www.jnto.go.jp/](https://www.jnto.go.jp/)
11. Forter, "JCA EMV 3DS Mandate" — [https://www.forter.com/blog/new-guidance-from-japan-credit-associate-jca-on-emv-3ds-mandate/](https://www.forter.com/blog/new-guidance-from-japan-credit-associate-jca-on-emv-3ds-mandate/)
12. JCB / IWI / PKSHA Technology, FARIS Joint Scoring Service Announcement — [https://www.iwi.co.jp/news/2022/11/iwipkshafaris-powered-by-pksha-security.html](https://www.iwi.co.jp/news/2022/11/iwipkshafaris-powered-by-pksha-security.html)
13. Ravelin, "Machine Learning for Fraud Detection" — [https://www.ravelin.com/insights/machine-learning-for-fraud-detection](https://www.ravelin.com/insights/machine-learning-for-fraud-detection)
14. Nippon.com, "Fraud and Crime Data in Japan 2024" — [https://www.nippon.com/en/japan-data/h02424/](https://www.nippon.com/en/japan-data/h02424/)

---

### Visa VAMP 2026: Your Compliance Math Changed on April 1

Published: 2026-04-02 | https://www.corgilabs.ai/insights/vamp-2026-merchant-compliance

<video src="https://tcogpkjbcipaopdsvkgf.supabase.co/storage/v1/object/public/blog-videos/1775162367055-Visa_VAMP_2026__The_5-Step_Compliance_Audit.mp4" controls playsinline preload="metadata" poster="https://tcogpkjbcipaopdsvkgf.supabase.co/storage/v1/object/public/blog-images/1775163096672-Visa_VAMP_2026__cover.webp" style="display: block; margin-left: auto; margin-right: auto"></video>

> **TL;DR**
> 
> - Visa’s Visa Acquirer Monitoring Program (VAMP) merchant threshold dropped from 2.20% to 1.50% on April 1st, 2026. If you were sitting just under the old line, you may already be in violation without changing a thing.
> - The new formula merges fraud reports and disputes into a single ratio and one transaction can count against you twice. It’s measured by count, not dollars, so high-volume merchants carry more exposure.
> - Over-blocking fraud doesn’t help. Declining legitimate transactions shrinks the denominator of the ratio without reducing the numerator, which can push you further out of compliance.
> - The path forward is dual optimization: approve more real transactions to grow the denominator while cutting fraud and disputes to shrink the numerator. That’s a different discipline than chargeback management alone.

**On April 1st, 2026, the Visa Acquirer Monitoring Program (VAMP) merchant threshold for fraud-and-dispute ratio decreased from 2.20% to 1.50%.** That’s a 32% reduction, effective overnight. If your combined fraud-and-dispute ratio was sitting at 1.8% in March, you were compliant. So on April 2, with the exact same transaction volume and dispute count, you will be in violation and subject to penalties. 

This isn’t an incremental policy tweak. The VAMP restructured how network-level risk enforcement works for card-not-present merchants. It unifies fraud reports and disputes into a single ratio, introduces a mechanism where one transaction can count twice against you, and creates cascading pressure from Visa to acquirers to merchants. For risk directors at high-volume eCommerce platforms, April 1st turned compliance from a backward-looking chargeback management task into a forward-looking optimization problem.

Here’s what the new math looks like, why it’s harder than the old math, and what you can do about it.

## The Threshold Shift: 420 Fewer Allowable Incidents at the Same Volume

The numbers tell the story clearly. Under the prior threshold, a merchant processing 60,000 transactions per month could absorb up to 1,320 combined fraud-and-dispute events before entering Visa's "Excessive" monitoring tier. Under the April 1 threshold of 1.50%, that ceiling drops to 900 events. That's 420 fewer allowable incidents for the exact same transaction volume (Source: Coinflow, 2026).

A merchant operating at 1,050 incidents per month (a 1.75% ratio, comfortably compliant under the old rules) now exceeds the threshold without any operational change (Source: Coinflow, 2026). The new limits apply to merchants in the US, Canada, EU, and APAC. The CEMEA region remains at 2.20% (Source: Basis Theory, 2026; Forter, 2025). Latin America and the Caribbean was already at 1.50% before April 2026 (Source: Basis Theory, 2026).

The enforcement timeline matters too. Visa began enforcing Above Standard fines against acquirers in January 2026, adding pressure to thresholds that have been in place since VAMP launched in June 2025. Merchant thresholds tightened further on April 1. First-time violators get a three-month grace period before fines begin (Source: Chargebacks911, 2025; Forter, 2025; Ravelin, 2025). (This applies to merchants not enrolled in VAMP monitoring within the prior 12 months.) That grace period is the window you're in right now if your ratio crossed the new line.

## What VAMP Actually Measures, and Why One Transaction Can Count Twice

The VAMP ratio formula is: (TC40 Fraud Reports + TC15 Disputes) / TC05 Settled Transactions (Source: Basis Theory, 2026; Chargebacks911, 2025; Forter, 2025). Three things about this formula deserve close attention.

**It unifies fraud and disputes into one number.** Prior programs tracked fraud monitoring and dispute monitoring separately. VAMP collapses them. A fraud alert (TC40) and a chargeback (TC15) from the same transaction both count against your ratio. One disputed transaction can generate two events, hitting your ratio twice. Forter's analysis notes this creates the potential for fines on a single disputed transaction from two separate penalty events (Source: Forter, 2025).

**It's count-based, not dollar-based.** Visa calculates VAMP ratios by transaction count, not transaction value. A marketplace with $200M in gross merchandise value across millions of low-price-point orders faces far more ratio exposure per dollar of revenue than a merchant with the same GMV concentrated in fewer high-value orders (Source: Basis Theory, 2026; Ravelin, 2025; MRC, 2025). The minimum monitoring threshold of 1,500 combined fraud-and-dispute events per month means high-volume operators are almost always in scope (Source: Basis Theory, 2026; Ravelin, 2025; Equifax, 2025).

**It only counts card-not-present transactions.** VAMP targets eCommerce specifically. Only CNP transactions enter the TC05 denominator (Source: Chargebacks911, 2025; MRC, 2025).

The double-counting mechanism is especially important for friendly fraud. Visa data indicates that approximately 75% of all disputes originate as friendly fraud (Source: Chargebacks911, 2025, citing Visa data). When a buyer receives an order, uses it, and files a fraud claim for an unauthorized transaction, both the TC40 fraud report and the TC15 dispute flow into the VAMP ratio. If you can't invoke Compelling Evidence 3.0 to exclude those counts (more on that below), both stand.

## The Cascade You May Not See Coming: Acquirer-Level Pressure

Your acquirer has its own VAMP thresholds, and they're tighter than yours. Visa set acquirer "Above Standard" at 0.50% and "Excessive" at 0.70% for portfolio-level VAMP ratios (Source: Equifax, 2025; Basis Theory, 2026). Acquirers exceeding those limits face fines per affected transaction across their entire portfolio (Source: Chargebacks911, 2025).

This creates strong financial incentive for acquirers to proactively restrict or offboard merchants whose individual ratios threaten portfolio compliance (Source: Equifax, 2025; Forter, 2025; Chargebacks911, 2025). You may not hear about this pressure directly. The first signal could be tighter processing restrictions, account reserves, or a settlement pause.

The terminal consequence for persistent non-compliance is MATCH list placement, which effectively ends your ability to process Visa payments. Settlement pauses often occur before merchant communication, creating fund freezes lasting three to 14+ days before any formal notice arrives (Source: Coinflow, 2026).

If your acquirer's own ratio is under pressure, your individual compliance buffer shrinks further. The margin for error narrows from both directions.

## Compliance Exclusions Exist, but They Require Infrastructure You May Not Have

VAMP does offer ratio relief through specific dispute resolution channels. Transactions resolved through Compelling Evidence 3.0 (CE3.0), Verifi CDRN, or Visa Rapid Dispute Resolution (RDR) can be excluded from the VAMP ratio calculation (Source: Forter, 2025; Chargebacks911, 2025; Basis Theory, 2026).

CE3.0 exclusions are the most valuable, and the hardest to qualify for. They require three things:

- **Device ID and IP address captured on all prior transactions.** If you weren't collecting device fingerprints before the dispute, you can't retroactively produce matching data.
- **120 days of transaction history.** You need at least four months of matching device and IP records for the disputed cardholder (Source: Forter, 2025).
- **Resolution within the same calendar month as the dispute.** Both the dispute and its CE3.0 resolution must land in the same month to qualify for exclusion.

This creates an asymmetric advantage. Merchants who already have device fingerprinting infrastructure will systematically earn ratio exclusions that unprepared merchants simply cannot access (Source: Forter, 2025; Chargebacks911, 2025). The data capture has to be in place before the dispute happens. There's no way to build this retroactively once you're already in the monitoring window.

VAMP also introduced a separate Enumeration Ratio, tracking confirmed card-testing attempts as a share of all authorization attempts, including declined transactions. Merchants exceeding a 20% enumeration threshold face enrollment in a separate monitoring track (Source: Ravelin, 2025; Chargebacks911, 2025; Forter, 2025). Monitoring entry also requires a minimum of 300,000 enumerated authorization transactions per month (Source: Ravelin, 2025). For marketplace platforms where seller-side fraud or API-exposed checkout flows may invite card testing, this is a second compliance surface to monitor.

## The False Decline Trap Hiding Inside VAMP Compliance

Here's where VAMP creates a genuinely new problem. Under prior monitoring programs, over-aggressive fraud blocking could drive down chargebacks without direct regulatory consequence. You'd lose revenue from false declines, but you'd stay compliant. Under VAMP, that trade-off breaks.

The false decline problem under VAMP is a denominator problem. Every legitimate transaction you decline removes one settled transaction from TC05 without removing a single fraud or dispute event from your numerator. Meanwhile, the fraudulent transactions you do approve still generate TC40 and TC15 events. Over-aggressive blocking shrinks the denominator without proportionally reducing the numerator, which makes the ratio worse, not better. The only way to improve both sides simultaneously is to approve more legitimate transactions (growing TC05) while preventing fraud and disputes at their source (shrinking TC40 + TC15).

The false decline cost across the industry is already substantial: approximately $50 billion annually in lost revenue. Global false decline losses are estimated at $443 billion annually, roughly nine times the $48 billion lost to actual fraud (Source: Riskified, 2025).

VAMP turns this from a revenue problem into a compliance problem. The optimization it imposes is genuinely dual-sided: minimize (TC40 + TC15) / Settled Transactions while simultaneously maximizing approved volume (Source: Corgi Labs internal memo, March 2026). Tightening your fraud rules without precision doesn't help the ratio. It can make it worse.

## What Risk Directors Should Do Now

VAMP compliance is no longer about managing chargebacks in isolation. It's about optimizing a ratio where both the numerator and denominator matter, and where over-correction in either direction carries consequences.

Five concrete steps to take this month:

1. **Calculate your current VAMP ratio.** Pull your TC40, TC15, and TC05 counts from the last 90 days. Know exactly where you stand against the 1.50% threshold.
2. **Audit your CE3.0 readiness.** Confirm that your system captures device ID and IP address on every transaction. Verify you have 120 days of history. If you don't, start collecting now.
3. **Quantify your friendly fraud exposure.** With approximately 75% of disputes originating as friendly fraud (Source: Chargebacks911, 2025), this is likely the largest single contributor to your VAMP ratio.
4. **Measure your false decline rate alongside your fraud rate.** If your fraud rules are blocking legitimate transactions, you're shrinking your denominator without reducing your numerator.
5. **Talk to your acquirer.** Understand where their portfolio ratio stands and whether they're tightening restrictions on merchants in your category.

The underlying challenge is a dual optimization: approve more real buyers to grow your denominator while reducing fraud and disputes to shrink your numerator. These two goals used to live in separate operational silos. VAMP forces them into a single formula.

Corgi Labs builds tools for exactly this kind of problem. Corgi Intelligence surfaces your fraud, dispute, and decline data in one view so you can see your actual VAMP ratio exposure across processors. Corgi Model uses custom machine learning trained on your transaction data to dig into both sides of the equation, approving more legitimate orders while reducing chargebacks. For one eCommerce merchant, that meant +22% payments accepted, an 18% reduction in realized fraud rate, and more than $2 million in recovered revenue (Source: Corgi Labs product documentation, 2026).

If you want to see where your VAMP ratio stands and where the optimization opportunities are, [book a demo](#book-demo).

---

## Source Index

- [Basis Theory, "VAMP 2026: What Changes on April 1"](https://blog.basistheory.com/visa-acquirer-monitoring-program-2026-updates)
- [Chargebacks911, "Visa Acquirer Monitoring Program: Major Visa Updates in 2026"](https://chargebacks911.com/visa-acquirer-monitoring-program/)
- [Forter, "Visa Updates VAMP Program: Key Changes and What They Mean for Merchants"](https://www.forter.com/blog/may-2025-visa-updates-vamp-program/)
- [Ravelin, "New VAMP for 2025: Visa's Changes to Dispute Thresholds"](https://www.ravelin.com/blog/visa-vamp-changes-chargeback-disputes)
- [MRC, "A Merchant's Guide to the New Visa VAMP Program"](https://merchantriskcouncil.org/learning/resource-center/member-news/blog/2025/flexpay-july-2-a-merchants-guide-to-the-new-visa-vamp-program)
- [Equifax, "The Visa Acquirer Monitoring Program (VAMP): What New Rules Mean"](https://www.equifax.com/business/blog/-/insight/article/the-visa-acquirer-monitoring-program-vamp-what-new-rules-mean-for-acquirers-and-merchants/)
- [Coinflow, "VAMP Is Getting Stricter in April 2026"](https://coinflow.cash/blog/vamp-changes-april-2026/)

---

### How a 15% Decline Rate Compounds Into an ~18% Revenue Loss

Published: 2026-03-01 | https://www.corgilabs.ai/insights/how-a-15-decline-rate-compounds-into-an-18-revenue-loss

Roughly 15% of all ecommerce orders are declined during authorization. About 70% of those declined orders belong to legitimate customers who were qualified to buy. And between 27% and 33% of those falsely declined customers never come back. Each of those numbers is a problem on its own. Together, they compound into something much larger: approximately 18% of your addressable revenue, lost before it ever reaches your books.

This is not a single-source headline statistic. It’s derived math, with each component independently documented. This article breaks down that math, traces it to the three friction mechanisms responsible for most avoidable declines, and shows you what recovery looks like in practice.

## The Three-Part Equation: Where the ~18% Comes From

**Start with the broadest layer.** Across all markets, roughly 15% of ecommerce transactions fail to process successfully. That 15% includes both recoverable declines (false positives, routing failures, 3DS abandonment) and non-recoverable ones (insufficient funds, closed accounts, hard fraud). The 70% filter in the next layer isolates the recoverable portion. E-commerce baseline decline rates run 10–13%, with subscription and recurring billing models hitting 18–20% due to expired cards, changed billing details, and automated bank blocks (Wallid; Recurly, “Top Payment Decline Reasons for eCommerce”). The 15% figure represents a cross-market average.

**Now apply the second layer.** For the average merchant, issuers decline one in every 10 ecommerce dollars during payment authorization, and 70% of these declined orders are from good customers qualified to make the purchase.

**The math at this point:** 15% of orders declined, 70% of those from real customers. That gives you roughly 10.5% of all attempted orders from genuine buyers incorrectly rejected. This is immediate, same-day revenue loss.

**Now add the third layer:** the customers who don’t come back. Among customers who experience a false decline, 27%-41% never return to the merchant.

When you combine the immediate transaction loss (10.5% of revenue from real customers) with the permanent lifetime value destruction from non-return (27–33% of those customers gone forever), the total revenue impact across the customer lifecycle approaches 18% of addressable revenue.

## What “Authorization Friction” Actually Means: Three Root Causes

Authorization friction is not a synonym for “low auth rate.” It refers to specific mechanisms within the authorization flow that cause legitimate transactions to fail. Three friction sources drive the bulk of avoidable declines.

Issuer over-restriction: the “do not honor” black box. Issuers see the basics: card details, balance, amount, location, and results from their standard fraud checks. They don’t see behavioral patterns, order history, or device details. This information gap leads to systematic over-flagging. Banks falsely decline approximately 15% of legitimate orders. The “do not honor” response code represents 10–60% of all refusals depending on geography. American Express codes over 90% of its declines as “do not honor,” while Visa in the US codes approximately 10% this way (Churnkey, “Do Not Honor Decline”). You can’t fix what you can’t diagnose.

3DS challenge abandonment. Ravelin found that 22% of payments sent through 3DS were lost (Ravelin, “One Fifth of Payments Sent to 3D Secure Are Lost”). That data is from 2019, before widespread 3DS 2.x adoption, and the landscape has improved since: 64% of 3DS transactions now go through a frictionless flow globally, and the UK achieves 93% 3DS success rates (Ravelin, 2025 Global Payments Report). But the friction remains real and ongoing: in Ravelin’s 2019 data, 91% of 3DS transactions took over five seconds to authenticate, with an average of 37 seconds (Ravelin, 2019). European merchants still see a 2–3.5% conversion drop from poorly applied 3DS. In the US, where 3DS success rates average only 41%, merchants may lose up to 15% (DECTA, “Why Your 3DS Authentication Has Low Approval Rates”).

Routing inefficiency. Merchants relying on a single acquirer without fallback logic leave revenue on the table when network rules or processor conditions change (Solidgate, “Intelligent Payment Routing”). A transaction that fails through one processor might succeed through another. Without cascading fallback routing, that revenue is simply abandoned. Intelligent routing optimization can improve approval rates by 10–15% (Solidgate; FlyCode).

## The Customer Who Doesn’t Come Back: Why the Loss Keeps Growing

The immediate transaction loss is only the first impact. The compounding effect is what turns a $150 declined order into a multi-thousand-dollar problem.

Among loyal customers (those with three or more prior approved orders), a false decline triggers a 65% reduction in the number of future orders and a 16% drop in average order value. Consider what that means: a customer who spent $1,200 with you last year gets falsely declined on a $150 order. If they’re in the 27–33% who never return, you’ve lost $1,350 in year-one value alone, not $150. If they’re in the group that comes back but spends less, you’ve still lost hundreds in lifetime revenue from that single decline event.

The behavioral data reinforces this. Only 25% of declined customers try another payment card. Thirty-nine percent abandon the cart entirely (PYMNTS, November 2023). And up to 32% of falsely declined customers post negative feedback on social media (ClearSale / Sapio Research, 2020). That’s brand damage on top of revenue loss.

Fiserv’s research adds another dimension. Twenty percent of cardholders stop using their card entirely after experiencing two or more false declines within a six-month period, and average monthly spending drops 15% per card after two or more false positive denials (Fiserv, “Financial Institutions Ease Cardholder Frustration by Addressing Transaction False Declines”). The damage extends beyond a single merchant.

The financial scale is significant. US ecommerce merchants permanently lost $81 billion to false declines in 2023, with $157 billion in sales initially at risk (PYMNTS, November 2023). Riskified’s 2025 Ascend research, based on a practitioner survey of 130+ payment professionals, puts total ecommerce losses from false declines, fraud, and policy abuse at $448 billion annually. J.P. Morgan data shows that false positive losses (19% of total fraud cost) actually exceed actual fraud losses (7% of total fraud cost) (J.P. Morgan, “False Positives & Fraud Prevention Tools”). False declines cost merchants 13 times more than actual fraud (Fiserv Carat). One Aite Group / ClearSale estimate from 2019 puts the ratio at 75 times.

## Why Your Dashboard Doesn’t Show Any of This

You might expect your payments dashboard to surface this problem. It doesn’t.

Eighty-two percent of executives cannot pinpoint why their payments fail due to fragmented data (PYMNTS, August 2024). Only one-third of ecommerce merchants know whether fraud caused a failed payment (PYMNTS, November 2023). Sixty percent say failed payments are expensive to track and resolve (PYMNTS, 2024).

Standard PSP dashboards report total authorization rate. They don’t report false decline rate. They don’t track whether a declined customer returns or churns permanently. They don’t measure lifetime value erosion from individual decline events. For multi-PSP merchants, the problem multiplies: three different dashboards with three different authorization rate figures and no unified view of which declines are recoverable false declines versus genuine fraud.

This is why the ~18% revenue impact stays invisible. The data exists, but it sits in separate systems that don’t connect.

## What High-Performing Merchants Do About Authorization Friction

Recovery is structured around the three root causes.

**Enriching transaction data for issuers.** Sending additional context (device fingerprint, customer tenure, transaction history) gives issuers the confidence to approve transactions they would otherwise flag. 

**Smarter 3DS application.** Applying 3DS selectively (exempting low-risk transactions, using risk-based authentication) reduces abandonment while maintaining compliance. The difference between blanket 3DS enforcement and intelligent exemption strategies can be the difference between a 2–3.5% conversion drop and minimal impact.

**Network tokenization.** Replacing stored card numbers with network-level tokens delivers a 4.6% global authorization rate lift and 26–30% fraud reduction (Visa Acceptance Solutions, “Tokens Are Key to Future Proofing Payments”).

The results at scale are real. [Checkout.com](http://Checkout.com)’s Intelligent Acceptance raised merchants’ acceptance rates by an average of 3.8% in 2024, generating over $10 billion in additional merchant revenue since launch ([Checkout.com](http://Checkout.com) newsroom). Stripe’s Adaptive Acceptance recovered $6 billion in falsely declined transactions in 2024, a 60% year-over-year improvement in retry success rate (Stripe, “AI Enhancements to Adaptive Acceptance”).

## The Recovery Calculation: What This Is Worth for Your Business

Here’s the math applied to a specific scenario.

> If your business processes $10 million per month at an 87% authorization rate, $1.3 million per month is declining. If 70% of those declines are false declines from real customers, that’s $910,000 per month in legitimate buyers being turned away. A 3–5 percentage point improvement in authorization rate recovers $300,000 to $500,000 per month, or $3.6 million to $6 million per year. That recovery doesn’t require new customers, additional marketing spend, or pricing changes. It comes from approving real buyers who are already at checkout.

The first step is visibility: understanding which of your declines are recoverable, which friction mechanisms are driving them, and which customers you’re losing permanently. That’s the analytical layer most merchants are missing.

Corgi Intelligence surfaces exactly this data, unifying decline analytics across processors and quantifying the revenue impact of each friction source. Corgi Model takes it a step further with custom machine learning trained on your transaction data, approving more real buyers while reducing chargebacks. 

Sources

Aite Group / ClearSale, “False Decline Cost Ratios” (2019), via [Greip.io](http://Greip.io)

[Checkout.com](http://Checkout.com), “[Checkout.com](http://Checkout.com) Surpasses $10 Billion in Revenue Unlocked”

Churnkey, “Do Not Honor Decline: Meaning, Stats, and How To Fix”

ClearSale / Sapio Research via Digital Commerce 360, “33% of US Consumers Drop Retailers After a False Decline” (2020)

DECTA, “Why Your 3DS Authentication Has Low Approval Rates: 5 Optimisation Tips”

Fiserv, “Financial Institutions Ease Cardholder Frustration by Addressing Transaction False Declines”

Fiserv Carat, “False Decline”

FlyCode, “Smart Payment Orchestration: From Simple Rules to AI”

GR4VY, “Approval Rates in Payments: Meaning and Deep Dive for 2025”

J.P. Morgan, “False Positives & Fraud Prevention Tools”

LexisNexis, 2018 True Cost of Fraud Survey, via Sherwen

[Primer.io](http://Primer.io), “How to Recover Lost Revenue with Cascading Payments”

PYMNTS, “82% of Merchants Don’t Have the Data to Pinpoint Why Payments Fail” (August 2024)

PYMNTS, “eCommerce Firms Will Lose $81B to False Declines in 2023” (November 2023)

PYMNTS, “Nearly 60% of Firms Say Failed Payments Are Expensive to Track and Resolve” (2024)

Ravelin, “One Fifth of Payments Sent to 3D Secure Are Lost” (2019)

Ravelin, “New Data in Payments Authentication & 3DS Released” (Global Payments Report 2025)

Recurly, “Top Payment Decline Reasons for Subscription eCommerce”

Riskified, “Unlock Revenue by Optimizing Payment Authorization Rates”

Riskified, Lorna Jane Case Study

Riskified / StockTitan, “85% of Merchants Battle to Balance Customer Experience and Fraud Prevention” (Ascend 2025)

Sherwen, “How False Declines Hurt More Than Actual Ecommerce Fraud” (LexisNexis data)

Signifyd, “5 Strategies to Increase Bank Authorization Rates for Merchants”

Signifyd, “False Declines Explained”

Solidgate, “Intelligent Payment Routing: Boost Conversion”

Stripe, “AI Enhancements to Adaptive Acceptance”

Visa Acceptance Solutions, “Tokens Are Key to Future Proofing Payments”

Wallid, “Where Payments Fail: Industries with Highest Decline Rates 2025”

---

### Payment Optimization ROI: How to Build the Business Case Your CFO Will Approve

Published: 2026-02-16 | https://www.corgilabs.ai/insights/payment-optimization-roi-how-to-build-the-business-case-your-cfo-will-approve

Most payment optimization proposals stall in budget conversations because they speak in percentages instead of dollars. You have the benchmarks. You know your acceptance rate could be higher and your chargebacks could be lower. But the business case your CFO approves is built on payback period, net revenue impact, and margin preservation. Not on authorization rate dashboards.

This article gives you the ROI formula, the industry benchmarks to fill it in, a fully worked example you can adapt to your own numbers, and the structure for a business case presentation that translates payment metrics into P&L language.

## Why Payment Optimization Proposals Stall (and What CFOs Actually Need)

Payment teams tend to pitch optimization in operational language: authorization rates, decline codes, chargeback ratios. These metrics matter. But they’re not the language of budget approval.

CFOs are shifting from asking “How much should we spend to be compliant?” to “What is the expected loss exposure across our payment flows, and how does that compare to the cost of advanced controls?” (PYMNTS). That shift is real. Nearly 70% of financial institutions increased fraud-detection spending year over year, and cost is becoming less of a barrier as firms view fraud technology as core infrastructure (PYMNTS).

But strategic investment still requires a quantified framework. Your CFO needs three things before approving a payment optimization budget:

1. **Net revenue impact in dollars.** Not percentages. Dollars.
2. **Payback period.** Under 12 months is a straightforward yes by most CFO frameworks; anything under 24 months is within standard approval range (Nucleus Research).
3. **Cost of inaction.** What you lose by maintaining the status quo, expressed in annual margin erosion and competitive risk.

The ROI formula below gives you all three.

## The ROI Formula: Four Variables with Industry Benchmarks

Here’s the formula. Each variable includes benchmark ranges from industry research so you can plug in your own numbers or start with the midpoint. If you want to skip ahead and run the numbers now, try our Payment Revenue Calculator with your own data.

**Net Annual ROI = Acceptance Rate Lift Revenue + Chargeback Cost Reduction + False Decline Revenue Recovery - Total Project Cost**

Break it down:

### Variable 1: Acceptance Rate Lift Revenue

**Formula:** Acceptance Rate Lift (pp) x Monthly Transaction Volume x AOV x 12

**What it measures:** The additional revenue you collect by approving transactions that would otherwise decline.

**How to find your baseline:** Pull your current authorization rate by processor, card brand, and region. E-commerce card-not-present rates typically range from 85% to 92% (Worldpay; Nuvei). If you run multiple PSPs, average them or (better) use the volume-weighted rate.

**What to use if you don’t have exact numbers:** Start with a conservative 3-percentage-point lift, which sits at the low end of documented outcomes.

### Variable 2: Chargeback Cost Reduction

**Formula:** Current Monthly Chargebacks x Reduction Rate x Average Cost per Chargeback x 12

**What it measures:** The savings from reducing chargebacks through better fraud decisioning and prevention tooling.

| Input | Benchmark Range | Source |
| --- | --- | --- |
| Chargeback reduction rate | 70-95% | Chargeflow; industry case studies |
| Average cost per chargeback | $15-$100 in fees alone; true cost is $4.61 per $1 of fraud when including merchandise loss, labor, and penalties | Chargeflow; Chargebacks911; Mastercard |
| Current chargeback ratio | Industry average: 0.56-0.60%; digital goods/subscriptions: 1.85% | Chargeflow; ChargebackStop |

**Why the cost per chargeback matters more than the fee:** The $15-$100 fee is just the processor charge. In 2025, every dollar lost to fraud costs U.S. merchants $4.61 total, a 37% increase from 2020 (Chargeflow). That multiplier accounts for the transaction amount, merchandise loss, shipping, administrative labor, and potential card network penalties. A $100 chargeback really costs you $461.

**The penalty cliff:** Merchants exceeding a 0.9% chargeback ratio enter Visa’s Dispute Monitoring Plan, with penalties of $50 per chargeback plus $25,000 review fees in months five through 12 (Visa VAMP). This isn’t a theoretical risk. Digital goods and subscription merchants average a 1.85% chargeback rate (Chargeflow), well above the threshold.

### Variable 3: False Decline Revenue Recovery

**Formula:** Recovered Transactions per Month x Percentage Who Would Have Been Lost x Average Customer Lifetime Value x 12

**What it measures:** The lifetime value preserved by approving real buyers your current system would have blocked.

| Input | Benchmark Range | Source |
| --- | --- | --- |
| False decline cost (global, annual) | Estimates range from $50 billion (PYMNTS, conservative) to $443 billion (ClearSale; Riskified), depending on methodology and scope | ClearSale; Riskified; PYMNTS |
| Customers who never return after a false decline | 40% | ClearSale |
| Loyal customer order volume reduction after a false decline | 65% | Riskified |
| Average customer lifetime value | Your data (or estimate based on AOV x purchase frequency x retention period) | Internal reporting |

This variable is the hardest to quantify precisely, which is exactly why most business cases undercount it. The acceptance rate lift (Variable 1) captures the immediate transaction revenue. Variable 3 captures the downstream impact: when you decline a real buyer, 40% of them never come back (ClearSale). Among loyal customers who do return, their order volume drops by 65% (Riskified).

**Conservative approach for your CFO:** If you can’t model CLV precisely, present Variable 3 as upside rather than a core number. Note that merchants lose up to 75 times more revenue to false declines than to actual fraud (Aite Group, via Riskified). That ratio reflects the compounding effect of lost lifetime value, not just the declined transaction. Frame the CLV recovery as additional return beyond the hard-dollar figures in Variables 1 and 2.

### Variable 4: Total Project Cost

**Formula:** Implementation Cost + Annual Ongoing Cost

| Input | Benchmark Range | Source |
| --- | --- | --- |
| Implementation cost | ~$50,000 for mid-market implementations (illustrative; actual costs vary by vendor and scope) | Industry estimates |
| Ongoing cost | Varies: monthly SaaS fee, percentage of recovered revenue, or per-transaction pricing | Vendor-specific |
| First-year ROI on sub-$50K implementations | 10-26x | Signifyd; industry benchmarks |

For most mid-market merchants, the implementation cost is small relative to the revenue at stake. That’s why first-year ROI on sub-$50K implementations consistently falls in the 10-26x range (Signifyd; industry benchmarks).

## Worked Example: A $120M Mid-Market Merchant

Let’s run the numbers for a merchant that looks like a typical multi-PSP e-commerce operation.

### Current State

| Metric | Value |
| --- | --- |
| Annual transaction volume | $120,000,000 |
| Monthly transactions | 150,000 |
| Average order value | $67 |
| Current authorization rate | 87% |
| Monthly approved transactions | 130,500 |
| Monthly declined transactions | 19,500 |
| Current chargeback ratio | 0.70% |
| Monthly chargebacks | ~910 |
| Average all-in chargeback cost | $200 (fee + labor + merchandise loss) |

An 87% authorization rate sits in the lower half of the 85-92% e-commerce range (Worldpay; Nuvei). That’s not unusual for a multi-PSP merchant without optimization tooling.

### Optimized State (Conservative Scenario: 3pp Lift, 70% Chargeback Reduction)

*Implementation and ongoing costs below are illustrative for a mid-market deployment. Your actual costs will vary by vendor, scope, and pricing model.*

**Variable 1: Acceptance Rate Lift Revenue**

A 3-percentage-point lift (87% to 90%) recovers 4,500 additional transactions per month.

4,500 recovered transactions x $67 AOV x 12 months = **$3,618,000 per year**

**Variable 2: Chargeback Cost Reduction**

A 70% reduction drops monthly chargebacks from 910 to 273, saving 637 chargebacks per month.

637 saved chargebacks x $200 all-in cost x 12 months = **$1,528,800 per year**

**Variable 3: False Decline Revenue Recovery (Upside)**

Of the 4,500 newly approved transactions per month, assume 40% of those buyers would have never returned. At a conservative CLV of $200 (roughly 3x AOV), that’s:

4,500 x 40% x $200 = $360,000 per month in preserved lifetime value

This figure is directional, not exact. Present it as upside in your business case, not as a guaranteed return.

**Variable 4: Total Project Cost**

$50,000 implementation + $30,000 annual ongoing = **$80,000 first year**

### The Math

| Component | Annual Impact |
| --- | --- |
| Acceptance rate lift revenue | +$3,618,000 |
| Chargeback cost reduction | +$1,528,800 |
| **Hard-dollar gross benefit** | **+$5,146,800** |
| Total project cost (Year 1) | -$80,000 |
| **Net first-year impact** | **+$5,066,800** |
| **Payback period** | **~6 days** |
| **First-year ROI** | **63x** |

Even if you cut the acceptance rate lift in half (1.5pp instead of 3pp) and the chargeback reduction to 50%, the net first-year impact is still over $2.3 million on an $80,000 investment.

### Realistic Scenario (5pp Lift, 70% Chargeback Reduction)

For context, a 5-percentage-point lift sits in the middle of the 3-12% benchmark range. Klarna achieved 6 percentage points (Optimized Payments). Reach achieved 9.5 percentage points with [Checkout.com](http://Checkout.com). Nord Security achieved 10% conversion improvement through AI-driven routing (Juspay; Adyen).

| Component | Annual Impact |
| --- | --- |
| Acceptance rate lift revenue (7,500 x $67 x 12) | +$6,030,000 |
| Chargeback cost reduction | +$1,528,800 |
| **Hard-dollar gross benefit** | **+$7,558,800** |
| Total project cost (Year 1) | -$80,000 |
| **Net first-year impact** | **+$7,478,800** |

The point isn’t to pick one scenario. The point is that even the most conservative projection delivers returns that exceed any reasonable payback threshold.

**Want to see what these numbers look like for your business?** Run your own scenario in our Payment Revenue Calculator. Plug in your transaction volume, authorization rate, and chargeback ratio to get a personalized revenue recovery estimate in seconds.

## The Cost of Doing Nothing: Margin Erosion You Can Quantify

Your CFO will ask about risk in both directions: “What if the optimization doesn’t deliver?” and “What if we don’t invest?” The second question has a concrete answer.

**False declines compound.** Industry estimates of the global cost of false declines range from $50 billion to $443 billion per year, depending on methodology (ClearSale; Riskified; PYMNTS). Even at the conservative end, that dwarfs the $48 billion lost to actual fraud. Every false decline isn’t just a lost transaction. It’s a customer relationship at risk: 40% never return, and the ones who do reduce their order volume by 65% (ClearSale; Riskified).

**Chargeback penalties escalate.** Total chargeback losses will reach $117 billion globally in 2026 (Chargebacks911). Merchants who exceed Visa’s 0.9% chargeback ratio face escalating penalties that can reach $50 per chargeback plus $25,000 in review fees (Visa VAMP). In severe cases, exceeding thresholds can cost you your merchant account entirely, which means you can’t process payments at all.

**The fraud cost multiplier grows.** Every dollar lost to fraud now costs $4.61 in total impact (Chargeflow). That’s up 37% from 2020, and the trajectory is not reversing. Merchant losses from online payment fraud will exceed $91 billion in 2028 alone (Juniper Research).

**Competitors are investing.** Nearly 70% of financial institutions increased fraud-detection spending year over year (PYMNTS). Competitors who optimize their payment flows capture the customers you decline. Once those customers form new purchasing habits, they don’t come back.

Frame the cost of inaction as an annual number in your business case. For the $120M merchant in our worked example, maintaining the current 87% authorization rate and 0.70% chargeback ratio costs roughly $5.1 million per year in recoverable revenue and avoidable chargeback costs. That’s not a projection. It’s the gap between where you are and where documented benchmarks say you could be.

## From Spreadsheet to Approval: Structuring the Deck

You have the formula. You have the math. Here’s how to package it for the budget conversation.

### The Six Slides Your CFO Needs

**Slide 1: Executive summary.** Lead with the payback period and net first-year revenue impact. One sentence on what you’re proposing. One sentence on total cost. One sentence on what happens if you don’t invest.

**Slide 2: Current-state audit.** Your authorization rate by processor, card brand, and region. Your chargeback ratio and total chargeback costs (not just fees, but the full $4.61 multiplier). Your estimated false decline volume, based on the gap between your current auth rate and the 92-95% benchmark (Micros Integrated Payments).

**Slide 3: The ROI formula with three scenarios.** Run conservative, realistic, and optimistic projections using the formula above. Anchor on the conservative scenario. Let the realistic and optimistic numbers show the upside range. This approach demonstrates rigor, not optimism.

**Slide 4: Proof points and case studies.** Cite real examples: Klarna’s 6% acceptance rate increase across key markets (Optimized Payments). Reach’s 9.5% authorization rate increase through intelligent acceptance ([Checkout.com](http://Checkout.com); Juspay). [Checkout.com](http://Checkout.com)’s $741 million in revenue recovered across its merchant base. A mid-sized insurance company saving $700,000 annually through payment process optimization (Optimized Payments). Worldpay recovering $200 million in revenue for merchants in 2024 (Worldpay).

**Slide 5: Implementation timeline and resource requirements.** Be specific about what the project needs: timeline, internal resources, integration scope. Sub-$50K implementations with 10-26x first-year ROI speak for themselves (Signifyd; industry benchmarks). Target a 12-month payback as the benchmark for a straightforward approval; anything under 24 months is within standard CFO approval range (Nucleus Research).

**Slide 6: Cost of inaction.** Quantify the annual cost of maintaining the status quo using the formula in reverse. Show the chargeback penalty risk if your ratio crosses 0.9%. Note the competitive context: competitors who optimize will capture the buyers you decline.

### Three Tips for the Conversation

**Speak in dollars, not percentages.** “$3.6 million in recovered revenue” lands differently than “a 3-percentage-point auth rate lift.” Both describe the same outcome. Only one gets a budget approved.

**Present the conservative scenario as your ask.** If the conservative projection justifies the investment (and at these benchmarks, it almost always does), the realistic and optimistic scenarios become upside. Your CFO will appreciate the intellectual honesty.

**Address the fraud question directly.** “If we approve more transactions, do we increase fraud exposure?” The answer: properly implemented optimization actually reduces fraud. Network tokenization delivers a 2.1-6% authorization rate lift while simultaneously reducing fraud by 30% (Visa; Mastercard). The goal is approving more real buyers, not lowering the bar.

## Start with Visibility, Then Build the Case

The ROI formula works when you have clean data to feed into it. That means knowing your authorization rate by processor, your true chargeback cost (not just the fee), and your false decline volume. Most merchants running multiple PSPs don’t have unified visibility across these metrics.

If your payments data sits in three different dashboards with three different reporting formats, the first step isn’t buying optimization tooling. It’s getting a unified view of where your revenue is actually leaking. Once you can see the full picture across processors, building the business case is arithmetic.

Corgi Intelligence surfaces these metrics across your payments stack, and Corgi Model applies merchant-specific machine learning to approve more real buyers while reducing chargebacks. Both work on your existing platform with no development work and deliver results in days.

Your CFO doesn’t want a pitch about payment technology. She wants a spreadsheet that shows payback period, net revenue impact, and the cost of standing still. Now you have the formula to build one.

[Corgi Labs Payment Revenue Calculator](/resources/roi-calculator)



---

## Sources

- [Chargebacks911, “Chargeback Stats: All the Key Dispute Data Points for 2026”](https://chargebacks911.com/chargeback-stats/)
- [Chargeflow, “The Ultimate Chargeback Statistics 2025: Trends, Costs, and Solutions”](https://www.chargeflow.io/blog/chargeback-statistics-trends-costs-solutions)
- [Checkout.com](http://Checkout.com)[, “A Guide to Payment Optimization”](https://www.checkout.com/blog/a-guide-to-payment-optimization)
- [Checkout.com](http://Checkout.com)[, “Revenue Optimization in Payments”](https://www.checkout.com/blog/what-is-revenue-optimization)
- [ClearSale, “False Declines and Ecommerce Fraud Prevention Report”](https://offer.clear.sale/false-declines-ecommerce-fraud-prevention-report)
- [Juniper Research, “Losses from Online Payment Fraud to Exceed $362 Billion Globally Over Next 5 Years”](https://www.juniperresearch.com/press/losses-online-payment-fraud-exceed-362-billion/)
- [Juspay, “How to Maximize Your Payment Acceptance Rate”](https://juspay.io/blog/how-to-maximize-your-payment-acceptance-rate-a-complete-guide-for-growing-businesses)
- [Mastercard, “Payment Optimization Platform Uses the Power of Data to Drive More Approvals”](https://www.mastercard.com/us/en/news-and-trends/press/2025/october/Mastercard-Payment-Optimization-Platform-uses-the-power-of-data-to-drive-more-approvals.html)
- [Micros Integrated Payments, “Boost Restaurant Payment Approval Rates & Recover Revenue”](https://microsintegratedpayments.com/blog/payment-approval-rates/)
- [Nucleus Research, “Everything to Know About ROI, TCO, NPV, and Payback”](https://nucleusresearch.com/everything-to-know-about-roi-tco-npv-and-payback/)
- [Nuvei, “Payment Authorization Optimization”](https://www.nuvei.com/solutions/authorization-optimization)
- [Optimized Payments, “Case Studies”](https://optimizedpayments.com/resources/case-studies/)
- [PYMNTS, “B2B CFOs Bring Fraud Controls Into Their Cash Flow Strategies”](https://www.pymnts.com/fraud-prevention/2026/b2b-cfos-bring-fraud-controls-into-their-cash-flow-strategies/)
- [Riskified, “How Much Does a False Decline Cost Your Business?”](https://www.riskified.com/blog/reduce-false-declines/)
- [Riskified, “The True Cost of Declined Orders”](https://www.riskified.com/blog/true-cost-declined-orders/)
- [Signifyd, “5 Strategies to Increase Bank Authorization Rates for Merchants”](https://www.signifyd.com/blog/increase-authorization-rates/)
- [Visa, “A Deep Dive into Tokenized Transactions”](https://corporate.visa.com/en/solutions/commercial-solutions/knowledge-hub/tokenization.html)
- [Visa Acceptance Solutions, “Why Tokens Are Key to Future Proofing Payments”](https://www.visaacceptance.com/en-us/blog/article/2025/tokens-are-key-to-future-proofing-payments.html)
- [Worldpay, “The C-Suite’s Guide to Payment Authorization Rates”](https://www.worldpay.com/en/insights/articles/c-suite-guide-to-auth-rates)

---

### Your Fraud System Is Your Most Expensive Revenue Leak.

Published: 2026-02-10 | https://www.corgilabs.ai/insights/false-declines

Most ecommerce finance teams track fraud losses closely. Chargebacks get dashboards. Fraud rates get quarterly reviews. But false declines (legitimate orders your fraud system blocks by mistake) rarely get the same attention, even though they cost you far more.

In 2023, US merchants lost $81 billion to false declines. For comparison, total ecommerce fraud losses were roughly $48 billion globally. For many ecommerce sellers, fraud prevention tools are blocking more revenue than fraudsters are stealing.

That’s worth saying again: for many ecommerce businesses, the system designed to protect their revenue may be their biggest source of lost revenue.

## The real cost of a $100 false decline

When your system blocks a $100 order from a real buyer, you don’t just lose $100. You lose in four directions at once.

**The immediate sale.** That $100 is gone. Research from the Merchant Risk Council shows merchants decline about 6% of orders for suspected fraud. Of those, roughly two-thirds are legitimate buyers who got caught in the filter.

**The customer’s lifetime value**. This is the big one. Industry surveys consistently show that 40% to 42% of customers never return after a false decline. They don’t call support. They don’t retry. They just leave. If that customer would have spent $100 a month over the next several years, you’ve lost thousands of dollars over a single blocked order.

One study of loyal customers (three or more previous purchases) found that a false decline cut their future order volume by 65%. Even the ones who came back spent 16% less per order. The relationship doesn’t recover.

**Your acquisition cost.** You spent real money to get that customer to checkout. The average ecommerce CAC is $70, which ranges from $50 to $130 depending on your vertical (industry benchmarks). When a new customer gets declined and walks away, 100% of that acquisition investment is wasted. You paid to acquire someone, then your own system turned them away.

**Your brand.** 32% of falsely declined customers post about it online. Among Gen Z, that number rises to 35%. One frustrated social media post about being “treated like a fraudster” doesn’t just lose you that customer. It discourages the next 10 who see it.

## Add it up

For a $100 false decline, the math looks roughly like this:

| **Component** | **Cost** |
| --- | --- |
| Lost sale | **$100** |
| Lost lifetime value (40% defection × $2,000 avg LTV*) | **$800** |
| Wasted acquisition cost (40% defection × $70 CAC) | **$28** |
| Support and brand damage | **$50–$100** |
| **Total cost per $100 decline** | **$978–$1,028** |

**Based on repeat-purchase ecommerce benchmarks ($100 AOV × 20 orders). Luxury and subscription verticals typically exceed this figure.*

The claim that you lose $750+ in lifetime value and $250+ in wasted CAC for every $100 blocked is directionally right. In some verticals (luxury, subscription, B2B), it’s conservative.

Other research puts it more starkly: for every $1 lost to actual fraud, merchants forfeit $30 by declining real buyers.

To put it in cumulative terms: if a business has a 6% decline rate and two-thirds of those are false declines, total revenue can be boosted 4% simply by improving payment decision logic. For a retailer with $100M in annual sales, that’s $4M in revenue being forfeited needlessly.

## Why this stays invisible

False declines don’t show up as a line item. There’s no chargeback notification, no dispute filing, no alert from your payment processor. The customer simply doesn’t come back, and your analytics never register the lost customer at all — or misattribute the drop to routine churn.

Most merchants don’t track their false decline rate at all. The ones who do often discover the number is higher than expected. PYMNTS Intelligence found that 64% of failed payments are difficult to recover, and only 22% of customers will definitely retry after being declined.

The customers you’re losing aren’t complaining to you. They’re complaining to Twitter. Or they’re just buying from your competitor.

## What to do about it

**Measure your insult rate — or at least estimate it.** Track retry success rates and customer complaints on blocked orders. If you have the appetite, run holdout tests on a sample of auto-declined transactions. The number will be imprecise, but even a rough estimate is better than the zero most merchants are working with.

**Quantify the full cost.** Don’t model a false decline as a $100 loss. Model it as a $1,000 loss. Use your own LTV and CAC numbers to build the multiplier for your business. When finance teams see the true cost, false decline reduction moves from a fraud team problem to a CEO’s or CRO’s revenue priority.

**Rethink your fraud approach.** Generic fraud rules block good customers because they don’t know your buyers. Custom machine learning trained on your transaction data can separate real buyers from real fraud with much higher accuracy. The goal isn’t less fraud prevention. It’s smarter fraud prevention that blocks fraud, not buyers.

Your design team has optimized every pixel for a good experience and high shopping cart conversion. So why aren’t you thinking about how every 20th legitimate customer is being told to go away — right when they are trying to pay you?

The $81 billion lost to false declines in 2023 is a cost. It’s also an opportunity. Every legitimate order you approve that your current system would have blocked flows straight to your top line.

**Your payment data is sitting on gold. The question is whether you’re digging it up, or burying it deeper.**

---

**Sources**

[PYMNTS Intelligence & Nuvei, "Fraud Management, False Declines and Improved Profitability" (November 2023)](https://www.pymnts.com/study/fraud-management-false-declines-improved-profitability-ecommerce)

[Merchant Risk Council, "2024 Global eCommerce Payments & Fraud Report"](https://merchantriskcouncil.org/learning/mrc-exclusive-reports/global-payments-and-fraud-report/2024-global-payments-and-fraud-report)

[Forter, "2023 Consumer Trust Premium Report"](https://explore.forter.com/2023trustpremiumreport/p/1)

[ClearSale, "State of Consumer Attitudes on Ecommerce, Fraud, & CX 2023-2024"](https://en.clear.sale/blog/report-state-of-consumer-attitudes-on-ecommerce-fraud-cx-2023-2024)

[Signifyd, "False Declines Explained: How to Prevent Fraud False Alarms"](https://www.signifyd.com/blog/how-the-top-retailers-measure-fraud-false-declines/)

[Riskified, "How Consumers Respond to False Declines"](https://www.riskified.com/blog/how-consumers-respond-to-false-declines/)

[Rivo, "Average Customer Acquisition Cost for eCommerce"](https://www.rivo.io/blog/average-customer-acquisition-cost-for-ecommerce)

[Deliberate Directions, "Customer Acquisition Cost Ecommerce: 2026 Benchmarks"](https://deliberatedirections.com/customer-acquisition-cost-ecommerce-benchmarks/)

[Harvard Business Review / Bain & Company, "The Value of Keeping the Right Customers"](https://hbr.org/2014/10/the-value-of-keeping-the-right-customers)

---

### Your Authorization Rate Is a Vanity Metric: What That 91% Is Actually Hiding

Published: 2026-02-09 | https://www.corgilabs.ai/insights/your-authorization-rate-is-a-vanity-metric-what-that-91-is-actually-hiding

**For payment operations leaders, the authorization rate has become the metric you check but never question.** It sits on a dashboard, it trends in a reasonable range, and it gives you a false sense of control. The problem isn’t that the number is wrong. The problem is that it’s incomplete, and the gap between what it shows and what’s actually happening is where your revenue disappears.

According to Worldpay, for a business processing $1 billion in annual transactions, a single percentage point improvement in authorization rate equals $10 million in recovered revenue. That lift comes without acquiring new customers, increasing marketing spend, or changing pricing. Yet most merchants lack the visibility to diagnose where those lost percentage points go.

Here’s what your authorization rate is hiding, how to quantify what you’re losing, and what the highest-performing merchants do to close the gap.

## The Composite Metric Problem: Why Top-Line Auth Rates Mislead

Industry authorization rates for e-commerce range from 85% to 95%, according to data from Worldpay and GR4VY. These benchmarks primarily reflect North American and European markets; authorization rates in LATAM and APAC regions often trend lower due to different issuer practices and fraud patterns. That said, even within this range, a “good” rate for one merchant may represent millions in lost revenue for another at similar scale. The top-line number tells you your approval percentage, but it doesn’t tell you why transactions fail, which failures you can fix, or how much money sits on the table.

Your authorization rate is a composite of multiple failure modes blended into one figure. It includes hard declines (stolen cards, closed accounts) that you can’t recover. It includes soft declines (insufficient funds, processor timeouts, missing authentication data) that you often can recover. It includes transactions flagged by issuer fraud models for patterns that aren’t actually fraudulent. And it includes a massive bucket of “do not honor” responses that carry no diagnostic value at all.

When you look at a single number on a dashboard, you’re averaging all of these together. A stable 91% might mean your soft decline recovery is excellent and your hard decline rate is creeping up. Or it might mean your fraud flags are increasing but your retry logic is compensating. You can’t tell, because the metric doesn’t decompose itself.

## What Your Dashboard Isn’t Showing You: The Anatomy of a Decline

Here’s the first thing most dashboards obscure: 80% to 90% of all payment declines are soft declines, meaning they’re potentially recoverable. Soft declines can often be resolved through retry logic, updated card credentials, or richer transaction data sent to the issuer. Yet most dashboards don’t clearly separate soft declines from hard declines (Spreedly; GR4VY).

The second thing your dashboard hides is even more frustrating. According to a 2016 Visa Global Declines Analysis, over 76% of Visa’s global declined transaction volume fell into just two categories: “insufficient funds” and “do not honor.” Industry sources confirm this pattern persists today (Churnkey). The “do not honor” code (response code 05) is a catch-all that can represent anywhere from 10% to 60% of all refused payments depending on geography (Churnkey). As American Banker reported, issuing banks put most declines into one large bucket of “do not honor,” giving merchants almost no information about why a transaction actually failed.

Think about what that means in practice. Your dashboard shows a decline. The decline code says “do not honor.” You have no idea whether the issue was a fraud rule, a velocity check, an address mismatch, or something else entirely. **You can’t fix what you can’t diagnose.**

If you run payments across multiple processors, the problem compounds. Each PSP uses different data formats, reporting structures, decline code taxonomies, and settlement timelines. A merchant using Stripe, Adyen, and Braintree may see three different decline rates for the same region with no way to normalize or compare them (Payrails). Every PSP dashboard shows different metrics, with fields that don’t match and varying timeframes, creating fragmented reporting that hides revenue opportunities.

For multi-PSP merchants, your authorization rate isn’t just a vanity metric. It’s three or four different vanity metrics that don’t talk to each other.

## The Hidden Revenue Leak: Quantifying What You’re Losing

The revenue buried beneath your authorization rate is larger than most payment teams realize.

False declines (legitimate transactions incorrectly rejected) cost merchants an estimated $308 billion globally in 2023, according to industry estimates compiled by Riskified and others. That figure exceeds actual fraud losses. A more conservative 2026 estimate from PYMNTS places the number at $50 billion. Either way, merchants lose more money to false declines than to fraud itself, a point Chargebacks911 has emphasized (CrowdFund Insider).

The customer impact is just as stark. In 2024, 56% of U.S. consumers reported experiencing a false payment decline in the prior three months (PYMNTS). Among loyal customers who experience a false decline, subsequent order volume drops by 65% (Riskified). Riskified’s research shows that 27% of loyal customers never return to the merchant after a false decline. Broader studies suggest 32% to 33% of all consumers abandon a merchant entirely after the experience (Riskified; Signifyd).

For subscription and SaaS businesses, the math gets worse. The average SaaS business loses approximately 9% of its recurring revenue to failed payments annually, effectively negating a full month of growth each year (Stripe analysis, via Baremetrics). Involuntary churn, caused by failed payments rather than customer decisions, accounts for 20% to 40% of total churn in subscription businesses (ProfitWell research, via Userpilot).

Consider what that means if you’re running a $40 million ARR SaaS company. Nine percent of recurring revenue is $3.6 million per year lost to payment failures. Only about 70% of failed payments are ever recovered on average (Recurly Research). The remaining 30% becomes permanent revenue loss that your dashboard attributes to “churn” without distinguishing whether the customer chose to leave or their payment simply failed.

Your authorization rate doesn’t tell you any of this. It shows you a percentage. It doesn’t show you the customers who left because their renewal was declined, the revenue that could have been retried, or the fraud rules that are blocking your own subscribers.

## What High-Performing Merchants Do Differently

The gap between average and top-performing merchants isn’t luck. It’s instrumentation and process. Here are the specific techniques that move authorization rates by meaningful amounts, backed by data.

**Network tokenization.** Replacing stored card numbers (PANs) with network-level tokens delivers a measurable 2 to 6 percentage point lift in authorization rates. Visa reported a 4.6% global authorization rate lift for tokenized transactions versus PAN-based transactions, along with a 30% reduction in fraud (Visa Acceptance Solutions). Mastercard reports a 3 to 6 percentage point improvement (Mastercard). By 2024, 47% of merchants had adopted tokenization, up from 44% in 2023. By 2025, six in 10 merchants using tokenization cited authorization rate improvement as a primary benefit (MRC Global Reports).

**Intelligent retry logic.** Smart retry engines, combined with card account updater services, recover 60% to 70% of failed payments (Slickerhq; Cleverbridge). The timing, sequencing, and data enrichment of retries matters enormously. A retry sent at the wrong time or without updated card information fails just like the original attempt. A retry sent with fresh credentials, when the cardholder’s account is more likely to have funds, succeeds at significantly higher rates.

Stripe’s Adaptive Acceptance recovered $6 billion in falsely declined transactions in 2024, reflecting a 60% year-over-year increase in retry success rate (Stripe). Their average authorization rate lift across merchants is roughly 2.2%.

**Richer transaction data for issuers.** Issuers decline transactions when they lack confidence that the transaction is legitimate. Sending additional data fields (device fingerprint, customer tenure, transaction history) gives issuers more context to approve. One athletic apparel brand working with Riskified lifted authorization rates from 82% to 95% by enriching transaction data and optimizing the fraud decisioning layer before transactions reached issuers (Riskified).

**Unified cross-processor analytics.** Merchants who normalize their decline data across processors can spot patterns invisible in siloed dashboards. Is one processor declining more transactions in a specific BIN range? Are issuer fraud rules triggering differently depending on which acquirer routes the transaction? Without unified analytics, these questions go unanswered.

The proof points are compelling. Zapier achieved a 4% authorization rate uplift by combining Adaptive Acceptance, network tokens, and card account updater, translating to over $3 million in additional revenue (Stripe Newsroom). GAIA, a streaming company, moved from 80% to 89%+ authorization rates after gaining visibility into why transactions were failing and applying targeted optimization (Stripe). Worldpay reports that their optimization tools deliver a 1.5% revenue uplift within 90 days for participating merchants.

## From Vanity Metric to Revenue Recovery: Five Steps to Start

Closing the authorization rate blind spot doesn’t require a full platform migration. It starts with visibility.

**1. Disaggregate your authorization rate.** Break your top-line number down by decline type (soft vs. hard), decline code, issuer, BIN range, card brand, and processor. This single step often reveals that 80% or more of your declines are soft and potentially recoverable.

**2. Build a soft decline retry strategy.** Not all retries are equal. Map your most common soft decline codes to specific retry actions: timing adjustments, credential updates, data enrichment, or alternative routing. Target a 60% to 70% recovery rate on soft declines as your benchmark.

**3. Adopt network tokens.** If you haven’t moved to network tokenization, you’re leaving a 2 to 6 percentage point authorization rate lift on the table. The merchant adoption curve is accelerating, and the data on authorization rate improvement is consistent across card networks.

**4. Unify your payments data across processors.** If you run multiple PSPs, you need a single view that normalizes decline codes, standardizes reporting periods, and lets you compare performance across processors for the same transaction types. Fragmented dashboards make optimization guesswork.

**5. Measure what matters.** Track false decline rate, soft decline recovery rate, involuntary churn rate, and revenue recovered per retry cycle. These metrics tell you whether your authorization rate is improving because you’re actually approving more real buyers, or just because your transaction mix shifted.

Each of these steps moves you from treating your authorization rate as a number to check toward treating it as a system to optimize. The merchants recovering millions in previously lost revenue aren’t doing anything mysterious. They’re looking at data that was always there, just buried beneath a single percentage on a dashboard.

**For payment teams ready to dig into their decline data across processors and pinpoint exactly where revenue is leaking, Corgi Intelligence and Corgi Model provide this level of visibility and optimization, with results in days and no development work required.**

The 91% on your dashboard isn’t wrong. It’s just not telling you the whole story.



---



## Sources

- [American Banker, “05: Do Not Honor Card Refusals Are Confusing to Merchants”](https://www.americanbanker.com/payments/opinion/05-do-not-honor-card-refusals-are-confusing-to-merchants)
- [Baremetrics, “5 Ways to Prevent Involuntary Churn in SaaS”](https://baremetrics.com/blog/involuntary-churn) (citing Stripe analysis on SaaS failed payment revenue loss)
- [CrowdFund Insider, “False Declines Costing Merchants More Than Fraud, Report Claims”](https://www.crowdfundinsider.com/2025/10/254284-false-declines-costing-merchants-more-than-fraud-report-claims/) (Chargebacks911)
- [Churnkey, “Do Not Honor Decline: Meaning, Stats, and How To Fix”](https://churnkey.co/blog/do-not-honor-decline/) (citing Visa Global Declines Analysis, 2016)
- [Cleverbridge, “Recover Failed Payments and Prevent Involuntary Churn with AI-powered Retry Logic”](https://grow.cleverbridge.com/blog/failed-payment-recovery-dynamic-retries)
- [GR4VY, “Approval Rates in Payments: Meaning and Deep Dive for 2025”](https://gr4vy.com/posts/approval-rates-in-payments-meaning-and-deep-dive-for-2025/)
- [GR4VY, “What Is the Difference Between Hard and Soft Decline in Payments?”](https://gr4vy.com/posts/what-is-the-difference-between-hard-and-soft-decline-in-payments/)
- [MRC, “2025 Global eCommerce Payments and Fraud Report”](https://merchantriskcouncil.org/learning/mrc-exclusive-reports/global-payments-and-fraud-report)
- [MRC, “2024 Global eCommerce Payments and Fraud Report”](https://merchantriskcouncil.org/learning/mrc-exclusive-reports/global-payments-and-fraud-report/2024-global-payments-and-fraud-report)
- [Optimized Payments, “Network Tokenization: A Strategic Advantage in Modern Payments”](https://optimizedpayments.com/insights/card-fees/network-tokenization-a-strategic-advantage-in-modern-payments/) (Mastercard data)
- [Payrails, “From Data Fragmentation to Strategic Control”](https://www.payrails.com/blog/unified-payment-analytics)
- [PYMNTS, “56% of US Consumers Experienced a False Payment Decline in Last 90 Days” (2024)](https://www.pymnts.com/news/payments-innovation/2024/56-of-us-consumers-experienced-a-false-payment-decline-in-last-90-days)
- [PYMNTS, “47% of Merchants Say False Declines Cost Them Sales” (2026)](https://www.pymnts.com/fraud-prevention/2026/47-percent-of-merchants-say-false-declines-cost-them-sales/)
- [Riskified, “The True Cost of Declined Orders”](https://www.riskified.com/blog/true-cost-declined-orders/)
- [Riskified, “Unlock Revenue by Optimizing Payment Authorization Rates”](https://www.riskified.com/blog/payment-authorization-rates/) (athletic apparel brand case study, 82% to 95% lift)
- [Signifyd, “5 Strategies to Increase Bank Authorization Rates for Merchants”](https://www.signifyd.com/blog/increase-authorization-rates/)
- [Slickerhq, “Cut Involuntary Churn by 70% in 2025”](https://www.slickerhq.com/blog/cut-involuntary-churn-70-percent-ai-retry-engines-vs-static-billing-logic-2025)
- [Spreedly, “How to Improve Soft and Hard Decline Rates”](https://www.spreedly.com/blog/how-to-improve-soft-and-hard-decline-rates)
- [Stripe, “AI Enhancements to Adaptive Acceptance”](https://stripe.com/blog/ai-enhancements-to-adaptive-acceptance) ($6B recovery in 2024)
- [Stripe, GAIA Customer Case Study](https://stripe.com/en-jp/customers/gaia) (80% to 89%+ authorization rate)
- [Stripe Newsroom, “Zapier sees 4% uplift in auth rates with Stripe”](https://stripe.com/newsroom/stories/zapier) ($3M+ additional revenue)
- [Userpilot, “Involuntary Churn vs Voluntary Churn in SaaS”](https://userpilot.com/blog/involuntary-churn/) (citing ProfitWell research, 20-40% of total churn)
- [Visa Acceptance Solutions, “Tokens Are Key to Future Proofing Payments”](https://www.visaacceptance.com/en-us/blog/article/2025/tokens-are-key-to-future-proofing-payments.html) (4.6% auth rate lift, 30% fraud reduction)
- [Worldpay, “The C-Suite’s Guide to Payment Authorization Rates”](https://www.worldpay.com/en/insights/articles/c-suite-guide-to-auth-rates) ($10M per percentage point at $1B volume)
- [Worldpay, “Smarter Payments, More Revenue”](https://www.worldpay.com/en/insights/articles/authorization-rates-insights) (1.5% revenue uplift within 90 days)

---

## Documentation

### Overview Dashboard

https://www.corgilabs.ai/docs/corgi-intelligence/overview-dashboard

Understand your payment health at a glance with AI-powered insights tailored to your business model.

Your payment data holds the story of your business health. The Overview Dashboard in Corgi Intelligence surfaces that story at a glance, so you spend less time digging through charts and more time acting on what matters.

This page is your home base. It shows the metrics that matter most to your business model, plus AI-generated Key Insights that flag trends and revenue opportunities you might otherwise miss. Corgi Intelligence auto-detects whether you run a retail or subscription business during onboarding, then tailors the dashboard to match.

---

## Dashboard Modes: Retail vs. Subscription

Corgi Intelligence selects one of two dashboard modes based on your business model. You do not need to configure this manually.

| Mode | Best For | Key Focus |
|---|---|---|
| Retail | E-commerce, marketplaces, and physical goods | One-time purchases, GMV, and product performance |
| Subscription | SaaS, recurring billing, and usage-based models | Recurring revenue, retention, and churn signals |

If your dashboard mode does not match your business model, reach out to your Corgi Labs contact. They will update your configuration.

---

## Retail Dashboard

If you sell one-time products or services, your Overview Dashboard centers on purchase behavior and product performance. Here are the metrics you will see.

**Gross Merchandise Value (GMV)**. The total value of all transactions processed in the selected period. This is your top-line revenue number.

**Number of Transactions**. The total count of payment attempts, including both approved and declined transactions.

**Refund Rate**. The percentage of transactions that were refunded, with a trend comparison against the previous period. A spike here can signal product issues, fulfillment problems, or policy friction.

**Number of Unique Customers**. The count of distinct customers who made at least one purchase in the period. This helps you gauge reach beyond raw transaction volume.

**Repeat Purchase Rate**. The percentage of customers who made two or more purchases. This is a direct indicator of loyalty and product-market fit.

**Customer Lifetime Value (CLV)**. The average revenue per customer over their entire relationship with your business. Use this to calibrate acquisition spend and retention priorities.

**Average Order Value (AOV)**. The mean transaction amount per order. Small movements in AOV can drive outsized revenue impact at scale.

**Top 10 Products by GMV Contribution**. A ranked table showing your best-performing products by revenue. Each row includes purchase count, repeat customers, and the percentage of total revenue that product represents. Use this to spot winners, duds, and portfolio concentration risk.

---

## Subscription Dashboard

If you run a recurring or usage-based billing model, your Overview Dashboard focuses on revenue predictability and customer retention. Here are the metrics you will see.

**Monthly Recurring Revenue (MRR)**. Your predictable monthly revenue from active subscriptions. This is the heartbeat of your subscription business.

**Net Revenue Retention (NRR)**. Measures expansion, contraction, and churn relative to your starting revenue. An NRR above 100% means your existing customers are growing your revenue.

**Gross Revenue Retention (GRR)**. The revenue you retain from existing customers, excluding expansion revenue. This shows how well you hold onto revenue before any upsells.

**Logo Churn Rate**. The percentage of customers who canceled during the period. Track this alongside revenue churn to understand whether you are losing small customers or large ones.

**Dunning Recovery Rate**. The percentage of failed subscription payments recovered through retry logic and dunning flows. A low rate here can signal a need to tighten your recovery strategy.

**Deferred Revenue Balance**. Revenue you have collected but not yet recognized. This matters for accounting accuracy and cash flow forecasting.

**Revenue at Risk**. Revenue tied to customers showing churn signals or failed payments. Use this to prioritize outreach before cancellation happens.

---

## Key Insights

At the top of your Overview Dashboard, Corgi Intelligence surfaces AI-generated Key Insights. These are not static tips. They are observations drawn from your latest payment data, updated automatically, and designed to surface high-impact changes without manual chart review.

Here are the insight types you may see:

**Approval Upside**. An estimate of additional revenue you could unlock by improving your approval rate. The insight includes a specific dollar estimate, so you know the size of the opportunity.

**Disputes Down / Up**. A flag when your dispute rate changes meaningfully compared to the previous period. The insight includes a breakdown by primary and comparison ranges, so you see where the shift is coming from.

**Churn Spike**. An alert when churned revenue exceeds historical norms. The insight includes recommended actions, such as aligning dunning and card updater efforts to recover at-risk revenue.

**Rule Bias**. A warning when your fraud rules may be generating too many generic declines. The insight suggests refinements to help you block fraud, not buyers.

Key Insights refresh automatically as new data arrives. Treat them as your starting point for daily prioritization, not a replacement for deeper analysis.

---

## Payments & Fraud Overview

Both dashboard modes include a Payments & Fraud Overview section at the bottom of the page. These four metrics apply to every merchant, regardless of business model. Each includes a trend comparison against the previous period.

**Authorization Rate**. The percentage of payment attempts approved by the issuing bank. This is the single biggest lever for revenue growth in most businesses.

**Dispute Rate**. The percentage of transactions that resulted in a customer dispute. Watch this closely, as disputes can trigger network monitoring programs and increase processing costs.

**Block Rate**. The percentage of transactions blocked by your fraud rules or risk screening. A sudden jump here can mean your rules are too tight, or that you are under attack.

**Abandonment Rate**. The percentage of checkout sessions abandoned before payment completion. High abandonment can signal UX friction, unexpected fees, or payment method gaps.

For deeper analysis, see Payment Analytics and Dispute & Fraud.

---

### Payment Analytics

https://www.corgilabs.ai/docs/corgi-intelligence/payment-analytics

Track your complete payment funnel, identify where transactions fail, and find opportunities to improve your authorization rate.

The Payment Analytics page gives you a comprehensive view of your payment performance from checkout to final outcome. Use it to understand your payment funnel, identify where transactions fail, and find opportunities to improve your authorization rate.

---

## Payment Funnel

The **Payment Funnel** visualizes the complete transaction flow from checkout through risk screening, 3D Secure authentication, and final outcome. Each stage shows both the count and the dollar volume, so you can see both the frequency and financial impact at every step.

The funnel has four stages:

- **Checkout:** Total checkout sessions initiated by customers, and how many lead to attempted payments.

- **Risk Model:** Transactions evaluated by fraud prevention services, typically offered by your payment provider or a 3rd party, including by Corgi Labs. Shows how many transactions were approved vs. blocked.

- **3DS:** Transactions routed through 3D Secure authentication, performed by the card issuer. Shows three outcomes: No 3DS (not required), 3DS Passed, and 3DS Failed.

- **Outcome:** Final result of the payment: succeeded or declined by the issuer.

---

## Core Payment Metrics

Two metrics show top-line payment performance:

- **Payment Success Rate:** The overall percentage of payment attempts that resulted in a successful charge. This metric accounts for all failure points, including fraud blocks, 3DS failures, and issuer declines. A trend comparison against the previous period is shown.

- **Authorization Rate:** The percentage of payment attempts that were authorized (approved) by the issuing bank, after passing through risk screening and 3DS. This isolates network-level acceptance from fraud blocks performed by your payment and fraud prevention providers.

The distinction matters for diagnosis. Payment Success Rate tells you whether customers are completing payment. Authorization Rate tells you specifically how the issuing bank is responding, independent of what your fraud tools did upstream.

---

## Block, Decline & Abandonment Rates

Three rates show why payments do not succeed:

- **Block Rate:** Percentage of transactions blocked by your fraud rules or risk model before reaching the payment network.

- **Decline Rate:** Percentage of transactions declined by the card network or issuing bank.

- **Abandonment Rate:** Percentage of checkout sessions abandoned by the customer.

Each represents a different failure mode with a different corrective action. Blocks happen before the network (a merchant or fraud provider decision), declines happen at the issuer level, and abandonment is customer-initiated.

---

## Block Reasons

This section breaks down why transactions were blocked during risk screening. A stacked bar chart shows monthly volumes by block source, so you can see which rules or signals are driving the most blocks over time.

---

## 3D Secure Authentication

This section examines 3DS challenge rates and authentication performance across four metrics:

- **3DS Rate:** Percentage of transactions routed through 3D Secure.

- **3DS Success Rate:** Percentage of 3DS authentications that were successful.

- **Challenge Rate:** Percentage of 3DS transactions that triggered an active challenge, as opposed to frictionless authentication.

- **Challenge Success Rate:** Percentage of 3DS challenges that were successful.

A monthly breakdown chart shows Successful Challenges, Successful Frictionless, and Failed Challenges over time. A summary table shows the count, share, and request volume for each outcome.

---

## Decline Reasons Distribution

A stacked bar chart shows decline counts by reason category over time.

Use this to identify whether declines are driven by preventable issues (like expired cards) or systemic problems (like issuer-side fraud flags). The distinction shapes what action to take. Preventable issues can often be addressed through payment operations changes, while systemic issuer-side declines may require a different approach to authorization optimization.

---

## Geographic Payment Distribution

A world map visualization shows payment volume by card-issuing country. Use it to understand the geographic distribution of your customers and identify regions with unusually high decline or fraud rates.

---

## Deduplication Setting

Payment metrics can be viewed as deduplicated or raw:

- **Deduplicated:** Counts only the final outcome per payment, removing duplicate retries. Multiple attempts are treated as the same payment when they share:
  - The same `invoice_id` for subscription payments, or
  - The same Customer + close-in-time + same amount, or
  - The same card number + close-in-time + same amount

- **Raw:** Counts all payment attempts.

Tracking the same metrics across the same setting allows a fair evaluation of performance over time. Depending on your business model, a significant difference between deduplicated and raw metrics may indicate increased customer checkout friction.

---

### Customer Overview

https://www.corgilabs.ai/docs/corgi-intelligence/customer-overview

Analyze customer behavior, retention, and lifetime value to spot churn early and identify your most valuable buyers.

The Customer Overview page in Corgi Intelligence gives you a single place to analyze how your customers buy, how often they come back, and which ones drive the most value. Use it to spot retention problems early, identify your best customers, and decide where to invest in acquisition or loyalty.

---

## What you will see

The page contains four sections:

1. A combined **acquisition, retention, and churn chart**

1. Your **repeat purchase rate**

1. **Customer lifetime value (CLV)**

1. A **top frequent customers** table

Data comes from your connected Stripe account. Metrics update as new transactions are processed.

---

## Customer acquisition, retention, and churn

The main chart shows four metrics over time so you can see the relationship between bringing in new customers and keeping existing ones.

### Metrics in the chart

| Metric | What it means |
|---|---|
| **Total Customers** | The number of unique customers who made a purchase during the selected period. |
| **New Customers** | First-time buyers who had no prior transactions. |
| **Returning Customers** | Buyers who made at least one previous purchase. |
| **Churn Rate** | The percentage of customers who purchased in the previous period but did not return in the current period. |

### How to read the chart

Look at the balance between new and returning customer areas. A healthy business usually shows steady or growing returning customer volume alongside new customer growth.

Watch the churn rate line closely. If churn is rising while new customer growth stays flat, your retention is weakening. That is a signal to investigate causes, such as checkout friction, product issues, or increased payment failures.

If returning customers are growing but new customers are shrinking, you may be over-relying on existing buyers. That works in the short term, but it limits long-term growth.

---

## Repeat Purchase Rate

The repeat purchase rate shows the percentage of your customers who have made 2 or more purchases. It is a direct measure of loyalty.

A higher repeat purchase rate usually means two things:

- Your product or service matches what buyers want (strong product-market fit).

- Your retention efforts, such as email campaigns or loyalty programs, are working.

A low or falling rate suggests customers are not finding enough reason to come back. That could be a pricing issue, a competitive alternative, or a poor post-purchase experience.

---

## Customer Lifetime Value (CLV)

Customer lifetime value shows the average total revenue each customer generates across their entire relationship with your business.

Use this number to answer practical questions:

- **How much can I spend to acquire a customer?** If your CLV is $500 and your target payback period is 6 months, you know your ceiling for customer acquisition cost (CAC).

- **Should I invest more in retention?** Compare CLV for customers who joined 12 months ago versus 3 months ago. If newer customers have lower projected CLV, retention investment may be more efficient than acquisition spending.

- **Which segments are most valuable?** CLV varies by customer type, channel, or cohort. Use it to double down on the segments that generate the most long-term revenue.

CLV is calculated from all historical transaction data available in your Stripe account, so it becomes more accurate as you accumulate more purchase history.

---

## Top Frequent Customers

The top frequent customers table lists your most active buyers, ranked by purchase volume and filtered to surface customers with fewer disputes. For each customer, you can see:

| Column | What it shows |
|---|---|
| **Customer name and email** | The identifier from Stripe. |
| **Purchases** | Total number of completed transactions. |
| **Disputes** | Number of payment disputes initiated by this customer. |
| **Total Spent** | Cumulative revenue from this customer. |
| **Avg. Order** | Average transaction value. |
| **Last Purchase** | Date of the most recent transaction. |

### What to do with this data

**Identify VIPs.** Customers with high total spent, frequent purchases, and low dispute counts are your best candidates for loyalty programs, early access offers, or personalized outreach.

**Spot warning signs.** A customer with high purchase volume but rising disputes may indicate a problem: confusion about billing, product quality issues, or a payment method that is being tested by a fraudster. Investigate before the pattern escalates.

**Plan retention campaigns.** Customers whose last purchase date is growing stale but who have high historical value are ideal targets for win-back campaigns.

---

## Putting the data together

The four sections work best when you cross-reference them. For example:

- If your churn rate is rising, check your **authorization rate** and **dispute volume** in other Corgi Intelligence reports. Payment friction and disputes are common causes of attrition.

- If your **repeat purchase rate** is falling but **CLV** is stable, your remaining repeat buyers may be spending more per order. That shifts the problem from frequency to acquisition.

- If a customer shows up in the **top frequent customers** table with a rising dispute count, that is a red flag even if total purchases look strong.

---

## Data and availability

Customer Overview data is drawn directly from your Stripe transaction feed. There is no additional setup required beyond your standard Stripe integration.

Metrics reflect the date range selected in the time picker at the top of the page. Historical depth depends on how far back your Stripe data extends; Corgi Intelligence uses all available transaction history for CLV and repeat purchase calculations.

---

### Customer Clusters

https://www.corgilabs.ai/docs/corgi-intelligence/customer-clusters

Use AI-powered segmentation to group customers by spending and purchase frequency, and target retention and marketing by segment.

Customer Clusters uses AI-powered segmentation to group your customers by spending behavior and purchase cadence. This gives you a clear view of who your highest-value buyers are, where churn risk sits, and how to allocate marketing and retention spend instead of working through flat customer lists.

The analysis is based on two dimensions:

- **Average Order Value** (x-axis) — How much the customer spends per transaction.

- **Purchase Frequency** (y-axis) — How often the customer makes purchases, measured per month.

Corgi automatically identifies natural groupings in your customer base and assigns each customer to a cluster. The scatter plot on the Clusters page visualizes every customer, color-coded by their assigned cluster, so you can see density, outliers, and boundaries at a glance.

---

## The five customer segments

> **Note:**
>
> The segments below are the typical output for a merchant with healthy transaction volume and a diverse customer base.

### High-Value Customers

These are your most valuable customers: high spending, high frequency, top-right quadrant on the scatter plot.

- Characterized by above-average order values and high purchase frequency.

- Strategy: Prioritize retention, offer loyalty rewards, and ensure premium support.

### Loyal Frequent Buyers

Regular customers with moderate spending but consistent engagement. They appear in the upper-left or mid-top area of the scatter plot.

- Purchase often, even if individual order values are modest.

- Strategy: Encourage upselling and cross-selling to increase AOV.

### Price-Conscious Buyers

Budget-focused customers in the lower-left area who respond well to discounts and promotions.

- Tend to have lower order values and purchase less frequently.

- Strategy: Use targeted promotions and discount campaigns to drive repeat purchases.

### New Explorers

Recent customers still evaluating your product. They sit in the bottom-middle to mid-right range.

- Low frequency with moderate order values.

- Strategy: Focus on onboarding, first-purchase follow-ups, and welcome campaigns to convert them into repeat buyers.

### Dormant Customers

Previously active customers who have not purchased recently. They sit along the bottom of the scatter plot with near-zero frequency.

- Purchase history exists, but no recent activity.

- Strategy: Launch re-engagement campaigns, win-back offers, or surveys to understand why they left.

---

## Reading the charts and cards

### Cluster Summary Cards

Each cluster has a summary card showing four metrics:

| Metric | What it means |
|---|---|
| Total Revenue | Aggregate revenue from all customers in the segment. |
| Avg Order Value | Mean transaction amount for the segment. |
| Customers | Number of customers in the segment. |
| Frequency | Average purchases per month. |

Use the summary cards to compare segments numerically and identify which group is driving the most revenue.

### Segment Performance

A combined bar and line chart shows the number of customers (bars) and total revenue (line) for each segment side by side. This makes it easy to see which segments have the most customers versus which contribute the most revenue.

### Purchase Behavior by Segment

This chart compares average purchases per month and average order value across all segments. It helps you quickly identify which segments buy more often and which spend more per order.

### The Scatter Plot

The main Clusters view plots every customer on Average Order Value (x) and Purchase Frequency (y). Each point is color-coded by its cluster assignment. Use it to identify dominant segments, think about natural boundaries, and spot outliers worth investigating.

---

## Turning insights into action

A practical workflow for using Customer Clusters:

1. Open the Clusters page and look at the scatter plot to identify your dominant segments.

1. Check Segment Performance to confirm which clusters contribute the most revenue.

1. Drill into the Cluster Summary Cards for exact counts, averages, and frequency.

1. Use Purchase Behavior by Segment to compare the tradeoffs between high-frequency and high-AOV groups.

1. Act on each cluster using the recommended strategy for that segment.

| Cluster | Recommended strategy |
|---|---|
| High-Value Customers | Prioritize retention, offer loyalty rewards, and ensure premium support |
| Loyal Frequent Buyers | Encourage upselling and cross-selling to increase AOV |
| Price-Conscious Buyers | Use targeted promotions and discount campaigns to drive repeat purchases |
| New Explorers | Focus on onboarding, first-purchase follow-ups, and welcome campaigns to convert them into repeat buyers |
| Dormant Customers | Launch re-engagement campaigns, win-back offers, or surveys to understand why they left |

---

## Notes and limitations

- **Small customer bases.** Clusters may be less distinct with a small number of customers. Segmentation improves as transaction volume grows.

- **Single-purchase customers.** May cluster as New Explorers or Dormant depending on recency.

- **Seasonal merchants.** Purchase frequency can shift dramatically month to month. The clusters adapt automatically, but you should account for seasonality when deciding which segments to act on.

- **New merchant onboarding.** First-time users may see sparse or shifting clusters until enough transaction history accumulates.

---

### Disputes & Fraud

https://www.corgilabs.ai/docs/corgi-intelligence/disputes-and-fraud

Use the Disputes & Fraud page in Corgi Intelligence to monitor dispute trends, understand fraud sources, and reduce chargebacks.

The Disputes & Fraud page in Corgi Intelligence gives you a complete view of dispute activity, fraud patterns, and their financial impact on your business. Use it to track trends over time, identify where disputes are coming from, and take action to reduce chargebacks.

---

## Dispute, Fraud, and Chargeback Rate & Count

At the top of the page, you will see two headline numbers:

- **Dispute, Fraud, and Chargeback Rate:** The percentage of your transactions that resulted in a dispute, a fraud claim, or a chargeback during the selected period.

- **Count:** The total number of dispute, fraud, and chargeback cases in that same period.

Both numbers include a trend comparison against the previous period, so you can see at a glance whether your dispute activity is rising or falling.

**How to read them:** Use the rate to understand proportional impact (are disputes growing relative to your total volume?) and the count to see absolute volume (how many cases are you actually handling?). A falling rate with a rising count often means you are growing fast but dispute prevention is not keeping pace. A rising rate with a flat count means disputes are eating into existing volume.

---

## Dispute Win Rate

The **Dispute Win Rate** shows the percentage of disputes you have won.

A low win rate is a signal. It may mean your evidence is thin, your response practices are inconsistent, or the disputes you are receiving are difficult to win. Review your evidence practices: make sure you include delivery confirmation, customer communication logs, and transaction details in every response.

---

## Estimated Loss Analytics

This section shows the estimated financial damage from disputes and fraud. It is calculated as **three times the total disputed amount**.

The 3x multiplier captures more than just the refunded transaction value. It includes operational costs (time spent responding), network fees, and the lost value of goods or services already delivered. This gives you a realistic picture of what disputes are actually costing your business.

Use this metric to prioritize investment. If your estimated loss is rising, it may be time to tighten your fraud model, review fulfillment processes, or shift payment methods.

---

## Fraud Breakdowns

### Dispute Reason Breakdown

A stacked bar chart shows how many disputes fall into each reason category over time:

- **Fraud** (unauthorized use of a card)

- **Product Not Received**

- **Product Unacceptable**

- **Duplicated Charge**

- **All Other Reasons**

This view answers a critical question: are your disputes driven by fraud, or are they operational problems you can fix?

If fraud dominates your chart, focus on detection and prevention: review your authorization rules, check for card-testing attacks, and make sure your fraud model is tuned to your transaction patterns. If Product Not Received or Product Unacceptable lead the pack, look at your fulfillment and customer service workflows. Duplicated Charge disputes often point to a UI bug or a retry loop in your checkout flow.

### Payment Method Distribution

This section breaks down disputes and fraud by payment method (for example, Visa, Mastercard, American Express, JCB). It highlights three specific lenses:

- **Highest Fraud Rate by method:** Which card brand carries the most fraud risk for your business?

- **Most Disputes by method:** Which brand generates the highest absolute volume of disputes?

- **Safest Payment Method:** Which brand has the lowest dispute and fraud rate for you?

A bar chart compares Fraud vs. Other Disputes for each payment method, so you can see not just which methods are problematic, but what kind of problem they create.

#### Why payment method matters

Different card networks have different dispute rules, liability protections, and fee structures. Understanding these patterns helps you decide whether to adjust your acceptance rules by network.

### Payment Method Details Table

Below the chart, a detailed table gives you precise numbers for each payment method:

| Column | What it shows |
|---|---|
| Dispute Rate | Percentage of transactions for this method that became disputes |
| Dispute Count | Raw number of disputes for this method |
| % of Total Disputes | Share of all your disputes attributed to this method |
| Fraud Rate | Percentage of transactions for this method flagged as fraud |
| Fraud Count | Raw number of fraud disputes for this method |
| % of Total Fraud | Share of all your fraud attributed to this method |

Use the table when you need exact figures for reporting or for targeting a specific payment method. Use the chart when you are looking for broad patterns.

### Country Breakdown

Switch to the **Countries** tab to see fraud and dispute patterns by geography. This view helps you identify high-risk regions, spot sudden spikes in specific countries, and adjust geographic risk rules in your fraud model.

If you see a fraud surge from a single country, investigate whether it coincides with a recent campaign, a new sales channel, or a known card-testing pattern. If a previously safe country suddenly shows disputes, check for a change in your shipping policy or targeting.

---

## Rate Basis Setting

You can toggle how rates are calculated using the **Rate Basis** setting:

- **Dispute date:** Rates are calculated based on when the dispute was filed. Use this to understand your current dispute workload and recent trends.

- **Transaction date:** Rates are calculated based on when the original transaction occurred. Use this when you need to link a fraud spike to a specific event, like a product launch, a promotional campaign, or a system change.

**Why the two views differ:** A dispute filed today may be tied to a transaction from weeks ago. If you had a flash sale three weeks ago and your fraud rate spikes this week under Dispute date, the cause is not a new attack. It is the delayed appearance of fraudulent transactions from that sale. Flip to Transaction date to confirm the timing.

---

## Putting it together

Use the Disputes & Fraud page in a regular review cycle:

1. Check your headline rate and count to spot trends.

1. Review your win rate to judge whether your dispute response process is effective.

1. Look at Estimated Loss to quantify the business impact.

1. Use the Fraud Breakdowns to find the root cause: payment method, geography, or dispute reason category.

1. Adjust your Rate Basis to confirm whether a spike is recent or delayed from an earlier event.

If fraud is the dominant driver, review your Corgi Model rules or explore tightening your authorization settings. If operational issues lead your dispute reasons, focus on fulfillment and customer communication workflows.

---

### Product Performance

https://www.corgilabs.ai/docs/corgi-intelligence/product-performance

See which products drive your purchases, revenue, and repeat customers. Data updates automatically with no setup.

The Product Performance page in Corgi Intelligence shows you which products drive the most purchases, revenue, and customer engagement. You can use this report to identify your biggest sellers, spot products that never move, and make data-driven decisions about marketing.

Choose a date range and all charts and tables update together. The data comes straight from your transaction history, so there is no configuration required.

## Top Products by Purchase Volume

This section gives you a quick visual ranking of every product by total purchases during your selected period.

A bar chart lists your products from highest to lowest by purchase count. You can scan the bars to see which items are selling well and which ones sit at the bottom. If you expected a product to rank higher, you can dig into the details table (below) to check revenue, repeat buyers, and overall share.

## Revenue Distribution by Category

This section shows how your revenue is spread across product categories.

A donut chart breaks down total revenue by category. This helps you see whether your business depends on one area or spreads across many. If 80% of your revenue comes from a single category, that is not necessarily bad, but it tells you where your risk and opportunity live. Diversification might make sense, or you might choose to double down on what works.

## Product Performance Details

The table below the charts lists every product line by line. It includes six columns:

- **Product Name** — The name or description of the product.

- **Category** — The product category.

- **Purchases** — Total number of transactions for this product.

- **Repeat Customers** — Number of customers who purchased this product more than once.

- **Revenue** — Total revenue generated by this product.

- **% of Total** — This product's share of your total revenue.

You can sort the table by any column. Click a header once to sort ascending, again to sort descending. The table is paginated, so businesses with large catalogs can move through products without overwhelming the page.

## How to Use This Data

Here are three practical ways to turn the report into action:

1. **Identify top performers.** Look at products with high purchase counts, strong revenue, and repeat buyers. These are your winners. Funnel more of your marketing budget, ad spend, and inventory investment here.

1. **Spot products with high repeat rates.** If a product has a lot of repeat customers, it may be a fit for subscriptions, bundles, or loyalty promotions. Customers are already coming back, so make it easier for them to do it again.

1. **Find underperformers.** Products with low purchase counts or a tiny revenue share might need attention. Try adjusting the price, rewriting the description, or running a targeted promotion before removing them from your catalog.

## Notes

- The date range selector applies to every section on the page at once.

- All data comes from your transaction history automatically. No setup or imports are required.

- If you sell a high volume of products, use the sort and pagination controls to focus on specific categories or performance tiers.

---

### AI Insights & Reports

https://www.corgilabs.ai/docs/corgi-intelligence/ai-insights-and-reports

Learn how AI Insights & Reports analyzes your payment data, surfaces trends and anomalies, and delivers optimization recommendations.

The AI Insights & Reports page provides access to AI-generated payment insights reports that analyze your payment data and deliver actionable recommendations.

## How It Works

Corgi Labs' AI engine periodically analyzes your payment data and generates comprehensive reports that summarize key trends, anomalies, and optimization opportunities. These reports save your team hours of manual analysis by surfacing the most important findings automatically.

## Report Contents

Each AI Insights report typically covers:

| Section | What It Shows |
|---|---|
| Approval Rate Analysis | How your approval rate changed compared to the previous period, including daily trends and contributing factors. |
| Decline & Block Trends | Changes in decline rates, block rates, and the reasons driving them. |
| Transaction Volume | The number of approvals out of total transactions and how this compares historically. |
| Anomaly Detection | Unusual patterns or spikes in payment data that may require attention. |
| Optimization Recommendations | Specific, actionable suggestions to improve payment outcomes. |

## Report List

The main page shows a table of all generated reports with the following columns:

| Column | Description |
|---|---|
| Period | The date range the report covers (e.g., Apr 6, 2026 – Apr 12, 2026). |
| Insights Preview | A brief summary of the key finding in a report (e.g., approval rate changes, notable trends). |
| Generated | When the report was created. |
| Actions | Available actions on a report in the report list: view the full report or download it. |

## Report Cadence by Plan

| Plan | Report Frequency |
|---|---|
| Core | 1 report per month |
| Pro | 1 report per week (on-demand coming soon) |
| Enterprise | On-demand generation |

## Using Insights Effectively

AI Insights reports are most valuable when paired with the operational tools in Corgi Intelligence:

1. **Read the report** to understand what changed and why.

1. **Navigate to the relevant analytics page** (e.g., Payment Analytics, Disputes & Fraud) for deeper investigation.

1. **Take action** using Payment Tools: adjust fraud rules, update block/allow lists, or respond to disputes based on the report's recommendations.

## Related Tools

- **Payment Analytics** for deeper investigation into approval rate and payment trends identified in AI Insights reports.

- **Disputes & Fraud** for investigating fraud-related findings and anomaly patterns surfaced in reports.

- **Payment Tools** for acting on Optimization Recommendations (adjust fraud rules, update block/allow lists, respond to disputes).

---

### Rule Engine

https://www.corgilabs.ai/docs/corgi-intelligence/rule-engine

Configure payment rules that automatically request 3DS, block, allow, or review transactions based on criteria you define.

The Rule Engine lets you set criteria-based rules that automatically act on incoming payments. The supported actions are Request 3DS, Block, Allow, and Review.

- **Request 3DS.** Corgi Labs requests the issuer to perform 3D Secure (3DS), if the acquirer and the card issuer support it.

- **Block.** Corgi Labs cancels the payment.

- **Allow.** Corgi Labs attempts to process the payment, bypassing any block or review rules. Payments may still be subject to 3DS initiated by the acquirer or the issuer, and the acquirer or issuer may still block the payment due to their risk decisions.

- **Review.** Corgi Labs processes the payment normally, then places it in the review queue where you can approve or cancel/refund it.

If you process payments via Stripe, an integration change is required to ensure Corgi Labs rules are enforced. Otherwise, your rules might be overwritten by Stripe Radar.

## Rule Evaluation Order

Corgi Labs evaluates each payment in the following order by action type:

1. **Request 3DS.** Request the issuer to do 3DS. Whether or not there are matches on these rules, any allow, block, and review rules will still be evaluated.

1. **Allow.** Allow the payment to be processed. Payments that match allow rules will not be evaluated against any block or review rules. If a payment matches both request 3DS and allow rules, 3DS will still be attempted.

1. **Block.** Block the payment. Blocked payments will show up as cancelled `PaymentIntent`. Payments that match block rules will not be evaluated against any review rules. If a payment matches both request 3DS and block rules, 3DS will not be attempted.

1. **Review.** Place the payment in the review queue. The payment is processed and your customers will be charged as normal, but you can review the order for any precautionary measures in your review queue. If a payment matches both request 3DS and review rules, 3DS will still be attempted.

Rules of the same action type are not ordered. If you create multiple Allow rules, Corgi Labs does not define which Allow rule is evaluated first, second, etc. Only the action type ordering matters.

### Example: How Rules Interact

To illustrate, if you have the following rules in place:

1. Allow payments with amount less than or equal to $300

1. Allow payments from customers in the `VIP_list`

1. Request 3DS on payments with amount greater than $800

1. Block payments with amount greater than $1,000

1. Review payments made with a billing address outside of the US

With these rules:

- All payments less than 300 USD are processed, regardless of the customer or billing address location, because the payments match rule 1.

- A 500 USD payment made by a customer in the `VIP_list` is processed, because it matches rule 2.

- A 500 USD payment made by a non-US customer is processed and placed in the review queue, because it matches rule 5.

- A 900 USD payment is processed and subject to 3DS, because it matches rule 3.

- A 1,500 USD payment made by a VIP customer is processed and subject to 3DS, because it matches rules 2 and 3. Even though the payment matches a block rule (rule 4), allow rules (rule 2) take precedence.

- A 1,500 USD payment made by a non-VIP customer is blocked because it matches rule 4. Even though it matches a request 3DS rule (rule 3), 3DS is not triggered when a block rule also matches.

You have the option to review a payment before the customer is charged by using manual capture. Find more in Review Queue.

## Migrate rules from your payment provider

If you have any rules on your existing payment provider, we can migrate those rules to Corgi Labs on your behalf. Please contact your Account Manager for instructions.

You will also be able to review the effectiveness of your historic rules once the migration is completed.

## Create new rules and backtesting

View how to create new rules here. Before you implement a rule, Corgi Rule Engine also runs a backtest to estimate the impact of the new rule so that you can deploy it with confidence.

## Supported rule attributes

View the full list of supported attributes, types, and sample values [here](/docs/corgi-intelligence/supported-attributes).

| Attribute | Type | Description |
|---|---|---|
| Amount | Number | Payment amount in the currency's smallest unit. |
| Billing Address | String | Billing address fields (country, state, city, etc.). |
| Card BIN | String | First 6 digits of the card number. |
| Card Country | String | Country where the card was issued. |
| Card Fingerprint | String | Stripe card fingerprint (hashed card number). |
| Charge Description | String | Description attached to the charge. |
| Client IP Address | String | IP address of the customer. |
| Client IP Country | String | Country derived from the customer's IP address. |
| Customer ID | String | Stripe customer identifier. |
| Email | String | Customer email address. |
| Email Domain | String | Domain portion of the customer email. |

*This is a partial list. See the full supported attributes page for the complete set.*

## Rules based on lists

If you have rules based on the supported attributes, lists allow you to create rules for multiple items. For example, you can use the Allow rule action and an Email list to allow all payments from a list of VIP customers, based on their email address.

By default, Corgi Labs has a set of lists that you can use in rules:

| List Type | Description |
|---|---|
| Card BIN | Bank Identification Numbers |
| Card Country | Card-issuing country codes |
| Card Fingerprint | Stripe card fingerprints |
| Charge Description | Payment description strings |
| Client IP Address | Specific payer IP addresses |
| Client IP Country | ISO country codes from payer IP |
| Customer ID | Stripe customer identifiers |
| Email | Full email addresses |
| Email Domain | Email domains |

You can also create and manage your own list by selecting the desired attribute from the supported attributes.

---

### Create New Rules & Backtesting

https://www.corgilabs.ai/docs/corgi-intelligence/create-new-rules-backtesting

Build custom payment rules with conditions and operators, backtest against real transaction data, and deploy with confidence.

Corgi Rule Engine lets you build rules on customized payment conditions and estimate their impact with backtesting. This page explains how to create a rule, validate it, and deploy it.

## Create a rule

You create and manage rules from **Rule Management**. Select **New Rule** to open the rule builder, then:

1. Name the rule.

1. Choose the action.

1. Define the conditions.

### 1. Name the rule

Give the rule a clear name and an optional description. This helps your team understand what the rule does without opening it.

### 2. Choose the action

Pick what Corgi does when a payment meets the conditions:

- **Request 3DS** — trigger an additional authentication step (such as 3D Secure) before the payment processes.

- **Allow** — approve the payment automatically.

- **Block** — reject the payment automatically.

- **Review** — let the payment process normally, then send it to your team for manual review.

Corgi reads every rule as `action if conditions`. The action comes first, so the rule logic always reads from left to right. For details on how Corgi prioritizes rules when a payment matches more than one, see [Corgi Rule Engine](/docs/corgi-intelligence/rule-engine).

### 3. Define the conditions

Each condition has three parts:

- **Attribute** — the payment field to evaluate, such as `card_country` or `amount_in_usd`.

- **Operator** — how to compare the attribute to your value.

- **Value** — the number, text, or set to compare against.

The operators available depend on the attribute type.

| Operator | Matches when |
|---|---|
| `=` | The attribute equals your value exactly. |
| `!=` | The attribute does not equal your value. |
| `IN` | The attribute matches any entry in a List, for example `:card_country: IN @restricted_countries`. |
| `INCLUDES` | The attribute contains the value you specify. Useful for text or multi-value fields. |
| `LIKE` | The attribute matches a text pattern (partial match). |

For numeric attributes such as `amount_in_usd`, you also get comparison operators: greater than, less than, greater than or equal to, and less than or equal to.

To match an attribute against many values at once (for example, a set of VIP emails or a list of blocked card countries), use the `IN` operator with a List instead of repeating individual conditions. See **Rules based on lists** on the [Corgi Rule Engine](/docs/corgi-intelligence/rule-engine) page for details.

![](https://tcogpkjbcipaopdsvkgf.supabase.co/storage/v1/object/public/docs-media/docs/corgi-intelligence/create-new-rules-backtesting/390e65085e058073998ae91b7df2fb24-0ef3db15.png)

As you build, the **Preview** at the bottom shows the compiled rule. For example:

```plain text
block if :card_country: != 'US'
```

This lets you confirm the logic reads the way you intend before you move on.

> **Tip:**
> By default, rules apply to card, ACH, and SEPA payments. To target other payment methods (for example, Klarna, PayPal, or Link), add a `payment_method_type` condition to the rule. See [Supported attributes](/docs/corgi-intelligence/supported-attributes) for the full list of values.

## Build complex rules

Most rules combine more than one condition. How you connect them determines which payments the rule matches.

### Multiple conditions with the same connector

When every condition uses the same AND or OR logic, you don't need groups. Use **AND** when all conditions must be true, and **OR** when any one of them is enough.

For example, to block payments that come from a specific country and are over $500:

```plain text
block if :card_country: = 'AE' AND :amount_in_usd: > 500
```

### Mixed connectors (AND and OR together)

When you mix AND and OR in the same rule, use **Add Group** to nest conditions and make the precedence explicit. The group makes it clear which conditions bind together.

For example, to block high-value payments that are either from a brand-new customer or flagged as elevated risk:

```plain text
block if :amount_in_usd: > 500 AND (:hours_since_customer_was_created: < 24 OR :stripe_risk_level: = 'elevated')
```

Without the group, the AND and OR would bind in an ambiguous order. Grouping removes that ambiguity. Add conditions and nested groups with **Add Condition** and **Add Group**, set each group's connector to AND or OR, and watch the **Preview** update to confirm the logic.

## Backtest before you deploy

After you finish building a rule, Corgi simulates it against your last 6 months of real transaction data and estimates how it would have performed before it goes live. This lets you deploy with confidence.

The backtest metrics depend on the rule action because different actions change payments in different ways.

| Rule action | Metrics shown | What they tell you |
|---|---|---|
| Block, Allow | • Matched transactions (count and % of volume)<br>• Incremental auth rate<br>• Incremental dispute rate<br>• Net revenue impact | These actions change the outcome of a payment, so the backtest estimates the marginal effect of adding this rule on top of your live rules. An effective rule yields positive net revenue impact. |
| Review, Request 3DS | • Matched transactions (count and % of volume)<br>• Matched volume<br>• Dispute rate (matched)<br>• Fraud rate (matched) | These actions do not block a payment but add review load for your team or authentication friction for the customer. The backtest profiles the risk of the matched cohort and the operational cost. |

### Edge cases and limitations

The backtest is an estimate from the past, not a guarantee. Three exceptions are worth noting:

1. **Known blocklists and policy rules.** When you block known-fraud cards, emails, or restricted regions for policy or compliance reasons, deploy the rule regardless of what the backtest shows. The matched counts and net revenue impact can look small or even negative. The bad actors may have little recent activity, or they may have already been refunded or disputed inside the 6-month window. The rule is still doing its job.

1. **Thin history.** Rules built on brand-new metadata or rarely-seen attributes have little to simulate against, so the sample may be small.

1. **Low matched counts.** A handful of matched payments is a small sample. Read the rates with caution.

## Deploy your rule

You can deploy a rule after you validate the backtest result. The new rule takes effect on future payments only. It does not change anything already processed.

If you deploy a Review rule, matching payments process normally and then appear in your [Review Queue](/docs/corgi-intelligence/review-queue) for your team to approve or refund.

---

### Supported attributes

https://www.corgilabs.ai/docs/corgi-intelligence/supported-attributes

Build more precise Allow, Block, and Review rules with this complete reference of every attribute in the Corgi Intelligence Rule Engine.

This page lists every attribute available in the Corgi Intelligence Rule Engine. Use these attributes to build Allow, Block, and Review rules. Each entry includes the attribute name, its type, and a sample value.

---

## 3D Secure

| **Attribute** | **Type** | **Sample value** |
|---|---|---|
| **`three_d_secure`** Identifies if the payment uses a 3D Secure source. | *Boolean* | `true` |
| **`three_d_secure_authenticated`** Identifies if the payment was authenticated after a successfully completed 3D Secure verification (either risk-based or challenge-based). | *Boolean* | `true` |
| **`three_d_secure_authentication_flow`** The authentication flow used for 3D Secure on this payment. | *Case-insensitive string* | `challenge` |
| **`three_d_secure_result`** The 3D Secure result for the card used to make the payment. The supported values are: **authenticated**, **attempt\_acknowledged**, **processing\_error**, **exempted**. | *Case-insensitive string* | `authenticated` |

---

## Address

### Billing address

| **Attribute** | **Type** | **Sample value** |
|---|---|---|
| **`billing_address`** The full provided billing address. | *Case-insensitive string* | `123 Main St #3J Chicago, IL 60007 US` |
| **`billing_address_line1`** The first line of the provided billing address (typically a street name and number). | *Case-insensitive string* | `123 Main St` |
| **`billing_address_line2`** The second line of the provided billing address (typically an apartment or unit number). | *Case-insensitive string* | `#3J` |
| **`billing_address_postal_code`** The postal code of the provided billing address. | *Case-insensitive string* | `60007` |
| **`billing_address_city`** The city of the provided billing address. | *Case-insensitive string* | `Chicago` |
| **`billing_address_state`** The state of the provided billing address. | *Case-insensitive string* | `IL` |
| **`billing_address_country`** The two-letter code corresponding to the country of the provided billing address. | *Case-insensitive country* | `US` |

### Shipping address

| **Attribute** | **Type** | **Sample value** |
|---|---|---|
| **`shipping_address`** The full provided shipping address. | *Case-insensitive string* | `123 Main St #3J Chicago, IL 60007 US` |
| **`shipping_address_line1`** The first line of the provided shipping address (typically a street name and number). | *Case-insensitive string* | `123 Main St` |
| **`shipping_address_line2`** The second line of the provided shipping address (typically an apartment or unit number). | *Case-insensitive string* | `#3J` |
| **`shipping_address_postal_code`** The postal code (ZIP) of the provided shipping address. | *Case-insensitive string* | `60007` |
| **`shipping_address_city`** The city of the provided shipping address. | *Case-insensitive string* | `Chicago` |
| **`shipping_address_state`** The state of the provided shipping address. | *Case-insensitive string* | `IL` |
| **`shipping_address_country`** The two-letter code corresponding to the country of the provided shipping address. | *Case-insensitive country* | `US` |

---

## Amount

| **Attribute** | **Type** | **Sample value** |
|---|---|---|
| **`amount_in_usd`** The amount of the payment, converted to USD. For non-USD payments, Corgi Labs automatically calculates a converted amount based on a [reference exchange rate](https://www.ecb.europa.eu/stats/policy_and_exchange_rates/euro_reference_exchange_rates/html/index.en.html), updated daily. | *Case-insensitive string* | `50` |

---

## Card info

| **Attribute** | **Type** | **Sample value** |
|---|---|---|
| **`card_brand`** The brand of the card used to make the payment. The supported values are: **amex** (American Express), **visa** (Visa), **mc** (Mastercard), **dscvr** (Discover), **diners** (Diners Club), **interac** (Interac), **jcb** (JCB), and **cup** (UnionPay). | *Case-insensitive string* | `visa` |
| **`card_bin`** The Bank Identification Number (BIN) of the card used to make the payment. The BIN is the first six digits of the card number. | *Case-insensitive string* | `371758` |
| **`card_country`** The two-letter code corresponding to the country where the card was issued. | *Case-insensitive country* | `US` |
| **`card_fingerprint`** The fingerprint of the card used to make the payment. The card fingerprint is a unique identifier of a particular card number. | *Case-sensitive string* | `example_fingerprint` |
| **`card_funding`** Whether the card is a prepaid, debit, or credit card. The supported values are: **credit**, **debit**, **prepaid**, **unknown**. | *Case-sensitive string* | `credit` |
| **`card_description`** A high-level description of the type of cards issued in this range. This attribute is case-insensitive, but it's punctuation sensitive. | *Case-insensitive string* | `Visa Signature` |
| **`card_issuer`** The name of the card's issuing bank. This attribute is case-insensitive, but it's punctuation sensitive. | *Case-insensitive string* | `JP Morgan Chase` |
| **`cardholder_name`** The provided name associated with a purchaser's card information. This attribute is case-insensitive, but it's punctuation sensitive.  Use this attribute only to block names or name patterns of individuals who you have reason to believe have previously committed fraud on your service. Your operations team should be prepared to respond to any customer complaints and to add legitimate customers to an allowlist where appropriate. | *Case-insensitive string* | `Jane Doe` |
| **`statement_descriptor`** The statement descriptor provided on a payment. | *Case-insensitive string* | `example descriptor` |

---

## Email

| **Attribute** | **Type** | **Sample value** |
|---|---|---|
| **`email`** The email address supplied with the payment. | *Case-insensitive string* | `user@example.com` |
| **`email_domain`** The domain of the email supplied with the payment. | *Case-insensitive string* | `example.com` |

---

## IP address

| **Attribute** | **Type** | **Sample value** |
|---|---|---|
| **`ip_address`** The IP address from which the payment originated. Sourced from device fingerprinting. | *Case-insensitive string* | `192.168.1.1` |
| **`ip_country`** The two-letter country code corresponding to the IP address of the payment. | *Case-insensitive string* | `US` |
| **`ip_state`** The state or region corresponding to the IP address of the payment. | *Case-insensitive string* | `California` |
| **`is_anonymous_ip`** Identifies if the payment originated from a known anonymous IP (for example, a VPN, Tor, or proxy). | *Boolean* | `true` |

---

## Issuer checks

> **These attributes are only evaluated after authorization.** A Block rule using these attributes is still enforced even if a pre-auth Allow rule matched the payment. If your payment provider has IC++ pricing, a small authorization interchange fee may still be incurred.

| **Attribute** | **Type** | **Sample value** |
|---|---|---|
| **`address_line1_check`** A check by the card issuer to match the first line of the provided billing address (typically a street name and number) against the information they have on file for the cardholder. The supported values are: **pass**, **fail**, **unavailable**, **unchecked**, **not\_provided**. | *Case-sensitive string* | `pass` |
| **`address_zip_check`** A check by the card issuer to match the provided postal code against the information they have on file for the cardholder. The supported values are: **pass**, **fail**, **unavailable**, **unchecked**, **not\_provided**. | *Case-sensitive string* | `pass` |
| **`cvc_check`** A check by the card issuer to match the provided CVC (also referred to as CVV) against the information they have on file for the cardholder. The supported values are: **pass**, **fail**, **unavailable**, **unchecked**, **not\_provided**. | *Case-sensitive string* | `pass` |

---

## Customer

| **Attribute** | **Type** | **Sample value** |
|---|---|---|
| **`customer`** The Customer object ID supplied with the payment. | *Case-sensitive string* | `cus_x6UEhEYs5JHZhu` |
| **`customer_name`** The name associated with the Customer object. | *Case-insensitive string* | `Jane Doe` |
| **`delinquent`** Whether the customer is marked as delinquent. | *Boolean* | `true` |
| **`hours_since_customer_was_created`** The number of hours since the Customer object making the payment was created on your account. | *Numeric* | `50` |
| **`minutes_since_customer_was_created`** The number of minutes since the Customer object making the payment was created on your account. | *Numeric* | `50` |
| **`seconds_since_customer_was_created`** The number of seconds since the Customer object making the payment was created on your account. | *Numeric* | `50` |
| **`hours_since_customer_was_created_on_transactions`** The number of hours since the Customer object making the transaction was created on your account. | *Numeric* | `50` |
| **`minutes_since_customer_was_created_on_transactions`** The number of minutes since the Customer object making the transaction was created on your account. | *Numeric* | `50` |
| **`seconds_since_customer_was_created_on_transactions`** The number of seconds since the Customer object making the transaction was created on your account. | *Numeric* | `50` |

---

## Metadata and custom attributes

You can pass custom attributes in the metadata. Corgi Labs automatically parses the fields you include and adds them to your Rule Engine.

| **Attribute** | **Type** | **Sample value** |
|---|---|---|
| **`::metadata_key::`** Access custom metadata attached to the payment. Replace `metadata_key` with the key name you set when creating the payment. For example, if you set `metadata[item_id]`, the rule attribute is `::item_id::`. | *String* | `sku_12345` |

---

## Stripe Radar risk assessment

If you process payments via Stripe, Stripe Radar evaluation results are available.

| **Attribute** | **Type** | **Sample value** |
|---|---|---|
| **`stripe_risk_level`** The risk level assigned to the payment by Stripe Radar's model. The supported values are: **normal**, **elevated**, **highest**, **not\_assessed**. | *Case-insensitive string* | `elevated` |
| **`stripe_risk_score`** The risk score assigned to the payment by Stripe Radar's model, from 0 (lowest risk) to 100 (highest risk). | *Numeric* | `50` |

---

## Other details

| **Attribute** | **Type** | **Sample value** |
|---|---|---|
| **`currency`** The 3-digit currency code representing the currency in which the customer paid. | *Case-insensitive string* | `usd` |
| **`digital_wallet`** The type of digital wallet used to store payment information. The supported values are: **android\_pay**, **amex\_express\_checkout**, **apple\_pay**, **masterpass**, **samsung\_pay**, **visa\_checkout**, **meta\_pay**, **amazon\_pay**, **revolut\_pay**, **demo\_pay**, **unknown**, **none**.  *Note: Except for android\_pay (valid with or without cryptogram), these are only valid when Corgi Labs receives a cryptogram that can only be generated by a registered device, as opposed to an unencrypted Primary Account Number (PAN).* | *Case-insensitive string* | `android_pay` |
| **`payment_method_type`** The payment method used on the payment. The supported values are: **card**, **sepa\_debit**, and **us\_bank\_account** (ACH direct debit). | *Case-insensitive string* | `us_bank_account` |
| **`charge_description`** The description supplied with the payment. | *Case-insensitive string* | `example descriptor` |
| **`destination`** For Connect users creating destination charges, the destination account on whose behalf the charge is made. | *Case-sensitive string* | `acct_19KCB9AlaaEw6AgR` |
| **`is_off_session`** Indicates when a Stripe Billing payment isn't triggered by direct user action, or when the `off_session` flag is set at PaymentIntent confirmation. | *Boolean* | `true` |
| **`is_recurring`** Identifies if the payment is recurring, for example, from subscriptions. | *Boolean* | `true` |
| **`is_setup_intent`** Identifies if the transaction is a SetupIntent. | *Boolean* | `true` |
| **`transaction_type`** **(DEPRECATED: use** **`is_setup_intent`** **where possible.)** The type of the transaction. The supported values are: **charge**, **payment\_intent**, **setup\_intent**. The **payment\_intent** value is only supported for Request Credentials rules. In that case, any Allow, Block, or Review rules run against the charge attempts created when confirming the payment. | *String* | `charge` |

---

## Non-card payment methods

By default, rules are evaluated on card payments (including digital wallet transactions where the underlying payment method is a card), SEPA Direct Debit, and ACH bank transfer.

To build rules for specific payment methods, including alternative payment methods such as stored-value wallets and Buy Now, Pay Later providers, specify `payment_method_type`:

| **Attribute** | **Type** | **Sample value** |
|---|---|---|
| **`payment_method_type`** The payment method used on the payment. The supported values are: **acss\_debit**, **affirm**, **afterpay\_clearpay**, **alipay**, **alma**, **amazon\_pay**, **au\_becs\_debit**, **bacs\_debit**, **bancontact**, **billie**, **blik**, **boleto**, **card**, **card\_present**, **cashapp**, **crypto**, **customer\_balance**, **eps**, **fpx**, **giropay**, **grabpay**, **ideal**, **interac\_present**, **kakao\_pay**, **klarna**, **konbini**, **kr\_card**, **link**, **mobilepay**, **multibanco**, **naver\_pay**, **nz\_bank\_account**, **oxxo**, **p24**, **pay\_by\_bank**, **payco**, **paynow**, **paypal**, **pix**, **promptpay**, **revolut\_pay**, **samsung\_pay**, **satispay**, **sepa\_debit**, **sofort**, **swish**, **twint**, **us\_bank\_account**, **wechat\_pay**, and zip. | *Case-insensitive string* | `klarna` |

The following attributes are only evaluated on SEPA Direct Debit and ACH bank transfer payments.

| **Attribute** | **Type** | **Sample value** |
|---|---|---|
| **`sepa_debit_bank_code`** The bank code of the SEPA Direct Debit payment method. | *Case-sensitive string* | `COBADEFFXXX` |
| **`sepa_debit_country`** The two-letter country code of the SEPA Direct Debit payment method. | *Case-insensitive country* | `DE` |
| **`sepa_debit_fingerprint`** The unique fingerprint of the SEPA Direct Debit bank account. | *Case-sensitive string* | `example_sepa_fp` |
| **`us_bank_account_bank_name`** The name of the US bank for ACH Direct Debit payments. | *Case-insensitive string* | `JP Morgan Chase` |
| **`us_bank_account_fingerprint`** The unique fingerprint of the US bank account. | *Case-sensitive string* | `example_ach_fp` |
| **`us_bank_account_routing_number`** The routing number of the US bank account. | *Case-sensitive string* | `021000021` |

---

## Pre-computed aggregate attributes

Pre-computed attributes provide aggregate counts, sums, and averages of historical activity, grouped by a specific dimension and computed over a time window. These are useful for velocity checks and anomaly detection.

### Grouping dimensions

Pre-computed attributes are grouped by the following dimensions:

| **Dimension** | **Description** |
|---|---|
| **Card** (`card_fingerprint`) | Groups activity by the unique card number fingerprint. |
| **Customer** (`customer_id`) | Groups activity by the Stripe Customer object ID. |
| **Email** (`email`) | Groups activity by the email address on the payment. |
| **Billing Address** (`billing_address_postal_code`) | Groups activity by the billing address postal code. |
| **Shipping Address** (`shipping_address_postal_code`) | Groups activity by the shipping address postal code. |
| **Payment Method** (`payment_method_id`) | Groups activity by the Payment Method object ID. |

### Time windows

Each aggregate attribute is computed over one of the following time windows:

| **Window suffix** | **Period** |
|---|---|
| `_hourly` | Past 1 hour |
| `_daily` | Past 1 day (24 hours) |
| `_weekly` | Past 7 days |
| `_yearly` | Past 1 year |
| `_all_time` | All time |

### Naming convention

The naming convention for pre-computed attributes is:

```plain text
{measure}_for_{dimension}_{time_window}
```

For example: `count_dispute_for_card_daily` is the count of disputes on a given card fingerprint in the past day.

### Counts

| **Measure** | **Description** | **Type** |
|---|---|---|
| `count_dispute_for_{dimension}_{window}` | Number of disputes filed against payments grouped by this dimension, within the time window. | *Numeric* |
| `count_payment_intent_for_{dimension}_{window}` | Number of payment intents (attempted payments) grouped by this dimension, within the time window. | *Numeric* |
| `count_refund_for_{dimension}_{window}` | Number of refunds issued for payments grouped by this dimension, within the time window. | *Numeric* |
| `count_fraud_for_{dimension}_{window}` | Number of payments flagged as fraudulent (based on dispute data) grouped by this dimension, within the time window. | *Numeric* |
| `count_chargeback_for_{dimension}_{window}` | Number of chargebacks filed against payments grouped by this dimension, within the time window. | *Numeric* |
| `count_card_for_{dimension}_{window}` | Number of distinct cards used, grouped by this dimension, within the time window. *Not applicable when the dimension is Card.* | *Numeric* |

### Amount aggregates

| **Measure** | **Description** | **Type** |
|---|---|---|
| `sum_amount_in_usd_for_{dimension}_{window}` | Total amount (in USD) of payments grouped by this dimension, within the time window. | *Numeric* |
| `avg_amount_in_usd_for_{dimension}_{window}` | Average amount (in USD) of payments grouped by this dimension, within the time window. | *Numeric* |
| `avg_dispute_amount_in_usd_for_{dimension}_{window}` | Average disputed amount (in USD) for payments grouped by this dimension, within the time window. | *Numeric* |
| `avg_refund_amount_in_usd_for_{dimension}_{window}` | Average refund amount (in USD) for payments grouped by this dimension, within the time window. | *Numeric* |

### Spike detection

| **Measure** | **Description** | **Type** |
|---|---|---|
| `is_new_max_amount_in_usd_for_{dimension}` | Whether the current payment amount is the highest ever seen for this dimension. Useful for detecting anomalously large payments on a card, customer, email, or other dimension. | *Boolean* |

### Available dimension and window combinations

All combinations of the dimensions and windows listed above are available for count and amount aggregate measures.

**Example attribute names using the Card dimension:**

- `count_dispute_for_card_all_time`

- `count_dispute_for_card_hourly` / `_daily` / `_weekly` / `_yearly`

- `count_payment_intent_for_card_all_time` / `_hourly` / `_daily` / `_weekly` / `_yearly`

- `count_refund_for_card_all_time` / `_hourly` / `_daily` / `_weekly` / `_yearly`

- `count_fraud_for_card_all_time` / `_hourly` / `_daily` / `_weekly` / `_yearly`

- `count_chargeback_for_card_all_time` / `_hourly` / `_daily` / `_weekly` / `_yearly`

- `sum_amount_in_usd_for_card_all_time` / `_hourly` / `_daily` / `_weekly` / `_yearly`

- `avg_amount_in_usd_for_card_all_time` / `_hourly` / `_daily` / `_weekly` / `_yearly`

- `avg_dispute_amount_in_usd_for_card_all_time` / `_hourly` / `_daily` / `_weekly` / `_yearly`

- `avg_refund_amount_in_usd_for_card_all_time` / `_hourly` / `_daily` / `_weekly` / `_yearly`

- `is_new_max_amount_in_usd_for_card`

Replace `card` with `customer`, `email`, `billing_address`, `shipping_address`, or `payment_method` to get the equivalent attributes for those dimensions.

**Additional count attributes for non-card dimensions:**

- `count_card_for_customer_{window}` — Distinct cards used by this customer

- `count_card_for_email_{window}` — Distinct cards used with this email

- `count_card_for_billing_address_{window}` — Distinct cards used at this billing address

- `count_card_for_shipping_address_{window}` — Distinct cards used at this shipping address

- `count_card_for_payment_method_{window}` — Distinct cards associated with this payment method

---

### Review Queue

https://www.corgilabs.ai/docs/corgi-intelligence/review-queue

Review and act on flagged payments and held authorizations from one centralized queue.

The Review Queue is a centralized view of payment decisions that require manual assessment. When a transaction is flagged for review, your team can quickly inspect the details and choose the right action.

Payments enter the Review Queue in one of two ways:

1. **Review rule matches.** A transaction matches a rule with a Review action in the Rule Engine.

1. **Manual capture payments.** A payment is authorized but not yet captured.

Each item shows transaction details, the rule that triggered the review, and relevant customer information. You can review the payment and then approve, refund, capture, or cancel it depending on the item type. The queue also retains completed decisions, so you can reference past reviews.

---

## 1. Review Rule Matches

When a transaction matches a rule with a Review action, Corgi Intelligence still processes the payment as normal. If the payment succeeds, it is placed in the Review Queue for manual assessment.

From the Review Queue, you have two options:

### Approve

Approve marks the review as completed. Nothing changes on the underlying payment. The customer was already charged during normal processing, and the payment proceeds as usual.

### Refund

Refund cancels the payment and returns the funds to the customer. Your payment provider typically charges a non-refundable processing fee. Some providers also charge an additional refund fee. Your support team may want to inform the customer or be prepared for any follow-up inquiries.

### Review before the customer is charged

By default, payments that match Review rules are processed and the customer is charged as normal. If your business needs time to prepare for fulfillment, or if your average order value is high enough that you want to review orders before capturing funds, you can use manual capture instead.

Manual capture places a hold on the customer's payment method without charging them. You can then review the order and decide whether to capture or cancel.

> **Tip:**
> If you process payments via Stripe, you can refer to Stripe's guide on manual capture [here](https://docs.stripe.com/payments/place-a-hold-on-a-payment-method).

---

## 2. Manual Capture Payments

All manual capture payments automatically appear in the Review Queue. If a payment matches both a Review rule and the manual capture criteria, you can see both reasons listed for the item.

When you review a manual capture payment, you have two options:

### Capture

Capture completes the charge and the customer is billed. The authorization hold is converted into a captured payment.

### Cancel

Cancel releases the hold on the customer's payment method. No charge is made.

### Authorization timing

The authorization placed on the customer's payment method expires based on the capture window set by your payment provider or card network. That window is typically five to seven days, though it can vary by provider and network.

If you do not act on the review within the authorization period, your payment provider will typically cancel the authorization automatically unless otherwise specified.

---

## 3. Key behaviors to keep in mind

- **Rule-matched payments are still processed.** A Review action does not stop the transaction. The payment goes through, and the item lands in the queue afterward.

- **Dual-trigger items show both reasons.** If a payment is flagged by a Review rule and is also a manual capture, both reasons are visible in the queue.

- **Refunds incur fees.** Processing fees are usually not refunded by the payment provider. Some providers charge an additional refund fee.

- **Uncaptured authorizations expire.** If you do not capture or cancel a manual capture payment within the authorization window, the hold is typically released automatically.

---

### Transactions

https://www.corgilabs.ai/docs/corgi-intelligence/transactions

View every payment and its risk evaluation in one place. Compare CORGI model with your existing provider, and filter to find exactly what you need.

## Overview

The Transactions tab shows every payment Corgi Labs ingests from your payment provider, together with the risk evaluation behind it. For each payment, you can see which model evaluated it, the CORGI score, any rule that matched, and the final decision Corgi Labs applied.

Use the Transactions tab to:

- Look up a payment by customer email, IP address, payment ID, or last 4 digits of the card.

- Understand why a payment was allowed, blocked, reviewed, or sent to 3DS.

- During CORGI model ramp-up, compare CORGI model results with your existing provider while CORGI model evaluates part of your traffic.

Payments sync from your payment provider about every 2 hours. The **Last synced** time under the page title shows when the most recent sync ran.

## How Corgi Labs evaluates a payment

Each risk column in the Transactions tab reflects one step of the evaluation pipeline, in this order:

1. **Traffic split.** During a phased rollout, each eligible payment is routed to either CORGI model or your existing provider (for example, Stripe Radar). The model a payment is routed to is its live model, and only the live model's decision counts. The **Traffic split** column shows which one it was, or **None** if the payment was outside the phased rollout.

1. **CORGI score.** CORGI model scores the payment from 0 to 100. The icon next to the score shows whether the score falls on the **Allow** or **Block** side of your block threshold. CORGI model also scores payments when it isn't the live model, so you can compare it with your existing provider. These scores carry a **Shadow** tag and have no effect on the payment decision.

1. **Model decision.** The **Allow** or **Block** decision of the live model shown in the Traffic split column:
  - For **CORGI model** traffic, Model decision is the CORGI score compared with your block threshold, so it matches the CORGI score icon.
  - For **Stripe Radar** traffic, Model decision is Stripe Radar's decision, even when the CORGI score suggests a different outcome. **Block** means Stripe Radar rated the payment highest risk.
  - When the live model doesn't return a verdict, or Traffic split is **None**, Model decision shows **Not evaluated**.

1. **Rule match.** Rule Engine evaluates your rules against the payment. A matched Rule Engine rule overrides the live model decision and appears in the Rule match column. If no rule applies, the column shows **No match** and the live model decision stands. Rule match can also show a match from one of your Stripe Radar rules. Stripe Radar applies those rules itself, so they don't change Final decision.

1. **Final decision.** The action Corgi Labs applied to the payment, after the model decision and any matched rule. This appears in the Final decision column. If Rule Engine never made a decision for the payment, the column shows **None**.

When CORGI model evaluates 100% of your eligible traffic, every eligible payment shows **CORGI model** in the Traffic split column. The phased rollout columns are most useful while you are ramping up CORGI model on a portion of your traffic (for example, 30% or 70%).

### Shadow scoring

During shadow testing, or for payments not assigned to CORGI model during a staged rollout, CORGI model still scores the payment. These scores appear with a **Shadow** tag. A shadow score lets you see what CORGI model would have decided without affecting the live outcome.

## Transaction table

The transaction table has two groups of columns: payment details on the left and risk evaluation on the right.

### Payment details

| Column | Description |
|---|---|
| **Amount** | Payment amount and currency. |
| **Status** | Current payment status: Succeeded, Uncaptured, Failed, Blocked, Canceled, Auth expired, Refunded, Partially refunded, or Disputed. |
| **Payment method** | For cards, the card brand and last 4 digits. For other payment methods, such as Link or Amazon Pay, the payment method's logo or name. A wallet icon appears when the customer pays with a wallet such as Apple Pay. |
| **Customer** | Customer email address. |
| **Date** | Date and time the payment was created, in your account's time zone. |

### Risk evaluation

| Column | Values | Description |
|---|---|---|
| **Traffic split** | CORGI model, your existing provider (for example, Stripe Radar), or None | The model the payment was routed to during a phased rollout. **None** means the payment was outside the phased rollout. |
| **CORGI score** | 0 to 100, or -- | CORGI model’s payment risk score. Higher values indicate a higher predicted likelihood of dispute. The icon next to the score shows what it suggests against your block threshold: a green tick means CORGI model suggests **Allow**, and a red cross means CORGI model suggests **Block**. Hover over the icon to see your block threshold. A **Shadow** tag means CORGI model scored the payment but the score did not take effect (see Shadow scoring above). A dash means CORGI model did not score the payment. |
| **Model decision** | Allow, Block, Not evaluated | The decision of the live model shown in the Traffic split column. For CORGI model traffic, this is the CORGI score compared with your block threshold. For Stripe Radar traffic, **Block** means Stripe Radar rated the payment highest risk. **Not evaluated** means the live model didn't return a verdict, for example for Stripe Radar traffic before a charge was attempted, or when CORGI model didn't score the payment. An override icon next to the decision means an **Allow** or **Block** rule reversed it (see Decisions and rule overrides below). |
| **Rule match** | No match, Allow, Block, Review, Request 3DS | The action of the rule that matched the payment. The rule can be a Rule Engine rule or one of your Stripe Radar rules. Open the payment to see the rule's name and where it runs. Rules running in shadow mode show a **Shadow** tag. |
| **Final decision** | Allow, Block, Review, Request 3DS, None | The action Corgi Labs applied to the payment after the model and your rules were evaluated. **None** means Rule Engine never made a decision for the payment. If Stripe Radar blocked the payment natively, this column still shows Corgi Labs' decision, and hovering over it shows "Blocked natively by Stripe Radar; not a CORGI decision." See Decisions and rule overrides below for details. |
| **Issuer decline reason** | Issuer decline reason code, or -- | The reason the card issuer gave for declining the payment, for example **Do not honor**. Hover over the reason to see a short explanation. An issuer can decline a payment even when the final decision is **Allow**. |

Select any row to open the transaction details page for that payment. The details page shows the payment's lifecycle, its CORGI and Stripe Radar scores, the rules that matched, and card and customer signals.

## Status tabs

Tabs above the table group payments by outcome. Each count updates to match your current date range. Search and column filters don't change the counts.

| Tab | Shows |
|---|---|
| **All** | Every payment in the selected date range. |
| **Succeeded** | Payments that were authorized and captured. |
| **Failed** | Payments that failed, including payments declined by the card issuer. |
| **Blocked** | Payments blocked before the charge, by CORGI model, a rule, or your existing risk provider. |
| **Refunded** | Payments refunded in full or in part. |
| **Disputed** | Payments your customer disputed with their card issuer. |
| **Uncaptured** | Payments that were authorized but not yet captured. |
| **CORGI ≠ final decision** | Payments where the CORGI score's verdict differs from the Final decision. Payments with a final decision of **Review** or **None** are excluded, and **Request 3DS** counts as **Allow**. This tab is especially useful during ramp-up to see where CORGI model would have decided differently. |

Selecting a status tab, such as **Blocked**, also sets the Status filter. You can combine a status tab with other column filters. For example, selecting the **Disputed** tab and filtering Traffic split to **Stripe Radar** shows only disputed payments from Stripe Radar traffic.

## Decisions and rule overrides

**Final decision** combines the model decision with your rules, following the Rule Engine evaluation order:

1. **Request 3DS** rules are evaluated first.

1. **Allow** rules.

1. **Block** rules.

1. **Review** rules are evaluated last.

If a rule matches, its action can change the final outcome. The type of rule determines whether the override icon appears.

### Override icon

The override icon appears next to **Model decision** only when an **Allow** or **Block** rule reversed the model decision. For example, if the model returned **Block** but an **Allow** rule matched, you see the override icon next to the model's **Block** and the Final decision column shows **Allow**. Hover over the icon to see which rule overrode the model decision. To list only these payments, open the Model decision filter and select **Rule override only**.

**Review** and **Request 3DS** rules never show the override icon. When they change the outcome, **Final decision** differs from **Model decision**, but no icon marks the change. This is because Review and Request 3DS add a step rather than reversing the model's allow-or-block judgment.

For details on creating and managing rules, see Rule Engine.

## Search and filter transactions

Use the date range picker to choose a preset, such as **Last 30 days**, or a custom range. The default is **Last 3 months**. Use the search box to find payments by customer email, IP address, payment ID, or last 4 digits of the card.

You can narrow the transaction list further using column filters. Most column headers have a filter icon that opens a list of available values. The Amount, CORGI score, and Date filters also let you sort, and the Amount filter lets you set an amount range and currency.

### How filters work

- **Within a column:** each filter takes one value at a time, except **Status**. In the Status filter, selecting multiple values shows payments that match **any** of them (OR logic). For example, filtering Status to **Refunded** and **Disputed** shows payments that were refunded or disputed.

- **Across columns:** filters on different columns combine, so each filter you add narrows the list (AND logic). For example, filtering Traffic split to **CORGI model** and Rule match to **Block** shows only CORGI model payments where a Block rule matched.

- **Bookmarkable:** your search, status tab, and column filters are saved in the page URL, so you can bookmark or share a filtered view with your team. The date range isn't saved in the URL, so a shared link opens with the default date range (**Last 3 months**).

### Export and choose columns

To download transactions as a CSV file, open the **More options** menu (⋮) next to the search box and select **Export CSV**. To show or hide columns, open the same menu and select **Columns**.

### See what each model decided

These filter combinations help you isolate traffic by model and outcome:

| To see | Set these filters |
|---|---|
| Every payment routed to Stripe Radar | Traffic split: **Stripe Radar** |
| Payments Stripe Radar decided to block | Traffic split: **Stripe Radar**, Model decision: **Block** |
| Every payment blocked in Stripe Radar traffic | Traffic split: **Stripe Radar**, then select the **Blocked** tab |
| CORGI model decisions where no rule matched | Traffic split: **CORGI model**, Rule match: **No match** |
| Payments that CORGI model and a Block rule would both block | Traffic split: **CORGI model**, Model decision: **Block**, Rule match: **Block** |
| Payments where an Allow or Block rule reversed the model decision | Model decision: **Rule override only** |

To find payments blocked in Stripe Radar traffic, use the **Blocked** tab rather than Final decision: **Block**. Final decision shows only Corgi Labs' decision, so it doesn't include payments that Stripe Radar blocked natively.

### Compare CORGI model with Stripe Radar

During ramp-up, you can use these filter combinations to compare what CORGI model would have done versus what Stripe Radar actually did:

In the CORGI score filter, **CORGI model decision** shows what CORGI model decided, or would have decided, for each payment: **Allow**, **Block**, or **No score**.

| To see | Set these filters | What it tells you |
|---|---|---|
| Payments CORGI model would have blocked, but Stripe Radar allowed | Traffic split: **Stripe Radar**, CORGI score: **Block**, Model decision: **Allow** | Potential fraud that Stripe Radar missed. Select the **Disputed** tab to see which became disputes. |
| Payments CORGI model would have allowed, but Stripe Radar blocked | Traffic split: **Stripe Radar**, CORGI score: **Allow**, Model decision: **Block** | Potential good customers that Stripe Radar turned away. These represent possible false declines. |
| Payments CORGI model flagged that were later disputed | Traffic split: **Stripe Radar**, CORGI score: **Block**, then select the **Disputed** tab | Disputes that CORGI model would have prevented. |
| Payments CORGI model and a Block rule would both have blocked | Traffic split: **Stripe Radar**, CORGI score: **Block**, Rule match: **Block** | Rules whose blocks CORGI model already covers. |

These comparisons are most valuable during a phased rollout, when both models are evaluating live traffic and you can measure the difference in outcomes.

---

### List Management

https://www.corgilabs.ai/docs/corgi-intelligence/list-management

Create and manage reusable value lists for allow and block rules using card fingerprints, emails, IPs, and more.

The **List Management** page lets you create and manage reusable value lists that power your fraud detection rules in Corgi Intelligence.

---

## What Are Lists?

Lists are collections of values, such as emails, card fingerprints, IP addresses, or customer IDs, that can be referenced in your fraud rules. Rather than hard-coding individual values directly into each rule, you maintain a central list and point your rules to it. When you update the list, every rule that references it automatically uses the latest values.

For example, you might create an email block list containing known fraudulent email addresses. You can then create a fraud rule that rejects any transaction where the customer's email appears on that list. If you discover a new fraudulent email, you add it to the list once, and all linked rules immediately apply it.

---

## Default Lists

Corgi provides several default block lists that are pre-populated with known bad actors. Default lists are managed by the system and updated automatically.

| List | Description |
|---|---|
| **Card Fingerprint Block List** | Known fraudulent card fingerprints. |
| **Email Block List** | Known fraudulent email addresses. |
| **Email Domain Block List** | High-risk email domains commonly used for fraud. |
| **Client IP Country Block List** | Countries associated with elevated fraud rates. |
| **Customer ID Block List** | Known fraudulent customer identifiers. |
| **Charge Description Block List** | Suspicious charge descriptions that signal risky transactions. |
| **Card Country Block List** | Card-issuing countries to block. |
| **Client IP Address Block List** | Specific IP addresses associated with malicious activity. |

Default lists are identified in the main table by a **Default** badge next to the list name.

---

## Custom Lists

In addition to the system defaults, you can create custom allow and block lists for any supported attribute type.

### Supported Attribute Types

| Type | Description |
|---|---|
| **Card Fingerprint** | Unique card identifier. |
| **Email** | Customer email address. |
| **Email Domain** | Domain portion of the email (case-insensitive matching). |
| **Customer ID** | Your internal customer identifier. |
| **Country** | Country code. |
| **IP Address** | Client IP address. |
| **Charge Description** | Transaction description string (case-sensitive or case-insensitive matching). |
| **Card BIN** | Bank Identification Number (first 6–8 digits of card number). |
| **String** | Flexible string matching for custom attributes. |

You can create custom lists for either allowing or blocking, depending on how you configure them in your rules.

---

## List Details

The main **List Management** table displays every list in your workspace, both default and custom, with the following columns:

| Column | Description |
|---|---|
| **Name** | The display name of the list. Default lists show a "Default" badge. |
| **Alias** | The programmatic reference used when selecting the list in rule conditions. Keep aliases short and descriptive, such as `fraud_emails` or `trusted_ips`. |
| **Type** | The attribute type the list matches against (for example, Email, IP Address, or Card BIN). |
| **Items** | The current number of entries in the list. |
| **Created By** | The source of the list: "System" for defaults, or the name of the team member who created a custom list. |
| **Created** | The timestamp when the list was created. |

You can sort and filter the table to quickly find the list you need.

---

## Creating a New List

To create a custom list, click **+ New List** in the top-right corner of the page. You will be asked to provide the following:

### Name

A descriptive display name, such as "Trusted Corporate IPs" or "High-Risk Email Domains."

### Alias

A short, unique identifier used in rule conditions. Aliases must be easy to reference when building rules. For example, an alias of `trusted_ips` is easier to work with in a rule condition than a long display name.

### Type

The attribute type that entries in this list will match against. Once selected, this type cannot be changed. Choose the type that aligns with the data you want to match in your transactions.

### Entries

Add values to the list using one of two methods:

- **Manual entry:** Type or paste individual values one at a time.

- **Bulk import:** Import many values at once. Import formats and file-type requirements are displayed in the import dialog.

After you save the list, it becomes available immediately in the rule builder. You can add or remove entries at any time.

---

## Next Steps

- Learn how to build fraud rules that reference your lists

- Review the default lists regularly to understand the threat categories Corgi tracks

---

*Last updated: 2026-07-01*

---

### List Management API

https://www.corgilabs.ai/docs/corgi-intelligence/list-management-api

Create and manage value lists by alias. Covers SDK methods, bulk operations, cursor pagination, error codes, and raw HTTP endpoints for list management.

The List Management API lets you create and manage lists of values, such as email addresses, IP addresses, or payment IDs, that you can reference by alias in your rules.

Lists are immutable: after you create a list, you cannot rename or delete it through the API.

---

## Install the SDK

```bash
npm install corgi-sdk
```

## Initialize the SDK

Create a Corgi SDK token on the [Corgi web app](https://www.corgilabs.ai/) settings page, then pass it to the constructor:

```typescript
import { CorgiSDK } from 'corgi-sdk';

const sdk = new CorgiSDK({
  token: process.env.CORGI_API_TOKEN!,
});
```

---

## Create a list

```typescript
const list = await sdk.lists.create({
  alias: 'vip_customers',
  name: 'VIP customers',
  itemType: 'email',
});
```

**Parameters**

| Parameter | Type | Description |
|---|---|---|
| `alias` | `string` | Unique identifier used to reference the list in rules. Lowercase letters, digits, and underscores; max 255 chars |
| `name` | `string` | Human-readable name for the list |
| `itemType` | `string` | Type of values stored in the list. One of `email`, `email_domain`, `customer_id`, `ip_address`, `country`, `card_fingerprint`, `sepa_debit_fingerprint`, `us_bank_account_fingerprint`, `charge_description`, `case_insensitive_string`, `case_sensitive_string` |

**Response**

```json
{
  "id": "9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d",
  "alias": "vip_customers",
  "name": "VIP customers",
  "itemType": "email",
  "isDefault": false,
  "itemCount": 0,
  "createdAt": "2026-08-24T12:00:00Z",
  "updatedAt": "2026-08-24T12:00:00Z"
}
```

If the alias already exists, the SDK throws a `CorgiSDKError` with code `LIST_ALIAS_EXISTS`.

---

## Add items

```typescript
await sdk.lists.addItems('vip_customers', [
  'a@example.com',
  'b@example.com',
]);
```

**Parameters**

| Parameter | Type | Description |
|---|---|---|
| `listId` | `string` | List id or alias |
| `values` | `string[]` | Values to add (1–10,000 per request, each ≤ 1,000 chars) |

**Response**

```json
{
  "added": 2,
  "skipped": 0,
  "invalid": 0,
  "invalidValues": []
}
```

Items are trimmed and deduped server-side. Invalid values are reported in `invalidValues` but do not fail the request, unless every value is invalid — then the request fails with `ALL_VALUES_INVALID`.

---

## Remove items

```typescript
await sdk.lists.removeItems('vip_customers', ['b@example.com']);
```

**Parameters**

| Parameter | Type | Description |
|---|---|---|
| `listId` | `string` | List id or alias |
| `values` | `string[]` | Values to remove (1–10,000 per request) |

**Response**

```json
{
  "deleted": 1
}
```

---

## List items

Item listing is cursor-paginated. Set `limit` to 500 or less.

```typescript
let cursor: string | undefined;
do {
  const page = await sdk.lists.listItems('vip_customers', {
    limit: 500,
    startingAfter: cursor,
  });
  console.log(page.data.map((item) => item.value));
  cursor = page.nextCursor ?? undefined;
} while (cursor);
```

**Parameters**

| Parameter | Type | Description |
|---|---|---|
| `listId` | `string` | List id or alias |
| `limit` | `number` | Page size (max 500, default 500) |
| `startingAfter` | `string` | Cursor from the previous page |

**Response**

```json
{
  "data": [
    { "id": "5a8f3c2e-1d4b-4e6a-9c7f-2b8d0e4a6c1f", "value": "a@example.com", "createdAt": "2026-08-24T12:00:00Z" }
  ],
  "hasMore": false,
  "nextCursor": null
}
```

---

## List all lists

List every list in your account. Set `limit` to 100 or less.

```typescript
let cursor: string | undefined;
do {
  const page = await sdk.lists.list({ limit: 100, startingAfter: cursor });
  console.log(page.data.map((list) => list.alias));
  cursor = page.nextCursor ?? undefined;
} while (cursor);
```

**Parameters**

| Parameter | Type | Description |
|---|---|---|
| `limit` | `number` | Page size (max 100, default 100) |
| `startingAfter` | `string` | Cursor from the previous page |

**Response**

```json
{
  "data": [
    {
      "id": "9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d",
      "alias": "vip_customers",
      "name": "VIP customers",
      "itemType": "email",
      "isDefault": false,
      "itemCount": 2,
      "createdAt": "2026-08-24T12:00:00Z",
      "updatedAt": "2026-08-24T12:00:00Z"
    }
  ],
  "hasMore": false,
  "nextCursor": null
}
```

---

## Error handling

API errors throw `CorgiSDKError`, which exposes `status`, `code`, and `message`.

```typescript
import { CorgiSDKError } from 'corgi-sdk';

try {
  await sdk.lists.create({ alias: 'vip_customers', name: 'VIP customers', itemType: 'email' });
} catch (error) {
  if (error instanceof CorgiSDKError) {
    console.error(error.status, error.code, error.message);
  }
  throw error;
}
```

**Common error codes**

| Code | HTTP | Meaning |
|---|---|---|
| `UNAUTHORIZED` | 401 | Invalid or missing API token |
| `INVALID_INPUT` | 400 | Request body failed validation |
| `INVALID_CURSOR` | 400 | The `startingAfter` id does not exist. A malformed (non-UUID) cursor returns `INVALID_INPUT` instead |
| `NOT_FOUND` | 404 | List or item does not exist |
| `LIST_ALIAS_EXISTS` | 409 | A list with this alias already exists |
| `ALL_VALUES_INVALID` | 400 | Every value in the request failed validation |

---

## Raw HTTP API

The SDK is a thin wrapper over a REST API. You can call it directly from any language.

- **Base URL:** `https://app.corgilabs.ai/api/v1/corgi-sdk`

- **Auth:** `Authorization: Bearer <token>` on every request. List endpoints require a plan with rule management access; without it requests return 400

- **Errors:** Non-2xx responses return `{ "error": "...", "code": "..." }`

In the endpoints below, `{listId}` accepts either the list id or its alias.

### List lists

```bash
curl -H "Authorization: Bearer $TOKEN" \
  "https://app.corgilabs.ai/api/v1/corgi-sdk/lists?limit=100"
```

**Query parameters**

| Parameter | Type | Description |
|---|---|---|
| `limit` | `number` | Page size (max 100, default 100) |
| `startingAfter` | `string` | Cursor for pagination |

**Response**

```json
{
  "data": [
    {
      "id": "9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d",
      "alias": "vip_customers",
      "name": "VIP customers",
      "itemType": "email",
      "isDefault": false,
      "itemCount": 2,
      "createdAt": "2026-08-24T12:00:00Z",
      "updatedAt": "2026-08-24T12:00:00Z"
    }
  ],
  "hasMore": true,
  "nextCursor": "..."
}
```

### Create a list

```bash
curl -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"alias":"vip_customers","name":"VIP customers","itemType":"email"}' \
  https://app.corgilabs.ai/api/v1/corgi-sdk/lists
```

**Response (201)**

The created list, wrapped in a `list` key:

```json
{
  "list": {
    "id": "9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d",
    "alias": "vip_customers",
    "name": "VIP customers",
    "itemType": "email",
    "isDefault": false,
    "itemCount": 0,
    "createdAt": "2026-08-24T12:00:00Z",
    "updatedAt": "2026-08-24T12:00:00Z"
  }
}
```

**Error (409)**

```json
{
  "error": "List alias already exists",
  "code": "LIST_ALIAS_EXISTS"
}
```

### Add items

```bash
curl -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"values":["a@example.com","b@example.com"]}' \
  https://app.corgilabs.ai/api/v1/corgi-sdk/lists/vip_customers/items
```

**Response**

```json
{
  "added": 2,
  "skipped": 0,
  "invalid": 0,
  "invalidValues": []
}
```

### List items

```bash
curl -H "Authorization: Bearer $TOKEN" \
  "https://app.corgilabs.ai/api/v1/corgi-sdk/lists/vip_customers/items?limit=500"
```

**Query parameters**

| Parameter | Type | Description |
|---|---|---|
| `limit` | `number` | Page size (max 500, default 500) |
| `startingAfter` | `string` | Cursor for pagination |

**Response**

```json
{
  "data": [
    { "id": "5a8f3c2e-1d4b-4e6a-9c7f-2b8d0e4a6c1f", "value": "a@example.com", "createdAt": "2026-08-24T12:00:00Z" }
  ],
  "hasMore": false,
  "nextCursor": null
}
```

### Delete items

```bash
curl -X DELETE \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"values":["b@example.com"]}' \
  https://app.corgilabs.ai/api/v1/corgi-sdk/lists/vip_customers/items
```

**Response**

```json
{
  "deleted": 1
}
```

---

## SDK reference

| Method | Description |
|---|---|
| `sdk.lists.create({ alias, name, itemType })` | Create a new list |
| `sdk.lists.addItems(listId, values)` | Add items to a list (bulk, max 10,000) |
| `sdk.lists.removeItems(listId, values)` | Remove items from a list (bulk, max 10,000) |
| `sdk.lists.listItems(listId, { limit?, startingAfter? })` | List items with pagination |
| `sdk.lists.list({ limit?, startingAfter? })` | List all lists with pagination |

---

### Plans & Features

https://www.corgilabs.ai/docs/corgi-intelligence/plans-and-features

Find the right Corgi Intelligence plan for your team with clear pricing, features, and support tiers.

Corgi Intelligence is available in three plans designed to match your team size and operational needs.

---

## Plan Comparison

### Core — $299/month

*16% discount if paid yearly*

Best for business owners or small teams who need advanced analytics to better understand their payments and unlock actionable insights.

Core includes:

- Unlimited analytics: revenue, payments, customer & product performance, disputes & fraud

- Customer clusters and advanced segmentation

- AI Insights report (1 per month)

- AI payment & analytics agent

- Custom metrics

- Dispute management

- 3 admin user seats

- 24/7 chatbot support (24-hour live chat SLA)

### Pro — $999/month

*16% discount if paid yearly*

Best for businesses with dedicated payment or risk operations staff who need payment tools to optimize revenue and prevent fraud.

Pro includes everything in Core, plus:

- Rule & List management

- AI-assisted Rule Intelligence (backtesting, experimentation, natural language rule generation)

- AI Insights report (1 per week; on-demand coming soon)

- Early Fraud Warning plus intelligent refund suggestions

- Chargeback prevention (10 alerts/month included; $20/alert thereafter)

- AI-assisted Dispute intelligence

- 10 user seats with access management

- 24/7 chatbot support (3-hour live chat SLA)

### Enterprise — Custom pricing

Best for businesses processing with multiple PSPs or with dedicated payment/operations teams who need maximum revenue conversion and enterprise security.

Enterprise includes everything in Pro, plus:

- Multi-PSP support

- Enterprise SSO

- Developer API & Analytics Query Language

- AI Insights report (on demand)

- Chargeback prevention (100 alerts/month included)

- Hands-on report implementation

- Dedicated success manager

- Custom seat allocation

- 24/7 chatbot support (5-minute live chat SLA)

---

## Feature Availability Summary

### Analytics & Insights

All analytics features (Overview Dashboard, Payment Analytics, Customer Overview, Customer Clusters, Product Performance, Disputes & Fraud) are available on all paid plans.

AI Insights report frequency varies by plan:

- Core: 1 per month

- Pro: 1 per week (on-demand coming soon)

- Enterprise: on demand

### Payment Tools

Dispute Management is available on all plans. Rule Management, List Management, Review Queue, and AI-assisted intelligence features require the Pro plan or higher.

Sales Tax tracking is available on all plans.

### Team & Access

Core includes 3 seats. Pro includes 10 seats with access management. Enterprise offers custom seat allocation with SSO.

---

## Trial & Expired Plans

All plans include a **30-day free trial** with full access to your plan's features.

### What happens when the trial ends

If you choose not to upgrade after your trial expires, the following limits apply:

- Only the Overview dashboard remains visible, limited to 6 months of data.

- AI Insights reports generated during the trial remain viewable.

- Payment Tools and other analytics pages are not accessible.

---

## Getting Started

Ready to try Corgi Intelligence?

[Start your 30-day free trial here](https://app.corgilabs.ai/auth/register). No card is required.

Or [book a demo](https://www.corgilabs.ai/#book-demo) and we will walk you through the platform.

---

### Migration Guide: Payment Element → Corgi-Controlled Confirmation

https://www.corgilabs.ai/docs/corgi-model/migration-guide-payment-element-corgi-controlled-confirmation

Add Corgi Model fraud decisioning to your existing Stripe Payment Element integration with one backend change and no checkout UX impact.

If you process payments using Stripe [**Payment Element**](https://docs.stripe.com/payments/payment-element) with PaymentIntent, you can start using Corgi Model or Corgi Rule Engine by migrating to Corgi-Controlled PaymentIntent Confirmation. This enables deterministic **Request 3DS**, **Allow**, **Block**, and **Review** decisions enforced by Corgi Labs before payment confirmation, without changing your checkout UX.

## Changes at a high level

You will make **one flow change**. Instead of having Stripe's standard client confirmation flow finalize the payment, you collect payment details in your existing Payment Element, create a Stripe `ConfirmationToken`, send it to your backend, and let your server call Corgi Labs' confirm-payment endpoint.

Your checkout UX remains largely unchanged, but the confirmation control is moved to your server. Your customers should not experience any noticeable changes.

|  | Before | After |
|---|---|---|
| Client flow | Mount Payment Element, then call `stripe.confirmPayment(...)` | Mount Payment Element, collect a Fingerprint event, call `elements.submit()`, create a `ConfirmationToken`, then call your backend finalize endpoint with `confirmationTokenId` and `fpEventId` |
| Server flow | Create PaymentIntent directly with Stripe | Call Corgi Labs to create the PaymentIntent, evaluate rules, and execute confirmation |
| Risk evaluation | Controlled by Stripe Radar | Controlled by Corgi Model and Corgi Rule Engine |

---

# Migrate to Corgi-Controlled Confirmation

## Step 1 — Replace direct PaymentIntent creation with server finalization

Allow Corgi Labs to evaluate the payment during the server-finalize flow. This is the main backend change.

### ❌ Before (direct Stripe call)

```python
# server.py
pi = stripe.PaymentIntent.create(
    amount=5000,
    currency="usd",
    automatic_payment_methods={"enabled": True},
    metadata={"order_id": "123"},
)

return {"client_secret": pi.client_secret}
```

---

### ✅ After (HTTP API example, recommended)

Create a `CORGI_API_TOKEN` in your Corgi Web App at [app.corgilabs.ai](https://app.corgilabs.ai/). Keep that token on your server only.

```python
# server.py
import os
import requests

CORGI_API_TOKEN = os.environ["CORGI_API_TOKEN"]

# /api/finalize-payment
def finalize_payment(confirmation_token_id, fp_event_id):
    response = requests.post(
        "https://app.corgilabs.ai/api/v1/corgi-sdk/confirm-payment",
        headers={
            "Authorization": f"Bearer {CORGI_API_TOKEN}",
            "Content-Type": "application/json",
        },
        json={
            "confirmationTokenId": confirmation_token_id,
            "paymentIntentParams": {
                "amount": 5000,
                "currency": "usd",
                "metadata": {
                    "order_id": "123",
                    "fp_event_id": fp_event_id,
                }
            }
        },
        timeout=15,
    )
    response.raise_for_status()
    return response.json()
```

### Optional: SDK (Node.js) example

```typescript
import { CorgiSDK } from 'corgi-sdk';

const corgi = new CorgiSDK({
  token: process.env.CORGI_API_TOKEN,
});

// /api/finalize-payment
export async function finalizePayment(
  confirmationTokenId: string,
  fpEventId: string,
) {
  return await corgi.confirmPayment(confirmationTokenId, {
    amount: 5000,
    currency: 'usd',
    metadata: {
      order_id: '<order_id>',
      fp_event_id: fpEventId,
    },
  });
}
```

## Step 2 — Change the frontend to create a Stripe `ConfirmationToken`

Move the client from Stripe-controlled confirmation to token creation plus server finalization. The checkout UI remains the same, but the submit path changes.

Your frontend should also embed Fingerprint.js, collect a Fingerprint event ID for each checkout attempt, and send that `fpEventId` to your backend. Your backend should persist that value to PaymentIntent metadata as `fp_event_id` during the Corgi confirm call. This lets Corgi retrieve IP address, user agent, and related request/device context.

### ❌ Before (client confirms directly with Stripe)

```javascript
const stripe = Stripe(PUBLISHABLE_KEY);
const elements = stripe.elements({
  mode: "payment",
  currency: "usd",
  amount: 5000,
  captureMethod: 'manual',
  paymentMethodCreation: 'manual',
});

const paymentElement = elements.create("payment");
paymentElement.mount("#payment-element");

const { error } = await stripe.confirmPayment({
  elements,
  confirmParams: {
    return_url: "<your return url>",
  },
});

if (error) {
  window.alert(error.message);
}
```

---

### ✅ After (client creates `ConfirmationToken`, server finalizes)

```javascript
import * as Fingerprint from '@fingerprint/agent';

const stripe = Stripe(PUBLISHABLE_KEY);
const elements = stripe.elements({
  mode: 'payment',
  currency: 'usd',
  amount: 5000,
});

const paymentElement = elements.create('payment');
paymentElement.mount('#payment-element');

const submitResult = await elements.submit();
if (submitResult.error) {
  window.alert(submitResult.error.message);
  return;
}

const tokenResult = await stripe.createConfirmationToken({
  elements,
  params: {
    payment_method_data: {
      billing_details: {
        name: '<name>',
        email: '<email>',
      },
    },
    return_url: '<your return url>',
  },
});

if (tokenResult.error) {
  window.alert(tokenResult.error.message);
  return;
}

const fp = Fingerprint.start({
  apiKey: 'CXTnbDDa5sn49p2NSHNm',
  endpoints: "https://metrics.corgilabs.ai"
});
const fpResult = await fp.get();
const fpEventId = fpResult.event_id;

const result = await fetch('/api/finalize-payment', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    confirmationTokenId: tokenResult.confirmationToken.id,
    fpEventId,
  }),
}).then((res) => res.json());

if (result.action === 'block') {
  window.alert('Your card was declined.');
  return;
}

if (result.action === 'request_3ds' || result.status === 'requires_action') {
  const { error } = await stripe.handleNextAction({
    clientSecret: result.clientSecret,
  });

  if (error) {
    window.alert('We are unable to authenticate your payment method. Please choose a different payment method and try again');
    return;
  }
}
```

### Expo / React Native Fingerprint event ID

For mobile checkout, keep the backend payload unchanged. The React Native SDK returns the per-identification event ID as `requestId`; send that value as `fpEventId`.

```bash
pnpm add @fingerprintjs/fingerprintjs-pro-react-native
```

For Expo, add the native config plugin and use a native build or custom dev client. Expo Go is not supported because the SDK uses native code.

```json
{
  "expo": {
    "plugins": ["@fingerprintjs/fingerprintjs-pro-react-native"]
  }
}
```

Wrap the app with the Fingerprint provider using Corgi's public API key and metrics endpoint. In the React Native SDK, this endpoint config is `endpointUrl`.

```typescript
import { FingerprintJsProProvider } from '@fingerprintjs/fingerprintjs-pro-react-native';

export function AppRoot() {
  return (
    <FingerprintJsProProvider
      apiKey="CXTnbDDa5sn49p2NSHNm"
      endpointUrl="https://metrics.corgilabs.ai"
    >
      <App />
    </FingerprintJsProProvider>
  );
}
```

In the mobile checkout submit path, collect `requestId` and pass it to the same finalize endpoint used by web:

```typescript
import { useVisitorData } from '@fingerprintjs/fingerprintjs-pro-react-native';

const { getData } = useVisitorData();

const visitorData = await getData();
const fpEventId = visitorData.requestId;

await fetch('/api/finalize-payment', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    confirmationTokenId,
    fpEventId,
  }),
});
```

No backend change is needed. Continue saving the value as `paymentIntentParams.metadata.fp_event_id` during the Corgi confirm call.

See Fingerprint's [React Native SDK docs](https://docs.fingerprint.com/docs/fingerprintjs-pro-react-native) and [package README](https://www.npmjs.com/package/@fingerprintjs/fingerprintjs-pro-react-native) for native setup details.

## Step 3 — Optional: Add metadata for better decisions

In addition to the required `fp_event_id` field used for device and request context, you can pass any metadata you already have. For example:

```json
{
  "metadata": {
    "user_id": "u_456",
    "loyalty_tier": "gold"
  }
}
```

Corgi Labs automatically ingests the custom metadata. These fields can be used for Corgi Model evaluation and Rule Management immediately.

## Step 4 — Optional: Subscribe to webhooks

We recommend subscribing to the following events:

- `payment_intent.succeeded`

- `payment_intent.payment_failed`

If you already listen to Stripe PaymentIntent events, no changes are required.

---

# Handle payments with Corgi-Controlled Confirmation

For each checkout attempt routed to Corgi after the migration:

1. The client mounts Payment Element and initializes Fingerprint.js.

1. The client collects `fpEventId` and calls `elements.submit()`.

1. The client creates a Stripe `ConfirmationToken`.

1. The client sends `confirmationTokenId` and `fpEventId` to your backend.

1. Your backend calls Corgi's confirm-payment endpoint or SDK, creates the PaymentIntent, and saves `fp_event_id` in metadata.

1. Corgi Labs creates the draft `PaymentIntent`, evaluates rules, and executes the confirmation flow.

1. Corgi Labs returns a result such as `allow`, `block`, `request_3ds`, or `review`, along with Stripe status fields.

1. If Stripe requires customer authentication, the client calls `stripe.handleNextAction(...)` using the returned `clientSecret`.

---

# API response shape

`confirmPayment(confirmationTokenId, paymentIntentParams)` returns:

- `action`: `allow`, `block`, `none`, `request_3ds`, or `review`

- `matchedRuleId`: the matched rule ID, if any

- `request3ds`: whether Corgi forced 3DS on the underlying PaymentIntent confirmation

- `paymentIntentId`: the Stripe PaymentIntent ID created by Corgi

- `status`: the latest Stripe PaymentIntent status

- `clientSecret`: the Stripe client secret when Stripe returns it

Pass the intended Stripe `PaymentIntentCreateParams` as the second argument when using the SDK. Corgi uses those parameters to create the draft PaymentIntent before rule evaluation and confirmation.

---

### Corgi Labs transaction metadata

https://www.corgilabs.ai/docs/corgi-model/corgi-labs-transaction-metadata

Reference for every metadata key Corgi Labs writes to your transactions, with integration-specific details and decision semantics.

# Transaction Metadata

When Corgi Labs processes a transaction, Corgi Model and Rule Engine add metadata that explains the risk evaluation and the resulting action. The exact metadata keys available depend on your integration flow and payment service provider.

This reference lists every metadata key Corgi Labs writes, when it appears, and what it means. Use it to debug transactions, build reporting, or integrate Corgi data into your own systems.

---

## CORGI Model metadata

Corgi Model is managed by Corgi and does not appear as a merchant-configurable rule in the Rule Engine. Corgi Model scores every transaction, including transactions where other risk engines, such as Stripe Radar, make the decision. To determine whether a transaction is in Corgi traffic, check `corgi_exp_group`.

| Metadata key | Integration flow | Description |
|---|---|---|
| `corgi_score` | All supported flows | Corgi's payment risk score from 0 to 100. Higher values indicate a higher predicted likelihood of dispute. Corgi Model scores 100% of traffic, so every payment has this key. Corgi Model participates in the payment decision only when `corgi_exp_group` is `corgi`. When `corgi_exp_group` is `stripe`, the score is for comparison only. |
| `corgi_exp_group` | All supported flows | Experiment group assigned to the payment. Use this key to determine whether a payment is in Corgi traffic or Stripe traffic. `corgi` means Corgi Model participated in the payment decision. `stripe` means Stripe Radar evaluated the payment, and Corgi Model generated `corgi_score` for comparison only. During staged rollout, Corgi may assign 30%, 70%, or 100% of eligible traffic to `corgi`. |
| `corgi_model_version` | All supported flows | Version of Corgi Model that generated `corgi_score` for the payment. |
| `corgi_model_threshold` | All supported flows | Corgi Model's blocking threshold when the payment was evaluated, on the same 0 to 100 scale as `corgi_score`. |
| `corgi_pre_auth_decision`, `corgi_pre_auth_matched_rule` | Corgi SDK `confirm-payment` only | Result of the Corgi Model and Rule Engine evaluation before payment authorization. When Corgi Model approves the payment, `corgi_pre_auth_decision` is `NONE` unless a rule also matched. When Corgi Model blocks the payment, `corgi_pre_auth_decision` is `BLOCK`, and `corgi_pre_auth_matched_rule` is `corgi-model-rule-id, CORGI model`. |
| `corgi_decision`, `corgi_matched_rule` | Stripe Checkout for subscriptions only | Result of the Corgi Model and Rule Engine evaluation. When Corgi Model approves the payment, `corgi_decision` is `NONE` unless a rule also matched. When Corgi Model blocks the payment, `corgi_decision` is `BLOCK`, and `corgi_matched_rule` is `corgi-model-rule-id, CORGI model`. |
| `corgi_action` | All supported flows | Final action taken by Corgi Model and Rule Engine. When Corgi Model blocks the payment, `corgi_action` is `model_block`. When Corgi Model recommends blocking but enforcement is disabled, `corgi_action` is `model_block_dry_run`. See Decision values for all values. |

`corgi-model-rule-id` is a reserved, stable identifier that represents the Corgi-managed model rule consistently across integrations.

---

## All transaction metadata by integration type

### Corgi SDK `confirm-payment` for Stripe

Calls to `POST /api/v1/corgi-sdk/confirm-payment` may be routed through a two-phase evaluation. The Rule Engine evaluates the payment before authorization and, when required, after authorization. Corgi Labs writes the metadata below to the Stripe `PaymentIntent` it creates and preserves any metadata you supplied in `paymentIntentParams.metadata`.

| Metadata key | Type / example | When present | Description |
|---|---|---|---|
| `corgi_pre_auth_decision` | enum / `ALLOW`, `BLOCK`, `REVIEW`, `REQUEST_3DS`, or `NONE` | After pre-auth evaluation | Result of the Corgi Model and Rule Engine evaluation before payment authorization. `NONE` means evaluation completed and no model or rule produced an action. |
| `corgi_pre_auth_matched_rule` | string / `rule_123, Review new customers` | After pre-auth evaluation | Matched rule ID and name before authorization, formatted as `rule ID, rule name`. An empty string means no rule matched. |
| `corgi_post_auth_decision` | enum / `ALLOW`, `BLOCK`, `REVIEW`, or `NONE` | After post-auth evaluation | Result of the Rule Engine evaluation after payment authorization. `ALLOW` means an allow rule matched; `NONE` means evaluation completed and no post-authorization rule produced an action. This key is absent when post-authorization evaluation does not run. |
| `corgi_post_auth_matched_rule` | string / `rule_456, Block high risk` | After post-auth evaluation | Rule ID and name matched after authorization, formatted as `rule ID, rule name`. An empty string means no rule matched. |
| `corgi_action` | enum / `rule_block`, `model_block_dry_run`, `pending`, or `no_action` | When Rule Engine evaluates the payment | Summary of the final action taken by Corgi Model and Rule Engine, including global rule, model, and merchant rule actions. Values ending in `_dry_run` mean an action was recommended but enforcement was disabled. `pending` means the post-authorization decision is not final yet. For all values, see Decision values. |
| `corgi_request_3ds_matched_rule` | string / `rule_789, Require 3DS` | When 3DS is requested | Rule ID and name that requested 3D Secure, formatted as `rule ID, rule name`. When present, `corgi_pre_auth_decision` is `REQUEST_3DS`. The authentication result is available on the Stripe `PaymentIntent` or `Charge`. |
| `corgi_global_rule` | string / `0.1, OFAC Comprehensively Embargoed Jurisdictions` | When a global rule matches | Number and name of the matched global rule, formatted as `number, name`. Global rules are Corgi-managed compliance and network-level fraud rules. You cannot configure them, but this metadata identifies the matched rule. |
| `corgi_global_block` | boolean / `true` or `false` | When a global rule matches | `true` when the matched global rule produces a block action. |
| `corgi_capture_method` | enum / `automatic` or `manual` | When Rule Engine evaluates the payment | The capture method requested in `paymentIntentParams.capture_method`; defaults to `automatic`. Corgi creates the `PaymentIntent` with manual capture while evaluating risk, then uses this value to preserve your requested capture behavior. This is separate from the Stripe Payment Element configuration. The `ConfirmationToken` must be created with `captureMethod: "manual"` for this flow. |
| `fp_event_id` | string / `fp_evt_…` | When supplied by you | Your event ID from [fingerprint.com](http://fingerprint.com/), provided through `paymentIntentParams.metadata`. Corgi copies it to the `PaymentIntent` and uses the event to evaluate device, browser, IP, and other device signals. |

### Stripe Checkout for subscriptions

This flow is for subscription businesses using Stripe Checkout. It uses a payment-mode Checkout Session for a temporary manual-capture authorization. After `checkout.session.completed`, Corgi evaluates the authorized payment, cancels the authorization, and creates a `Subscription` unless the payment is blocked.

Your Checkout Session must use `mode: "payment"` with `payment_intent_data.capture_method: "manual"` and `setup_future_usage: "off_session"`.

| Metadata key | Type / example | When present | Description |
|---|---|---|---|
| `corgi_decision` | enum / `ALLOW`, `BLOCK`, `REVIEW`, or `NONE` | After this Checkout subscription flow is processed | Corgi Model or Rule Engine evaluation result written to the Checkout Session and related `PaymentIntent` objects. This value records the evaluated action; enforcement may depend on your project's action settings. `NONE` means no model or rule produced an action, unless `corgi_rule_engine_skipped` is `true`. |
| `corgi_action` | enum / `rule_block`, `model_block_dry_run`, or `no_action` | After this Checkout subscription flow is processed | Summary of the final action taken by Corgi Model and Rule Engine, including global rule, model, and merchant rule actions. Values ending in `_dry_run` mean an action was recommended but enforcement was disabled. For all values, see Decision values. |
| `corgi_subscription_id` | string / `sub_…` | When a subscription is created | ID of the `Subscription` created by this Stripe Checkout subscription flow, written to the Checkout Session and related `PaymentIntent` objects. This key is absent when the payment is blocked or no `Subscription` is created. |
| `corgi_matched_rule` | string / `rule_123, Review new customers` | When a rule matches | Matched rule ID and name, formatted as `rule ID, rule name`, written to the Checkout Session and related `PaymentIntent` objects. |
| `corgi_rule_engine_skipped` | boolean / `true` | When rule evaluation is skipped | `true` when Corgi intentionally skips rule evaluation for the transaction. Written to the Checkout Session and the created `Subscription`'s `PaymentIntent`. |
| `corgi_global_rule` | string / `0.1, OFAC Comprehensively Embargoed Jurisdictions` | When a global rule matches | Number and name of the matched global rule, formatted as `number, name`, written to the Checkout Session and related `PaymentIntent` objects. Global rules are Corgi-managed compliance and network-level fraud rules. You cannot configure them, but this metadata identifies the matched rule. |
| `corgi_global_block` | boolean / `true` or `false` | When a global rule matches | `true` when the matched global rule produces a block action. Written to the Checkout Session and related `PaymentIntent` objects. |
| `corgi_decision_at` | ISO 8601 string / `2026-07-28T06:50:21.907Z` | After this Checkout subscription flow is processed | ISO 8601 timestamp marking completion of this Checkout subscription evaluation, written to the Checkout Session and related `PaymentIntent` objects. |
| `corgi_checkout_session_id` | string / `cs_…` | On the created `Subscription` | ID of the Checkout Session that originated the `Subscription`. |
| `corgi_subscription_params` | JSON / `{"items":[{"price":"price_…","quantity":1}]}` | Required for this flow | Your Stripe `Subscription` creation parameters stored on the Checkout Session. The JSON value must contain at least one `items` entry. When the payment is permitted, Corgi creates the `Subscription` from these parameters and derives the customer and default payment method from the completed Checkout flow. |
| `fp_event_id` | string / `fp_evt_…` | When supplied by you | Your event ID from [fingerprint.com](http://fingerprint.com/), provided through `paymentIntentParams.metadata`. Corgi copies it to the `PaymentIntent` and uses the event to evaluate device, browser, IP, and other device signals. |

---

## Decision values

The following enum values appear in `corgi_pre_auth_decision`, `corgi_post_auth_decision`, and `corgi_decision`:

| Value | Meaning |
|---|---|
| `ALLOW` | An allow rule matched. |
| `BLOCK` | A block rule or the Corgi Model blocked the payment. |
| `REVIEW` | A review rule matched. |
| `REQUEST_3DS` | 3D Secure was requested (pre-auth only). |
| `NONE` | Evaluation completed and no model or rule produced an action. |

The following enum values appear in `corgi_action`:

| Value | Meaning |
|---|---|
| `global_block` | A global rule blocked the payment. |
| `model_block` | Corgi Model blocked the payment. |
| `rule_block` | A merchant rule blocked the payment. |
| `rule_review` | A merchant rule sent the payment for review. |
| `rule_3ds` | 3D Secure was requested. |
| `model_block_dry_run` | Corgi Model recommended blocking, but enforcement was disabled. |
| `rule_block_dry_run` | A rule recommended blocking, but enforcement was disabled. |
| `rule_review_dry_run` | A rule recommended review, but enforcement was disabled. |
| `rule_3ds_dry_run` | A rule recommended 3D Secure, but enforcement was disabled. |
| `rule_allow` | An allow rule matched. |
| `no_action` | No model or rule action was taken. |
| `pending` | The final post-authorization decision is still pending. |
| `error` | Rule Engine evaluation failed. |

---

## Global rules

Global rules are Corgi-managed compliance and network-level fraud rules. You cannot configure them, but Corgi exposes when they match through metadata.

---