Count of support conversations opened by shoppers whose payment was refused at the gateway in the last 7 days — the support tail of a checkout problem.
At a glance
Support Spike on Failed Payments is a cross-channel revenue-at-risk metric that joins your Intercom support inbox to your Adyen payment gateway. It counts conversations opened by people whose card was refused at checkout, so you can see when a payment outage or a fraud-rule misfire is generating support load. When this number climbs, you are not just losing the sale at the gateway — you are paying agents to mop up the confusion, and the shopper is forming an opinion about Blitz. The card only renders when an Adyen (or equivalent payment-gateway) sibling connector is connected; it has no meaning on Intercom alone.
| What it counts | The number of distinct Intercom conversations created in the window whose contact matches an Adyen shopperReference that had a refused authorisation in the same window. One conversation per refused-payment shopper; the card also surfaces the linked conversation list so you can open them. |
| Sample type | Derived. Intercom conversations (with contacts) intersected with Adyen refusal events on shopperReference / contact email. Refreshed on the standard data refresh. |
| Why it matters | A failed payment is a sale already at risk; a failed payment that also generates a support ticket means the shopper is confused, frustrated, and waiting. A rising count is an early warning of a gateway misconfiguration, a 3-D Secure friction problem, or an over-tight fraud rule — issues a support lead would otherwise only spot anecdotally. |
| Reading the value | Any value above zero deserves a look; a sudden jump versus the prior 7 days points at a systemic checkout fault rather than scattered individual declines. Open the linked conversations to see what shoppers are actually saying (card declined, “tried three times”, “is my order placed?”). |
| Currency | number |
| Time window | 7D |
| Alert trigger | >0 conversations from shoppers with refused payments |
| Sentiment key | — |
| Roles | owner, operations, finance |
Calculation
The card resolves Adyen authorisation events with aRefused (or otherwise declined) result code over the trailing 7 days, collects the shopperReference and email on each, and intersects that set with the contacts on Intercom conversations created in the same window. The headline number is the count of matched conversations; the underlying table links each one to its Intercom thread and to the refused payment that triggered the join. The only_when gate means the card stays hidden unless a payment-gateway sibling (Adyen) is connected, because the join has nothing to resolve against otherwise.
Worked example
A representative reading of Support Spike on Failed Payments for Blitz, the sports retailer. On a normal week the card sits at 1-2 conversations — the occasional genuinely declined card. On Tuesday it reads 14. The support lead opens the linked conversations and sees a pattern: every one is a customer on a high-value basket (football boots, club kit bundles) saying their Visa was declined despite “plenty of funds”. Cross-referencing the Adyen refusal reason on the joined records showsRefused with a 3-D Secure step that was timing out on mobile. That is not 14 unlucky shoppers — it is a checkout fault costing Blitz the sale and the agent time. The founder escalates to the payments team; the support lead drafts a saved reply pointing affected shoppers to an alternative payment method. Without the join, the inbox would have looked like 14 unrelated “card declined” tickets. To trace the gateway side, jump to the Adyen refusal-rate sibling; for natural-language exploration, ask Ask Viq “show me failed-payment support tickets this week”.
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
ic_xc_high_value_waiting | Cross-channel sibling: are any of these refused-payment shoppers also high-LTV customers breaching SLA right now? |
ic_xc_support_load_per_100_orders | Cross-channel sibling: a payment spike inflates contacts-per-100-orders — confirm the macro signal. |
ic_new_today | Executive sibling: is the failed-payment cohort big enough to move total new conversations today? |
ic_top_tags | Conversation Intelligence sibling: confirm “payment” / “checkout” tags are climbing in the topic mix. |
ic_alert_volume_spike | Alerts sibling: a failed-payment event often shows first as a raw volume spike. |
Reconciling against the vendor’s own dashboard
Where to look in Intercom’s own dashboard: Intercom alone cannot produce this number — it has no view of Adyen refusals. The closest native equivalent is the Inbox filtered to conversations taggedpayment or checkout (Reports → Conversations, or a saved Inbox view on those tags), but that depends on agents tagging accurately and will not isolate the shoppers whose card actually failed at the gateway. To inspect a single matched conversation, open it from the linked list and use Intercom’s conversation view; the contact’s email is the join key back to Adyen.
Why the Vortex IQ value may legitimately differ:
| Reason | Direction | What to do |
|---|---|---|
Join coverage. A shopper who contacted you from a different email than the one on the Adyen shopperReference will not match. | Vortex IQ lower | Confirm contact email hygiene; guest checkouts are the usual gap. |
Tag reliance in Intercom. Intercom’s tag-filtered view counts anything an agent tagged payment, including pricing questions with no refusal. | Intercom higher | Use the Vortex IQ join, which is anchored on actual gateway refusals. |
| Window boundary. Vortex IQ uses a rolling 7-day window; an Intercom saved view may use calendar dates or a different range. | Variable | Match the date range before comparing. |
Known limitations / merchant FAQs
Q: How often does Support Spike on Failed Payments update? The card refreshes on the standard data refresh (typically every 30-60 minutes for live integrations). For a real-time read during an incident, force a manual refresh from the dashboard. Q: Why does this card show nothing even though I have payment declines? The card is gated byonly_when: it only renders when a payment-gateway sibling (Adyen) is connected. With Intercom alone there is no refusal data to join against, so the card stays hidden.
Q: Why does my Intercom inbox show more “payment” tickets than this card?
Intercom’s tag view counts every conversation an agent labelled payment, including pricing and refund questions. This card counts only conversations from shoppers whose card was actually refused at the gateway in the window — a tighter, revenue-anchored set.
Q: Can I customise the alert threshold?
Yes. The default alert fires above zero, but sensitivity is configurable per profile in the Sensitivity tab — raise it if a low baseline of genuine declines is normal for Blitz.