Securely store and tokenize your customer's bank account information, then use the token to create payments and see transaction history
Our platform has been designed specifically around processing ACH transactions. To learn more about how ACH payments work, please see our section on ACH Payments
In order to process ACH transactions, you must obtain the routing and account number of your customer's account. Obtaining this information can be challenging, as customers don't typically memorize these numbers or carry these
numbers on them the way they do credit and debit cards. To solve this problem, we have designed a user-friendly widget that can be implemented directly in your webpage or mobile app that can obtain your customer's routing and account
number by using their online banking credentials. By using our widget, all data transmission is secure, and no sensitive data (such as your customer's online banking credentials or account numbers) is transmitted through or stored on your
platform. Using our enrollment widget to obtain your customer's account information works seamlessly with our API, and all enrolled accounts can be accessed through our API using the account token returned from the widget.
For more information on our enrollment widget, please visit the Widgets home page.
For security and compliance purposes, we do not offer API endpoints for direct integration of obtaining bank account information from a user's online banking credentials.
The API endpoints available for adding accounts will require your customer's routing and account number.
When an account is created, it's sensitive information is securely stored and becomes inaccessible. This protects you and your customer's sensitive data, so that no account information can be retrieved from our API.
A token is then used to reference the account any time a payment is created or information about an account is requested.
You can provide your own account token to the POST /accounts/account endpoint. The token you provide could be a
reference number to something in your own system. If no token is provided when you create the account, a unique
GUID will be created as the token. You can store this token in your system and use it for reference or rely on our
GET
Accounts
endpoint to bring up a list of accounts each time a payment is created.
There are no endpoints available to return a full account number from our API.
Account Statuses
The following statuses can be assigned to an account
Open - By default, all accounts are Open when created
Closed - Accounts are marked as closed when they are deleted using the API.
When an account is marked Closed, you will be unable to schedule payments against this account, and all recurring or scheduled payments for this account will stop when the status changes.
Once an account is closed, it cannot be re-opened.
Locked - Accounts can become locked automatically when certain payments are returned on this account. This feature is a safeguard so you do not receive multiple returns and mitigate your risk.
For example, if we receive a return on a payment against a closed account, we will lock the account to prevent future returns. Please check with your contract terms to see the exact reasons why me may lock accounts.
Deleted - This status is used in the test environment when an account has been permenately deleted and should not appear in results. There is no user-facing method to change this status,
and would be performed internally upon your request.
Creating an Account
We recommend adding accounts using our enrollment widget. Using our enrollment widget keeps all sensitive data, such as account numbers and online banking credentials, out of your environment and stored securely in our environment.
In addition, our enrollment widget offers alternative methods of enrolling your bank account, such as using your online banking credentials to obtain the routing and account numbers. For more information about our enrollment widget,
or to see a demo of how the widget works, please visit our Widgets home page.
If you create an account using our enrollment widget, the use of the widget replaces this step. The widget will create the account and return an account token (account ID),
which you can use the same way you would use the account token returned from this API call
To create an account directly from the API (not the widget), you will need to obtain your customer's routing number, account number, and account type.
You will also need to create a customer first. You will provide the CustomerId in your POST call to add an account, which will associate the account with the customer
To create the account, send a POST call to /accounts/account
You can provide a unique account token to reference this account, or leave the token empty and a unique GUID will be created as the token. This token can then be used to reference this account in the future or to make a payment using this account.
Once an account is added to a customer, it will be visible through our website by looking up the customer.
Account Information from the Widget
When using the widget to capture your customer's account information, you can choose whether or not to save the account with the customer. There may be situations where further due diligence needs to be performed on the account before
it should be associated with the customer, or the enrollment widget may be used solely to return account information to you. When using the widget to enroll an account, an enrollment token is provided that you can use to
reference that enrollment.
Saving an account
If the widget is customized to not save an account upon successful enrollment, you will need to capture the enrollment token and POST to /accounts/enrollment/account to save the account for the customer.
If you require routing and account numbers from accounts enrolled from the widget, you must call the enrollment endpoint within 24 hours of the enrollment. After 24 hours, you will be unable to obtain the account information.
get /accounts/enrollment/account/{enrollmentToken}
You can retrieve an account using the token that was provided at the time the account was created. If you have an enrollment token rather than an account token, you will first need to save the account using the enrollment token, which will provide an account token.
You can also obtain all accounts for a customer. This is helpful in scenarios where you add a customer's account to their portfolio, then let the user chose at the time of payment what account to use.
This scenario eliminates the need to capture account tokens using the widget - The use of the widget will save the account and associate it with your customer. Then, when you are ready to create a payment,
call the All Accounts endpoint to bring back a list of all enrolled accounts.
To remove an account, make a DELETE call to accounts/account/{accountToken}. Deleted accounts are soft-deleted from our system, and will have a status of Closed.
Once deleted (closed), you will still be able to access this account, but will be unable to schedule payments from it.
Once an account has been deleted, it cannot be re-opened.
This will stop future scheduled payments from processing from this account. Payments that are scheduled to run the current business day may still process.
You can perform a risk inquiry on a bank account before you add the account. By doing so, you can decide whether you
want the account to be added to the customer or not, depending on the associated risk.
If you are using our enrollment widget, account risk inquiry can be performed automatically when customers enter their
routing and account number. You can then use a set of rules to determine whether users can continue and add their
account or receive an error message back. The response given to your customer can be customized to match your
needs. Acceptance levels and custom messages are controlled internally by CFS. To discuss these options or change your
settings, please contact your CFS representative.
To perform an account risk inquiry through our API, make a POST call to /verifications/riskInquiry.
The following information will need to be included in your POST call:
RiskInquiryTypeId = 2 (Account Verification)
The AccountVerificationInformation model, which includes: