Payment Health & Radar

Most merchants think about Stripe risk in terms of disputes and freezes. Those are the visible threats. But there is a quieter problem that affects far more businesses: money you should be collecting but are not, because your payment stack is misconfigured.

Payment health is the broader picture. It includes your authorization rate (what percentage of attempted charges actually succeed), your decline rate (how many legitimate customers are turned away), your Radar configuration (how your fraud rules interact with real transactions), and your checkout conversion flow (where customers drop off during payment).

A business can have zero disputes, zero risk of a freeze, and still be losing 10-20% of revenue because Stripe Radar is blocking legitimate payments. This is the part nobody talks about because it does not send you an angry email. The money just never arrives.

Your authorization rate is the percentage of payment attempts that successfully complete. A healthy Stripe account typically sees authorization rates between 85-95%, depending on your industry, customer geography, and product type.

Every point below your optimal rate is lost revenue. If you process $100K/month and your auth rate is 80% when it should be 90%, you are leaving $10K on the table every month. Not because customers do not want to pay — because your payment stack is preventing them from paying.

Common causes of low auth rates: not passing complete customer data with charges (name, email, billing address), over-aggressive Radar rules blocking legitimate cards, requesting 3D Secure on low-risk transactions where it adds friction without value, and not using Stripe Customer objects for returning customers (which reduces the data available for authorization optimization).

The fix is usually configuration, not code. Passing the right data fields, tuning Radar rules, and applying 3D Secure selectively can improve auth rates without any changes to your product or checkout design.

Stripe Radar is a machine learning fraud detection system that scores every transaction for risk. When a transaction's risk score exceeds your threshold, Radar blocks it. The problem: Radar does not know your customers. It scores based on aggregate patterns across all Stripe merchants, which means it can flag legitimate transactions on your account that happen to share characteristics with fraud patterns elsewhere.

The most common scenario: a customer with a slightly unusual profile — international card, VPN IP, new email address — tries to pay you. Radar scores the transaction as elevated risk and blocks it. The customer sees a generic decline message, assumes their card does not work on your site, and leaves. You never know it happened unless you check your Radar blocked payments logs.

This gets worse after account events. If your account has had disputes or a volume spike, Radar can become more aggressive in its blocking. The system is protecting Stripe from risk on your account, which means it would rather block a legitimate payment than let through a potentially fraudulent one. That tradeoff makes sense for Stripe. For your business, it means lost customers.

The default Radar configuration is designed for the average Stripe merchant. If your business has an above-average percentage of international customers, high-value transactions, or customers with less common payment profiles, the defaults will over-block.

One merchant discovered that 30% of their payment attempts were being blocked by Radar — silently, with no alerts, no notifications, and no indication in their dashboard. They only found it by digging into their Radar blocked payments log months later. By then, they had lost an estimated 15-20% of total revenue over that period.

The leak compounds over time. Every blocked customer is a lost sale today, a lost repeat customer tomorrow, and a lost referral next month. If you are spending money on acquisition (ads, content, partnerships) and Radar is blocking 15% of the customers you paid to acquire, your actual customer acquisition cost is 15% higher than you think.

This is why payment health monitoring matters even if your dispute rate is zero. The absence of disputes does not mean the absence of problems. It might mean Radar is so aggressive that it is blocking both fraud and legitimate customers — which looks like low disputes but is actually strangled revenue.

3D Secure (3DS) adds an additional verification step during checkout — the customer confirms the payment through their bank's app or a one-time code. The benefit: liability for fraud disputes shifts from you to the card issuer. A dispute on a 3DS-authenticated transaction is the bank's problem, not yours.

The cost: friction. Every additional step in checkout reduces conversion. In the EU, 3DS is legally required for most transactions under Strong Customer Authentication (SCA) regulations, so the friction is expected and customers are accustomed to it. In the US, 3DS is optional and less common — US customers often abandon checkout when faced with an unexpected verification step.

The strategic benefit of selective 3DS: on the transactions where you do use it, you get liability shift protection. On the transactions where you skip it, you get higher conversion. The key is applying it where the fraud risk justifies the friction and skipping it where it does not.

Card testing is when attackers use your checkout to validate stolen credit card numbers. They run small transactions — usually under $5 — in rapid succession. Cards that go through are confirmed active and get sold or used for larger fraud. The small charges on your end eventually result in chargebacks that count against your dispute rate.

The pattern is unmistakable once you know what to look for: a sudden spike of low-value charges or failed charge attempts, often from different card numbers but with similar metadata — same IP range, same device fingerprint, machine-gun timing (multiple attempts per second).

Immediate response: If you are under active attack, enable 3D Secure on all transactions via a Radar rule as an emergency measure. Set a minimum transaction amount. If the attacks are coming through your API, rotate your publishable and secret keys immediately.

Preventive configuration: Add Radar velocity rules (block IPs with more than 3 failed charges in 10 minutes). Require CVC on all transactions (most card testing scripts do not have CVCs). Add CAPTCHA to your checkout. Consider blocking prepaid cards if they are not typical for your customer base.

PayCanary detects card testing patterns through volume spike analysis and alerts you with an immediate response playbook — before the chargebacks from those small successful charges start arriving weeks later.

Most Stripe merchants are running Radar on default settings. That means the fraud rules are calibrated for a generic merchant profile, not your specific business. Tuning Radar for your business is one of the highest-ROI changes you can make.

Pass complete customer data. Every charge should include: customer name, email, billing address, and IP address. Radar uses all of these signals for scoring. Missing fields mean worse scores, which mean more blocks. If you are using Stripe Checkout or Payment Links, most of these are collected automatically. If you are using the API directly, you need to pass them explicitly.

Use Stripe Customer objects. When a returning customer pays, create or reuse a Stripe Customer object. This gives Radar historical context — a customer with 5 successful prior payments is less likely to be flagged than an anonymous charge.

Review your Radar rules quarterly. If you added rules during a card testing attack or a dispute spike, check whether they are still needed. Rules that were appropriate during a crisis may be over-blocking during normal operations.

Check your blocked payments log weekly. This is where you find the silent revenue leak. Look for patterns: are legitimate customers being blocked? Are certain card types or geographies disproportionately affected? Adjust your rules accordingly.

Use allow lists for trusted customers. If you have B2B clients or high-value repeat customers, add their email domains or card fingerprints to an allow list. This prevents Radar from accidentally blocking your best customers.

When you connect your Stripe account to PayCanary, the Radar Health Audit runs automatically on your first sync. It checks your Stripe integration for the configuration gaps described above — missing customer data fields, Radar rule misconfigurations, 3DS over-application, blocked payment patterns, and authorization rate anomalies.

The audit produces a report with specific, actionable findings. Not "your Radar configuration could be improved" — but "your charges are missing billing address in 68% of transactions, which is reducing your Radar scoring accuracy and likely increasing false blocks. Here is the code change to fix it."

For most merchants, the Radar Health Audit identifies 2-5 configuration gaps that, when fixed, improve authorization rates by 3-8 percentage points. On a $50K monthly volume, a 5-point improvement is $2,500/month in recovered revenue — $30K/year from a configuration change that takes an hour to implement.

The Radar Health Audit is included in all paid plans. For merchants not ready to connect their Stripe account, the free health check provides your risk score and dispute rate analysis — the other half of payment health.