While progress is being made to modernize ACH processes, the U.S. banking system as a whole is not always straightforward. Truthfully, navigating through the world of ACH can be quite daunting at times. With all the complexities, one would assume that developing an application to facilitate bank-to-bank transfers would be an arduous task. However, with Dwolla’s Access API, you can integrate technology that helps you facilitate bank-to-bank transfers.
When an application involves facilitating the transfer of money to or from a bank account there is the possibility of transaction failures. This possibility is simply a part of transferring funds within the ACH network. Instead of leaving the handling and processing of ACH errors up to the business, the associated financial institution that rejected the transaction will assign an ACH return code when a bank transfer fails.
Let’s walk through how ACH return codes play out in relation to the Access API. Understanding how the API handles transfer failures in the Sandbox will help avoid unnecessary confusion when you deploy into Production.
When you think about how these failed ACH transactions play out in relation to Dwolla’s Access API, you might have a transfer that ends up failing. By calling the API to retrieve a transfer failure reason, you will receive a receipt of the return code from the financial institution letting you know why the transaction failed. Transfers facilitated by your application can be returned as failed by a financial institution days, or even weeks after they were initially created. For this reason, you will want to account for and test ACH return codes and scenarios prior to going live with your Access API Integration.
In the Sandbox environment, Dwolla allows you to trigger various bank transfer failures by specifying an “R” code in the funding source name parameter when creating or updating a funding source for an Access API Customer. When a transfer is initiated using a funding source that has an “R” code assigned to its name, a transfer failure event will trigger and the status will update to failed when you simulate bank transfer processing. Let’s walk through two testable scenarios of transfer failures in the Sandbox environment using two Verified Personal Customers.
R01 — Insufficient Funds
Sometimes there is just not enough money available in a bank account. When this happens, a financial institution can return an R01 return code. For this example, let’s consider how a transaction could play out between two verified Customers in the Access API. Sam (source) has a questionable bank account. He doesn’t have enough money in his account to transfer funds to Darren (destination), but he initiates a transfer anyways. Since Sam doesn’t have enough money to cover the transaction he initiated, the transfer will fail. In the Sandbox, we can test the transfer to see what will happen during this transaction.
Setting the transaction up in the Sandbox
To test the transaction in the Sandbox, you can create or update a funding source by changing the `name` to R01. You can now initiate a transfer with the Source of the transfer being the R01 bank account.
In a transfer scenario between two Personal Verified Accounts, you can expect these webhooks to be fired.
Sam initiated a request to transfer money from his bank account to Darren’s bank account. However, the money was not moved from Sam’s bank account because Dwolla was unable to complete the transaction; there were insufficient funds. In order to avoid an ACH return the next time, Sam will need to initiate another transaction when he does have sufficient funds.
R03 — No Account/Unable to Locate Account
Now let’s talk R03 codes. Imagine making a mistake when typing, it’s not hard to do. An R03 Return Code can come up for a couple reasons, but one of the more common reasons is when a bank account number or routing number is mistyped when creating a bank funding source.
For instance, when micro-deposits are initiated, this can still be considered a transfer, as funds are being sent to a destination. If an account number was mistyped and micro-deposits were initiated, these will be unable to clear. Let’s imagine a scenario Sam wants to initiate micro-deposits to his new bank account for the purpose of bank funding source verification. If he ends up mistyping his bank account number, the microdeposits will have no place to settle. Dwolla will receive an R03 return code and will automatically remove the bank funding source.
Set this up in the Sandbox
To test this in the Sandbox, you can create or update a funding source by changing the `name` to be R03. You can now initiate microdeposits to this bank funding source.
In this scenario, you can expect these webhooks to be fired.
Dwolla was unable to clear the microdeposits to Sam’s bank, as it was unable to be found. The bank funding source will be automatically removed. The application will allow Sam to add another bank account and try again.
Bank transfer failures are not the only things you need to test for when getting started with the Access API. You can check out our documentation for tips on how to simulate transfer all of our failures in the Sandbox.
With a powerful set of tools at your disposal, testing in the Sandbox is intuitive. Remember that the transfer of funds is simply the movement of data, and utilizing Dwolla’s powerful API’s can facilitate quick and reliable transfers for a variety of scenarios.
We'll help you design your ideal payments experience. We’ve sent you a message to kick off the conversation with our team. Please check your inbox. There was an error and the form was not submitted.
Get started with ACH transfers
We'll help you design your ideal payments experience.
We’ve sent you a message to kick off the conversation with our team. Please check your inbox.
There was an error and the form was not submitted.