> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mx.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.