Best Practices

Reducing ACH Returns

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

We advise you to run a real-time balance check on an account before submitting an ACH transaction for that account.

R01 — Insufficient Funds

Prevent:

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

Troubleshoot:

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

R02 — Account Closed

Prevent:

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

Troubleshoot:

1. Stop all future transfer requests for this account.
2. Have the end user verify a different account.

R03 — Account Not Found

Troubleshoot:

Make sure that an account owner identification (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 identification.

R04 — Invalid Account Number

Prevent:

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.

Troubleshoot:

Stop all future transfer requests for this account.

Logging

Clients Should Log Every Authorization Code

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

Processors Should Log Every access_token

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.

Processors Should Log account_guid, member_guid, user_guid

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 Every Success or Failure

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.