Best Practices to Build Your Dwolla Payment Integration
Some of the most common issues we see when reviewing Dwolla integrations are highlighted in this resource to help better prepare your app before submitting it for review.
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.
Security
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.
Password Hashing
Dwolla requires hashing algorithms that fall within the table below:
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.
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.
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.
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.
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).
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.
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.