DEV Community: Swipe Again

Three Stations, No Mystery: Reading a Recovery System by Its Handoffs

Swipe Again — Sat, 14 Nov 2026 10:40:08 +0000

Every recovery system, whatever its brochure says, is three stations and two handoffs. A failure is detected. A decision is made about what kind of failure it is. Attempts and messages go out in some order, and either money lands or the case closes. The brochures photograph the stations. The losses hide in the handoffs — the places where a case waits, unowned, while one part of the system assumes another part is watching it.

Station one is detection, and it is less trivial than it sounds. A failed payment is not one event but a family: the charge that declined, the retry the platform scheduled, the card the bank quietly replaced, the subscriber who updated their details somewhere the billing system did not look. A system that detects only the first event works a partial list all month and reports its recovery rate against a denominator it chose itself. Honest detection means the queue contains every case that is actually failing, including the ones no webhook announced.

The handoff into station two — triage — is where reading matters. A decline code is a sentence about a specific card at a specific moment: this one is early, that one is final, this third one is a timing problem wearing a money problem's coat. Systems that treat the queue as uniform spend their attempts evenly and recover unevenly. A plain walkthrough of how recovery moves from detection through retry to a saved subscription lays the sequence out in the order it actually happens, which is the order worth auditing in any tool, including the one you already own.

Station three is the attempt itself, plus the message that travels with it — and the second handoff, between attempt and message, is the one most often dropped. A retry fired with no notice asks the bank to approve a charge the customer may no longer expect. A message sent with no working fix link asks the customer to do homework. The pair, timed together, is the unit of recovery; either half alone is a gesture. When a case closes unpaid, the useful autopsy question is rarely "how many times did we try?" It is "at which handoff did this case sit still, and for how long?"

None of this requires exotic machinery. It requires that the three stations agree on what a case is, that no case changes hands without a timestamp, and that somebody — or some system — reads the stillness report: the list of cases that have not moved in days. Stillness, in a recovery queue, is never neutral. It is a decision made by default, and it always decides against the merchant.

Judge any system, ours included, by its handoffs. The stations are easy to build. The handoffs are the product.

The same handoff test works in reverse, as a design tool rather than an audit. Lay your last twenty lost cases on a table and mark, for each one, the last station it demonstrably reached and the length of its longest stillness. Patterns appear quickly that no aggregate rate would show you: a detection gap on one platform's failures, a triage rule that parks a whole decline family indefinitely, a message sequence that ends two days before the final retry fires, so the last attempt arrives unannounced. Each pattern is a single, fixable seam. Recovery programs rarely fail everywhere at once. They fail at one seam, repeatedly, while the stations on either side report themselves healthy — which is why the seams, and only the seams, deserve the first hour of every review.

Published by Swipe Again — failed payment recovery at a flat $179/mo.

Bring Your Failure Report to the Tool Comparison

Swipe Again — Sat, 14 Nov 2026 10:13:40 +0000

Every comparison of payment recovery tools reads well, because vendors write their feature lists to be read. The demo call goes well too. What never goes well is the first month after a switch, when a team discovers that the tool they bought was evaluated against a generic failure profile — and their actual failures look nothing like it. The fix is unfashionable and entirely in the buyer's hands: bring your own failure report to the comparison, and make every candidate answer to it.

Your failure report is not exotic. It is the last ninety days of failed charges, grouped by decline reason, by card type, by plan size, and by how each case ended. That document knows things no feature grid does. If most of your failures are expired cards on annual plans, the tool that matters is the one with the strongest pre-expiry and account-updater story, and its retry choreography is a footnote. If your failures cluster on insufficient funds in the last week of the month, timing intelligence is the whole purchase. If a third of your failures eventually pay on the platform's own retries, then the honest question for every vendor is narrower: what do you recover from the two-thirds that were otherwise gone?

That last question also disciplines the pricing conversation. A percentage-of-recovery tool evaluated against your real failure mix has to show its take against the cases it would actually touch — not against the whole failure pool, some of which your billing platform was already recovering for free. Teams that run this arithmetic before signing routinely find the ranking of tools flips: the expensive option gets cheap, or the cheap option reveals it was priced against recoveries it never caused.

Eight payment recovery tools for SaaS compared against the criteria a failure report actually tests is structured around exactly those tests — decline handling, updater coverage, pricing model against a real failure mix, and what happens to the cases nobody recovers.

The failure report also protects you after the signature, because it becomes the baseline the tool is judged against. Without it, the first quarter's review is an argument about dashboards: the vendor's number says one thing, the billing platform's says another, and nobody can reconstruct what would have happened without the tool. With a ninety-day pre-purchase baseline grouped by decline reason, the review is a comparison instead of an argument — same failure mix, same counting rules, before and after. Vendors who expect to be renewed welcome that baseline. It is worth noticing, during the sales process, which ones encourage you to build it and which ones change the subject to feature roadmaps.

Integration depth is the last item the report tests, and it is really a question about evidence. A tool that can see only that a charge failed will always recover less than a tool that can see why, on which card, after how many platform attempts, and whether the subscriber engaged with the last message. Ask each candidate, concretely, what data it reads from your billing platform and what it writes back — because the write-back is what your own reporting, your support team, and your next tool comparison will all depend on. A recovery tool that leaves no trace in your own systems has made itself impossible to evaluate, which some vendors count as a feature. Your failure report is how you decline that arrangement in advance.

One more test belongs on the list, and it is the easiest to run: ask each vendor how a recovered subscriber is counted, and whether a payment your platform collected on its own retry counts toward their number. The answer separates measurement from marketing faster than any feature question. A tool confident in its own work will happily be judged only on the recoveries it caused. Bring the failure report, ask that question, and the comparison writes itself — in your numbers, not theirs.

Published by Swipe Again — failed payment recovery at a flat $179/mo.

Smart Retries Are a Bet About Strangers: Reading Stripe's Timing Like Your Own

Swipe Again — Sat, 14 Nov 2026 09:40:32 +0000

Stripe's Smart Retries make a genuinely reasonable bet: across millions of subscriptions, machine-learned timing recovers more than any fixed schedule a small team would design by hand. The bet is about strangers — the average subscriber, in the average week, at the average bank. Your renewal queue is not made of strangers. It is made of your subscribers, whose paydays cluster around your pricing, whose banks cluster around your market, and whose failures cluster around the specific week your product renews them. The gap between the average and your queue is where a billing team earns its keep.

Start by separating two questions that dashboards habitually merge. The first is whether the platform's retries recovered a payment. The second is whether they recovered it because of the timing, or simply before your own process would have. A recovery on the platform's eighth day looks identical in the summary to a recovery your card-update email caused on day two — but they imply opposite decisions about where to invest next. Until a team stamps each recovery with what actually preceded it, every argument about retry strategy is an argument about fog.

The decline mix matters more than the retry count. Smart timing helps most against the soft, situational failures — insufficient funds early in a pay cycle, a bank's temporary risk posture, a credential mid-replacement. Against a card that was cancelled in a fraud sweep, no timing model on earth recovers anything; the only route is a human updating a card, which means the email, the hosted update page, and the tone of both matter more than the schedule. Teams discover, once they sort by decline family, that their queue is usually two different problems wearing one label.

stripe dunning software that sorts declines before it schedules retries lays out that sorting in detail: which decline families respond to patience, which respond only to a card update, and how to read the platform's recovery numbers without crediting the schedule for the subscriber's own initiative.

A small experiment makes the point concrete. Take one month of failures and hand-sort them, on paper, into three piles: paid after a retry and nothing else, paid after a subscriber touched the card, and never paid at all. Most teams who do this expect the first pile to dominate. What they usually find is a humbling second pile — subscribers who fixed the problem themselves after a message, while the retry schedule was still warming up — and a third pile dominated by one or two decline codes they had never isolated. That single afternoon of sorting routinely changes a team's roadmap more than a quarter of dashboard reviews, because it replaces a platform's average story with the queue's actual one.

The practical posture that follows is neither worship nor replacement. Leave the platform's retries running — they catch the easy timing wins at zero marginal effort — and build your own work in the spaces the model cannot occupy: the subscriber-facing messages, the card-update path, the watch on credentials that changed upstream, and the honest ledger that says which recoveries were yours. Where the two schedules meet, weave rather than collide: your outreach lands in the platform's quiet stretches, never an hour after its loudest attempt.

Judged that way, Smart Retries stop being a feature you either trust or resent and become what they actually are — a competent default for the average case, running underneath a queue that is not average at all. The businesses that recover best on Stripe are rarely the ones with the cleverest retry settings. They are the ones that stopped asking the platform's model to know their subscribers, and started keeping the records that let them know the subscribers themselves.

Published by Swipe Again — failed payment recovery at a flat $179/mo.

Rounds Before the Renewal: The Week That Decides the Charge

Swipe Again — Sat, 14 Nov 2026 09:14:09 +0000

Hospitals do rounds before a crisis, not after one. Subscription billing mostly does the opposite: all of its energy, tooling, and worry concentrates on the days after a payment fails, while the week before the renewal — when a meaningful share of failures are already visible and preventable — passes without a single scheduled look.

Consider what is knowable seven days before a charge. The card on file has an expiry month, and expiry is the most predictable event in the entire billing file. The account updater may already hold a replacement credential issued when the subscriber's bank reissued their card. The subscriber's last renewal may have failed once and healed, which marks the account as fragile. None of this requires prediction. It requires a list, reviewed on a cadence — rounds.

Pre-dunning is the name for working that list. Its moves are deliberately unglamorous. A courteous note before renewal to subscribers whose cards expire this month, carrying a secure update link and no alarm. A quiet check that updater coverage is actually flowing, not merely enabled. A flag on accounts whose details changed elsewhere in the stack. Each move is cheap, each is timed while the subscriber still feels like a customer rather than a debtor, and each converts a future failure — with its retries, its anxious emails, its churn risk — into a non-event.

None of these moves asks the subscriber for anything unusual, and that restraint is the point: the ask is small, early, and obviously in their interest.

The objection is usually that pre-renewal messages train subscribers to ignore billing mail. The evidence of the queue suggests the opposite: a short, specific, genuinely useful note — your card ending in this number expires before your next renewal — is the best-opened message most subscription businesses ever send, precisely because it arrives as service rather than collection.

A practical explainer of pre-dunning and the quiet week before a renewal sets out the full routine: which signals to pull, how far ahead to pull them, and how to keep the messages welcome rather than wearying.

The rounds themselves need a fixed shape or they dissolve into good intentions. A workable cadence pulls the signal list twice: once about a week out, when there is still time for a replacement card to arrive or an updater record to settle, and once two days out, as a final sweep for anything the first pass missed. The list itself stays short enough to read in one sitting — cards expiring before the renewal date, credentials replaced upstream since the last charge, accounts that failed once and healed, and payment methods flagged by the processor as at risk. Each entry gets one of three dispositions: contact now, watch silently, or clear. What rounds must never become is a second dunning sequence pointed earlier; the messages stay rare, specific, and visibly about the subscriber's convenience, because the entire advantage of acting before a failure is that trust has not yet been spent.

The deeper shift is accounting. Teams that run rounds start reporting a new number alongside recovery rate: failures prevented, estimated from the cards updated before their renewal date. It is a humbler metric than recovered revenue, because nobody can photograph a crisis that did not happen. But month over month it is the number that compounds — every prevented failure is a subscriber who never entered the queue, never read a dunning email, and never had a reason to reconsider the subscription at all. Recovery will always be necessary. The week before is where it gets smaller.

Published by Swipe Again — failed payment recovery at a flat $179/mo.

Shift Log: One Night in the Recharge Renewal Queue

Swipe Again — Sat, 14 Nov 2026 09:09:01 +0000

Every subscription business that runs on Recharge has a queue it rarely looks at directly: the renewals that failed overnight. The platform retried them on its own schedule, some recovered without anyone noticing, and the rest are sitting there in the morning, aging. This is a shift log from that queue, written the way an operator actually meets it — one failure at a time, with the clock running on each.

02:10 — the expired card. The first entry is the most honest failure in the file. The card did not decline for lack of money; it declined because it stopped existing. Recharge's native retry will try this credential again and get the same answer, because time does not resurrect an expired card. What this subscriber needs is not another attempt but a door: one message, one secure update page, and a reason to bother. The log entry closes when new details land, not when the retry count climbs.

03:40 — the insufficient-funds renewal. This one failed on a Tuesday morning, which is the worst morning of the month for a large share of households. The money is not missing; it is scheduled elsewhere. A retry tomorrow is a coin flip. A retry aligned with the end of the week, when wages land, is a different proposition entirely. The platform's fixed cadence cannot know this. An operator reading the log can.

05:15 — the do-not-honor. No explanation, no appeal, just the issuer declining to explain itself. The correct response is restraint: space the attempts, send one clear message that does not pretend to know more than it does, and set an early point at which the account is honestly written off instead of chased forever. Chasing this class hard teaches banks to treat your traffic as noise.

06:30 — the authentication request. The bank wants the cardholder to confirm the charge is genuine. No retry succeeds until a person acts, so the work here is timing and clarity: reach the subscriber when acting is plausible, ask for exactly one thing, and make the confirmation feel like service rather than suspicion.

Reading the queue this way changes what dunning means on this platform. The native machinery handles the easy recoveries — the transient glitches, the one-day timing misses. Everything above that line is judgment work: sorting failures by cause, matching the response to the cause, and knowing which attempts to stop. A working map of Recharge dunning, from the first native retry to the last rescue attempt lays out that division of labor in full, and it is worth reading before the next morning's queue, not after it.

07:00 — the handover. The night's real lesson is about who owns which entries. The platform's native attempts should run untouched for the failures they are good at: the one-day timing miss, the transient issuer glitch, the retry that simply needed a second morning. Everything the log flagged by name — the dead credential, the payday case, the unexplained refusal, the pending authentication — belongs to a layer that can read, decide, and write to the subscriber like a person. Businesses get into trouble in the seam between those two layers: either they let the native schedule grind through cases it cannot solve, spending attempts and goodwill, or they duplicate it with a second schedule that fires on the same mornings and double-contacts the subscriber. The discipline is a clean handover — native first, briefly; judgment second, personally; and a hard stop both layers respect the moment a subscriber cancels, pays, or updates.

The log's last entry is always the same: the subscribers who recovered silently and never knew anything was wrong. They are the majority, and protecting their experience — no alarming emails, no visible drama — is half the job. The other half is the queue above, read slowly, one honest failure at a time.

Published by Swipe Again — failed payment recovery at a flat $179/mo.

The Retry Clock Should Answer to the Decline, Not the Calendar

Swipe Again — Sat, 14 Nov 2026 08:47:44 +0000

Ask ten subscription teams when they retry a failed payment and most will answer with a schedule: day one, day three, day seven, or some variation worn smooth by habit. Ask why those days, and the room usually goes quiet, because the honest answer is that the schedule came with the tool, or with a blog post, or with the last person who held the job. Schedules are not wrong. A retry has to happen sometime. But a schedule that ignores why the payment failed is a clock answering to itself, and the decline codes in any real file are patiently explaining that different failures keep different time.

Start with the failure that keeps calendar time most literally. Insufficient funds is a statement about a moment, not a person: on the morning of the attempt, the money was not there. Its remedy lives in other people's calendars — wage cycles, benefit payment dates, the first business day after a long weekend. Retrying this decline on a fixed day-three cadence is a lottery ticket. Retrying it near the subscriber's likely payday is a plan. The information needed is embarrassingly available: the day of the week the failure occurred, the rhythm of the month, and the patience to wait for a better morning instead of spending attempts on bad ones.

Expired and replaced cards keep the opposite time. They do not heal by waiting. Every day spent politely spacing retries against a dead credential is a day the subscriber drifts toward forgetting the subscription exists, while the fix — new details, entered once — takes two minutes whenever it happens. For this class the clock should be measured in hours to first contact, not days to first retry, and retries should mostly stop until the credential changes. Notes on when to retry failed payments, sorted by the clock each decline actually keeps is a useful corrective here, because it reframes the schedule as several clocks sharing one queue.

Authentication-required failures keep a third time: the subscriber's attention. The bank wants the cardholder to confirm the payment is genuine, which means the retry cannot succeed until a person has done something, and people do things in the margins of a day — the commute, the lunch break, the evening scroll. Contact for this class should land when acting is plausible, carry exactly one action, and expire gracefully, because a confirmation request discovered a week later reads as archaeology, not service.

Then there is the failure that should slow every clock down: the unexplained issuer refusal. Spaced attempts, a clear message, and an early verdict respect both the bank's opaque risk posture and the subscriber's patience. Compressing this class into a rapid schedule does not recover more subscribers. It recovers the same subscribers faster, annoys the rest sooner, and teaches issuers to associate your attempts with noise.

None of this requires exotic machinery. It requires sorting before scheduling: read the decline, assign its clock, then let the calendar be built from the file instead of imposed on it. Teams that make that one change usually discover their attempt count falls while their recoveries rise, which feels like a paradox until you see the file clearly. They were never short of retries. They were short of timing, and timing was sitting in the decline codes all along, waiting to be read. Write the clocks down where the whole team can see them, one line per decline family, and review them monthly against what actually recovered. A timing rule that cannot be pointed at will quietly revert to the old fixed schedule the first busy week nobody is watching the queue.

Published by Swipe Again — failed payment recovery at a flat $179/mo.

The Category Page Is a Promise. The Queue Decides If It Was True.

Swipe Again — Sat, 14 Nov 2026 08:40:08 +0000

Every category page in this market makes roughly the same promise in roughly the same order: failures are expensive, retries should be smarter, emails should be kinder, and the dashboard will prove it worked. None of that is false, exactly. It is just written from the wrong end of the work. The page describes the system as its builders wish it behaved. The renewal queue, thirty days later, describes the system as it actually behaved, in timestamps and decline codes and subscribers who either paid or quietly disappeared. If you are choosing in this category, the second document outranks the first every time.

A useful exercise is to take one ordinary week of your own failures and walk it, case by case, through any tool you are considering. Not the vendor's demo week, with its clean cards and cooperative balances. Yours: the expired card on an annual plan, the insufficient-funds failure that landed two days before payday, the do-not-honor that gave you nothing to work with, the subscriber who had already replaced her card somewhere else and simply never told you. For each case, write down what the tool would do on day one, day three, and day seven, and what evidence you would see that it had done it. A field guide to failed payment recovery software that starts in the renewal queue is valuable precisely when it survives that walk without hand-waving, because the walk is the job.

Three failure modes show up quickly in that exercise. The first is the blended retry: a schedule that treats every decline as the same event with a different timestamp. Expired cards do not need urgency, they need a new credential. Insufficient funds do not need pressure, they need a better day. A tool that cannot separate those cases is not running a strategy, it is running a metronome, and a metronome pointed at a bank account mostly produces fees and fatigue. The second failure mode is the silent case: a failure that enters no queue, triggers no message, and waits for a customer to notice a cancelled service and complain. Silence is where willing subscribers are lost, and it never appears in a feature list.

The third failure mode is accounting. Ask, for any recovered payment, how the tool knows it recovered it, and what it does when the same subscriber's card is quietly refreshed by the network updater the night before a retry succeeds. Honest systems stamp the sequence and give the network its credit. Generous systems give themselves all of it. The difference matters beyond vanity: if you cannot separate recoveries you caused from recoveries that happened near you, you cannot price the tool, you cannot improve it, and you cannot defend its number in the room where budgets are set. A recovery rate without an attribution rule is a story, not a measurement.

None of this requires a sales call to test. Your own export contains the cases, your own calendar contains the paydays, and a careful afternoon contains the walk. Bring the week, bring the awkward cases especially, and let the category page make its promise against them. The tools that welcome that test tend to be the ones built by people who have stood in the queue themselves. The tools that steer you back to the headline number have told you, in that steering, everything the walk was designed to learn. Keep the walk's notes, whichever tool you choose. A quarter later they become the baseline nobody can argue with: the cases you brought, the behaviour you were promised, and the behaviour the queue recorded, side by side in your own handwriting.

Published by Swipe Again — failed payment recovery at a flat $179/mo.

The Recovery Bill Should Fit on One Line

Swipe Again — Sat, 14 Nov 2026 07:39:57 +0000

Every December I watch the same small ritual in subscription businesses: someone opens the year's recovery invoices and tries to answer a deceptively simple question — what did getting our own money back cost us? With percentage-of-recovery pricing, that answer has to be assembled. Twelve invoices, twelve different recovered totals, a rate that may have tiered as volume grew, and a final number that is really a sum of monthly negotiations the business never knew it was having. The tool got paid more in the good months precisely because the work worked, which sounds fair until you notice the business also did better in those months for the same reason. Both sides cannot own the same improvement.

This is the quiet argument behind flat-fee payment recovery priced as a single monthly line. One line, the same line, every month: that is the entire invoice. The appeal is not that it is always cheaper — in a terrible month, a percentage bill would be smaller, and honesty requires saying so. The appeal is that the cost becomes knowable in advance, which changes what a business can plan. A fixed line can be budgeted in January, compared against a salary hour or an ad line, and judged at year-end without an afternoon of archaeology.

Percentage pricing also distorts behaviour in ways that rarely get discussed. A vendor paid a share of recovered revenue has a structural reason to keep marginal cases open longer, attempt more aggressively, and define recovery generously, because every borderline dollar carries their fee inside it. None of that requires bad faith; incentives do the work quietly. A flat fee removes the vendor's thumb from those particular scales. The decision about when a case is honestly finished can then be made on the customer's experience and the bank's evidence, not on whether one more attempt might produce one more billable recovery.

There is a second distortion, on the buyer's side. When recovery costs a percentage, teams start treating recovered revenue as slightly less real than new revenue — it arrives with a visible tax attached. Finance rounds it down in forecasts. Founders discount it in their heads. That mental discount hides the true size of the failed-payment problem and delays the boring fixes — descriptor clarity, pre-expiry card updates, renewal reminders — that shrink the problem at the source. A flat line does the opposite: recovered money is simply money, and the fee is judged separately, the way rent is judged, on whether the whole arrangement earns its keep.

Judging it is straightforward, which is rather the point. Take any ninety days. Add the recovered revenue the record can honestly attribute — stamped when the money landed, not claimed by proximity. Compare it against three flat lines. If the recovered total clears the fee by a margin you would accept from any other vendor, renew without a meeting. If it does not, the conversation is equally simple, and nobody needs a spreadsheet with four tabs to have it. The clarity cuts both ways, and a vendor confident in the work should prefer a pricing shape that makes the judgement this easy.

Percentage pricing survives because it feels riskless at signing: pay only when it works. But the risk was never mainly in the fee. It is in the subscribers lost while the queue was handled indifferently, and no pricing model insures that. What a business can control is whether the cost of the help is predictable, whether the incentives point at the customer's interest, and whether December's question — what did recovery cost us this year? — can be answered in one sentence. One line is a good length for an answer.

Published by Swipe Again — failed payment recovery at a flat $179/mo.

The Scoreboard Is Not the Work, but It Decides Whether the Work Counts

Swipe Again — Sat, 14 Nov 2026 07:12:57 +0000

Every subscription business keeps two ledgers, whether it admits it or not. One is the work ledger: failures noticed, retries scheduled, emails sent, cards updated. The other is the scoreboard ledger: money that was owed, money that arrived, money that never will. Teams love the first ledger because it is full of activity. Finance trusts only the second, because activity that does not end in collected revenue is just motion.

That is the honest frame for revenue recovery software that is judged on collected renewals, not activity counts. Its job is not to generate attempts, messages, or dashboards. Its job is to turn a specific pile of failed renewals into paid ones, at a cost — in money, issuer goodwill, and customer patience — that leaves the business better off than doing nothing. Anything softer than that standard lets a tool look busy while the leak continues underneath it.

Begin an evaluation with the pile itself. How large is last month's failed-payment pool, really? Not the gross exposure number that makes a sales deck dramatic, but the workable pool: failures on cards and accounts where recovery is genuinely possible, separated from the closed accounts, the fraud cases, and the people who cancelled on purpose. A serious tool helps you draw that line. A unserious one prefers the bigger number, because a percentage of a bigger number always looks like more value.

Then follow one failure all the way through. A renewal fails on Monday. When is the first retry, and what decided that timing? When does the subscriber hear about it, in what words, and what exactly are they asked to do? If their card was replaced, does the system notice a new credential, or does it keep presenting the old one? If they pay by another route entirely, does the case close as recovered, or does the machinery keep writing to someone who has already fixed the problem? That last failure — pestering the recovered — is the one customers remember.

Cost deserves the same unsentimental treatment. A percentage-of-recovery price means the meter runs hardest in your best months, and the total is unknowable until the quarter ends. A flat price can be compared, budgeted, and judged: did collected revenue beat the fee by a margin worth the effort? Whichever model you choose, do the arithmetic on your own pool, with your own recovery rate, not on the worked example in a brochure where every assumption leans the vendor's way.

There is a timing question too, and it is easy to miss. Recovery that lands in week one is worth more than the same dollars landing in week five, because a subscriber recovered quickly never starts shopping for your replacement. Ask how long cases stay open, what the schedule looks like across that window, and when the system declares a case honestly finished. A long, vague tail of attempts is not thoroughness; it is a queue nobody is managing.

None of this requires a large finance team. It requires refusing to grade recovery work by how much of it happened. Count the pool honestly, trace single cases end to end, price the models on your own numbers, and check the scoreboard monthly against the work ledger. When the two agree, you have a system. When only the activity ledger looks healthy, you have a very energetic leak.

Start small if you need to: one month, one failure report, one afternoon. The businesses that get good at this are not the ones that bought the most features. They are the ones that decided, early, that recovered revenue is a number you verify — never a story you are told.

Published by Swipe Again — failed payment recovery at a flat $179/mo.

What the Percentage Took, Counted at Year's End

Swipe Again — Sat, 14 Nov 2026 06:43:11 +0000

Nobody notices a percentage leaving. That is the design. A recovery tool priced as a share of what it collects takes a little from every save, quietly, in the same motion that produces the good news. The invoice at month's end shows recoveries — money that would otherwise be gone — and the fee reads as a modest slice of a win. It is only at year's end, when someone adds the slices, that the arrangement shows its true size.

Run that addition before you sign, not after. Take your last twelve months of failed payments, estimate a plausible recovery share, and apply the percentage to that total. For many subscription businesses the result is a five-figure annual fee for software whose work — sorted retries, timed attempts, clear customer messages — is the same work every month whether it recovers a little or a lot. Reading a Gravy alternative priced as one flat monthly line is really reading a different theory of what the software is: a utility with a known cost, not a partner with a claim on the upside.

The percentage model also bends behaviour in a way worth naming. A vendor paid per recovered dollar is rewarded for volume of attempts, and the line between persistent and excessive retrying is one the merchant, not the vendor, pays to police — in issuer standing, in customer irritation, in the subscribers who leave annoyed rather than saved. A flat fee does not make a vendor virtuous, but it removes the meter that runs faster the more aggressively the system behaves. The incentives you buy are the behaviour you get.

Put plausible numbers on it, because abstractions hide in percentages and reveal themselves in dollars. A business recovering fifty thousand dollars a year from failed payments — a modest figure for a mid-sized subscription company — pays five thousand of it away at a ten percent share, and seven thousand five hundred at fifteen. That is the fully loaded cost of a part-time hire, or a year of the flat alternative several times over, spent on the same recovered dollars. The percentage did not change across those sentences. Only the habit of multiplying it out did.

The comparison sharpens as a business grows, which is the part of the pitch that works in reverse. Percentage pricing is often introduced as the low-risk option for a small company, and at very small volumes it can be. But success quietly promotes the arrangement into one of the larger lines in the software budget, with no renegotiation moment scheduled and no natural point at which anyone asks whether the original bargain still fits the company it now describes. Flat pricing has the opposite property: growth makes it relatively cheaper, month by month, without anyone lifting a finger.

None of this argues that percentage pricing is a trick. It argues that it should be priced honestly, against your own failure volume, before it becomes the default you never re-examine. Contracts renew quietly. The percentage, once embedded, is rarely re-added at year's end by anyone. Be the business that adds it.

There is a simple closing test for any recovery tool, whatever its model: after a year, can you say in one sentence what it recovered and what it cost, with both numbers from the same page? If the cost half of that sentence requires a spreadsheet and a definition, the pricing is doing something the product description is not. Choose the arrangement whose arithmetic you can say out loud.

Published by Swipe Again — failed payment recovery at a flat $179/mo.

A Cadence Is a Promise Kept at Intervals

Swipe Again — Sat, 14 Nov 2026 06:09:52 +0000

Ask a room of subscription operators how many times they contact a customer after a failed payment, and most will answer with a number. Ask when, and the room goes quieter. Yet customers do not experience a number. They experience intervals: a message the same evening, then silence for a week, then three messages in two days as a deadline approaches. That rhythm — not the count — is what teaches a subscriber whether your billing process is calm and deliberate or anxious and improvised. A cadence is a promise kept at intervals, and planning it means designing the rhythm on purpose.

That is the working idea behind recharge dunning planned as a cadence, not a retry count: lay the whole sequence out on one calendar, per failure type, before any of it fires. When the sequence exists as a picture rather than as settings scattered across a tool, its faults become visible at a glance. Gaps where a payday will pass unnoticed. Clusters where a retry and two emails land on the same morning. A final notice that arrives after the access it warns about has already ended, which is not a notice at all, just an apology with the wrong tense.

A useful way to build the calendar is to anchor it to the customer's life rather than to the failure timestamp. The failure happened when it happened — often at an hour chosen by a batch process, bearing no relation to when the subscriber is awake, paid, or able to act. The first contact can stay close to the failure; clarity early is kindness. But retries, especially for insufficient-funds cases, earn their keep by landing where money actually arrives: after common paydays, at hours when a person can respond to a bank prompt, never in a tight burst that spends attempts before conditions change.

Different failures also deserve different rhythms, and the planner is where that stops being a slogan. An expired or replaced card can be resolved the moment the customer acts, so its cadence should be short, clear, and built around prompt re-attempts once new details land. A soft decline needs spacing and variation. A case that will end in cancellation needs a rhythm that slows down, states dates honestly, and closes with dignity rather than accelerating into a wall of reminders in its final week. One cadence for every cause is not consistency; it is inattention, printed on a calendar.

Quiet days deserve the same deliberate design as contact days, because silence is also a message. A pause after a customer has promised to update a card on Friday tells them you believed them. A pause while a bank hold clears tells the issuer nothing frantic is coming. Even the gap before a final notice does work: it gives a busy person one last ordinary week in which to act before the tone changes. When teams plan only the touches and leave the gaps to accident, the gaps still communicate — they just communicate whatever the tool's defaults happened to produce, which is rarely patience and never gratitude.

Finally, a planned cadence can be tested, and an unplanned one can only be endured. With the sequence written down — attempt days, contact days, quiet days, closing day — a team can change one interval at a time and read the result honestly: did moving the second retry change recovery, or merely move it? Without the plan, every outcome is weather. With it, timing becomes what it should have been all along, a hypothesis the calendar lets you keep, test, and keep again.

Draw the calendar. Per cause, on one page, with the quiet days marked as deliberately as the loud ones. Your subscribers will never see the plan, but they will feel it, in the difference between a process that nags and a process that keeps its word.

Published by Swipe Again — failed payment recovery at a flat $179/mo.

Two Desks, One Overdue Account: Where Dunning Ends and Collections Begins

Swipe Again — Sat, 14 Nov 2026 06:09:22 +0000

Imagine two desks in the same small office, both looking at the same overdue account on the same morning. On the first desk sits a subscriber who has paid happily for fourteen months, whose card was replaced after a bank merger, and who has not yet noticed anything is wrong. On the second desk sits an account that signed up, consumed a month of service, disputed the first charge, and vanished. Treating those two files with the same voice, the same urgency, and the same threats is not firmness. It is a category error, and customers can feel it immediately.

That category error is the subject of a field guide to separating dunning from collections in practice, and its central claim is simple enough to tape above a monitor: dunning is a service conversation with someone who intends to stay, while collections is a debt conversation with someone who has already left in every way that matters. The tools overlap — email, reminders, deadlines — but the relationship underneath them does not, and the relationship is what decides tone, timing, and how much pressure is honest.

Start with intent. A dunning case begins with a failed payment, not a refusal to pay. The overwhelming majority of subscription failures are accidents of timing, expiry, replacement cards, or bank caution. The customer has made no decision about you at all. A collections case, by contrast, begins after a decision, or after silence so prolonged that the decision can fairly be inferred. Mixing the two means the accidental case receives language written for the deliberate one, which is how loyal subscribers end up reading words like delinquency in the first email after a bank quietly reissued their card.

Timing tells the same story. Dunning works in days, close to the failure, while the service relationship is still warm and the fix is still small: update a card, confirm a charge, wait for payday. Collections works in weeks and months, after the service has ended, when the question is no longer continuity but settlement. A team that starts collections language on day two has nowhere left to escalate, and a team still sending gentle dunning notes on day ninety is spending goodwill and compute on an account that needed a different process entirely.

There is a practical test any operator can run this week. Pull the last fifty payment-failure messages your system sent and sort them into two piles by a single question: does this message assume the reader wants to keep the subscription? If the answer is unclear, the message belongs to neither desk — it is a template doing two jobs badly. Rewrite it twice, once for each pile, shorter both times. The dunning version names what happened, offers one clear action, and states a calm, honest date. The collections version, reserved for genuinely ended accounts, can be firmer because firmer is truthful there.

None of this is softness for its own sake. Sorting correctly is also how the numbers stay honest. Recovery rates mean little when accidental failures and ended accounts are averaged together; a team can look excellent at dunning simply because its queue is full of easy credential fixes, or look terrible because dead accounts were never handed over. Two desks means two scoreboards, and two scoreboards mean you finally know which problem you actually have.

Keep the desks separate, in language, in timing, and in counting. The subscriber on the first desk will repay the courtesy with years of renewals. The account on the second desk deserves a clear, dignified process too — just not the same one.

Published by Swipe Again — failed payment recovery at a flat $179/mo.