Secure Payments settings
Managing your settings in Secure Payments.
These settings control how Secure Payments works. The profile section shows you your API credentials, the email where notifications are sent, and MFA settings. On the processors page, you can create and edit all of you payment processors.
You can set up webhooks to send information after specific events. You can also customize the styling for your Secure Payments iframe. Lastly, you can configure bank card and bank account controls.
Profile
The payment profiles section of Secure Payments is where you can add a payment profile for your account. This payment profile will be used to add funds to your account. To add a new payment profile, click the blue plus icon in the top right corner.
The following payment profile window will display and ask for basic card information such as cardholder name, card info, and billing address. Once you've entered the necessary information, click 'Save.'
After clicking 'Save', your payment profile information will be tokenized to ensure security.
You can use this token to access the payment profile through the API.
Secure Payments does not save the token, so this is your one chance to save it. Make sure to keep it in a safe place.
Processors
Here, you can add and manage instances of LoanPro's integrated payment processors. We actually recommend creating new processors from within LMS. For more details, check out our articles on creating payment processors and the individual articles for each processor.
Card programs
This tab shows all the card programs you've created, organized by issuer. You can edit, or toggle the activity for all programs, and delete programs if they don't have any active cards.
Card issuers
Here you can manage your configurations with card issuers.
Banking insight providers
Here you can manage your settings for banking insight providers, like Finicity. For more information on using banking insight providers, reach out to your regular LoanPro contact.
Events
Much like how LMS can send webhooks, Secure Payments can send information to a specified URL when certain events occur. In this article, we will explain how to add events to your Secure Payments account and provide some of the callback URLs used to link to your LoanPro account.
Adding Secure Payments Events
Full List of Events
- User password update
- Nacha file generation
- Swipe event created
- Card updated
- Bank account created
- Transaction status update
- Banking insight disconnected
- Galileo Pro event received
- Bank card update
- Card reissued
- Processor deleted
- User settings update
- Processor update
- Lithic event received
- Bank card deleted
- Card created
- Bank account updated
- Bank account deleted
- Visa DPS Forward event received
- Visa DPS Forward report received
- Nacha batch generation
- Payment processing
- Swipe created
- Card balances updated
- Card status updated
- Bank card created
- Processor created
- Swipe created
- Job update
To view, edit, and delete events, navigate to Settings > Events inside your Secure Payments account.
Here, you can also use the toggle switches to the right of an event to turn it on or off. To add a new event, click the blue plus icon in the top right.
Next, select the event type for which you want to add a URL from the 'Event type' drop-down. Then, enter the URL in the URL field. You'll notice that each Secure Payments event can have up to 5 callback URLs. Click 'Save' to add the event to your settings.
Required Event Configurations
The NACHA Batch Generation, NACHA File Generation, and Transaction Status are required events, as they communicate to the database and LoanPro's Loan Management System (LMS) when these events occur. All other events are optional, but we recommend setting them up if you'd like Secure Payments to send information to LMS.
NACHA Batch Generation

If you add the LoanPro callback URL for NACHA file generation, LoanPro will be updated with NACHA batch IDs. The batch IDs are assigned by Secure Payments for transactions processed with a NACHA processor. This is useful, as it will let you pull payments based on their batch ID.
To search by NACHA batch ID, go to Reports > Transaction History > Batch ID
LoanPro Callback URL:
https://loanpro.simnang.com/api/public/thirdparty.php/pciw/nacha-batch-generation/callback
NACHA File Generation
If you add the LoanPro callback URL for NACHA batch generation, LoanPro will be updated when a NACHA file is generated.
LoanPro Callback URL:
https://loanpro.simnang.com/api/public/thirdparty.php/pciw/nacha-file-generation/callback
Transaction Status
Including the LoanPro URL for transaction status updates will update payments' transaction status as they move through the payment process in Secure Payments.
If a payment is reversed, the r-code is included in the transaction status update callback.
LoanPro Callback URL:
https://loanpro.simnang.com/api/public/thirdparty.php/pciw/transaction-updated/callback
Other events
As we mentioned above, these events are not required to be configured. But they are available if you'd like to use them. Here's a breakdown of what's available:
Event | Description | Response Example |
Bank Account Create | Sends a notification when a new borrower bank account is created in Secure Payments. |
|
Bank Account Delete | Sends a notification when a borrower bank account is deleted in Secure Payments. |
|
Bank Account Update | Sends a notification when a borrower bank account is updated in Secure Payments. |
|
Bank Card Create | Sends a notification when a new borrower credit/debit card is added in Secure Payments. |
|
Bank Card Delete | Sends a notification when a borrower credit/debit card is deleted in Secure Payments. |
|
Bank Card Update | Sends a notification when a borrower credit/debit card is updated in Secure Payments. |
|
Card Balance Update |
Sends a notification when the balance of a card is updated.
|
|
Card Balance UpdateWe added the ability to select whether the "Card balances updated" webhook that's sent from Secure Payments provides the card's "real" balance or "optimistic" balance. This update provides greater control over the card balance information you receive from Secure Payments via webhooks and helps prevent over-authorization due to rapid transaction attempts. This option only applies to cards issued via a Bring Your Own Issuer (BYOI) configuration, and the option is can be determined for each Issuer configuration via the Card balances updated webhook trigger option of an issuer's settings. Here's a description of each balance type and how they differ:
| ||
Card Created | Sends a notification when a new card is created |
|
Card Status Updated | Sends a notification when a card's status is updated |
|
Card Updated | Sends a notification when a card's details are updated. |
|
Job Update | Sends a notification when an asynchronous job process is used to update an entity such as a card or card program. |
|
Payment Processing | Sends a notification when a payment is processed in Secure Payments. |
|
Processor Create | Sends a notification when a new processor is created in Secure Payments. |
|
Processor Delete | Sends a notification when an existing processor is deleted from Secure Payments. |
|
Processor Update | Sends a notification when an existing processor is updated in Secure Payments. |
|
Swipe Created | Sends a notification when a swipe is created. The transaction information provided when created the swipe is included in the notification. |
|
Swipe Event Created | Sends a notification when a swipe event is created. |
|
User Settings Update | Sends a notification when user settings are updated in Secure Payments. |
|
User Password Update | Sends a notification when the user password associated with a Secure Payments account is updated. |
|
Visa DPS Forward report received | Sends a notification when a report from Visa DPS is uploaded to your account. |
|
Iframe CSS
To maintain payment card information (PCI) compliance, applications integrated with Secure Payments are required to use the Secure Payments iframe. It may be helpful to change the iframe style so it matches your user interface (UI). Secure Payments offers some custom styling options to make this possible.
To use the custom styling in Secure Payments, navigate to Iframe CSS: Menu > Settings > Iframe CSS.

The following styling options are available for the iframe:
- Font – This selection lets you choose the text font for the iframe. Available options include:
- Arial
- Arial Black
- Comic Sans
- Courier New
- Georgia
- Impact
- Times New Roman
- Trebuchet MS
- Verdana
- Select Color – This color will display when a field is selected.
- Button Color – This changes the color of the buttons. Use a HEX code to get a specific color.
- Button Hover Color – This will change the color of a button when the cursor hovers over it. Use a HEX code to get a specific color.
These values will save automatically as you enter them.
Additionally, you have the ability to set a default country for the Secure Payments iframe.

Select United States or Canada, depending on what region you are in.
The Secure Payments iframe is also mobile friendly, so your customers should have no issues using the iframe on their handheld devices.
Bank cards control
These controls let you restrict which cards you'll accept payments from by looking at their Banking Identification Number (BIN), the first four to six digits on the card which indicate the account's type (debit, prepaid, etc.) and brand (Visa, MasterCard, etc.). When a payment profile with a bank card is created in Secure Payments, the system can use the BIN to determine the account's type and brand. All you have to worry about is whether you want to accept those types of payment profiles.
Using BIN ranges, Secure Payments can restrict certain types or brands of card with the click of a button. Within Secure Payments, you'll find these features under Settings > Bank Cards Control in the navigation pane at the left.
Secure Payments will only be able to block unwanted payment profiles if "Card Attribute Lookup" has been turned on (see below).
Types
The first set of controls allow you to restrict certain types of cards. If you don't want your customers paying with a credit card, for instance, you would just switch off 'Credit'. If you only wanted customers using prepaid debit cards, you would leave 'Prepaid' and 'Debit' on but switch off 'Credit' and 'All Others'.
Brands
The next set of controls governs which brands of cards are accepted, and the controls work just like the Types settings above. If you don't accept VISA, you would simply switch it off. If you only accept these four major brands, you would leave them on and switch 'All Others' off.
BIN Attributes
This last control determines what will happen if the BIN is not recognized. With this option on, you will still accept payment profiles even if the BIN attributes are not available. With this option off, you will not accept any payment profiles with unrecognized BIN attributes.
Card Attribute Lookup
All of these controls use cards' BIN ranges, but if your Secure Payments account doesn't lookup those ranges, it cannot block unwanted payment profiles. To turn on Card Attribute Lookup and enable Bank Card Control, go to My Account > Actions in the navigation pane on the left of the screen, and ensure 'Card Attribute Lookup' is turned on.
If you try to use Bank Card Control settings without Card Attribute Lookup, Secure Payments will display a notification with a link to turn it on.

Bank account control
NACHA has supplemented their fraud detection standards by requiring that lenders validate their borrowers' bank accounts. LoanPro is integrated with ValidiFI, whose services can help you validate your borrowers' bank accounts. These tools enable you to detect and prevent fraud, and maintain compliance with NACHA's due-diligence rules or any laws that your company is subject to. NACHA recognizes them as a preferred partner for account validation, meaning they can be trusted to provide top-tier service in this area.
ValidiFI's integration with LoanPro makes it simple and easy to validate any payment profiles you've entered on Secure Payments.
What are their service levels?
Through Secure Payments, you have access to three tiers of ValidiFI account validation: Basic, Standard, and Enhanced. All three tiers satisfy NACHA's standards, but the Standard and Enhanced options provide more information.
- Basic: Basic searches cost $0.34 per validation. They authenticate the routing number structure and status, and ensure that the account number conforms to the routing number. They also identify the most basic errors associated with data entry and outdated information.
- Standard: Standard searches cost $0.66 per validation. They do everything the Basic search does, as well as screen and validate the payment profile against ValidiFI’s network of payment, banking, and merchant contributors. This helps eliminate common errors and confirm the status of routing and bank account numbers.
- Enhanced: Enhanced searches cost $0.99 per validation. They do everything that the Basic and Standard searches do, and then verify routing and account numbers against an expanded list of sources. This search will return account attributes associated with the score. This is ideal for ensuring maximum coverage and identifying the account's status. It also identifies accounts associated with administrative returns.
Here's a breakdown of the different analytical tools applied with each tier of validation:
Analytics Tool | Basic | Standard | Enhanced |
Routing Number Validation | X | X | X |
Account Number Structure | X | X | X |
ValidiFI Bank Risk Data | X | X | X |
Third Party Data | X | X | |
Merchant Data | X | X | |
Banking Data | X | X | |
ValidiFI Insights Data | X |
Configuration
Within Secure Payments, click 'Actions' on the navigation pane on the left of the screen.
This page lists the different actions available in Secure Payments and lets you toggle each of them on or off. ValidiFI's services are listed as 'Bank Account Attribute Lookup', found near the bottom.
The drop-down menu lists the available service tiers.
Validating an account
Now that you've turned on bank account controls, the system will automatically validate any payment profiles you add. That validation happens any time the payment profile is saved or edited. Once you've created a payment profile, just navigate back to it in the Secure Payments UI and you'll see all the information ValidiFI found on the account. Add or edit a payment profile, then go to Customers > select a specific customer > Payment Profiles.
The Validation Response is a result, shorthand for what ValidiFI discovered. If there is an issue, it will be explained in the Message. This basic validation sample gives a result code of AVC8, and the message explains that while the routing number is valid, that bank has never used account numbers like the one this borrower gave. This would indicate either a simple typo or perhaps an attempt at fraud; in either case, the payment profile is likely unusable.
Result codes and controls
When an account is validated, the system will give you a result code explaining the results. You can configure your settings so that Secure Payments will not attempt to process payments from profiles with the result codes you specify. In the navigation pane at the left, select Bank Account Control.
Toggling each result will determine whether the system will attempt to process payments with those codes. If a result code is turned on, the system will accept payment profiles that return it.
The Basic validation will only return AVC0-5, and AVC8-9. The Standard and Enhanced validations will return any AVC, and the difference between the two is the level of detail provided in the response, with the Enhanced responses containing much more data.
This table explains what each indicates:
Result Code | Result | Message |
AVC0 | Unexpected Service Disruption | An unexpected service disruption with one or more data sources occurred. |
AVC1 | Invalid Routing Number Structure | The Routing Number structure does not conform to the ABA standard. |
AVC2 | Suspected Bad Routing Number | The Routing Number structure conforms to the ABA standard but has a history of returns for an invalid routing number |
AVC3 | Routing Number Not Found | The Routing Number is not found within the ABA list of Routing Numbers. |
AVC4 | Routing Number is Not ACH Capable | The Routing Number is not Active, not ACH capable, or is of the wrong type according to the ABA list of Routing Numbers. |
AVC5 | Suspected Bad Account Pattern | The Routing Number is valid, active, and is ACH capable. The Bank Account Number is suspected to be invalid, or has a length or pattern with a history of returns for invalid account. |
AVC6 | Valid Account with History of Recent Returns, Unpaid, or Stop Payments | The Routing Number is valid, active, and is ACH capable. The Bank Account Number is valid and there is recent histrory of returns/unpaid or stop payments seen in ValidiFI's database. |
AVC7 | Valid Routing Number with Limited Account Pattern and No History of Recent Transactions | The Routing Number is valid, active, and is ACH capable. There is limited history of the Bank Account pattern and no history of recent transaction seen in ValidiFI's database for the provided Bank Account Number.The Routing Number is valid, active, and is ACH capable. There is limited history of the Bank Account pattern and no history of recent transaction seen in ValidiFI's database for the provided Bank Account Number. |
AVC8 | Valid Routing Number with No History of Account Pattern | The Routing Number is valid, active, and is ACH capable. There is no history of the Bank Account pattern seen in ValidiFI's database for the provided Bank Account Number. |
AVC9 | Valid Routing Number and Account Pattern | The Routing Number is valid, active, and is ACH capable. The Bank Account pattern is valid. |
AVC10 | Valid Routing and Bank Account with Recent Transaction History | The Routing Number is valid, active, and is ACH capable. The Bank Account Number is valid and there is recent history of Bank Transaction seen in ValidiFI's database. |
AVC11 | Valid Routing and Bank Account with Verified Good Transaction History | The Routing Number is valid, active, and is ACH capable. The Bank Account Number is valid, has history of good transactions, and there is no recent history of returns seen in ValidiFI's database. |
NV | 99 | Not Validated |
Was this article helpful?
Unclassified Public Data