Secure Payments API – Getting Started


Audience: Developers, Data


If you're familiar with our products, you'll know that we have several: the Loan Management System (LMS), Secure Payments, and Connections. Of those three, we offer an API for LMS and Secure Payments—enabling you to integrate your software with ours. You may already be familiar with the LMS API, and we have a library of articles to read through if you'd like to learn a bit more. In this article, we'll specifically cover the Secure Payments API. Here, we'll cover the basics and explain how it differs from the LMS API.

If you're unfamiliar with the topic of APIs and would like to learn the essentials, our APIs 101 article is a great place to start.

The Secure Payments API

Like mentioned above, the Secure Payments API differs from the LMS API. Since Secure Payments and LMS are two separate products at the fundamental level, their respective APIs are separate as well. The Secure Payments API uses slightly different headers, endpoints, and payloads than requests made via the LMS API. Let's go over what is required to start sending Secure Payments API requests.

Why are Secure Payments and LMS two separate products?
Allowing Secure Payments to function separately from LMS creates an extra layer of protection for your payment information. Secure Payments is PCI-DSS compliant (Payment Card Information-Data Security Standards), and we maintain that compliance by keeping it separate from LMS.


The Secure Payments API will look for two authentication headers: Secret and Authorization. These two authentication tokens are created when you link your LoanPro and Secure Payments accounts. You can find this information by logging into LoanPro and navigating to Settings > Company > Merchant > Secure Payments.

These two tokens do not expire, and you can generate new tokens at any point if needed. Your Secure Payments API headers will need to be formatted like the following:

Secret: AQIDAHh...

Authorization: Ulo5UVJ...


The Secure Payments API also uses different endpoints. This is how the URLs used for Secure Payments requests are formatted:

Base URL

URL Path




The base URL will always remain the same for each Secure Payments API request. However, the URL path will change depending on the request you're making. For example, the URL paths listed in the table above are used for different requests such as generating NACHA files, pulling credit card information, or processing a payment through


Like the LMS API, the payloads used in Secure Payments PUT and POST requests are sent in JSON format. If you're familiar with the LMS API, you'll notice that the two APIs are slightly similar in how payloads are built. However, Secure Payments API payloads tend to be a bit smaller and simpler than LMS API payloads. Here are a few sample payloads for some common requests:

Process Authorize.Net Payment
"card": {
"token": "QVIR8sdl20k..."
"transaction": {
"amount": 10.00
"metadata": {}
Create a Callback
"callback": {
"event": "password-update",
"url": "",
"enabled": true
Create a NACHA Processor
"company_name":"Prime Lending",
"bank_name":"WELLS FARGO BANK",
"discretionary_data":"Accounts are numbered",
"name":"Wells Fargo Processor"

Common Questions

Is a Content-Type header required? No, the Secure Payments API does not require content type to be specified.

When I use the Secure Payments API, will it update my Secure Payments and LoanPro accounts automatically? It depends, but the answer is often no. While they do work in tandem, LMS and Secure Payments do not often automatically update the information in the other software. They only update the information stored in the other software automatically in specific circumstances, like when you link payment profiles to customers in LMS and when you use Secure Payments Events.

Why is the Secure Payments API separate from the LMS API? As we mention above, the two are separate pieces of software. And as such, their APIs are separate products. You'll need to use the Secure Payments API to handle anything you use Secure Payments for—like creating payment profiles, processing payments, creating NACHA files, and more. LMS does not have these capabilities, and neither does its API.

What’s Next

With the basics down, you should now start testing your connection to the API and building your own requests. For more information on the Secure Payments API, take a look at our Secure Payments API category. For information on how to use all of our API requests, head over to our ReadMe site where you can view our documentation as well as try some requests yourself.

How did we do?

Powered by HelpDocs (opens in a new tab)