All use cases

Collect / Recover

Failed-payment recovery for ecommerce subscriptions and orders

The card on your subscribe-and-save order just failed overnight. Before the shipment is cancelled, the agent has found the cause, prepared the fix, and opened the conversation.

Get aheadClose the loopNext best thingSystem triggerRisk triggerChatPushEmailWhatsAppE-commerce & Retail

What it does

In ecommerce a failed payment isn't just a frozen account — it's a shipment that won't go out and a replenishment habit about to break. A subscribe-and-save box silently skips, a stored-card reorder fails at renewal, a retail installment misses, and the shopper rarely finds out until the product they expected never arrives. Failed payments drive a large share of subscription churn, and a well-run recovery flow reclaims up to half of what would otherwise be lost. The agent treats a failed charge as the start of a conversation it opens itself: cause already diagnosed, fix already prepared, and the fulfillment held rather than cancelled while the shopper sorts the card out.

How it works

  1. 1
    Trigger. a payment_failed event arrives from the payment provider or commerce platform on a subscribe-and-save order, a stored-card reorder, or an installment plan, with the decline code and the affected order or subscription attached.
  2. 2
    Decision. the agent diagnoses the cause (expired card, insufficient funds, gateway decline), checks the order's fulfillment window and the shopper's memory, history, and channel consent, and decides whether the shipment can be held while the card is fixed. The quality judge gates the message before it goes out.
  3. 3
    Action. it opens already knowing the cause and the fix, on the shopper's preferred channel, and sends them to the payment provider's secure card-update page; card details never pass through the conversation. Any retry or re-charge runs under a money-moving policy class that requires the shopper's explicit confirmation first.
  4. 4
    Follow-through. once the shopper confirms, the retry runs through the commerce platform, the agent releases the held order back into fulfillment and confirms the dispatch in the same thread, writing the outcome back to the order and customer record. If the shopper fixes the card on their own first, the queued outreach is cancelled. An order still unpaid after one judged follow-up escalates before the fulfillment window closes.
Example
AgentHeads-up on your monthly coffee subscription — this month's payment didn't go through, and it looks like the card on file expired. I've held your box so it doesn't skip. Here's a secure link to update the card, and I can retry the charge once you give me the go-ahead.
CustomerUpdated, go ahead.
AgentRetried and it went through. Your box is back in dispatch and ships today, so you won't miss this month. Nothing else needed from you.

Configuration

How the agent is wired for this use case.

Triggera payment_failed webhook from the payment provider or commerce platform on a subscribe-and-save renewal, stored-card reorder, or installment, carrying the decline code and the affected order / subscription ID.
Tools & actions
  • Commerce / order management platform · read the order and subscription state and fulfillment window; hold the shipment, then release it once the payment clears.
  • Payment provider · diagnose the decline code; hand off to the secure hosted card-update page and run the retry after explicit confirmation (the agent never touches card data).
  • Subscription billing · re-bill the subscribe-and-save or installment cycle and write back the recovered status.
  • Messaging channel · open the recovery conversation on the shopper's preferred channel and confirm dispatch.
  • CRM / customer record · log the contact and the recovered outcome.
Autonomydiagnosis, the shipment hold, and outreach run unattended under judge gating; the retry / re-charge is a money-moving policy class requiring the shopper's explicit confirmation, and the payment itself completes only on the provider's secure hosted step.
Channelschat · push · email · whatsapp
Escalationan order still unpaid as the fulfillment window closes, a disputed charge, or a repeatedly failing method hands off to a human support agent.

What you need

The inputs this use case runs on. Your channels stay yours; the agent supplies the judgment.

Signals

payment_failed events on subscriptions, reorders, and installments; decline reason codes; the order's fulfillment / cutoff window; shopper self-fix events (for cancellation).

Data

order and subscription state, fulfillment status, payment and decline history, customer memory, channel consent.

Guardrails

money-moving policy class with explicit shopper confirmation; secure payment hand-off only, no card data in the conversation; judge gating on every unprompted message; frequency caps; stale-outreach cancellation when the shopper self-resolves; the shipment hold respects the order's real cutoff so nothing is promised that can't ship.

Metrics it moves

  • involuntary-churndown: the failed renewal is repaired before the subscribe-and-save lapses, so a replenishment relationship isn't lost over a card glitch.
  • recovered-revenueup: each repaired payment is revenue already earned and an order saved from cancellation; recovery flows in this category reclaim up to half of what would otherwise be lost.
  • save-rateup: opening with the cause, the fix, and a held shipment converts far better than a silent skip or a generic dunning email.

Related use cases

Collect / Recover

Failed-payment instant recovery

the subscription and fintech parent of this recovery pattern

Retain / Save

Missed-refill and replenishment outreach

keeping the replenishment habit alive when the cause is behavioral, not a payment

Collect / Recover

Pre-dunning card update

the upstream reminder that updates the card before the order's charge fails

See it on your own customer journey

Bring one drop-off, one churn cliff, or one silent segment. We will show you what a proactive agent with memory and judgment does with it.

Book a demo