By Adrian Keller, bank-payment risk analyst with 9 years of experience reviewing ACH onboarding, return codes and payment exceptions
Last reviewed: July 21, 2026
Dwolla provides payment infrastructure that lets platforms collect or send money through connected bank accounts. It supports ACH and eligible real-time payment methods, while the company using Dwolla usually controls the checkout, account screens and customer-support experience.
This independent guide is not operated by or affiliated with Dwolla.
For most users, the practical job is identifying whether a payment is waiting for bank verification, actively processing, or failing because of a funding problem. Those conditions can look similar on a customer screen but require different responses.
What does Dwolla mean by pay by bank?
Pay by bank refers to an account-to-account payment made directly between bank accounts instead of through a conventional card transaction. Dwolla provides businesses with access to Standard ACH, Same Day ACH and supported instant-payment capabilities through its platform and financial institution partners.
The business integrating Dwolla decides how that payment appears to its customers. A user may see a button labeled “Pay from bank,” “Add bank account,” “Withdraw” or “Receive payout” inside another company’s application.
That company remains central to the transaction.
Dwolla’s account terms explain that its clients use the Dwolla Platform to provide services to consumers and businesses. Users send payment instructions through the platform to financial institution partners, which perform the relevant funds-transfer services.
This is why a transfer processed through Dwolla may not appear in a standalone Dwolla login. The customer-facing record may remain inside the client’s product.
Why bank verification happens before payment
Bank verification checks whether the account supplied by the user can be connected for the intended payment flow. Dwolla currently offers instant verification and micro-deposit verification, positioning both methods as controls that can reduce invalid-account failures and ACH returns.
Instant verification is designed to confirm an eligible bank connection quickly. Micro-deposit verification requires small trial deposits and a later confirmation step.
Neither method guarantees that every future transfer will succeed.
A verified bank account can later lack sufficient funds, become closed, encounter an institutional restriction or be associated with a disputed authorization. Verification confirms the connection needed for payment initiation; it is not an unconditional promise of settlement.
Platforms should keep four states distinct:
- Bank information entered
- Verification in progress
- Bank connection ready
- Transfer actually initiated
Customers often mistake the third state for the fourth. A linked account may be available for use even though no payment request has been created.
What a bank balance check can and cannot do
Dwolla documents an open-banking Bank Balance Check capability that allows a platform to retrieve real-time balance information before attempting an ACH transaction. The stated purpose is to reduce preventable payment failures and improve ACH success rates.
This is useful when a business plans to debit a customer’s bank account. A balance signal may help the platform detect that the requested payment exceeds the balance information returned at that moment.
It is not a reservation of funds.
The balance may change after the check but before the debit settles. Other transactions, holds or bank activity can alter what remains available. A successful balance check should therefore be treated as one risk signal, not as guaranteed payment approval.
Check before initiating. Skip marketing language that promises a debit cannot fail merely because a balance was viewed.
Businesses also need a fallback when balance information is unavailable. A customer should not receive a vague account error when the actual issue is that the bank connection does not support the requested data or the institution is temporarily unavailable.
What happens after a transfer is created?
Dwolla’s current transfer lifecycle documentation uses statuses including pending, processed, cancelled and failed. A pending transfer may not yet have been sent to the payment network, or it may have been submitted but not finished processing.
| Status | What it tells the user |
|---|---|
| Pending | The transfer remains active and has no final result |
| Processed | The applicable transfer path reached its completed state |
| Cancelled | Processing stopped before completion |
| Failed | The transfer could not complete |
The meaning of processed depends on the destination. Dwolla states that a processed transfer going to a linked bank account has remained in the lifecycle long enough for the funds to clear into that account. A transfer involving a Dwolla Wallet follows the balance-specific meaning described in the same documentation.
The client application may replace these terms with friendlier language. Internally, it should preserve Dwolla’s underlying status rather than collapsing all successful-looking states into one generic “done” flag.
Why a transfer remains pending
A pending status is not automatically an error.
ACH payment time varies according to the type of transaction, the payment option selected and the day on which the transfer is initiated. Dwolla contrasts those timelines with real-time payments, which follow a faster payment path for eligible transactions.
Weekends and banking holidays can extend the calendar time a customer sees. The business may also perform its own review before creating the Dwolla transfer, which means the withdrawal-request date and transfer-creation date can differ.
Ask for the second date.
A customer may say that a payout has been pending for five days when the platform created the bank transfer only one business day ago. Support staff need both timestamps to identify whether the delay sits with the business or the payment network.
Do not create another transfer first. Duplicate payments are harder to correct than one delayed payment.
Why Dwolla transfers fail
Dwolla states that a bank transfer unable to complete is updated to failed. When the transfer is retrieved through the API, the response can include a failure link that leads to the reason associated with the failed payment.
Insufficient funds is one documented cause. Other ACH problems can involve the bank account, authorization or the financial institution’s response.
A business should never treat all failures as one retryable condition.
A funding shortage may be corrected before another attempt. An invalid or closed account requires different bank information. An authorization-related return needs review rather than repeated debit attempts.
Read the failure resource first. Skip blind retries.
A useful internal support screen should retain:
- The company’s payment reference
- Dwolla’s transfer reference
- Source and destination
- Current status
- Failure reason
- Last status-change time
- Whether another attempt is allowed
The customer-facing message can be simpler, but it should identify the action the user can take.
A verified customer can still hit a balance problem
Dwolla’s developer changelog documents a customer_bank_transfer_creation_failed event for an attempt to initiate a transfer to a verified customer’s bank when the necessary funds are not available in that customer’s balance. The documented flow requires funds intended for the verified customer’s bank to pass through the customer’s balance first.
This creates a specific failure that can occur before a normal transfer lifecycle fully develops.
The receiving bank may be valid. The customer may be verified. Yet the payout cannot be created because the balance does not contain the requested amount.
That distinction matters for platform support. Asking the recipient to reconnect a bank will not fix insufficient balance funding on the sending side.
Operations staff should inspect whether the transfer itself failed during processing or whether its creation failed before money movement began. Those cases may produce different events and require different reconciliation steps.
How the dashboard helps operations teams
Dwolla’s Payment Operations Dashboard is designed to show payment statuses, transactions and exceptions across ACH and real-time payment activity. Its published features include return investigation, payment tracking, data export and reconciliation support.
The dashboard can answer infrastructure questions. The client’s internal system must answer the business questions.
For example, Dwolla may show a failed transfer for a particular amount and customer. The client still needs to know whether it belongs to an invoice, marketplace withdrawal, loan payment or contractor payout.
The two systems should share one traceable reference.
Dwolla’s dashboard does not remove the need for an internal ledger, especially where one customer-visible payment contains fees, multiple transfer legs or a later correction. Exported payment data should reconcile against the company’s own records rather than act as the only accounting source.
What Dwolla costs
Dwolla currently advertises custom, volume-based pricing for platforms and enterprises. Pricing is tailored to transaction volume, selected payment rails and integration requirements rather than offered as one universal public tier.
This conflicts with old search results that describe Dwolla as a consumer transfer service with a fixed fee or free-payment threshold. Those articles may refer to products and pricing that no longer represent Dwolla’s current business model.
A company requesting a quote should provide:
- Expected monthly transfer count
- Typical and maximum payment value
- ACH debit and credit mix
- Real-time payment usage
- Bank-verification volume
- Expected return and support workload
Compare total operating cost, not only the transfer price. Engineering, verification, reconciliation and payment-exception handling all affect what the integration costs to run.
Where to get Dwolla help
Dwolla maintains a client support portal and publishes support@dwolla.com as a support contact. Its support guidance says Basic Support clients typically receive a response within two business days, while Premium Support is a separate offering.
That response target applies to the described client support plan. It is not a universal deadline for every customer of every platform using Dwolla.
End users should contact the business where the payment began first. That business can see its order, account or payout record and match it to the relevant Dwolla transfer.
Contact your bank as well when a debit is unfamiliar. Use the bank’s official app, website or published contact information and ask it to identify the ACH originator.
Frequently asked questions
Is Dwolla a bank?
No. It provides payment software, while financial institution partners perform the applicable funds-transfer services.
Does Dwolla process credit cards?
Its current public platform is centered on ACH and real-time account-to-account payments.
Why is my bank connected but no payment appears?
Connecting a bank does not create a transfer. The business must still initiate the payment through its Dwolla integration.
Can a balance check guarantee an ACH debit?
No. It is a pre-payment risk signal, not a reservation of funds.
What does pending mean?
The transfer has not reached a final outcome and may still be awaiting submission or payment-network processing.
Why would transfer creation fail before processing?
One documented case occurs when a verified customer’s available balance is lower than the amount intended for transfer to that customer’s bank.
Is Dwolla pricing publicly fixed?
No. Dwolla currently uses custom pricing based on volume, rails and integration needs.
Who should investigate a missing payment?
Contact the business that created it first. Its support team can locate the internal payment, inspect the Dwolla status and escalate through Dwolla’s client support channel when required.
