Every week I write one deep dive, two or three
industry signals, and one reusable framework -
all from inside the layer where payment decisions
actually happen.

This week: why blind ACH retries are a silent risk
inside most payment systems, and what we changed.

- Gaurav

Transaction fails. Wait a few hours. Try again.

It felt reasonable. Retries exist for a reason -
transient errors, timing issues, momentary
processor hiccups. The assumption baked into the
system was simple: if it failed once, trying again
is probably worth it.

That assumption was costing us.

The problem wasn't that we were retrying. The
problem was that we were retrying blindly -
without asking whether a retry made sense for
that specific failure, at that specific moment,
against that specific processor.

These are not the same failure. They don't have
the same retry profile.

Retrying an R02 doesn't just waste a cycle - it's
a compliance risk. Retrying an R10 can escalate a
dispute. Retrying against a processor experiencing
degraded performance adds load to a system already
struggling.

But the original system didn't know any of this.
It saw a failure. It scheduled a retry. It moved on.

We redesigned retry logic around two inputs that
had always been available but never used together:
return codes and processor health signals.

Return codes told us why a transaction failed.
Processor health signals told us whether the
environment was stable enough to retry.

We built a decision matrix:

➥ Permanent failures - no retry under any
circumstance. (Closed account, disputed
transaction)

➥ Conditional failures - retry only if processor
health signals are green and the retry window
hasn't been exhausted.

➥ Transient failures - standard retry with
adjusted timing.

The system stopped asking "should we retry?" as a
binary question. It started asking "is this retry
safe, meaningful, and likely to succeed?"

ACH success rates improved by 12%.

But the more important outcome was what didn't
happen. Duplicate settlement attempts dropped.
Compliance flags related to retry behaviour
reduced. Support escalations from banks asking
why we were retrying closed accounts went away.

The improvement wasn't from trying harder. It was
from building a system that knew when trying
harder was the right call.

The PM lesson

Retry logic is easy to treat as an engineering
detail. It lives deep in the stack, nobody sees
it, and it mostly works - until it doesn't.

But retry behaviour is a product decision. It
encodes assumptions about risk, compliance, user
experience, and processor relationships. When
those assumptions are implicit, they accumulate
technical and regulatory debt quietly.

The job of a PM in a payment system isn't to push
for higher success rates. It's to understand why
transactions fail and design systems that respond
to failure intelligently.

There's a difference between optimising for
success and designing for failure.

Before designing any retry, fallback, or recovery
logic - classify your failures first.

Most systems treat all failures as transient by
default. The moment you classify explicitly, your
retry logic becomes a risk management tool instead
of a retry loop.

Three categories worth defining for any
payment system:

Modern Treasury - ACH Return Code Reference

A free, comprehensive reference covering all 85
ACH return codes - meanings, timeframes, and
handling rules for each one.

More readable than NACHA's official docs, and
kept up to date as codes evolve.

moderntreasury.com/learn/ach-return-code-reference

The list is public. The judgment about what to
do with each code is where the real product
work lives.

- Gaurav Nikumbh
Senior PM · Payments & Banking Infrastructure
Founder, TechVenture360

If this made you think differently about
something, hit reply and tell me.
The best responses become future issues.