Payment Processing


Payments are the lifeblood of any lending business. Most lenders want to be able to collect payments in a way that won't require considerable cost or effort. Payment processing involves initiating payments, moving money, recording payments against the appropriate loans, and tracking failures and chargebacks to ensure the payments were truly received. LoanPro is integrated with and/or provides solutions for payment processing of many types. Lenders can choose the payment processing option that makes the most sense for them.

This article provides information on how payments are processed through credit/debit cards, ACH/EFT, and NACHA files. Below is a diagram displaying how payment processing works. This article will reference the diagram to provide a clearer picture of what is happening when payments are processed.


Payment Submission

LoanPro provides options that allow payments to be submitted manually, as automatic payments, through the API, or through the customer-facing website. Regardless of how payments are submitted, the process that follows is the same.

Payment Profile Creation

In order to process a payment, payment profile information is required. The diagram below shows how payment profiles are created in LoanPro.

PCI compliance standards dictate that payment profile information can only be submitted directly to Secure Payments. This can be achieved through an import or through an iframe in the LoanPro user interface. When payment profile information is submitted, Secure Payments will store it and then return a token to LoanPro, which LoanPro can use to reference the payment profile in the future. Payment profiles include credit/debit cards and bank accounts.

Payment Processors

There are four different types of payment processors: credit/debit card, ACH, EFT, and NACHA. For the purposes of this article, we will talk about ACH and EFT together since they both use bank account information to automatically process payments. When a payment is submitted through LoanPro, the path the processing will follow depends on the payment profile and the processor. A payment processor in Secure Payments will be linked to a specific account with one of our integrated payment processors or will be used as a way to mark transactions for inclusion in NACHA files.

Several banks and ACH processors will treat multiple payments on the same DATE, for the same AMOUNT, from the same BANK ACCOUNT as duplicates, even if they are not. This means that if you have multiple payments that share all these characteristics, only one of the transactions will be processed.

Credit/Debit Card

LoanPaymentPro, TabaPay, Repay, and are the currently available credit/debit card processors within LoanPro and Secure Payments. When a payment transaction is submitted through Authorize.Net, the amount, processor, and payment profile token will be sent from LoanPro to Secure Payments. Secure Payments will use the token to identify the payment profile and it will submit the transaction to Authorize.Net. Authorize.Net will then provide an immediate response to Secure Payments that will say whether the transaction was successful or not. If the transaction was successful, Secure Payments will send a successful response to LoanPro, and LoanPro will log the payment and save the information returned from Authorize.Net.

Authorize.Net will only accept 1 incoming transaction per minute with the same amount. If a user attempts to place more than one charge/transaction per minute, Authorize.Net processors reject any incoming transactions that are of the same amount. An error message will be displayed with the text, "A duplicate transaction has been submitted."


When an ACH/EFT payment is submitted, the amount, processor, and payment profile token are submitted to Secure Payments from LoanPro. Secure Payments will use the token to identify the payment profile and the information will be sent on to the ACH or EFT processor. If there is no immediate problem with the data, a success response will be returned to Secure Payments. This does not guarantee that the payment will be successful. Secure Payments will pass the transaction information and success response to LoanPro where the payment will be logged. If the transaction is not ultimately successful, Secure Payments will query the ACH or EFT processor to learn the status of the transaction, or the ACH or EFT processor will send information about the failed transaction to Secure Payments. Depending on your Secure Payments settings, the information may be passed to LoanPro and the payment transactions reversed.


Using a NACHA file for payment processing involves LoanPro and Secure Payments very little. When you submit a payment transaction to a NACHA processor, Secure Payments will receive the transaction and immediately return a success response to LoanPro. Transactions will then be logged in LoanPro. However, this does not mean the money is on its way. The next step is to generate a NACHA file. To generate the NACHA file, you have two options: You can either generate an unbalanced NACHA file or an 80-byte file through Secure Payments. Lastly, you can download a payment breakdown report from LoanPro, and with that information you can create your own NACHA file.

Once you have the NACHA file, you will submit it to the bank that will process the payments. The processing usually takes a few days to complete. Once processing is finished, the bank will usually submit a file to you that provides information about transactions that failed. You can use this information to create an import file so that these payments can be reversed in LoanPro. To be clear, once a report or NACHA file is generated, the rest of this process takes place outside of both LoanPro and Secure Payments. If you would like a more automated solution for payment processing, you should use one of our integrated ACH or EFT processors.


Payments will settle to the bank account you specify with the payment processor you use. LoanPro never receives funds for your payment transactions, nor do we act as a middleman of any kind.

Payment Lifecycle

How did we do?

Powered by HelpDocs (opens in a new tab)