> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Decline Spike vs Checkout Funnel Drop, CyberSource > When CS declines spike, do we see commerce checkout completion drop? If yes, declines are causing real revenue loss, not just buyer remorse... How to read... **Metrics type:** [Cross-Platform Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Payment Gateway](/nerve-centre/connectors#connectors-by-type) > When CS declines spike, do we see commerce checkout completion drop? If yes, declines are causing real revenue loss, not just buyer remorse. ## At a glance > A dual-axis chart joining CyberSource decline-rate (15-min rolling) to the connected commerce platform's checkout-step-completion-rate (15-min rolling) over a 24-hour window. The card answers the diagnostic question *"is our decline-rate spike actually costing us revenue, or are customers just retrying on a different card?"* When both lines move together (declines up AND funnel completion down), the merchant has a real revenue-loss incident; when only the CS line moves, customers are absorbing the friction via alternate tender. The single most important card during a payment incident. | | | | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **The formula** | Two synchronised time series at 15-minute granularity over 24 hours: (1) CyberSource `decline_rate(15min)` from `/tss/v2/searches`, (2) commerce-platform `checkout_step_completion_rate(15min)` from the connected commerce sibling (Adobe Commerce, Shopify, BigCommerce, or Magento). Plotted on dual y-axes, time-aligned to UTC. | | **Why both signals matter** | A CS decline-rate spike alone could mean: (a) real revenue loss (customers can't pay, abandon), or (b) absorbed friction (customers retry on Apple Pay / PayPal / different card and the storefront completes anyway). The two scenarios have different ops responses; this card disambiguates. | | **What "moves together" looks like** | When both lines diverge from baseline by >2σ within the same 15-min window, the card flags the incident as "decline-driven revenue loss". When only the CS line moves, the card flags as "alternate-tender absorption". | | **Required connectors** | CyberSource AND a commerce-platform connector. Card grays out if no commerce sibling is connected (the formula needs `checkout_step_completion_rate`). | | **Currency** | n/a (rate-based, both lines are percentages). | | **Refunds / disputes** | Excluded. This card is about live authorisation outcomes vs live checkout completion; post-auth events live elsewhere. | | **Failed / declined payments** | These ARE the signal. This card is about understanding the cross-platform impact of declines. | | **Time window** | `24H`. The chart shows the most recent 24 hours at 15-min granularity (96 data points per series). | | **Refresh cadence** | Both series refresh every 60 seconds during an active incident; otherwise on the standard 5-15 min sync cycle. | | **Alert trigger** | Both conditions must fire: CS decline rate **+5pp above 1h baseline** AND commerce checkout completion **−5pp below 1h baseline** within the same 15-min window. | | **Roles** | owner, finance, marketing, on-call | ## Calculation Calculated automatically from your CyberSource 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 North American electronics retailer running CyberSource for ecommerce + Adobe Commerce for the storefront. On the morning of 09 Apr 26, an incident is in progress; the on-call payments lead opens this card at 10:15 UTC. The 24-hour view shows two series (rendered as a dual-axis line chart): | Time slot (UTC) | CS decline rate | Adobe checkout completion | Status | | --------------- | --------------------------- | ------------------------- | ------------------------ | | 00:00 - 09:30 | 4.8, 5.4% (baseline ±0.3pp) | 87, 89% (baseline) | Healthy | | 09:30 - 09:45 | 5.6% | 87.4% | Marginal noise | | 09:45 - 10:00 | **8.7%** | **84.2%** | **Both signals diverge** | | 10:00 - 10:15 | **11.4%** | **80.8%** | Spike sustained | ```text theme={null} Cross-platform correlation flagged at 09:48 UTC: CS decline rate : +6.0pp above 1h baseline (5.4% → 11.4%) Adobe checkout : −6.4pp below 1h baseline (87.2% → 80.8%) Window : 09:45-10:15 UTC (30 min sustained) Diagnosis : "Decline-driven revenue loss" (both signals moving together) Live revenue loss : ~$25,673 and counting (see cs_revenue_at_risk_live) ``` Five things worth noticing during the active incident: 1. **The two-line correlation is the diagnostic.** A CS decline spike alone is ambiguous, customers might be retrying on Apple Pay, PayPal, or a different card and the storefront completes anyway (no real revenue loss). The Adobe checkout-completion line dropping in lockstep tells the operator the customers are NOT absorbing the friction; they're abandoning. This is what makes this card uniquely valuable during incident response. 2. **Time-aligned to the minute.** Both series are pulled at 15-minute granularity in UTC, so the operator can see the exact moment the spike started (09:48 in this case) and correlate against any internal events: Decision Manager rule pack deploys, Adobe Commerce releases, third-party checkout-script updates. For this incident, the root cause was a Decision Manager rule pack deployed at 09:35 UTC that over-weighted AVS-mismatch on non-US issuers. 3. **The 30-minute sustained window prevents false alerts.** A single 15-min spike in either series can be noise (a small batch of high-risk customers, a brief Adobe Commerce slow-page event). The card requires both signals to diverge for ≥2 consecutive 15-min windows before flagging the incident, which prevents alarm fatigue. 4. **The card pairs with [Revenue at Risk (live)](/nerve-centre/kpi-cards/cybersource/revenue-at-risk) for the dollar quantification.** This card is the diagnostic chart; the live \$-at-risk card is the size-of-problem signal. Both cards drive the same incident response but answer different questions: "what's happening?" vs "how much is this costing per minute?" 5. **Resolution shows up the same way.** When the DM rule pack was rolled back at 10:38 UTC, both lines returned to baseline within 4 minutes. The card retroactively annotates the incident window for post-mortem documentation. Total revenue lost during the 56-minute incident was \~\$54,000 (per the Revenue at Risk card), which becomes the line item on the post-mortem and the case for tighter rule-pack deployment review. Compare this to the alternative pattern, "alternate-tender absorption". On a different day, a similar CS decline spike happened but the Adobe checkout-completion line didn't move, customers were retrying with Apple Pay (which doesn't route through CS) and the storefront completed normally. The card flagged as "alternate-tender absorption" rather than "revenue loss"; the operator confirmed via Adobe analytics and didn't escalate the same way. Same CS-side symptoms, very different revenue impact. ## Sibling cards merchants should reference together | Card | Why pair it with Decline Spike vs Checkout Funnel Drop | | ----------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | [Revenue at Risk (live)](/nerve-centre/kpi-cards/cybersource/revenue-at-risk) | The dollar quantification. This card shows the diagnostic; that card sizes the problem. | | [Decline Rate Spike Alert](/nerve-centre/kpi-cards/cybersource/decline-rate-spike-alert) | The alert that lights up when this card's correlation fires. | | [Decline Rate](/nerve-centre/kpi-cards/cybersource/decline-rate) | The base CS-side signal. | | [Top Decline Reasons](/nerve-centre/kpi-cards/cybersource/top-decline-reasons) | Diagnostic drilldown when the spike fires. | | [Top Declining Issuers](/nerve-centre/kpi-cards/cybersource/top-declining-issuers) | Single-issuer-outage diagnostic. | | [Decision Manager Score Mix](/nerve-centre/kpi-cards/cybersource/decision-manager-score-mix) | Was a recent fraud rule-pack deploy the cause? | | [Recoverable Revenue (decline-driven)](/nerve-centre/kpi-cards/cybersource/recoverable-revenue) | Post-incident: how much can be won back via dunning / retry? | | [3DS Friction Revenue Loss](/nerve-centre/kpi-cards/cybersource/3ds-friction-revenue-loss) | The 3DS-specific cross-platform loss view. | | Adobe Commerce / Shopify / BigCommerce checkout-funnel | The storefront pulse feeding the Y-axis-2 line. | ## Reconciling against the vendor's own dashboard **Where to look in CyberSource Business Center (EBC2):** This card has no direct EBC2 counterpart, it's a Vortex IQ cross-platform join between CS decline data and the commerce-platform checkout-funnel pulse. Operators investigating the CS-side line on this card should cross-reference: * [EBC2 → Transactions → Search](https://ebc2.cybersource.com/ebc2/app/Transactions/transactions) for last-15-min decline confirmation. * [EBC2 → Decisions → Decision Manager → Performance](https://ebc2.cybersource.com/ebc2/app/RiskManagement/DecisionManager), was a rule pack recently deployed? * The connected commerce platform's analytics for the checkout-funnel side (Adobe Analytics, Shopify Analytics, BigCommerce Analytics). **Why our number may legitimately differ from a hand-rolled equivalent:** | Reason | Direction | What to do | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------- | ------------------------------------------------------------------------------------------------- | | **15-min granularity**. We aggregate to 15-min buckets to reduce noise. Smaller windows would be noisier but faster to detect. | Spike-detection lag of up to 15 min. | Trade-off; operator sees the spike on the live alert before the 15-min bucket fully materialises. | | **CS side uses `submitTimeUtc`; commerce side may use checkout-step-recorded-at.** | Tiny sub-minute drift between the two series. | Negligible at 15-min granularity. | | **Multi-currency commerce platform**. If the merchant runs multi-currency on the storefront, the checkout-completion-rate is currency-neutral (success ÷ attempts) so the cross-platform correlation is valid. | n/a (no currency mismatch). | n/a. | | **Refresh lag**. Both connectors refresh on independent cycles; tightest refresh during an active incident is 60 seconds, otherwise 5-15 min. | Both series can be slightly stale. | The card grays partially if either side hasn't refreshed in >5 min. | **Cross-connector reconciliation:** | Comparison | Expected relationship | When divergence is legitimate | | ------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ | | `cs_xc_decline_vs_funnel` ↔ [`cs_revenue_at_risk_live`](/nerve-centre/kpi-cards/cybersource/revenue-at-risk) | This card is the diagnostic chart; the other is the dollar quantification. They co-fire. | n/a (causal). | | `cs_xc_decline_vs_funnel` ↔ commerce-platform checkout-funnel-step alert | The funnel-side signal in this card is sourced from the same data; they should agree exactly within the 15-min bucket. | Discrepancy = data-pipeline issue, escalate. | | `cs_xc_decline_vs_funnel` ↔ [`cs_xc_recoverable_revenue`](/nerve-centre/kpi-cards/cybersource/recoverable-revenue) | This card flags incidents in real-time; that card aggregates post-incident revenue recovery potential. | Different time horizons; both can fire on the same incident. | ***
Documentation cross-reference (for incident-response teams) This card is unique to CyberSource within Vortex IQ Nerve Centre because the cross-platform join requires fresh CS decline-rate data joined to a commerce-platform checkout pulse. Stripe and PayPal don't have direct equivalents because their incident-response model differs (Stripe's volume profile is more SMB; PayPal's checkout flow is partially decoupled from the merchant's storefront). For multi-acquirer enterprises, this remains the canonical "is the spike costing me revenue" view.
## Known limitations / merchant FAQs **Why does the card need both CS and a commerce-platform connector?** The diagnostic value is the correlation. CS-side decline data alone tells you "declines are spiking" but not "is this costing revenue." The commerce-side checkout-completion data alone tells you "checkout completion dropped" but not "is the cause payment-side or storefront-side." The two signals together identify true cross-platform revenue-loss incidents. **What if my CS decline rate spikes but the storefront checkout-completion doesn't move?** Three possible interpretations: (1) **Alternate-tender absorption**, customers retry on Apple Pay / PayPal / Google Pay / different card and complete via a non-CS payment path; storefront completion stays normal. (2) **Issuer-specific outage** affecting only a small share of attempts; the overall storefront completion barely registers it. (3) **Latency-masked failure**, the customer sees the decline but stays on the page hoping it'll clear; the funnel doesn't yet log them as abandoned. The card flags as "alternate-tender absorption" by default for case (1); operator can manually re-classify for cases (2) and (3) using the issuer drilldown and customer-side timing. **What if the storefront checkout completion drops but CS decline rate doesn't move?** Then the cause is storefront-side, NOT payment-side. Common causes: a frontend JavaScript error breaking the cart, an Adobe Commerce / Shopify outage, a third-party checkout-script (Klarna, Afterpay) misbehaving, a CDN / DNS issue. Open the storefront's own observability tools; CS is not the cause and don't waste payments-ops effort on it. **Why 15-minute granularity instead of 1-minute?** Trade-off between noise and detection latency. At 1-minute granularity each bucket has only \~3-4% of an hour's transactions, which is too small to detect a +5pp spike against baseline noise. At 15-min granularity each bucket has enough volume for stable rates. Real-time alerting still happens via [Decline Rate Spike Alert](/nerve-centre/kpi-cards/cybersource/decline-rate-spike-alert) which runs at 1-min granularity for spike detection, with this card providing the visual diagnostic at 15-min granularity. **The card flagged but my ops team thinks it's a false positive. How do I confirm?** Three diagnostic checks: (1) cross-reference [Top Decline Reasons](/nerve-centre/kpi-cards/cybersource/top-decline-reasons), does any reason bucket also spike? Real incidents always show a single dominant reason driving the spike. (2) cross-reference [Top Declining Issuers](/nerve-centre/kpi-cards/cybersource/top-declining-issuers), is the spike concentrated on one issuer (real outage) or spread across all (real merchant-side cause)? (3) cross-reference deploy logs, was a Decision Manager rule pack, an Adobe Commerce release, or a third-party script update deployed within the prior 30 minutes? If all three signals are flat, the alert is most likely real-but-resolvable (e.g. a brief issuer slowdown). **My multi-currency global merchant, does the cross-platform join work across currencies?** Yes. Both signals are rate-based (decline rate, completion rate) so currency-neutral. The card aggregates across currencies for the global view; the drilldown can split by region / currency if the merchant configures it. **Can this card fire during a planned maintenance event?** Yes, it doesn't know about planned events. If ops knows a Decision Manager rule pack deployment is planned (with expected decline-rate impact), suppress the alert manually or schedule the rule pack outside peak hours. Vortex IQ doesn't currently have a "maintenance window suppression" feature for this card; could be added. **How fast does the resolution show up?** Both lines return to baseline within 1-2 minutes once the underlying issue resolves (e.g. DM rule pack rollback). The card retroactively annotates the incident window so the post-mortem documentation has clean start / end timestamps. **Does this card work for non-PSD2 merchants?** Yes. The card is independent of regulatory regime; it's about the cross-platform correlation between processor-side declines and storefront-side completions. PSD2 merchants will tend to see more 3DS-related incidents (where [3DS Friction Revenue Loss](/nerve-centre/kpi-cards/cybersource/3ds-friction-revenue-loss) is the more specific card); non-PSD2 merchants see more issuer-side and DM-rule-side incidents. *** ### Tracked live in Vortex IQ Nerve Centre *Decline Spike vs Checkout Funnel Drop* is one of hundreds of KPI pulses Vortex IQ tracks across CyberSource and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.