A consumer agrees to twelve monthly payments in September, and for the first seven months everything works exactly as expected. Then April comes around and payment eight fails.

At first glance, that looks simple. The payment didn’t go through. But that result doesn’t tell you why. The card the consumer provided in September may have expired on March 31. It may have been replaced after a fraud alert. Or, if the arrangement is running through ACH, the debit may have come back with a return code pointing to something entirely different.

From the outside, all of those situations look like the same thing, a payment plan that stopped working. Underneath, they’re very different payment events, and understanding that difference makes the decline and return reports your team already looks at much more useful.

Why later payments behave differently than the first one

The first payment in an arrangement happens while the consumer is there. They provide the card or bank account information, hear the amount and schedule, agree to the terms, and the payment runs.

The installments that follow depend on the information and authorization captured at that moment. A card payment runs using a stored credential. An ACH debit runs under the standing authorization the consumer gave when the arrangement was created.

That doesn’t mean the consumer’s intent changes after payment one. Often, it doesn’t. What changes is the information supporting the arrangement. Cards expire, accounts close, credentials get replaced, and bank debits come back for reasons that have nothing to do with whether the consumer still intends to complete the plan. That’s why a failure months into an arrangement deserves a little more context than “declined” or “returned.”

On a card, the expiration date is running the clock

Imagine that September payment plan was created with a card expiring 03/27. September clears, followed by October, November, December, January, February, and March. Then April arrives, and the credential that supported every previous installment has expired.

Nothing about the arrangement changed. The card aged out on a date the issuer established long before the payment plan existed.

Expiration is only one way a stored credential becomes outdated. Cards are replaced after fraud alerts, reissued when they’re lost, and sometimes tied to accounts that are later closed. Each of those events retires the credential sitting behind a recurring arrangement, even when the consumer still intends to pay.

This is one reason the card networks created account updater services. Visa Account Updater and Mastercard Automatic Billing Updater allow participating issuers to pass updated card information through to acquirers for merchants holding credentials on file. Visa, for example, describes responses that include an updated account number or expiration date, notice of a closed account, or a contact cardholder advice. That last one is one of my favorites because, stripped of the payments language, it means it’s time to talk to the consumer.

Account updaters help keep a long-running arrangement from failing because the card information changed. They don’t eliminate failures altogether, and participation varies, but they’re a good example of why a card decline several months into a plan doesn’t automatically tell you anything about the consumer’s willingness to keep paying.

Sometimes the credential changed. That’s the whole story.

On ACH, the return code gives you more context

ACH gives you a different kind of visibility because a returned debit comes back with a code, and those codes tell you what kind of return you’re looking at.

Nacha publishes three return-rate levels that are worth understanding. The unauthorized return rate threshold is 0.5% and covers R05, R07, R10, R11, R29, and R51. The administrative return rate level is 3.0% and includes R02, R03, and R04, which cover closed and invalid accounts. The overall return rate level is 15.0% and captures debit returns more broadly, excluding RCK. An everyday insufficient-funds return such as R01 doesn’t appear in the unauthorized or administrative lists, so it falls into the overall return rate.

There’s an important distinction here, too. Nacha makes clear that exceeding the administrative or overall return-rate levels does not automatically mean a rules violation occurred. It can instead trigger an inquiry into what is producing the return pattern, and that’s where understanding the code becomes more valuable than counting the return.

R11 is especially important for payment arrangements

Of all the return codes you might see, R11 is one worth recognizing if your organization runs recurring payment plans.

Nacha defines R11 as the customer advising that an entry was not in accordance with the terms of the authorization. In practical terms, the consumer agreed to an arrangement but later says something about the payment that ran wasn’t what they agreed to. Maybe the amount was different, the debit hit on a different date, or the schedule didn’t match what they expected.

That makes R11 very different from something like R01. R01 is an insufficient-funds issue. R11 points back to the authorization itself.

Since April 2020, R11 has counted toward Nacha’s unauthorized return-rate calculation, which makes that distinction even more important. When R11 appears months after a payment plan was created, it’s giving you a clue about where to look. What was authorized at the beginning, and how does that compare with the payment that ran? That’s real information sitting inside what could otherwise look like just another failed debit.

“Failed” is the outcome, not the explanation

This is the takeaway from all of it. A report can tell you that an installment failed, and it may give you a decline reason or an ACH return code. But the failure itself is only the outcome. The situations behind it look similar at the top line, and they aren’t the same underneath.

At Payment Savvy, these are the kinds of payment-level questions we walk through with clients. We can look at how an arrangement is being submitted, what came back when an installment failed, and what the payment rail is telling us.

Whether you work with us or another payment partner, it’s worth understanding what sits beneath those failures. Pick one payment plan that has been running for several months and follow it forward. Look at which installments cleared, which rail they used, and what came back when one didn’t. You may find that a plan that looks perfectly simple from the outside has a much more useful story underneath it.

The first payment tells you the arrangement started. Understanding what happens to the payments that follow is what makes the rest make sense.