Composite, auth-rate × inverse decline × inverse dispute × payout-on-time × Radar-clean share. The CFO single-number.
At a glance
A 0, 100 composite that compresses four payment-health signals (auth rate, decline rate, dispute rate, payout punctuality) into one number a non-finance founder can read at a glance. Designed for the question “is my Stripe doing what it should be doing today, yes or no?”
| The formula | 0.35 × auth_rate + 0.25 × (100 − 5 × decline_rate) + 0.20 × (100 − 50 × dispute_rate) + 0.20 × payout_on_time_pct. The four components are weighted because not all matter equally, auth rate is the day-to-day signal; disputes are the worst-case money-out signal so they punch above their weight when they spike. |
| Components are 0, 100 too | Each component clamps at 100 so a 102% auth rate (rare, but happens with refund recapture) doesn’t blow up the composite. |
| Auth rate component (35% weight) | successful_charges ÷ all_charges × 100. Healthy = 92, 96%. Below 90% is unusual and usually means a bad customer cohort (high-risk traffic source) or a Stripe Radar rule mis-tuned. |
| Decline rate amplifier (25% weight) | 100 − 5 × decline_rate. The ×5 amplifier means even a 2% absolute jump in decline rate drops the composite by 2.5 points (small movements feel large). This is intentional. Decline rate going from 4% to 6% costs a healthy CFO real money. |
| Dispute rate amplifier (20% weight) | 100 − 50 × dispute_rate. The ×50 amplifier is harsh: at 1% dispute rate the component is 50; at 2% it’s zero. This is calibrated to Visa / Mastercard chargeback monitoring thresholds (>0.9% triggers programs that can suspend the merchant account). |
| Payout-on-time (20% weight) | Percentage of payouts arriving by their arrival_date divided by all payouts. Stripe schedules payouts based on plan and history; payouts arriving late are a banking-side signal not a Stripe-side problem, but they still affect cash-flow planning. |
| Refunds | NOT a direct input. Refunds drive retroactive changes to other components but the composite reads the live state. |
| Currency | n/a (composite 0, 100). The component metrics are currency-neutral (rates, not amounts), so multi-currency stores get a single, valid health score. |
| Time window | RT/7D (real-time, rolling 7 days). The score updates every sync. |
| Alert trigger | < 70, when the composite drops below 70 the merchant gets pinged. The 70 threshold corresponds roughly to “auth rate < 88% OR decline rate > 6% OR dispute rate > 0.4%”. |
| Roles | owner, finance, operations |
Calculation
Calculated automatically from your Stripe data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A subscription brand running on Shopify with Stripe as the primary processor. The 7-day window covers 06 Apr 26 to 12 Apr 26.| Component | Value | Score |
|---|---|---|
| Auth rate | 4,820 succeeded ÷ 5,140 total = 93.8% | 93.8 |
| Decline rate | 240 failed ÷ 5,140 = 4.7% | 100 − 5 × 4.7 = 76.5 |
| Dispute rate | 9 disputes ÷ 4,820 succeeded = 0.187% | 100 − 50 × 0.187 = 90.6 |
| Payout-on-time | 6 of 7 payouts on time = 85.7% | 85.7 |
- Decline rate is dragging the score the most. At 4.7% it cost 5.9 composite points (vs an ideal score of 100). Look at Stripe Decline Rate and the outcome.reason breakdown to see if it’s
do_not_honor,insufficient_funds, or a Radar rule firing too aggressively. - Disputes are well below the danger zone. 0.187% is comfortably under the 0.9% Visa threshold. No action needed but watch the trend.
- One late payout. Could be a banking holiday, weekend timing, or a temporary Stripe hold. Usually self-resolves.
Sibling cards merchants should reference together
| Card | Why pair it with Payment Health Score |
|---|---|
| Stripe Auth Rate | The 35%-weight component. The first card to open when the composite drops. |
| Stripe Decline Rate | The 25%-weight component (amplified ×5). Decline movements drive most score swings. |
| Stripe Dispute Rate | The 20%-weight component (amplified ×50). Most punishing input. |
| Stripe Payout Age (Days) | The 20%-weight component. Payouts overdue means cash-flow drag. |
| Stripe Decline Reasons Breakdown | When decline rate is the cause, this card tells you whether it’s customer-side (insufficient funds), issuer-side (do_not_honor), or your-side (Radar rules / 3DS). |
| Stripe Refund Rate | NOT a direct input but high refund rates often co-move with high dispute rates. |
| Stripe Total Revenue | Pair with this card to read scale alongside health: a 95-score on 5M/wk is essential. |
Reconciling against the vendor’s own dashboard
Where to look in Stripe Dashboard: The Stripe Dashboard does NOT have a single “Payment Health” composite, this card synthesises one from four Stripe-native metrics. The closest equivalent screens:- Payments → Authorizations for auth-rate context.
- Payments → Failed payments for decline-rate context.
- Disputes for dispute-rate context.
- Balance → Payouts for payout-on-time context.
| Reason | Direction of divergence |
|---|---|
| Page cap (1,000 charges per request). High-volume merchants (>1,000 charges per day) see truncated daily figures in Vortex IQ. | Vortex IQ rates may be slightly off on heavy days |
| Time-zone. Stripe Dashboard runs on the merchant account’s timezone; Vortex IQ runs on UTC by default. | Boundary-day effects |
Outcome reasons reclassified after the fact. Stripe’s outcome.type and outcome.reason can be backfilled hours after the charge as more signal arrives (Radar feedback loops). Vortex IQ reads the snapshot at sync time. | Small 1, 2% drift on the most recent 24h |
Refund-on-charge metric semantics. The Stripe Dashboard sometimes counts a refunded charge as “succeeded then refunded”; this card’s auth rate counts it as “succeeded” (correct, refunds don’t change status). | Auth-rate component slightly higher in Vortex IQ |
paypal.pp_payment_health_score, which uses the same composite shape but with PayPal’s success / decline / dispute / payout signals.
For end-to-end revenue-side reconciliation see stripe.stripe_total_revenue, which has explicit cross-connector reconciliation against the commerce platforms.
Known limitations / merchant FAQs
My score is 88 but I feel like everything is fine, why isn’t it 100? A score of 100 would mean: 100% auth rate, 0% decline rate, 0% dispute rate, 100% payouts on time. This basically never happens in production, even healthy stores run at 92, 96% auth rate (some declines are just bank-side issuer behaviour the merchant can’t fix). 85, 95 is the healthy band; below 70 is the trigger. My score dropped 8 points overnight, what should I look at first? Open the four component cards in this order: Decline Rate (most likely), Auth Rate, Dispute Rate, then Payout Age. Decline rate is amplified ×5 in the formula so even a 1% absolute jump is 1.25 score points; this is usually the cause. Then check Decline Reasons to see which decline category drove it (issuer-sidedo_not_honor, customer-side insufficient_funds, or merchant-side Radar/3DS rules).
The dispute amplifier feels punishing, why is it ×50?
Because Visa and Mastercard run chargeback monitoring programs at 0.9% and above. Crossing those thresholds can suspend your merchant account or force enrolment in expensive programs (Visa VDMP, Mastercard Excessive Chargeback Merchant). The composite is designed to drop below 70 well before you hit those thresholds, so the alert fires early enough for you to react.
Does Stripe have an official “health score”?
No. Stripe surfaces individual component metrics on the dashboard but doesn’t provide a single composite. This card synthesises one. The four components and weights were chosen by the Vortex IQ team based on (a) what merchant CFOs ask first when they open the dashboard and (b) which metrics correlate with downstream revenue impact when they drift.
Can I customise the weights or amplifiers?
Not yet, the formula is fixed in the manifest. If you’d like a different weighting (e.g. weight payout-on-time higher because you have very tight cash-flow), open a request, the formula lives in stripe.yaml and is straightforward to add as a per-merchant override.
My score is 70 but I have 0% disputes, how is that possible?
The auth-rate component (35% weight) and decline-rate component (25% weight) together carry 60% of the formula. If your auth rate is 80% (low) and decline rate is 18% (high), the score can fall to 70 with disputes at 0%. This is actually common during a card-issuer outage or a Radar rule mis-fire.
Why isn’t refund rate in the formula?
Refunds aren’t a health signal at the payment-processing layer, they’re a fulfilment / product-quality signal. A merchant with 0% disputes and a 20% refund rate has a happy-customer-but-bad-product problem; that’s not what this card is designed to detect. Watch Stripe Refund Rate separately.
My multi-currency store, does the score work for me?
Yes. The components are rates, not amounts, so multi-currency stores get a single, valid health score. The auth/decline/dispute rates are computed across all charges regardless of currency. Payout-on-time looks at payouts in each currency the merchant settles in.