Processing Payments

Transactions Through LMS vs Secure Payments

If you are a user of LMS and Secure Payments, it is generally preferable to submit new payments to LMS instead of Secure Payments. At first glance, this may seem a bit counterintuitive considering Secure Payments has "Payments" right there in the name. In reality, Secure Payments is intended to be set up and left alone, and users can instead interact with Secure Payments through LMS. This arrangement stems from the other part of the software's name, "Secure". Managing payments requires that the software be PCI compliant, but there's no practical need for PCI compliance in other aspects of loan servicing; so, we've sectioned off all the actual payment processing to Secure Payments leaving LMS free from PCI requirements.

How does this work in practice? A payment processor is created in either LMS or Secure Payments (it'll be saved to both). Then, a loan is creating and linked to a customer with a payment profile. This profile is technically always saved in Secure Payments, but it can be made through a Secure Payments iFrame inside of LMS. With profile and processor in place, a payment is logged in LMS. LMS communicates this to Secure Payments, which, in turn, works with our integrated payment processors to move money from the borrower's account into yours.

Alternatively (though we recommend against this), you can log into Secure Payments and initiate a transaction there, but Secure Payments does not communicate back to LMS.

To submit a payment through the LMS API, see the Add New Payment endpoint.

Payments Through the API

When adding new payment transactions to Secure Payments through the API, there will be some variance based on the processor used. However, each call will use an endpoint and payload that have many similarities.

The endpoint is structured like so:

https://securepayments.loanpro.io/api/processors/{Processor_Type}/process/{Processor_ID}

The Processor_Type will be replaced with the appropriate option from the list below:

• versa
• anet
• tabapay
• speedchex
• loanpaymentpro-cc
• loanpaymentpro-ach

The Processor_ID will be replaced with the ID of a processor. To create a processor, see the endpoints in the Processors section. Make sure the ID you use corresponds to a processor with the same Process_Type provided in the URL. To pull a list of your processors, see the Get Processors endpoint.

The payload for each call will include 3 objects: transaction, payment method, and metadata. The payload will look something like this:

{ 
   "transaction": { 
     "amount": 1.00 
   }, 
   "card": { 
     "token": "QVFJREFIalVqRlk3bHJIVFJFWERTSFljS3R6R1haaFNNNEFJVjkwbWFlalRZUEw3RmdIandScHFDU3Vma0VaUm95VXRud05TQUFBQWZqQjhCZ2txaGtpRzl3MEJCd2FnYnpCdEFnRUFNR2dHQ1NxR1NJYjNEUUVIQVRBZUJnbGdoa2dCWlFNRUFTNHdFUVFNK1YzUDNmZW9BNTYzVTFJYUFnRVFnRHRQWmhtcG1CM1lIRUtNVUNRTXdTRTFkWnRNUmsxcTRsNXg1ZDlyTWNzT0oyUnplSnBzanBsdHpEbUdURlpKbDgzTTJLRGM2SFZZYmR4VEdnPT0udG9rVVBreXRkRVRMWW8xU2NZMW91dz09LkFRSURBSGpVakZZN2xySFRSRVhEU0hZY0t0ekdYWmhTTTRBSVY5MG1hZWpUWVBMN0ZnSGp3UnBxQ1N1ZmtFWlJveVV0bndOU0FBQUFmakI4QmdrcWhraUc5dzBCQndhZ2J6QnRBZ0VBTUdnR0NTcUdTSWIzRFFFSEFUQWVCZ2xnaGtnQlpRTUVBUzR3RVFRTStWM1AzZmVvQTU2M1UxSWFBZ0VRZ0R0UFpobXBtQjNZSEVLTVVDUU13U0UxZFp0TVJrMXE0bDV4NWQ5ck1jc09KMlJ6ZUpwc2pwbHR6RG1HVEZaSmw4M00yS0RjNkhWWWJkeFRHZz09LmdheFNoclhkbzhhRWlKMHZ3MmpZNzE5VDFIbzB4dXkwWXA3ZHg5NkFmTU5mSXk5TG5iN05HVk4xVmpQQ2diRUU4Sk91SDFlcXZ1dDQ0bGNESVpNRkdPNXJ2R3FjelNWK3BzaS9QMWFGTCtQd3NvLytRZE5oekJ0Vkc2U2NCWGtoZXN5eHVMQ2xJUW5oTGJQa242c2RvUzFvQ1JnOThWZXZDNTNNWTJSNWV5ZHY5TU1zN0N0dk0zT2R5NFVKNnJYcWxpZUFTNHRUc29VeUt5SWJ2cDY4YzBwUzRaeC9CM3BKN3JhOEhTWGc1Mm0zdEh3REIxcU9VNEhBcHJya0ZUN252dEt3MjhCbHZGQUNTd1ljTytSclhFd3I4OHZ6RS85UVVaRzNTMW1wcU5PeGdacW5JOHNZTkZUSWNkQkZHVDJra256NnB6T3B1UjI4OFdPVkFuZVVzblM3WWFReTgxSnJKRkR4cWlvYWU4VT0"
   }, 
   "metadata": {} 
}

The transaction object will always contain the payment amount, but it may also contain other things (e.g. the direction of funds) depending on the processor and the functionality they offer.

The payment method object will be named card, checking-account, or savings-account, depending on the payment method. It will always contain the token for the payment profile that will be used to process the payment. This is the token returned by Secure Payments when the payment profile is created.

The metadata object is typically empty but can contain properties. Even if it's left empty, this object is required for the call.

For more information about each processor and how to run transactions, see their respective pages on this site or our general help site: Secure Payments API – Payment Processors