Processors – Using Multiple Payment Processors
Introduction
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 | |
ACH/eCheck Processing | |
Canada EFT Processing |
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:
GET https://loanpro.simnang.com/api/public/api/1/tenant/easypay/processors
The payload of the request will need to be formatted as follows:
{
d:{
"anet":[],
"tabapay":[],
"speedchex":[],
"versapay":[],
"nacha":[]
"loanpaymentpro":[],
"eftcanada":[],
"cpa":[],
"repay":[],
"actum":[],
}
}
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).
AutoPays
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:
"mcProcessor":"{\"bankAccount\":{\"id\":\"nacha\",\"name\":\"RCC\",\"default\":0}}
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:
{
"bankAccount":
{
"id":"nacha",
"name":"RCC",
"default":0
}
}
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:
https://loanpro.simnang.com/api/public/api/1/tenant/easypay/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
- NACHA
- 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:
"selectedProcessor":"2"