When a bank (ACH) payment is returned, Payload shows a standardized status reason on the transaction rather than the raw bank return code. This article explains what each reason means and what to do next.
How ACH returns work
An ACH payment can be returned by the receiving bank after it processes — for insufficient funds, a closed or frozen account, a stop payment, and more. The bank issues a standard NACHA “R” return code (e.g., R01). Payload groups those codes into a smaller set of clear status reasons, shown below.
| Status reason | ACH return codes | What it means | What to do |
|---|---|---|---|
insufficient_bal |
R01, R09 | The account didn’t have enough available funds. | Retry later or use another payment method. |
payment_stopped |
R05, R07, R08, R10, R11, R14, R15, R29, R38 | The payment was stopped or reported as not authorized. | Confirm authorization with the payer and obtain a new authorization before retrying. |
invalid_account_number |
R02, R03, R04, R12, R20, R28 | The bank account couldn’t be used (closed, no account, invalid or non-transaction account, routing error). | Verify and re-enter the bank account and routing numbers. |
suspicious_activity |
R16 | The receiving bank has frozen the account. | The payer needs to resolve the freeze with their bank. Don’t retry until it’s resolved. |
duplicate_attempt |
R24, R37 | The bank flagged the entry as a duplicate. | Confirm whether the original payment already succeeded before retrying. |
processing_issue |
R17, R18, R19, R21, R22, R25, R26, R27, R32, R33, R39 | The entry couldn’t be processed due to a formatting or settlement error. | Contact Payload support — these are typically corrected on our end. |
general_reject |
R06, R13, R23, R30, R31, R34, R35, R36 | The bank refused the entry for another reason. | Contact Payload support for the specific reason. |
For developers
These reasons appear in the transaction object’s status_code and in reject webhooks. The raw NACHA R-code is normalized to the reasons above and isn’t passed through directly.