The SubsShield blog
Field notes on involuntary churn, payment recovery, and retention infrastructure for Indian SaaS.
Read by topic
Featured reads
Recent posts
Your ‘failed’ UPI AutoPay debit might not have failed at all
Since 1 August 2025, NPCI holds UPI AutoPay debits during peak hours and releases them later. A debit that looks failed may simply be queued.
The ₹2 line: why ₹14,999 and ₹15,001 behave completely differently
To a pricing page they look like rounding. To the RBI e-mandate framework they are two different products — one renews itself, the other asks permission every month.
Subscription saved vs MRR recovered: two different wins
When a halted subscription comes back, future cycles resume but the unpaid invoices don’t auto-charge. Saving the subscription and collecting the failed rupees are not the same number.
Founding 50 — free until you see results
We run the Leak Audit on your Razorpay or Cashfree account and show what's recoverable.
Join Founding 50The ‘zombie active’ subscription: active in the gateway, no money in
A ‘confirmed’ mandate doesn’t guarantee a cleared debit. There’s a window where a subscription shows active but the payment failed — and that gap is where silent revenue loss lives.
Card reissuance: the silent failure 2026 was meant to fix
When a bank reissues a card, the old token dies and the next recurring debit just stops. No one decided to leave. The 2026 framework addresses it — but implementation lags.
What Stripe’s Smart Retries get right — and where India stops it
Stripe’s retry engine is genuinely good, and the fastest way to understand why Indian recovery has to be built differently is the one line where Stripe admits it doesn’t apply here.
Soft decline vs hard decline: the call that sets your message
Two failures land in the same dashboard column minutes apart. One needs nothing from the customer for days; the other needs them today. Treat them the same and you’ll be wrong twice.
The 26-hour window: turning the RBI pre-debit notice into trust
The cheapest payment to recover is the one that never fails. Just before each renewal there’s a window where a brand-first message can make that happen — before the bank’s SMS lands.
Why ‘pause’ beats ‘discount’ in an Indian cancellation flow
Most save flows reach for a discount first. In India that often answers the wrong question — and pause is something the customer is already legally entitled to.
The first 50 failed payments: a recovery-setup playbook
You don’t need a perfect recovery system on day one. You need your first 50 failed payments to teach you one — here’s what to set up and what to check.
Dunning for Indian SaaS: the rail-aware version of failed-payment recovery
Card-first dunning playbooks under-specify India. Real recovery here starts with diagnosing which rail failed and why — not sending another email.
Why the Western dunning playbook underperforms on Indian customers
Copy a US card-and-email recovery flow into India and it quietly breaks — wrong rail assumptions, wrong channel, wrong timing.
A working taxonomy of failed payments in Indian SaaS
Recovery starts with classification, not communication. Six decline classes, each needing a different next action.
"Razorpay will retry it" is not a recovery strategy
A retry answers one question. Recovery answers six. After four failed attempts the subscription halts — and that’s where retries can’t help.
Billing automation is not revenue recovery
Your gateway tries to collect revenue. A recovery layer responds when collection doesn’t happen — and on domestic cards, that gap is real.
The cancellation-flow mistake Indian SaaS copies from the West
An Indian cancel flow should first work out whether the customer is leaving the product, the payment method, the mandate, or the price.
How involuntary churn quietly distorts your SaaS valuation
Blended into one churn number, failed-payment loss makes a good product look weak and a weak recovery process look like product failure.
The retention stack: turning a payment failure into a workflow
A failed payment shouldn’t create panic. It should create a six-layer workflow — with suppression rules that know when not to send.