Customer Website Authentication
LoanPro offers a pre-built customer website. While this website is not an optimal solution for all lenders, it can be configured and deployed quickly to give lenders the option of providing borrowers an online portal where payments can be made, loan information can be viewed, and personal information can be updated.
Some lenders choose to customize their own customer portal beyond the standard configuration offered by LoanPro. There are three primary ways that lenders provide a customer portal, and this article will cover the basics of how those options are implemented.
Option 1: Customer Portal Out-of-the-Box
Implementing the out-of-the-box customer portal is really simple. All our customer portal sites are hosted at the loanpro.software domain. A company-specific site will include a prefix (e.g. yourcompany.loanpro.software).
Authentication through the standard portal can be set up directly inside of the admin view of LoanPro.
Option 2: Embedded Login
LoanPro offers a way to embed the login for the customer portal site into another website. This is done either through an iframe, or is accomplished using the LoanPro API. This gives the flexibility of making the login area and fields look like the rest of the site in which they are embedded.
Doing this is relatively simple, as credentials to access the site can still be managed from LoanPro. Credentials and access management features include:
- Username and password creation
- Username and password reset
- Defining access to data and features once logged in
This option requires some amount of expertise in HTML and/or using the LoanPro API. It will also require that developers have access to make changes to the site into which the login will be embedded.
Option 3: Building Your Own Portal
This is the most customizable option, but is also the most difficult to accomplish. This option requires that you build your own website infrastructure and views and use the LoanPro API to retrieve data and make changes to the customer's account. This option requires your own development team and the ability to host your own website.
Clients who build their own customer portal often have questions about authentication and credentials management. There are two options for authentication:
- Use the LoanPro authentication endpoint and let LoanPro manage credentials
- Manage your own authentication
You can allow your customers to use the credentials created by LoanPro in order to log in to a customer portal you create. The following basic steps are required to to this:
- Create a login form that gathers username and password.
- When the login form is submitted, call the LoanPro customer authentication endpoint to see if the credentials are valid.
- Handle the success (200) or failure (401) responses to either grant access to customer data
- Use the customer id, returned with a 200 response, to get data for the correct customer through the LoanPro API
The endpoint for this call is as follows:
The payload should look something like:
For more information on the use of this endpoint, see the article here.
The benefits of doing things this way are:
- You can use LoanPro to manage credentials
- Assign usernames
- Generate passwords
- Reset passwords
Manage Your Own Authentication
When you choose to manage your own authentication, you will be required to do the following:
- Keep a database of usernames and passwords
- Create a way to add users and set usernames
- Ensure that each set of credentials is correctly associated with a customer in LoanPro
- Build a password-reset function
When you manage your own authentication, the basic process is as follows:
- Customer signs up to use your portal and creates a username and password
- The credentials are saved to a database (not hosted or provided by LoanPro), which associates then with the user's LoanPro ID and possibly other information
- This may be done by using a unique identifier for the user (e.g. email address) to query LoanPro to find the user's ID and add it to the database
- When the user logs in, they will enter their credentials, which should be compared against your database in order to authenticate the user
- If the user loses their credentials, reset functionality should be built
Managing your own authentication offers a few advantages. You can view, set, and reset user credentials; those credentials can be shared for a single login on any middleware or applications you control; and you ultimately have far greater flexibility, limited only by what you can program.
The drawback is that you will be responsible for creating all of your authentication and authentication-related features.