Introduction

It is common for enterprise customers to process payments using NACHA files. Usually this is done by creating a custom application that is integrated with LoanPro and Secure Payments (formerly PCI Wallet). This custom application will track payment transactions from start to finish.

 Because transacting money is the lifeblood of any lending business, and because making mistakes in this area has serious consequences, this article will give recommendations on working with Secure Payments to process NACHA payments. If you need to brush up on the NACHA process before reading this article, our article NACHA Process Start to Finish goes into more detail about each step. 

For now, let's quickly go over the process for NACHA payments:

There are 5 basic steps in the NACHA process:

1. Record Transactions
2. Create The NACHA File
3. Submit The File to the Bank
4. Update Transactions With the Outcome of Processing
5. Receive Funds to Your Bank Account

While this process may appear simple, it is important to track each payment from start to finish to make sure you are getting paid when you should, and not pulling money from customers when it isn't supposed to happen.

Division of Labor

Responsibility for specific parts of the process are divided between LoanPro, Secure Payments, and you or the custom application you build.

LoanPro

LoanPro is merely the system of record for loan transactions. That means the transactions should always be entered and updated in LoanPro.

Secure Payments

Secure Payments is responsible for batch transactions. This means the Secure Payments will divide transactions into batches, making sure that each transaction is included in a batch, and that transactions aren't included in more than one batch. This is the function that you should rely on Secure Payments to perform. Secure Payments has other functions, but in the NACHA process, you will be responsible to verify anything that these other functions do.

The other functions that may be used in the NACHA process are:

• Webhook Notifications
• NACHA File Generation

You/Your Custom Application

You or your custom application will be responsible for the following things:

• Pulling data for all transactions from Secure Payments.
• Pre-scrubbing on the transaction data to remove any bad account data or transactions that you know will fail.
• Creating the NACHA file from Secure Payments account data. Secure Payments does generate NACHA files, but using the generated NACHA file is not recommended, because it doesn't provide the option for scrubbing, and the file can't be easily updated once it's created.
• Tracking the status of payments from start to finish.
• Tracking Secure Payments batches to make sure they get submitted to the processing bank, but don't get submitted more than once.
• Updating transaction statuses once a returns file is received from the processing bank.

Common Mistakes

It is tempting to set up a webhook notification from Secure Payments that will notify you when it batches transactions each day, and have Secure Payments generate a NACHA file from the batch when the notification is received. This file can be sent to the bank, and your job is done. There are a few problems with processing transactions in this way.

First, webhook notifications are not 100% reliable. They may be received twice, or may not be received at all. If that is the case, you may miss out on processing payments or process payments twice.

Second, changing a batch and the generated NACHA file is difficult in Secure Payments. If you need to make changes to data in a file, it is far better to create your own NACHA files. It also could be that your bank uses a format that is not the same as what Secure Payments generates.

Recommendations

When creating your custom application, we recommend that you follow some best practices to ensure that you are processing payments correctly.

Batching

Secure Payments will create a batch of transactions each day for each NACHA processor. You can also request that Secure Payments creates a batch. If you have a large number of transactions (e.g. thousands per day), we recommend that you batch often, so that batches contain no more than 10,000 transactions each. This will help you load the batch information more easily and will ensure greater speed and consistency when downloading data and creating a NACHA file.

It is recommended that you set up the webhook notification to tell you when a new batch has been created. To ensure that you don't miss any batches, we encourage you to check the list of batches regularly. This should be done by querying the list of batch IDs and checking them against the IDs of batches you have.

Tracking

In your custom application we recommend that you have a database table that keeps track of the following:

Batch Status - This will help you know the status of each batch. At a minimum, we recommend the following statuses:

• Pending - The request for a batch has been sent to Secure Payments, but the batch has not yet been created.
• Created - The batch has been created by Secure Payments.
• Received - The batch information has been received by your custom application.
• NACHA Created - Preliminary scrubbing of transactions has been completed, and a NACHA file has been created.
• NACHA Submitted - The NACHA file has been submitted to the bank.
• NACHA Processed - Transactions have been processed and a returns file has been received from the bank.
• Transactions Updated - Secure Payments transaction statuses have been updated.

Batch ID - This will ensure that you are tracking each batch in a unique way, and will let you compare the batches you have with the list of batches in Secure Payments.

Processor ID - This will make sure that you know which processor the batch was generated for.

Tracking these things you ensure basic logic such as not submitting a batch multiple times to the bank, knowing what you have done and what you need to do to process each batch, and recording each batch in a way that directly connects it with the batch in Secure Payments.

Scrubbing

We recommend that you use some procedure to remove bad data from the list of transactions before you create your NACHA file. Reasons for changing the data could be anything from using alternate routing numbers, because some are not accepted for some banks, to removing transactions because the customer made other arrangements or paid via another method after the transaction was originally logged. Regardless of the reason, changing or removing data that will cause problems will help the process go smoothly.

Creating the NACHA File

We have referred to the file you will submit to the bank as a NACHA file, but this may not be the case. You should submit a file in whatever format your bank requires. You can either do the necessary programming in your custom application to format transactions into a file, or you can get the transactions from Secure Payments as a CSV and use a third-party application to create the file. We recommend this method because you can edit the data before a file is created. If you use the file that Secure Payments generates, it can't be easily changed, since NACHA files use a hash to guard against changes.

What's Next?

If you're interested in learning about more NACHA, How NACHA Files Work explains in detail the components of a NACHA file. We also recommend checking out NACHA Returns.