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?
The Secure Payments API will look for two authentication headers:
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:
The Secure Payments API also uses different endpoints. This is how the URLs used for Secure Payments requests are formatted:
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 Authorize.net.
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
Create a Callback
Create a NACHA Processor
"bank_name":"WELLS FARGO BANK",
"discretionary_data":"Accounts are numbered",
"name":"Wells Fargo Processor"
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.
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.