Shopify Subscription Monitoring: The Complete Guide
Shopify subscription monitoring is the practice of continuously detecting billing failures, payment state mismatches, and revenue gaps across your subscription stack — Recharge, Stripe, and Shopify — before they result in permanent revenue loss. If you sell subscription boxes or replenishment products on Shopify with Recharge managing subscription contracts and Stripe processing payments, you are operating across three systems that each track billing state independently. When any layer fails, the other two may never learn about it. Three failure classes account for most revenue loss: webhook delivery failures (payment collected but no order created), cross-stack state mismatches (subscription ACTIVE in Recharge but TERMINATED in Shopify), and ghost subscriptions (product fulfilling with zero revenue collected). Merchants in the $20K–$50K MRR range typically lose 10–20% of subscription revenue to silent failures they never detect. A daily reconciliation job surfaces every silent failure within 24 hours. This guide explains the root causes, how to detect them, and how to configure monitoring that catches every failure before it costs you money.
What causes silent Shopify subscription failures?
Silent failures happen because Shopify, Recharge, and Stripe each manage a different layer of the subscription lifecycle without a shared failure state. When a Stripe payment fails, Stripe fires a webhook to Recharge. Recharge updates its internal state and fires a webhook to Shopify. If any webhook in this chain fails to deliver — due to a timeout, HTTP error, or missed event — the downstream system never learns about the failure.
The result is a cross-stack state mismatch: Stripe shows a failed payment, Recharge may show the subscription as ACTIVE, and Shopify may show no billing attempt at all. No alert fires in any dashboard because each system believes it has correctly communicated the state change. The merchant sees revenue missing with no explanation.
What are the most expensive silent failure patterns?
Ghost subscriptions are the most costly pattern: Recharge shows a subscription as ACTIVE and continues trying to bill, but the Shopify subscription contract is TERMINATED or the billing errorCode is PAYMENT_PROVIDER_IS_NOT_ENABLED on every attempt. The merchant fulfills product every month while collecting zero revenue — sometimes for 3–6 billing cycles before it is discovered.
Webhook delivery failures are the second most expensive pattern. When Stripe fires payment_intent.succeeded but the Shopify order creation webhook times out, revenue is collected but no order is created and no product ships. The customer experiences this as the merchant taking money without delivering — the worst possible outcome for retention. Detecting this requires a daily reconciliation of Stripe successful charges against Shopify orders created.
How do you detect subscription monitoring gaps in your stack?
The fastest diagnostic is to compare your Stripe successful charges against Shopify orders created in the same 24-hour period. Any Stripe charge with no matching Shopify order is either a ghost subscription (billing without order creation) or a webhook delivery failure. Run this comparison daily — most merchants who run it for the first time find at least one mismatch per week.
For state mismatches, compare Recharge subscription statuses against Shopify subscription contract statuses daily. Any Recharge subscription showing ACTIVE where the Shopify contract shows TERMINATED, PAUSED, or has an errorCode on the most recent billing attempt is a mismatch requiring immediate investigation. Tools like AltorLab automate this cross-stack comparison without requiring custom engineering.
How should dunning be configured to minimize involuntary churn?
Dunning configuration is the highest-leverage subscription monitoring investment. Most merchants use a uniform retry cadence — retry on day 1, day 3, day 7 — regardless of the decline code. This approach is expensive: INSUFFICIENT_FUNDS retried on day 1 after payday has already passed almost always fails. AUTHENTICATION_REQUIRED retried at all is wrong — it requires the customer to complete 3DS authentication, not a retry.
Best-practice dunning segments retry timing by decline type: INSUFFICIENT_FUNDS retries on day 3 and day 7 to align with typical payday cycles. CARD_DECLINED retries on day 2 and day 5. AUTHENTICATION_REQUIRED fires an immediate customer notification with the 3DS URL — no retries. PAYMENT_METHOD_REVOKED and LOST_CARD or STOLEN_CARD skip all retries and immediately request a new payment method. This differentiated approach recovers 30–40% of initially failed payments versus 15–20% for uniform retry schedules.
What webhook events should every Shopify subscription merchant monitor?
The minimum webhook monitoring set for subscription merchants: subscriptions/billing_attempt_failure (fires on every failed billing attempt — the primary signal), subscriptions/billing_attempt_success (confirms successful billing — should always be paired with an order creation), orders/create (confirms Shopify order creation — reconcile against billing_attempt_success events), and charge/max_retries_reached (Recharge-specific — fires when dunning exhaustion cancels the subscription).
The most missed webhook is charge/max_retries_reached from Recharge. When Recharge cancels a subscription after exhausted dunning, it fires this webhook but does not automatically update the Shopify subscription contract. Without handling this event, merchants end up with subscriptions cancelled in Recharge but still showing ACTIVE in Shopify — a ghost subscription that continues fulfillment with no billing.
How do you set up a reconciliation job for subscription monitoring?
A reconciliation job runs on a schedule — daily at minimum, hourly for high-volume merchants — and compares the state of subscriptions across all systems. The minimum reconciliation checks: (1) Stripe charges in the past 24 hours vs Shopify orders created in the same period, (2) Recharge subscription statuses vs Shopify subscription contract statuses, (3) Recharge billing attempts vs Stripe PaymentIntent statuses for the same subscription ID.
Implementing a full reconciliation job requires connecting to three APIs: Stripe API (charges, payment intents), Recharge API (subscriptions, charges), and Shopify Admin API (subscription contracts, orders). The engineering investment is 2–3 days for an experienced developer. The alternative is using a monitoring tool like AltorLab that runs this reconciliation automatically and alerts on mismatches without custom engineering.
Frequently asked questions
What causes silent subscription failures in Shopify?
Silent failures occur when a payment fails in one layer of the subscription stack (Stripe, Recharge, or Shopify) but the failure state does not propagate to all connected systems. This happens through webhook delivery failures, API timeouts, or state machine mismatches between systems. The merchant sees revenue missing with no corresponding alert or error in any dashboard.
How much revenue do Shopify merchants lose to unmonitored subscription failures?
Merchants in the $20K–$50K MRR range typically lose 10–20% of subscription revenue to silent failures. A $30K MRR merchant who is not monitoring for cross-stack state mismatches may be losing $3,000–$6,000 per month in revenue that appears as normal churn in their analytics but is actually recoverable through proper monitoring and dunning configuration.
How do I know if I have ghost subscriptions in my Shopify store?
Run a cross-stack comparison: export all Recharge subscriptions with ACTIVE status, then query Shopify's subscriptionContracts API for the corresponding contract IDs and their status. Any contract showing TERMINATED or PAUSED in Shopify while Recharge shows ACTIVE is a ghost subscription. Also compare Recharge charge statuses against Shopify order creation events for the same customer and date.
How do I configure dunning correctly in Recharge?
In Recharge Admin, go to Settings > Dunning and configure retry timing by decline type rather than using uniform retries. Set INSUFFICIENT_FUNDS to retry at day 3 and day 7. Set authentication failures (AUTHENTICATION_REQUIRED, requires_action) to skip retries and trigger immediate customer notification with the 3DS URL. Set PAYMENT_METHOD_REVOKED and card-blocked declines (LOST_CARD, STOLEN_CARD) to skip all retries and trigger an immediate payment update email.