See the Dwolla Difference → View the Demo App
Close Announcement Bar

Dwolla’s payment platform supports a simple disbursement option from the dashboard or a sophisticated integration involving multiple funds flows and payment methods to initiate account-to-account transactions.

Before initiating payments, Dwolla will need to review your business’ use of our technology and ensure requirements are met. As soon as you begin your integration, we recommend reviewing the integration requirements and any questions with your Integration Consultant or Account Executive to understand all of the requirements applicable to your use of Dwolla.

When planning your timeline for rolling out payments on your platform, we recommend you submit your application through the Dwolla Dashboard at least two weeks before you’re hoping to go live with Dwolla.

To provide the best support and service, our approach to integrations is aligned with industry best practices to ensure a smooth start with an account-to-account payment solution. We’ve outlined integration requirements below to help your team get ahead of expectations in Dwolla’s application approval process and ultimately get you live faster with a payment service provider.


Dwolla’s security team takes your trust and the role payments platforms play in collecting and securing payment information very seriously. There are some minimum requirements your platform will need to incorporate in your security practices as you add payments capabilities to your services.

End-User Password Requirements

If your end users are able to initiate payments or access sensitive personal information (like an SSN or bank account numbers) using their login to your platform, we require those logins to use strong authentication. This means implementing multi-factor authentication (paired with at least an eight-character password). If a client does not want to implement MFA, passwords need to be at least 12 characters.
Screenshot Sign Up: App Approval

Password Hashing

Dwolla requires hashing algorithms that fall within the table below:
Password Hashing Chart: App Approval

Rate Limiting

Rate limiting helps to thwart password guessing and brute-force attacks. Dwolla requires that accounts are locked for at least 30 minutes after 10 incorrect log-in attempts.
Rate Limiting Screenshot: App Approval: App Approval

Sensitive Data in Transit

Sensitive data (think: personal information, bank information, identity documents) needs to be transmitted using TLS 1.2. We will ask for the URL where your application is hosted, and/or the URL for your API or database endpoint if there is a mobile application. Dwolla uses this for testing and verifying security headers and TLS support. There are known vulnerabilities with TLS 1.0 and TLS 1.1, so those will need to be disabled.

Email Validation

When an end user registers for an account, we require you to validate the email address they provide. This helps ensure end users receive notifications and is an added layer of protection against identity theft.
Verify Account Screenshot: App Approval

User Experience Requirements

Adding payment functionality to your platform comes with a lot of responsibility to your end users. Particularly if those users are creating Dwolla accounts, there are certain pieces of information you’ll need to disclose to them to ensure the account is created and administered properly.

We’ll ask you to verify these things with screenshots of your application.

Terms of Service and Privacy Policy

Each user who will authorize your platform to initiate debits from their bank account must explicitly agree to Dwolla’s terms of service and privacy policy. Clear disclosures of service providers are an essential component of building trust with end users of a payment platform, and this also ensures that we are properly authorized to provide Dwolla’s services.
Terms of Service Screenshot: App Approval

Display End-User Balance

All Verified Customers are creating a Dwolla Account that can hold a balance, and that balance must be displayed to the end user within your application.

We recommend using our Balance Display Drop-in Component.
Balance Display Screenshot: App Approval

Transaction History

Your end users must be able to access at least two years of transaction history within your application. A complete transaction history includes details of each transaction, such as the date, sender/receiver, description, amount and status of the transaction (pending, processed, failed).
Transaction History Screenshot: App Approval

Ultimate Beneficial Ownership (UBO) Attestation

All Business Verified Customers must provide the identity details of any beneficial owner of their business. A beneficial owner is any human who owns at least 25% of the interest in the business, and a controller who controls the day-to-day decision-making for the business (think: C-suite). Additionally, the business must certify that all information provided for purposes of verifying the beneficial owners is accurate and complete.
Beneficial Ownership Screenshot: App Approval

Clear Fee Disclosures

Any fees collected using the Dwolla platform must be clearly and accurately disclosed to end users at or before the time of payment.
My Receipt Screenshot: App Approval