Reducing ACH Returns

Below are best practices for preventing ACH returns and for dealing with the specific reasons for returns when they do occur.

As a general rule, the best advice is to run a real-time balance check on an account before submitting an ACH transaction for that account.

R01 — Insufficient Funds

Preventative Steps:

Always run a balance check before submitting an ACH transaction to ensure that there are sufficient funds in the account.
Submit the ACH transaction as soon as possible after running the balance check.

What To Do If You See This Return Code:

Wait until there are sufficient funds before submitting another ACH transaction for the account.

Preventative Steps:

Always run a balance check before submitting an ACH transaction to ensure that the account is still open.

What To Do If You See This Return Code:

What To Do If You See This Return Code:

Make sure that an account owner verification (identity) has been performed before initiating an ACH transaction.
Confirm that the name provided by the end user is the same as the one from the account owner verification.

Preventative Steps:

Clients should run an account verification for the account and confirm that the passed_validation field is true before passing an authorization code to processors.
Processors should confirm that the passed_validation field is true before submitting an ACH transaction for the account.

What To Do If You See This Return Code:

Stop all future transfer requests for this account.

Logging each authorization code you create and deliver to a processor may be helpful in troubleshooting with MX.

Processors should store all access tokens received from the /payment_processor_token endpoint.

Access tokens can be reused for the life of the token. Storing the token facilitates recurring payments as well as troubleshooting requests to MX should the need arise.
Access tokens expire 60 days from the time they were issued.

Log the account_guid, member_guid, and user_guid associated with each access token.

Access tokens are scoped to these specific GUIDs. Logging them will allow you to correctly map them to the stored token. This facilitates reuse and recurring payments.
These values are also necessary when troubleshooting problems with MX.
These values can be obtained from the client, and they are also returned in responses to processor endpoints.
MX does not currently check for duplicate tokens scoped to the same user/member/account. Thus, storing them on your end and mapping them appropriately will help prevent duplicates.

Processors should log the success or failure of each request where an access token is used.

If an error occurs, MX will need the access_token and the associated account_guid, member_guid, and user_guid in order to troubleshoot.