Skip to main content
Metrics type: Cross-Platform Metrics • 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.

​
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):
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

​
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: Why our number may legitimately differ from a hand-rolled equivalent: Cross-connector reconciliation:

​
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 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-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 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.