Building a 98% Payment Success Rate: The Engineering Behind Automated Loan Collections

FundFlick's (fundflick.in) Collection System automates EMI recovery across UPI, Netbanking, and NACH with a 98% success rate. That number doesn't come from one payment method being reliable — it comes from treating each channel's specific failure mode as a distinct engineering problem instead of running the same generic retry logic against all three.

The three channels fail in three different ways

UPI failures are mostly transient — a timeout, an app not open, a momentary bank-side hiccup — and respond well to a quick, near-term retry. NACH failures are structurally different: an insufficient-funds bounce on a mandate debit isn't going to resolve itself in the next ten minutes, and retrying immediately just adds another bounce (and, on some bank rails, another bounce fee) to a borrower who already doesn't have the funds. Netbanking sits in between — session-based failures that need a fresh redirect, not a blind retry of a stale reference. Treating all three the same way is the single biggest reason naive collection systems underperform their theoretical success rate.

A waterfall, not a single channel

Rather than committing to one payment rail per borrower, collection attempts fall through a waterfall: a fast channel is tried first, and a failure routes to the next-best channel rather than just retrying the same one. A NACH mandate is the backbone for scheduled recurring EMI debits — it's the channel designed for exactly this use case — but UPI collection requests fill the gap for pinpointed one-off follow-ups (a partial payment, a manually re-scheduled date) where the borrower's phone is the fastest path.

NACH retries respect the mandate, not just the deadline

NACH mandate debits are time-boxed by regulation, not by however a batch job happens to be scheduled — a bounced debit has to be re-presented within specific windows, and doing it wrong risks the mandate itself getting flagged. The retry scheduler treats a NACH bounce as a distinct state with its own re-presentment timeline, not just "try again tomorrow" logic borrowed from a generic job queue.

Reconciliation catches what retries can't fix

Not every failure resolves through more attempts — a closed account, an expired mandate, or a partial part-payment scenario needs a human collections workflow, not another automated debit attempt. The system flags these into a collections queue instead of silently retrying a payment method that structurally can't succeed. A collection system judged purely on "percentage of debits that eventually clear" will happily keep retrying a dead mandate forever if nothing tells it to stop.

Borrower notification before every debit

Every scheduled debit gets a pre-notification, both because it's expected practice for recurring debits and because it measurably reduces avoidable bounces — a borrower reminded a day ahead is more likely to have funds in the account than one who finds out only after a failed attempt already happened.

98% isn't one payment gateway working well. It's three different failure modes, each handled the way that specific failure mode actually requires — and an honest queue for the fraction that automated retries were never going to fix.

If you're evaluating a collections system for a lending product, ask specifically how it handles a NACH bounce versus a UPI timeout — a vendor that gives the same answer for both hasn't actually built channel-aware retry logic, they've built one retry loop pointed at three different APIs.