By Ethan Caldwell, payment-platform support analyst with 8 years of experience handling ACH onboarding, payout failures and funding-source issues
Last reviewed: July 21, 2026
Dwolla provides bank-payment infrastructure that businesses embed inside marketplaces, payout platforms and financial applications. A recipient may be created as a receive-only user who can accept money into a connected bank account but cannot send funds back through that same Dwolla customer record.
This independent guide is not affiliated with Dwolla.
The first task is to identify what kind of customer record the platform created. A receive-only user, an unverified customer and a verified customer have different capabilities, even when their screens look nearly identical.
What is a Dwolla receive-only user?
A receive-only user is a limited Dwolla customer type designed for payout-only flows. The user can receive transfers into an attached bank account and can interact only with verified customers or the platform’s Dwolla main account.
This structure fits businesses that pay sellers, contractors, vendors or other recipients who do not need to initiate transfers themselves. The onboarding path can remain lighter because the recipient is being set up for one direction of money movement.
There is an important restriction: receive-only users cannot send funds back through the Dwolla network. Dwolla’s documentation states that a return payment from this customer type may need to be handled outside Dwolla.
That detail affects refunds and corrections. A marketplace cannot assume that every recipient can simply reverse a payment from the same account record.
The platform should decide before launch how it will recover an overpayment, cancel an earnings adjustment or handle money sent to the wrong recipient. Leaving that question until after the payout creates an operational dead end.
Is a receive-only user the same as a verified customer?
No.
Verified customers have broader capabilities and may send and receive funds within supported flows. Receive-only users are restricted to receiving payouts into an attached bank account.
An unverified customer sits somewhere else again. Dwolla’s client materials describe unverified customers as users who may be eligible to send or receive payments, while receive-only users do not create a full Dwolla account in the same manner.
These labels are easy to blur in a customer-facing application. The recipient may only see an earnings or bank-settings page and have no reason to know which Dwolla customer type exists behind it.
Operations teams do need to know.
The customer type determines whether a linked bank must be verified, whether the customer can initiate money movement, and which other Dwolla accounts the record can interact with.
Choose the type based on the funds flow. Skip the temptation to use receive-only onboarding merely because it is lighter.
Can an unverified bank account receive money?
Yes, in supported Dwolla flows.
Dwolla’s bank funding-source documentation says that a bank account left in an unverified status may receive funds, but it cannot be used by the customer to send funds. Verification is required before a customer can initiate payments from that bank funding source.
That explains why some payout recipients can connect a bank and receive money without completing a full instant-verification process.
The rule changes when the customer becomes the sender. Dwolla states that the sending party must have a verified funding source before it can send funds. The receiving party does not always need a verified funding source merely to accept them.
This difference should be reflected in interface language.
“Bank added” may be sufficient for a payout-only destination. “Bank verified” is required for money to be pulled from that account. Calling both states “ready” creates confusion when a user later attempts a feature that needs debit authority.
How Dwolla bank linking works
A Dwolla client can add bank funding sources through several supported methods. Current documentation includes open-banking integrations, secure exchange methods, third-party providers and micro-deposit verification.
Instant verification uses a bank-authentication flow to confirm account ownership and pass verified account information into the Dwolla integration. Dwolla’s bank-verification page describes micro-deposits as a fallback in which two small deposits are sent and the customer confirms their amounts.
A Plaid-based Dwolla integration, for example, can create a funding-source URL that represents the selected bank account for ACH credits, debits or both, depending on the approved flow.
The customer should complete bank linking inside the platform that requested it. An unrelated Dwolla login may not contain that user’s client-managed record.
Do not request replacement bank information through ordinary email. Direct the recipient back to the platform’s authorized bank-settings screen.
Why would a payout recipient need to reconnect a bank?
A previously connected bank account may become unusable if the account is closed, removed or rejected by the receiving institution.
Dwolla provides an example involving a receive-only user whose bank account closes while a payout is pending. The bank cannot accept the credit, so an ACH return sends the funds back to the client’s Dwolla main-account balance rather than automatically returning them all the way to the client’s external bank.
This is a specific reconciliation problem.
The recipient sees no payout. The client may see funds sitting in its Dwolla balance. The original bank account may no longer be a valid destination.
The platform must then decide whether to ask the recipient to add another bank account, withdraw the returned funds, or use another approved payment method.
Do not issue a second payout first. Locate the original transfer and confirm where the returned funds settled.
What does a Dwolla transfer actually contain?
Dwolla transfers are two-sided. A bank-to-bank movement may be divided into separate legs, such as pulling money from the sender into the Dwolla network and pushing money from the network to the recipient’s bank.
This matters because one overall payment can contain several underlying transfer events.
A business might see the incoming leg succeed while the outgoing leg remains pending or later fails. The customer sees one withdrawal or payout request, while the operations team must inspect each part of the funds flow.
Dwolla’s dashboard Funds Flow Overview was designed to make those legs easier to review without moving repeatedly between separate transfer-detail pages. It can also display a failure reason when one leg fails.
That is one of the most useful support details in the current documentation. A payment that looks “stuck” may actually have completed one leg and failed another.
What do pending, processed and failed mean?
Dwolla’s transfer lifecycle includes states such as pending, processed, cancelled and failed. A pending transfer has not yet been sent to the payment network or has been sent but has not completed processing.
A failed status is commonly associated with an ACH return code received after rejection by the relevant financial institution.
The practical interpretation depends on the leg:
| Status | What to check |
|---|---|
| Pending | Whether the transfer is awaiting network submission or bank processing |
| Processed | Which leg or destination reached its completed state |
| Cancelled | Whether processing stopped before the payment advanced |
| Failed | Which ACH return or funding-source issue caused rejection |
Do not tell a recipient only that “Dwolla is processing it.” Identify whether the debit side, credit side or full payment remains open.
A useful support record should show the source, destination, amount, creation date, current leg and any failure reason.
Why do Dwolla payouts fail?
Dwolla says transfer failures commonly result from ACH rejection and receive an ACH return code. Insufficient funds is one documented example, while invalid or closed accounts can produce other return conditions.
For a payout recipient, insufficient funds usually concerns the source side rather than the receiving bank. A closed or invalid destination account points to the recipient’s funding source.
Those cases require different actions.
A source-side funding problem may be resolved by the payer. A destination failure generally requires corrected bank information. An authorization-related return may trigger further action on the customer or funding source rather than a simple retry.
Read the failure reason first. Skip automatic retries.
The user-facing message can remain simple, but the internal system should retain the return code and affected transfer leg.
How long does a Dwolla bank transfer take?
Timing depends on both sides of the bank-to-bank transfer. Dwolla explains that the payment-in debit and payment-out credit can use different speeds, so the total time depends on the combination selected for both legs.
A business could, for example, use Same Day ACH for the incoming debit and a real-time rail for the outgoing credit when the flow and institutions qualify.
That does not mean every payout will arrive immediately.
Standard ACH, Same Day ACH and instant payments follow different rules. Dwolla defines instant payments as transfers using the FedNow Service or RTP, and the destination funding source must support the chosen network.
The originating platform may also delay payout creation while it performs its own approval or risk review. That client-side wait is separate from Dwolla’s network processing.
Ask for the actual transfer creation date, not only the date when the user requested withdrawal.
Who should resolve a missing payout?
The business that issued the payout should investigate first.
Dwolla’s client integration guide says the Dwolla client is expected to provide customer support for account activity through the client’s own published channels.
That company can inspect the user record, bank funding source, payout ID and Dwolla transfer. It can also determine whether funds returned to its Dwolla balance after a failed recipient credit.
Dwolla’s direct support portal is primarily documented for Dwolla clients. Basic Support clients can submit requests through the portal or the published support email, with responses typically targeted within two business days.
That target applies to the client support plan, not to every end-user payout question.
For an unfamiliar credit or debit on a bank account, the account holder should also contact the bank through a trusted channel. The bank can identify the originator and explain its own transaction-review procedure.
Frequently asked questions
Can a receive-only user send a refund?
No, not through that receive-only record.
Does a payout recipient need a verified bank account?
Not always. An unverified funding source may receive funds, but it cannot be used to send them.
Why was my payout returned?
A closed, invalid or otherwise unusable destination account can cause an ACH return. The issuing platform should inspect the transfer failure reason and current location of the funds.
Can the returned money remain in Dwolla?
Yes. In Dwolla’s documented receive-only example, funds returned from a closed recipient bank settle in the client’s main Dwolla balance rather than automatically returning to the client’s bank.
Why can I receive money but not send it?
Your customer type or bank funding source may be configured only for receiving. Receive-only users cannot send, and unverified funding sources cannot initiate transfers.
Is every Dwolla payment one transfer?
Not necessarily. Bank-to-bank payments can be split into debit and credit legs that complete separately.
Should I reconnect my bank while a payout is pending?
Check the original transfer first. Changing the destination may not redirect a transfer already in progress.
Where should I report a missing Dwolla payout?
Contact the platform that issued it. That company can trace the customer record, funding source, transfer legs and any returned funds.
