Recurflux is now processor-agnostic . Everyone is served.
We just crossed a milestone I've been working toward since day one: Recurflux now works across Stripe, Paddle, Razorpay, and RevenueCat.
Web billing. Mobile billing. One recovery system.
That means whether your users pay on a browser or inside an iOS app, failed revenue now has somewhere to go.
Here's what "processor-agnostic" actually looks like in practice — 12 recovery mechanisms, running automatically:
Smart Retry by Failure Type - 30+ failure codes handled with logic tuned per code, not a blunt retry timer
Card Health Monitoring - catch cards about to expire before they fail
Multi-step Dunning - up to 6 email steps on Surge, separate sequences per failure type (expired card, insufficient funds, generic decline)
SMS Dunning - reach customers where they actually open things
Payment Portal - a hosted page where customers update payment without contacting support
Subscription Pause Instead of Cancel - give customers a middle option before they churn
Cancellation Flow Builder - intercept cancel intent, offer discounts or pauses
Checkout Recovery - catch drop-offs before they become failures
Dispute Protection - auto-builds your evidence package (delivery logs, portal visits, retry history). One click to export. Tracks your dispute rate against Visa (0.9%) and Mastercard thresholds in real time
90-Day Historical Sync - see what was failing before you connected
Recovery Dashboard - every failed charge in one table with live status: RECOVERED, RETRYING, AT RISK, LOST
Web + Mobile Billing - RevenueCat gets email sequences, push notification recovery, 90-day sync, and cancel-intent detection via mobile SDK
Some numbers that ground this:
5 min median time to first retry
30+ failure codes handled
6 dunning steps on Surge plan
4 processors, connect any in under 60 seconds
Dispute rate monitor with real headroom tracking
Nothing is a black box. Every failure is logged. Every email template is editable. Every retry rule is configurable per failure type. You can connect Slack for recovery alerts. You set your retry window, portal subdomain, and priority threshold from day one.
Recovery runs automatically, but you're always in control.
👉 [recurflux.com]
Happy to answer questions below, especially if you're on RevenueCat or Razorpay, since that support is the freshest and I want real feedback on edge cases.
The processor-agnostic milestone is the right one to build toward first. Most failed payment recovery tools assume Stripe and treat everything else as an edge case which works until your users are on mobile billing or a regional processor and suddenly the whole system has a blind spot. The dispute protection piece is interesting too. Auto-building the evidence package is the kind of thing that sounds like a nice-to-have until you’re staring down a chargeback at midnight. How are you handling cases where the failure reason from the processor is ambiguous or missing entirely?
 Ambiguous or missing codes fall into a conservative catch-all, defaulting to retry rather than skipping it, since most unclassified failures are transient. Each processor gets its own normalization layer before the retry logic ever sees the code, so Razorpay and Paddle quirks don't leak into the core engine. RevenueCat doesn't expose granular failure codes at all, so that path is handled separately via email recovery. On disputes, evidence is built passively from day one. By the time a chargeback lands, there's nothing to scramble for.
The normalization layer per processor is the right call letting Razorpay and Paddle quirks leak into the core retry logic would make debugging a nightmare at scale. The passive evidence building is the part I find most interesting. Most dispute handling is reactive by nature so designing it as a background process from day one is a meaningful architectural decision. Does the evidence package differ by processor or is it standardized once it clears the normalization layer?
The evidence package is standardized - once a charge clears the normalization layer, the signals we track (email delivery, portal visits, retry history) are processor-agnostic by design. The processor-specific calls happen earlier in the pipeline; by the time evidence is assembled it's working with internal records, not raw processor data. The passive-building angle is the one that actually changes outcomes. Most tools make you gather evidence after a dispute lands, at that point you're reconstructing a timeline that should have been logged all along. Treating it as background bookkeeping from day one means the package is mostly done before the dispute notification hits.
Reconstructing a timeline you should have been logging all along is exactly the wrong moment to find out your tooling was reactive. The fact that the evidence package is mostly done before the dispute notification hits flips the entire dynamic you’re not responding to a problem, you’re already prepared for one that hasn’t arrived yet. Solid architecture.
Hi , Your payment recovery system, Recurflux, is impressive, especially with its processor-agnostic approach. We'd love to help promote Recurflux to a broader audience of SaaS businesses who could greatly benefit from such a comprehensive solution. Let's discuss how we can assist you in driving more attention and users to your platform!
This is a strong step, but “processor-agnostic” only really matters if the recovery logic becomes data-advantaged across those processors—not just compatible with them; the real leverage here isn’t supporting Stripe + Paddle + RevenueCat, it’s learning from cross-processor failure patterns (e.g., how retry success differs between mobile vs web, or issuer behavior across regions) and feeding that back into smarter retries, dunning timing, and channel selection—otherwise it risks becoming a well-packaged orchestration layer rather than a compounding system. The control and transparency you’re emphasizing is a good differentiator, especially in a space full of black boxes, but the long-term moat likely comes from how much better your recovery rates get over time because of that aggregated signal. Are you already using cross-processor data to adapt retry/dunning strategies dynamically, or is each integration still operating in isolation today?