Using Multiple Payment Processors

LoanPro Software is linked to Secure Payments (formerly PCI Wallet) for everything related to payment processing directly. This allows for PCI compliance, other 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 type.

The advantages of having multiple processors configured per type is that you can elect to have payments, including autopays to a given processor. Each processor may have different credentials, including integrated processors or NACHA remitting. This means that in LoanPro you can have a payment go to one processor, which will then in turn use its integration or settings to process that payment. Then you can have another payment on the same loan account, or another account as selected use the same processor, or a different processor.

This tool will allow for various finance company configurations to have maximum control over ACH bounce rates, directional flow of funds, as well as having this ability for other administration reasons to control the processor that a given payment is processed with.

To pull processor information for your tennant, send a GET request to:

https://loanpro.simnang.com/api/public/apli/1/tenant/easypay/processors

It will then return a request formatted as follows:

{
   d:{
      "anet":[],
      "speedchex":[],
      "versapay":[],
      "nacha":[]
   }
}

The arrays correspond to:

• Authoriz.NET (anet)
• SpeedChex (speedchex)
• VersaPay (versapay)
• NACHA files (nacha)

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 for working in LoanPro you will only need the processor name (the name field), whether or not it is the default processor (the  default field), 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 will work the  same way as normal, but will have an additional field called mcProcessor. The mcProcessor field contains information about which PCI Wallet Processor should be used when processing the AutoPay. It will be a stringified json object. The json 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 with an id field of the group the processor is in (anet, speedchex, nacha, etc), a name field with the name of the processor, and a default field with whether or not the processor is the default processor. Below is an example for a nacha file processor called RCC:

{
   "bankAccount":
   {
      "id":"nacha",
      "name":"RCC",
      "default":0
   }
}

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}}

Payment Processing

Payment processing will  work the same as normal but with one difference: it will now have 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:

https://loanpro.simnang.com/api/public/apli/1/tenant/easypay/processors

Note: This id is relative to the order in which LoanPro returns it, not when items were created!

Note: Any changes to payment processors will change the id! Keep this in mind or else payments will be sent to the wrong processors

The order id starts with 0 and moves from top to bottom, and is not reset when moving between processors. This means that the first entry in anet will always be 0, regardless of when it was inputted 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
  • PreProcessed

The ordering ids would be as follows:

• Card Main – 0
• Card Backup – 1
• VP1 – 3
• VP2 – 4
• PreProcessed – 5

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

• Card Backup – 0
• SpeedChex – 1
• VP1 – 2
• VP2 – 3
• PreProcessed – 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
• PreProcessed – 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"