Processors – Using Multiple Payment Processors


LoanPro Software is linked to Secure Payments for everything related to payment processing directly. This allows for PCI compliance, additional security measures, centralization of payments, as well as for maximum flexibility in payment processing rules.

Secure Payments allows for multiple processors to be configured per processor type.

Processing Type

Available Processors

Bank Card Processing (ANET)




ACH/eCheck Processing

SpeedChex/ACHQ (integrated)

NACHA (non-integrated "batch processing")

Repay (integrated)

Actum (integrated)

LoanPaymentPro (integrated)

Canada EFT Processing


EFT Canada


The advantages of having multiple processors configured per type is that you can elect to have payments, including AutoPays, set to a given processor. Each processor may have different credentials, including integrated processors or NACHA remitting. This means that, in LoanPro, you have the flexibility to decide how your payments are handled; you can have a payment go through one processor, then have another payment on the same loan account, processed by a different processor.

Multiple payment processor options allow for various finance company configurations, leading to maximum control over ACH bounce rates and directional flow of funds.

To pull processor information for your tenant, send a GET request to the following endpoint:


The payload of the request will need to be formatted as follows:


Each array will have a JSON object detailing information about the processor. Below is a sample for a NACHA file:

    "name": "RCC",
    "cutoff_time": 0,
    "bank_routing": "123456789",
    "tax_id": "",
    "bank_name": "Bank",
    "company_name": "Lender",
    "discretionary_data": "",
    "bypass": "0",
    "default": "0",
    "auto_reversal": "0"

Each processor stores slightly different information, but you will typically only need the processor name, whether it is the default processor, and which group the processor is found in. Everything else can be almost always be ignored (except when working with the processor itself).


AutoPay creation works the same way as normal, but will have an additional field called mcProcessor. The mcProcessor field contains information about which Secure Payments processor should be used when processing the AutoPay. This field will be a stringified JSON object. Please note that when sending this information to create or update an AutoPay, the JSON object will be sent as a string and not as an actual JSON object. The completed mcProcessor field for using the above example will look like:


The object will consist of a creditCard or bankAccount field depending on if the processor will be processing credit cards, or bank accounts/checks. The field will then hold a JSON object consisting of an id of the group the processor is in (such as "anet", "speedchex", "nacha", etc), the name of the processor, and the default field which determines whether the processor is the default processor.

Here is an example for a NACHA file processor called RCC:


Payment Processing

Payment processing will also work the same as normal but with one difference: it will now include a selectedProcessor field. The selectedProcessor field will contain the order ID of the payment processor. This ID is determined by the order in which the payment processors are returned by the GET request to the following endpoint:
This ID is relative to the order in which LoanPro returns it, not when items were created.
Any changes to payment processors will change the ID! Keep this in mind to ensure payments are not sent to the wrong processors

The order ID moves from top to bottom, starting at 0, and it is not reset when moving between processors. This means that the first entry in ANET will always be 0, regardless of when it was input into the system. If there are no items in ANET, then the first item in SpeedChex will be 0 and so on.

As an illustration, lets say we have the following processors (shown by groups and names):

  • ANET
    • Card Main
    • Card Backup
  • SpeedChex
  • VersaPay
    • VP1
    • VP2
    • Pre-Processed

The ordering IDs would be as follows:

  • Card Main – 0
  • Card Backup – 1
  • VP1 – 3
  • VP2 – 4
  • Pre-Processed – 5

If Card Main was later removed, the ids would be reordered as:

  • Card Backup – 0
  • SpeedChex – 1
  • VP1 – 2
  • VP2 – 3
  • Pre-Processed – 4

If we then added a processor to SpeedChex called SP1, the ordering would be:

  • Card Backup – 0
  • SpeedChex1 – 1
  • SP1 – 2
  • VP1 – 3
  • VP2 – 4
  • Pre-Processed – 5

As you can see, the ordering ID is very relative and should be double-checked before submission.

Using the last list above, to process a payment using the SP1 processor, we would add the following to our normal payment processor request:


How did we do?

Powered by HelpDocs (opens in a new tab)