Skip to main content
Card class: Cross-Channel • Category: Payment Gateway
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 formulaTwo 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 matterA 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 likeWhen 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 connectorsCyberSource AND a commerce-platform connector. Card grays out if no commerce sibling is connected (the formula needs checkout_step_completion_rate).
Currencyn/a (rate-based, both lines are percentages).
Refunds / disputesExcluded. This card is about live authorisation outcomes vs live checkout completion; post-auth events live elsewhere.
Failed / declined paymentsThese ARE the signal. This card is about understanding the cross-platform impact of declines.
Time window24H. The chart shows the most recent 24 hours at 15-min granularity (96 data points per series).
Refresh cadenceBoth series refresh every 60 seconds during an active incident; otherwise on the standard 5-15 min sync cycle.
Alert triggerBoth conditions must fire: CS decline rate +5pp above 1h baseline AND commerce checkout completion −5pp below 1h baseline within the same 15-min window.
Rolesowner, 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 rateAdobe checkout completionStatus
00:00 - 09:304.8, 5.4% (baseline ±0.3pp)87, 89% (baseline)Healthy
09:30 - 09:455.6%87.4%Marginal noise
09:45 - 10:008.7%84.2%Both signals diverge
10:00 - 10:1511.4%80.8%Spike sustained
Cross-channel 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) 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

CardWhy pair it with Decline Spike vs Checkout Funnel Drop
Revenue at Risk (live)The dollar quantification. This card shows the diagnostic; that card sizes the problem.
Decline Rate Spike AlertThe alert that lights up when this card’s correlation fires.
Decline RateThe base CS-side signal.
Top Decline ReasonsDiagnostic drilldown when the spike fires.
Top Declining IssuersSingle-issuer-outage diagnostic.
Decision Manager Score MixWas a recent fraud rule-pack deploy the cause?
Recoverable Revenue (decline-driven)Post-incident: how much can be won back via dunning / retry?
3DS Friction Revenue LossThe 3DS-specific cross-channel loss view.
Adobe Commerce / Shopify / BigCommerce checkout-funnelThe 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-channel join between CS decline data and the commerce-platform checkout-funnel pulse. Operators investigating the CS-side line on this card should cross-reference: Why our number may legitimately differ from a hand-rolled equivalent:
ReasonDirectionWhat 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-channel 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:
ComparisonExpected relationshipWhen divergence is legitimate
cs_xc_decline_vs_funnel ↔ cs_revenue_at_risk_liveThis 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 alertThe 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_revenueThis card flags incidents in real-time; that card aggregates post-incident revenue recovery potential.Different time horizons; both can fire on the same incident.

​
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-channel 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 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, does any reason bucket also spike? Real incidents always show a single dominant reason driving the spike. (2) cross-reference 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-channel 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-channel correlation between processor-side declines and storefront-side completions. PSD2 merchants will tend to see more 3DS-related incidents (where 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 or book a demo to see this metric running on your own data.