You can build it, but keeping it working is where it's at
Someone I've reached out to a few weeks ago told me he's building his own recovery logic in-house. My first reaction was "fair enough", and I still think it's fair. Anyone can really build most of it in a weekend of focused work.
However, what the last three weeks taught me is that saying "I took care of it" is a big overstatement in a domain with this many moving parts, including when I say it too.
I went back to check a Visa rule I'd written retry logic against. Visa's own memo, article AI10325, moved four response codes out of Category 1 (the category you're never allowed to retry) and into Category 2 (where you can, and probably should). Codes 03, 62, 78 and 93. Effective April 2021, five years ago.
Then I looked one of those codes up the ordinary way, the way I'd sourced it in the first place. Those online references still put 78 in Category 1, and the AI agents I asked confirmed it too. None of what people build on top of had caught up.
None of the four that moved is in my own never-retry set, so nothing broke. Here's that whole set, copied out of my backend:
export const VISA_CATEGORY_1_CODES: ReadonlySet<string> = new Set([
'41', // Lost card
'43', // Stolen card
'46', // Closed account
'R0', // Stop payment order
]);
Really the description sitting above it says why it's just four: a false entry there silently kills retries on revenue you could have collected, which is a worse failure than eating a fee when scaling it. I was guarding against being wrong in one direction, and it happened to cover me in another.
None of this is a one-off either, four separate bodies moved something in the last twelve months:
- India's central bank consolidated eight separate circulars into a single framework for recurring debits in April.
- Mastercard widened its decline fee in January. It used to attach only to retries, but now lands on every declined transaction where the card isn't present.
- The EU's payment services overhaul got political agreement back in November 2025 and still isn't published, so the transition clock hasn't started yet.
- The FTC restarted its subscription-cancellation rulemaking from scratch, and while that's stalled, individual states are writing their own. Maryland's took effect in June.
The EU one is a real kicker. It slipped its own deadline this year with no announcement, no error and no notification of any kind, and while the US federal rule stalls, the states have stopped waiting on it and are now drafting their own versions (Maryland's came into force in June).
Four bodies on four different clocks, with the last one implying that each state has its own individual time schedule to track. Underneath them sits the surface you actually inherit if you build this yourself: the decline mappings, the retry categories, the exact caps and intervals, the regional mandates, the regulation that hasn't landed yet, and your own enforcement quietly failing open.
Also, having that list still doesn't really save you.
Everyone on it is a known player (Visa, Mastercard, RBI, the FTC). I can go and scrutinize over every new regulation they'll pass, and now I do regularly, but what I can't do is see the other players coming, when someone writes a rule somewhere I'm not watching and then I find out about it because it's relevant to what I do here.
Most people building this also have it harder than I do, because their business simply doesn't revolve around these topics in the first place, and they have their own domain of problems to solve & maintain. For most starters there is nobody whose job it is to notice these things.
I won't pretend to be the authority on a rabbit hole I've got about three weeks of expertise on. The goal is to have something watching every source I can actually reach (more on that next week), but I genuinely don't know how a founder outside this domain is supposed to learn that a rule exists before it bites them.
What known unknowns were new to you today? What unknown-unknowns you suspect are still out there? And how do you maintain that part of your business?
The maintenance framing here is the part I'd underline for anyone directing an AI to build financial logic instead of writing it themselves. I don't audit code, so I can't independently catch when an assumption the app was built on quietly goes stale, I can only tell it still runs without erroring, which isn't the same thing. Alisio tracks multiple currencies, and formatting rules aren't static either, decimal places, rounding, which currencies use whole units only. If that reference list drifts unnoticed, the app doesn't crash, it just quietly gets a number slightly wrong and looks fine doing it. What's worked for me isn't trusting the code to stay correct, it's keeping an explicit, dated list of the external assumptions the app depends on and rechecking it on a schedule, the same discipline your four-code never-retry set represents, just applied to a domain where nothing warns you when it's wrong.
The important point is that the hard part isn't writing the retry logic once — it's keeping it correct as the rules around it change. The fact that old references and even AI answers can lag behind official rules makes ongoing maintenance a much harder problem than implementation.
It's actually worse than lagging in cases like Mastercard's; they don't publish their rules publicly at all, so there's no primary source to check yourself against even when you do go looking.
That makes the maintenance problem even more interesting. When the primary source itself isn't available, keeping the logic trustworthy becomes a very different challenge.