Skip to content
Credit9 Roadmap
Credit9 Implementation Guide
More
Share
Explore

Credit9 Implementation Guide

The guide below will help with implementation specific to testing your LoanPro implementation while the linked reference material covers best practices and requirements across the broader ACH ecosystem
What's an ACH authorization?
Proper authorization is the key to avoiding chargebacks
Account Validation: It's a thing
Is your business compliant?
Data Security: This is the way
A simple guide to Nacha requirements
Testing Overview
The system integration test of the ACHQ + LoanPro system should validate from both the requirements perspective and business perspective that:
Payment requests originated in LoanPro are received by ACHQ
Payment status event tracking is relayed from ACHQ to LoanPro
Payment requests originated by Credit9 via ACHQ contain the correct statement identifiers
Successful payments are deposited into the appropriate Credit9 account by ACHQ
Payment reversals, or when an ACH return is transmitted post “settlement” are properly identified and reconciled
Additional testing required within LoanPro that ACHQ events trigger the appropriate notifications and/or actions
The objective of system integration testing is to validate the system operation as a whole and with each system. At the conclusion of testing, the project team and the test team will have a high level of confidence that the system will work according to user requirements and will meet business needs.
Features to be tested
Create borrower profile(s) within the LoanPro system and ensure that the account payment method is properly configured for ACHQ payments in the sandbox environment
Conduct a simulation of a successful (cleared) ACH payment by initiating a test debit transaction to the ACHQ sandbox using a bank account not detailed on the
Simulation data
⁠
table. The transaction will undergo the
Status Events
⁠
detailed below resulting in a “Cleared” status the next business day.
Optionally, test ability to Update or Cancel a payment. NOTE: This can only be done with the payment status is equal to “Scheduled” in ACHQ or the corresponding mapping in LoanPro. Once the payment is delivered to the ACH Operator it cannot be changed or stopped.
Conduct a simulation of a successful (cleared) ACH payment that is subsequently “charged-back” by initiating a test debit transaction to the ACHQ sandbox using the bank account number 444444444. The payment will be marked “Cleared” immediately and “Charged Back” the next business day
Conduct a simulation of an ACH administrative return by initiating a test debit transaction using the bank account number 222222222.
Conduct a simulation to generate an ACH “NSF” return by initiating another test debit transaction using the bank account number 111111111
Execute the simulations and verify that the LoanPro system updates accordingly and has the appropriate notifications configured
Perform live testing by initiating debit transactions from the LoanPro system, at least one - but optionally several - with a "good" bank routing and account combination that will successfully clear and one with a live routing number but an invalid bank account number 123456798765, which will fail.
The “good” bank account should be an internal company account so that you may view the statement line item and descriptor of the posted debit
Confirm the ACH descriptor, company name, and discretionary data (phone number) are correct and inline with expectations
Monitor the status of the transactions in the LoanPro system. Track the expected transaction lifecycle via the
Status Events
⁠
table.
Confirm deposit of “Cleared” live test debits correlate with a bank deposit in the target settlement account
Contact ACHQ relationship manager for any questions and go live.
Appendix
A conceptual overview of ACH debit clearing
⁠
Untitled scene.excalidraw.png
⁠
⁠
Application testing
Simulation data
0
Test Bank Account
Sandbox Testing Scenarios
Test Bank Account
Sandbox Testing Scenarios
1
111111111
Transaction status marked as Returned NSF on the next banking business day
2
222222222
Transaction status marked as Returned Other (administrative return) on the next banking business day
3
444444444
Transaction status gets marked Cleared and then it gets marked to Charged Back on the next business day
4
987654321
Transaction fails Express Verify and is immediately rejected
5
999999999
Fails bank account ownership authentication on the Echeck.VerifyPlus command
6
All other account numbers
Passes all bank account verifications.
There are no rows in this table
⁠
Don't use sensitive data when testing
This includes payment accounts, names, addresses, phone numbers, and email addresses. Please always use fabricated test information.
Status Events
0
Event
ACHQ Status
Description
Possible Actions
Event
ACHQ Status
Description
Possible Actions
1
Created
Scheduled
Payment is pending delivery to the Fed
Cancel a payment , Update a payment , Hold a payment
2
Submitted
In-process
Payment has been sent to Fed
None
3
Cleared
Cleared
Merchant or Receiver has been paid
Refund a payment
4
Failed / NSF
Returned-NSF
Payment failed due to the receiver not having enough funds to cover the debit
Create a payment
5
Failed / admin
Returned-Other
Payment failed due to administrative reasons (account closed, frozen, etc)
None (contact customer)
6
Charged-back
Charged Back
ACH return received after deposit was made
None (contact customer)
7
Bad bank account
Rejected
Bank account failed verification (pre-processing)
None (contact customer)
There are no rows in this table
⁠
LoanPro status labels may be differ slightly but represent a 1:1 match to ACHQ status

Testing Overview
Features to be tested
Appendix
A conceptual overview of ACH debit clearing
Application testing
Simulation data
Don't use sensitive data when testing
Status Events
LoanPro status labels may be differ slightly but represent a 1:1 match to ACHQ status
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.