By Trevor Mills, ACH support and reconciliation lead with 8 years of experience handling bank-transfer failures and funding-source issues
Last reviewed: July 21, 2026
Dwolla provides account-to-account payment infrastructure that businesses embed in their websites and applications. It connects payment instructions, customer records and funding sources across ACH and supported real-time rails rather than operating like a typical consumer money-transfer app.
This independent guide is not operated by or affiliated with Dwolla.
The most useful first question is not whether a transaction “used Dwolla.” Identify which company initiated it and which bank account acted as the source or destination. That information determines where the transfer appears, who can see its full status and whether another attempt is appropriate.
What is a Dwolla funding source?
A funding source is the payment account referenced when money is sent or received through a Dwolla integration. Dwolla documents bank accounts and Dwolla Balance accounts as funding-source types, while current API materials list available processing channels such as ACH, real-time payments and wire transfers.
Funding sources belong to either a main Dwolla account or a customer record. That relationship matters because one business can operate an integration while maintaining separate payment accounts for many customers.
A customer may therefore link a bank account inside a marketplace, lending platform or billing application without managing that funding source through a separate public Dwolla dashboard. The application remains the visible service, while Dwolla provides the underlying payment infrastructure.
Do not create another account first. Return to the platform where the bank account was originally connected.
Bank accounts and Dwolla Balances are different
A bank funding source points to an external account commonly used as the source or destination of an ACH transfer. A Dwolla Balance is an internal funding source that can hold U.S. dollar value for eligible account types that have completed applicable identity-verification requirements. Funds held in a Dwolla Balance are held by Dwolla’s financial institution partners, not by Dwolla itself.
This difference affects both timing and reconciliation.
A transfer involving an external bank must pass through the applicable payment rail and financial institutions. Money already available within an eligible balance follows a different path inside the Dwolla network.
Funds can also accumulate in a balance unexpectedly. Dwolla’s documentation notes that this may occur when a payment cannot reach its intended bank destination because of an application error, ACH return or reversal.
That is an operations issue, not necessarily missing money. The business should identify the failed destination, locate the balance entry and decide whether the funds should be resent, returned or held while account information is corrected.
How account-to-account payments work
Account-to-account payments move money directly between payment accounts through rails such as the ACH Network and the RTP Network. ACH supports both credits and debits, while RTP transactions are credit-only in Dwolla’s comparison of the payment methods.
An ACH debit pulls an authorized amount from a bank account. An ACH credit pushes money to a receiving account. That distinction explains why a company may use one method to collect customer payments and another to distribute withdrawals or seller earnings.
Dwolla currently offers one integration across standard, same-day and real-time bank-payment options. The client chooses which speeds and rails to support according to its approved configuration and payment flow.
Faster is not automatically better. A routine collection may fit Standard ACH, while an urgent eligible payout might justify a real-time credit. Cost, bank coverage, return handling and payment direction should influence the choice.
Why Dwolla verifies bank accounts
Bank verification helps confirm that the connected account belongs to the user and can be referenced for the intended payment flow. Dwolla’s current open-banking materials describe instant account verification, account-ownership confirmation and real-time balance information as tools businesses can use to reduce failures associated with bad account data.
Its funding-source documentation also identifies several verification methods, including secure connections involving Finicity, MX, Flinks or Plaid, as well as micro-deposits.
Verification has limits.
A valid account can later be closed, restricted or unable to cover a debit. The account holder may also dispute authorization. Verification reduces certain avoidable errors; it does not guarantee settlement.
Keep the states separate:
- Bank account added
- Ownership verification pending
- Funding source verified
- Transfer initiated
- Transfer completed or returned
Collapsing those stages into one “connected” label makes it difficult for customers and support agents to understand what remains unfinished.
What pending, processed and failed mean
Dwolla’s transfer lifecycle uses statuses such as pending, processed, cancelled and failed. A pending transfer remains active and may still be cancellable or may later fail. A failed status is associated with a payment-network return, including an ACH return code received from the receiving financial institution.
Pending is not a diagnosis. It describes a stage.
The payment could be waiting for submission, moving through the network or awaiting a final bank response. Standard ACH operates during banking schedules rather than continuously, while real-time rails follow different availability rules. Dwolla’s comparison material notes that ACH timing can range from hours to several business days, depending on the payment option and financial institutions involved.
Do not retry a pending payment merely because it has not arrived. A second valid transfer can create a duplicate.
Check the original platform’s estimated completion date first. Escalate after that window has passed.
Why a Dwolla transfer fails
Dwolla says bank-transfer failures usually follow rejection by a financial institution and include an assigned ACH return code. The API can expose a failure link that leads to the code, description, explanation and associated customer or funding source.
Common documented examples include:
- R01, insufficient funds: The source bank account lacked enough available funds.
- R03, no account or unable to locate account: The destination may be closed, or the account information may not correspond to a valid account.
- R10, customer advises not authorized: The account owner told the bank that the transfer was unauthorized.
Those codes lead to different next steps. An R01 may permit another attempt after the available-balance issue is resolved. An R03 usually requires corrected bank information. An authorization return may trigger a customer suspension and broader review rather than a simple retry.
Read the reason first. Skip automatic retries.
A failure can change the customer or bank status
A returned payment may affect more than the transfer record.
Dwolla documents systematic actions that can include suspending or deactivating a customer, unverifying a funding source, removing the bank or blocklisting it, depending on the ACH return category. R10 is specifically associated with customer suspension in the documented action table.
This can create a confusing sequence for users. The transfer fails, and then the bank account disappears or becomes unavailable for the next payment.
That is not necessarily a dashboard defect. It may be a protective response to the return code.
Applications should consume customer and funding-source events, not only transfer events. Dwolla advises using active webhook subscriptions to detect state changes caused by payment failures.
A support agent should be able to see both facts: why the payment failed and what Dwolla did to the associated customer or funding source.
How long ACH returns can take
Return timing depends on the reason.
Dwolla categorizes many administrative returns, such as invalid account information or insufficient funds, as typically arriving within two banking days. Unauthorized consumer-debit returns can be submitted up to 60 calendar days after settlement under the documented examples.
That is why a processed ACH payment should not be described as impossible to return. The National Automated Clearing House Association, known as Nacha, establishes operating rules and return time frames for the ACH Network. Dwolla’s ACH guide defines an ACH return as an entry sent back from the receiving institution to the originating institution within the time permitted by those rules.
For businesses, this affects release policies, account balances and reconciliation. For end users, it means a transaction can appear completed before a later bank action changes the final outcome.
What to do with an unfamiliar Dwolla transaction
Start with the company whose app, invoice or platform may have initiated the payment.
Dwolla’s account terms direct users of a client-provided Dwolla account to seek assistance from that client first. When adequate help is unavailable, the terms provide a route to contact Dwolla support.
Compare the bank entry with recent rent payments, marketplace withdrawals, contractor earnings, invoices, loan activity or other services where you connected a bank account. Use the amount and date to narrow the search.
No match?
Contact your bank through its official website, application or published number. Ask it to identify the ACH originator and explain the bank’s transaction-question or dispute procedure. Questions involving a separate non-Dwolla account should also be directed to that account provider under Dwolla’s open-banking terms.
Do not send account credentials or identity documents through an unsolicited message.
What Dwolla costs
Dwolla currently uses custom pricing for platforms and enterprises running high volumes of bank payments. Pricing is tailored to transaction volume, selected payment rails and integration needs rather than offered as one universal public tier.
A useful estimate should include more than the transfer charge. Bank verification, real-time balance checks, faster payment rails, returns, technical implementation, reconciliation and support volume can affect total operating cost.
A company evaluating Dwolla should provide a concrete funds-flow description: monthly volume, average amount, debit-credit mix, expected payout speed and customer type.
Generic pricing questions produce generic answers.
Frequently asked questions
Is Dwolla a bank?
No. Dwolla operates payment software, while financial institution partners provide applicable banking and payment-rail services.
What is a funding source?
It is a bank account or eligible Dwolla Balance connected to a main account or customer record and referenced for sending or receiving money.
Can a failed bank account disappear?
Yes. Certain ACH return codes may cause Dwolla to unverify, remove or blocklist the associated funding source.
Why was my customer suspended?
An authorization-related return such as R10 can trigger customer suspension under Dwolla’s documented failure actions.
Can a processed ACH payment return later?
Yes. Return periods vary, and some unauthorized consumer-debit returns may be submitted up to 60 calendar days after settlement.
Should I retry an R03 failure?
Not before correcting the bank information. R03 indicates that the account could not be located or may be closed.
Where can a Dwolla client get support?
Dwolla maintains a client support portal. Its instructions say clients without portal access can request an account through the published support channel.
How should a business match bank records to transfers?
Dwolla supports correlation IDs that connect a company’s internal payment reference with Dwolla and bank-payment records, improving transaction tracing and support investigations.
