# MRRdue — full content

Failed-payment recovery and involuntary-churn monitoring for subscription SaaS
businesses on Stripe or Dodo Payments.

Site: https://www.mrrdue.com
Support: support@mrrdue.com
Content last revised: 2026-10-22

This file contains the substantive content of the public site as plain text, for
AI crawlers and answer engines. It is generated from the same source the pages
render from.
---
## What MRRdue is

MRRdue connects to a Stripe or Dodo Payments account with a read-only key, imports the
subscription and invoice history, and turns failed payments into a ranked list
of customers who need a human today. For each case it explains what failed, what
the provider will do on its own, and what the operator should do now — with a
drafted recovery email ready to send.

What it does not do: it never charges a card, retries a payment, changes a
subscription, or cancels anything in the connected billing account. At
connection time it sends a write-shaped request to three record IDs that cannot
exist (one customer, one invoice, one subscription) and reports whether the key
was able to write. That establishes the key cannot write those three resources;
it is not a survey of every resource in the account, and MRRdue says so.

MRRdue can email an end customer on the workspace's behalf. That is off by
default and gated twice: the workspace must enable managed sending, and
automatic sending is a separate opt-in on top of it.
---
## The problem: involuntary churn

Not every customer who leaves a subscription meant to. Cards expire, banks
decline renewals, and a payment fails quietly. The billing provider records the
failure and retries on its own schedule, but it does not tell the business which
of those customers to chase first or what to say to them. If nobody acts, the
subscription is cancelled when the retries run out. That is involuntary churn:
revenue lost to a payment problem rather than a decision to leave.

MRRdue is built for founders and small teams running one billing account who do
not have a revenue-operations person and want to know which failed payments need
a human today.
---
## How it works

1. Connect read-only. Paste a Stripe restricted key or a Dodo Payments API key.
   Full Stripe secret keys are rejected outright, and the write-access probe
   described above runs at connection time.
2. MRRdue imports subscription and invoice history and turns every failed
   payment into a case, ranked by the revenue at risk, with the failure reason
   and what the provider will do on its own. New failures arrive through the
   provider's events, backed up by a scheduled check that catches anything
   delayed or missed. Alerts go out by email or Slack.
3. Each case comes with a recovery email written for that failure reason and a
   payment link. Templates: https://www.mrrdue.com/templates/recovery-emails
4. A person decides what goes out: send it yourself, hand the case to Slack, a
   signed webhook, n8n, Zapier or Make, or switch on MRRdue's managed sender.
   Sending is off by default.

Webhook Doctor watches Stripe webhook delivery and alerts when a signing secret
broke after a redeploy, an endpoint is returning errors, or events were
received but never processed — failures that otherwise silently make revenue
numbers wrong. It is included on every plan.

Try the full flow on sample data, with no signup: https://www.mrrdue.com/demo
---
## Pricing

One plan, Pro: $29 per month or $290 per
year (about two months free). Every feature is included; there is no per-seat
charge and no percentage of recovered revenue.

Everything MRRdue ships today for one provider account. Best for: founders and operators monitoring one billing account.

Included:
- Failed-payment recovery queue with risk scoring
- Ready-to-send recovery emails & payment links
- MRR, churn & retention-risk signals
- Webhook Doctor broken-webhook alerts
- Email, Slack alerts & daily summaries
- Automatic outreach handoff to your systems
- Outbound event webhooks & live read-only REST API
- CSV/JSON recovery exports
- Up to $100K tracked MRR · 24-month history

- 14-day trial, no card required. The trial starts when a
  billing provider is first connected, not at signup.
- Cancelling keeps access until the end of the paid period, and a scheduled
  cancellation can be resumed from Settings → Billing.
- After a trial or subscription ends, synced data is kept for
  30 days so you can pick up where you left off.
- MRRdue's own subscription is billed through Dodo Payments; the provider
  account you connect for monitoring stays separate and read-only.

Pricing page: https://www.mrrdue.com/pricing
---
## MCP server (Claude, ChatGPT, Cursor)

MRRdue ships a native Model Context Protocol server, so an AI assistant can
answer questions about a workspace's metrics, at-risk customers and recovery
queue in plain language.

- Server URL: https://www.mrrdue.com/api/mcp (Streamable HTTP)
- Auth: OAuth 2.1 (authorization code with PKCE S256, dynamic client
  registration) for ChatGPT and Claude.ai; an MRRdue API token created in
  Dashboard → Settings → Developer API for Cursor, Claude Code and Claude
  Desktop. OAuth tokens are read-only; API tokens can also draft campaigns.
- Plan: included on the paid plan at no extra cost. Rate limit shared with the
  REST API: 300 requests/hour/workspace.
- Tools include get_metrics, who_needs_attention, list_at_risk_customers,
  list_cases, get_case, get_recovery_email, find_customer, customer_health,
  compare_months, forecast_mrr, analyze_revenue, bulk_preview, execute_batch,
  cancel_campaign and list_campaigns.
- Approval gate: bulk_preview drafts up to 50 recovery emails into a campaign
  that waits for approval. Only a person signed into the dashboard can approve
  it; no assistant can approve its own campaign, and execute_batch rejects an
  unapproved one. Nothing an assistant does can touch the billing account.

Setup per client: https://www.mrrdue.com/docs/mcp
Agent-oriented summary: https://www.mrrdue.com/agents.txt
---
## Principles

- Read-only by design: no card charges, payment retries, refunds, subscription
  changes or cancellations in the connected billing account.
- No card or bank data: MRRdue does not ask for or store card numbers, CVCs or
  full bank account numbers. Provider keys are encrypted at rest and used only
  on the server.
- You decide what gets sent: customer email is off by default, automatic
  sending is a second, separate opt-in, and AI assistants can draft a campaign
  but only a signed-in person can approve it.
- No invented numbers: every figure comes from the workspace's own billing data.
---
## FAQ

**What does MRRdue do?**
It reads your billing data, finds the payments that failed, and ranks them by
how much revenue is at risk. For each one it tells you who the customer is, why
the payment failed, and what to send. You decide what actually goes out.

**Which billing providers does MRRdue support?**
Stripe and Dodo Payments. One provider per workspace.

**Does MRRdue have access to my money?**
No. It can read billing records and nothing else. It cannot charge customers,
change or cancel subscriptions, issue refunds, or move funds.

**Does MRRdue contact my customers automatically?**
Not unless you turn it on. By default it drafts the email and payment link and
leaves them in the dashboard. Managed sending is an opt-in, and automatic
sending is a second, separate opt-in.

**When does the trial start?**
The 14-day trial starts when you first successfully connect
Stripe or Dodo Payments, not at signup. No card is required.

**How much does it cost?**
One plan: $29 per month or $290 per year, every feature included.
Details: https://www.mrrdue.com/pricing

**Can I use it from ChatGPT, Claude or Cursor?**
Yes, through the MCP server. Assistants can read and draft; only a human can
approve a send. Setup: https://www.mrrdue.com/docs/mcp

**What happens after the trial ends?**
The dashboard pauses until you upgrade. Synced data is kept for a limited
period so you can pick up where you left off.

**Does MRRdue replace my billing provider?**
No. Stripe or Dodo Payments stays your billing system; MRRdue is the layer that turns
its data into recovery decisions.
---
## Company

MRRdue is operated by Akash Yadav, a sole proprietor registered in Balrampur, Uttar Pradesh, India. Bootstrapped, no outside investment.
Founder: Akash Yadav — X @akashyadav_dev (https://x.com/akashyadav_dev)
Support and all enquiries: support@mrrdue.com

- About: https://www.mrrdue.com/about
- Contact: https://www.mrrdue.com/contact
- Security and data access: https://www.mrrdue.com/security
- Privacy policy: https://www.mrrdue.com/privacy
- Terms of service: https://www.mrrdue.com/terms
---
## Stripe decline codes

### insufficient_funds — Insufficient funds

URL: https://www.mrrdue.com/guides/failed-payments/insufficient_funds

**What it means.** The card is valid and active, but the account behind it did not have enough balance (or available credit) at the moment Stripe attempted the charge. Nothing is wrong with the card itself, the timing was.

**Why it happens.**
- The charge landed just before payday or between account top-ups.
- A prepaid or debit card is used for subscriptions and runs dry.
- The customer's bank holds a temporary block that reads as insufficient balance.

**What Stripe does on its own.** Stripe retries these automatically, and its retry timing is genuinely good at catching the account after a deposit. If the invoice shows a next_payment_attempt in the future, the machine is still working.

**How to recover it.**
1. Wait out Stripe's scheduled retry first. Emailing before a retry that would have succeeded anyway costs goodwill for nothing. MRRdue's queue times its nudges after next_payment_attempt for exactly this reason.
2. If the retry fails (or there is none scheduled), send a short, friendly note with the Stripe-hosted invoice link so the customer can pay the moment their balance allows.
3. For high-MRR accounts, escalate to a personal note from the founder after 3 to 4 days unpaid. This is the segment where a human touch visibly beats automation.
4. Mark the case as contacted so recovery attribution can tell you whether outreach is what closed it.

**How recoverable it is.** Highest recovery rate of all decline reasons. The customer usually wants to keep paying and just needs the charge to land at the right time.

**Bank decline codes commonly seen alongside it** (quoted from Stripe's network-code reference; the same number differs by network and Stripe publishes no strict one-to-one mapping):
- 51 (Visa): Not sufficient funds.
- 51 (Mastercard): Insufficient funds / over credit limit.
- 51 (JCB International): Not sufficient funds.
- 116 (American Express): Not sufficient funds.
- 61 (Visa): Exceeds approval amount limit.
- 65 (Visa): Exceeds withdrawal frequency limit.

### expired_card — Card expired

URL: https://www.mrrdue.com/guides/failed-payments/expired_card

**What it means.** The card on file passed its expiry date. Every future charge will fail identically until the customer stores a new card. Retries cannot fix this one.

**Why it happens.**
- The bank reissued the card and the customer never updated subscriptions.
- Card networks' automatic updates (which Stripe uses where available) did not cover this card or issuer.
- The customer forgot which services were attached to the old card.

**What Stripe does on its own.** Stripe's card-account-updater catches many reissued cards automatically, but when a charge still fails with expired_card, the updater did not have new details. Retries against an expired card are pointless. Action has to come from the customer.

**How to recover it.**
1. Email immediately. There is no retry worth waiting for. Include the Stripe-hosted invoice link, which lets the customer pay and update the card in one step.
2. Be specific in the subject line ("your card ending 4242 has expired"). Vague billing emails get ignored; specific ones read as legitimate.
3. Follow up once after 3-4 days if unpaid; expired-card cases decay quickly once the customer's attention moves on.
4. Turn on expiring-card alerts (pre-dunning): MRRdue can warn you up to 30 days before a card expires with an optional read-only Payment Methods scope. The email goes out before the failure ever happens.

**How recoverable it is.** Very recoverable in the first week. These are engaged customers with a stale card, not churn risks. Speed matters more than copywriting here.

**Bank decline codes commonly seen alongside it** (quoted from Stripe's network-code reference; the same number differs by network and Stripe publishes no strict one-to-one mapping):
- 54 (Visa): Expired card or expiry date is missing.
- 54 (Mastercard): Expired card.
- 33 (JCB International): Expired card.
- 101 (American Express): Expired card / invalid expiry.
- 79 (Mastercard): Expired card (lifecycle decline; updated card data available).

### authentication_required — Authentication required

URL: https://www.mrrdue.com/guides/failed-payments/authentication_required

**What it means.** The customer's bank demands strong authentication (3D Secure / SCA) before approving the charge. The payment is stuck until the customer completes a verification step, usually one tap in a banking app.

**Why it happens.**
- European cards under PSD2/SCA rules require authentication for many recurring charges.
- The bank's fraud model flagged this particular charge for verification.
- An off-session subscription charge can't complete authentication without the customer present.

**What Stripe does on its own.** Stripe marks the invoice as requiring action and can email a hosted link, but silent retries cannot satisfy an authentication challenge. The customer must click through and approve.

**How to recover it.**
1. Send the hosted invoice link with a clear, calm explanation: their bank needs a quick confirmation, it takes under a minute, nothing is wrong with their card.
2. Treat these as time-critical. Authentication requests expire, and each re-attempt restarts the friction.
3. Avoid alarming language; 'your payment failed' reads scarier than 'your bank wants a quick confirmation' and produces worse completion rates.
4. If the same customer hits authentication_required repeatedly, suggest they re-enter the card so Stripe can request an off-session exemption going forward.

**How recoverable it is.** Recovery is almost entirely a function of how fast and how clearly you ask. The customer's intent to pay is nearly always intact.

**Bank decline codes commonly seen alongside it** (quoted from Stripe's network-code reference; the same number differs by network and Stripe publishes no strict one-to-one mapping):
- 1A (Visa): Additional customer authentication required.
- 65 (Mastercard): Exceeds withdrawal count limit (or Identity Check soft-decline of EMV 3DS authentication).
- A1 (Cartes Bancaires): Soft decline (electronic commerce only), 3DS with challenge required.
- 130 (American Express): Additional customer authentication required.

### card_declined — Card declined

URL: https://www.mrrdue.com/guides/failed-payments/card_declined

**What it means.** The catch-all decline: the issuing bank refused the charge without a specific reason Stripe can share. It can be fraud heuristics, a frozen card, a spending limit, or a bank-side rule about recurring charges.

**Why it happens.**
- The bank's fraud model blocked an online or cross-border recurring charge.
- The card was frozen, reported, or hit a spending control.
- Some issuers decline merchant categories or foreign merchants by policy.

**What Stripe does on its own.** Stripe retries generic declines on its smart schedule, and some clear on their own once the bank's block lifts. Repeated identical declines mean the bank's answer is settled. More retries won't change it.

**How to recover it.**
1. Let one Stripe retry pass. If it fails again, the bank is saying no on purpose.
2. Email the customer and name the likely fix directly: call the bank to approve the charge, or use a different card via the invoice link.
3. Suggesting 'contact your bank or try another card' outperforms asking them to guess what went wrong.
4. Watch for the same customer declining across multiple months. That pattern is a retention-risk signal, not just a payment problem.

**How recoverable it is.** Middling recovery odds that improve sharply when the email offers two concrete paths (bank call or new card) instead of a generic 'please update billing'.

**Bank decline codes commonly seen alongside it** (quoted from Stripe's network-code reference; the same number differs by network and Stripe publishes no strict one-to-one mapping):
- 05 (Visa): Do not honor.
- 05 (Mastercard): Do not honor.
- 59 (Visa): Suspected fraud.
- 62 (Visa): Restricted card (card invalid in this region or country).
- 82 (Visa): Negative CAM, dCVV, iCVV, or CVV results.
- 82 (Mastercard): Invalid transaction/merchant.
- 83 (Mastercard): Suspected fraud (MAC 01 and 03); retry the transaction later (MAC 02).
- 100 (American Express): Deny.

### payment_method_missing — Missing payment method

URL: https://www.mrrdue.com/guides/failed-payments/payment_method_missing

**What it means.** The subscription has no usable payment method attached, so Stripe has nothing to charge. Every invoice will fail until the customer stores a card.

**Why it happens.**
- The customer detached or replaced a card and the subscription lost its default.
- A trial converted to paid without a card ever being collected.
- A card was deleted after a dispute or bank replacement and never re-added.

**What Stripe does on its own.** Retries are meaningless with nothing to charge. Stripe will keep generating failed invoices until a payment method exists. This is the one decline where automation can do exactly nothing.

**How to recover it.**
1. Email immediately with the hosted invoice link. Paying it stores a card and fixes the subscription in one step.
2. Be direct: 'there's no card on your account' is unambiguous and gets acted on faster than a soft billing-problem framing.
3. Audit how the account got here. If trials convert without collecting a card, that funnel gap will keep manufacturing these cases.
4. If there's no response after two notes, treat it as a churn conversation, not a billing chase.

**How recoverable it is.** Binary outcomes: customers who meant to stay fix it fast, and silence usually means the subscription was already abandoned. Either way, one clear email resolves the ambiguity.

### do_not_honor — Do not honor

URL: https://www.mrrdue.com/guides/failed-payments/do_not_honor

**What it means.** The issuing bank refused the charge and declined to say why. Stripe's own documentation describes do_not_honor as “the card was declined for an unknown reason”, and its recommended next step is for the customer to contact their card issuer. The card itself is usually valid: this is the bank exercising discretion, not a data problem you can fix on your side.

**Why it happens.**
- The bank's risk model flagged the charge — a recurring merchant it does not recognise, an unusual amount, or a country mismatch.
- The customer has a block on recurring or card-not-present transactions they set up and forgot about.
- A temporary hold on the account that the bank will not describe to the merchant.
- The card was replaced and the old number still authorises some transactions but not others.

**What Stripe does on its own.** Stripe will retry on its schedule, and a meaningful share of do_not_honor declines clear on a later attempt because the bank-side condition was temporary. But there is no signal in the response telling you whether this one will, which is exactly what makes the code frustrating.

**How to recover it.**
1. Let Stripe's retry run first. A do_not_honor that clears on its own costs you nothing, and emailing before the retry spends goodwill on a problem that may not exist.
2. If the retry fails, email the customer and be specific about what to do: their bank refused the charge and only the bank can say why, so the fastest fix is a quick call to the number on the back of the card, or paying the invoice link with a different card.
3. Do not tell the customer their card was declined for insufficient funds or that it expired. You do not know that, and guessing wrong makes you look careless about their money.
4. For a high-value account, send a personal note rather than a template. A do_not_honor often needs the customer to actively authorise the merchant with their bank, and that only happens if someone asks them to.
5. If the same customer produces do_not_honor repeatedly, stop retrying and ask for a different card. Repeated declines against one issuer rarely resolve themselves.

**How recoverable it is.** Moderately recoverable, but only with customer involvement. Nothing you can do on the Stripe side changes a bank's decision — the recovery path runs through the cardholder.

**Bank decline codes commonly seen alongside it** (quoted from Stripe's network-code reference; the same number differs by network and Stripe publishes no strict one-to-one mapping):
- 05 (Visa): Do not honor.
- 05 (Mastercard): Do not honor.
- 05 (Discover): Do not honor.
- 05 (JCB International): Do not honor.
- 05 (Cartes Bancaires): Do not honor.

### transaction_not_allowed — Transaction not allowed

URL: https://www.mrrdue.com/guides/failed-payments/transaction_not_allowed

**What it means.** The bank refused this type of transaction on this card. Stripe classifies it with the unknown-reason declines and points the customer at their issuer, but the practical meaning is narrower than a generic decline: something about the shape of the charge, not the balance, was refused. Recurring charges, card-not-present charges and cross-border charges are the usual candidates.

**Why it happens.**
- The card is a debit, prepaid or corporate card with recurring billing disabled.
- The cardholder or the bank has blocked online or card-not-present transactions.
- The card is restricted to a region and your Stripe account bills from another.
- A corporate card's controls do not permit this merchant category.

**What Stripe does on its own.** Retrying an identical charge will usually produce an identical refusal, because nothing about the transaction has changed. This is the decline where waiting for Stripe's retry schedule is least likely to pay off.

**How to recover it.**
1. Do not wait for the retry cycle to finish. The condition is structural, so the same charge will be refused the same way.
2. Email promptly with the hosted invoice link and ask the customer to pay with a different card — ideally a personal credit card rather than a debit, prepaid or corporate card.
3. Say plainly that the bank blocked this type of payment rather than that the payment failed. It tells the customer what to change, and it is the truth.
4. If the customer wants to keep the same card, the fix is on their side: the bank has to allow recurring or online transactions on it. Only they can request that.
5. Watch for a cluster of these from one region or card type. It usually points at a billing-configuration issue rather than a run of unlucky customers.

**How recoverable it is.** Highly recoverable, but only by changing card — not by retrying. The customer almost always still wants the subscription; their card simply cannot do this kind of charge.

**Bank decline codes commonly seen alongside it** (quoted from Stripe's network-code reference; the same number differs by network and Stripe publishes no strict one-to-one mapping):
- 57 (Visa): Transaction not permitted to cardholder.
- 58 (Visa): Transaction not allowed at terminal.
- 62 (Visa): Restricted card (card invalid in this region or country).
- 57 (Mastercard): Transaction not permitted to issuer / cardholder.
- 5C (Visa): Transaction not supported/blocked by issuer.
- 119 (American Express): Not enrolled / permitted.
---
## Comparisons

### MRRdue vs ChurnWard

URL: https://www.mrrdue.com/compare/churnward

ChurnWard sends dunning emails and retries payments with write access to your billing. MRRdue is the read-only alternative: ranked recovery queue, your own sending, and API access.

### MRRdue vs Stripe Smart Retries

URL: https://www.mrrdue.com/compare/stripe-smart-retries

Stripe's own retries are part of Stripe Billing, which is priced as a percentage of the revenue it bills. Retries alone don't tell you who to email today. MRRdue adds the recovery workflow on top.

### MRRdue vs Baremetrics Recover

URL: https://www.mrrdue.com/compare/baremetrics-recover

Baremetrics Recover sends dunning emails and hosts card-update forms with write access, priced from ~$69/mo. MRRdue is the read-only alternative at $29/mo.

### MRRdue vs Churnkey

URL: https://www.mrrdue.com/compare/churnkey

Churnkey bundles cancel flows, precision retries, and payment walls from ~$250/mo with deep write access. MRRdue is the $29/mo read-only recovery layer for bootstrapped SaaS.
---
## Articles

- How to recover failed Stripe payments before they become churn (2026-06-15): A practical playbook for SaaS founders: quantify involuntary churn, decide who to contact first, and recover revenue with read-only billing data.
  https://www.mrrdue.com/blog/recover-failed-stripe-payments
- Churnkey alternative for bootstrapped Stripe SaaS (read-only recovery) (2026-06-20): Compare Churnkey's write-access recovery suite with a read-only, indie-priced approach for founders who want control over billing.
  https://www.mrrdue.com/blog/churnkey-alternative
- Involuntary churn in Stripe: what it is and how to spot it (2026-06-10): Voluntary cancellations get the attention. Card failures and expired payments quietly drain MRR. Here is how to tell the difference in your Stripe data.
  https://www.mrrdue.com/blog/involuntary-churn-stripe
- How to create a Stripe restricted key for MRRdue (2026-06-25): Step-by-step setup for a read-only restricted key. MRRdue imports billing metadata without permission to charge cards or edit subscriptions.
  https://www.mrrdue.com/blog/stripe-restricted-key-mrrdue
- Stripe Smart Retries vs manual recovery outreach (2026-06-28): Smart Retries recover a lot silently. They do not tell you which customers to email today. When manual outreach still wins for bootstrapped SaaS.
  https://www.mrrdue.com/blog/stripe-smart-retries-vs-manual-outreach
- How to give a SaaS tool read-only Stripe access safely (2026-07-06): Most billing tools ask for your full secret key or broad OAuth scopes. Here is how restricted keys actually work, what scopes to grant, and how to verify a vendor can't touch your billing.
  https://www.mrrdue.com/blog/read-only-stripe-access-for-saas-tools
- Why I built a Stripe recovery tool from India, without a Stripe account (2026-07-06): Stripe stopped onboarding new Indian merchants, so I couldn't build yet another dunning tool. That constraint became the product: recovery software that physically cannot touch your billing.
  https://www.mrrdue.com/blog/building-a-stripe-tool-from-india
---
## Machine-readable versions

- https://www.mrrdue.com/llms.txt — site map for language models
- https://www.mrrdue.com/llms-full.txt — the full site content as one plain-text file
- https://www.mrrdue.com/index.md · https://www.mrrdue.com/pricing.md · https://www.mrrdue.com/about.md · https://www.mrrdue.com/faq.md · https://www.mrrdue.com/mcp.md — markdown versions of the key pages
- https://www.mrrdue.com/agents.txt — how AI agents connect over MCP
- https://www.mrrdue.com/sitemap.xml — every public URL