Dwolla recommends using #2 — Secure Exchange solution with Plaid. We plan to eventually move away from the tokenized solution to either Secure Exchange or Open Banking for bank verification.
Could you clarify which account types are supported by Dwolla when creating a funding source?
The Dwolla documentation mentions checking, savings, general-ledger, and loan as accepted value,
but your integration example only includes savings and checking
Sure thing! Bank account types of general-ledger and loan are only supported when added using the bank account’s Account and Routing numbers via the Dwolla API using this request.
For all other Secure Exchange and Open Banking bank addition processes, only checking and savings are supported.
Thanks for asking! Hope this helps clarify things. I will also make a note on our end to clarify this in the docs!
Could you also help me with dwolla webhooks.
It looks confusing to subscribe each request for payment or am I getting it wrong ?
How to setup webhooks so we could get to know if payments are completed ?
We tried to set up a webhook in our sandbox, but we couldn’t figure out which method to use for sending the request to Dwolla or the appropriate URL to acknowledge that our app has received the webhook.
Your documentation suggests using an SQS queue, but it doesn’t provide any sandbox URL for sending these webhook responses/requests for acck.
Just to clarify, when you set up a webhook subscription with Dwolla, you’re subscribing to all events, not specific ones. The webhook URL you provide should be publicly accessible, and that’s where Dwolla will send notifications for any activity in your account.
Here’s a quick overview:
Create a Webhook Subscription: Use the Dwolla API to create a subscription by sending a POST request with your webhook server URL. This is where Dwolla will send events, including payment completions.
Webhook Listener: Set up a listener on your server to handle incoming webhook requests. Your server must respond with a 2XX status code within 10 seconds to acknowledge receipt.
Testing in Sandbox: There’s no special URL for the sandbox; you can use the same approach for testing. Just make sure your server is publicly accessible and can receive POST requests.
Using AWS SQS Queue (Optional)
As you mentioned, our documentation suggests using AWS SQS for webhook handling. This is optional, but it can be useful for handling high volumes of webhooks or ensuring message reliability. If you set up an SQS queue, you’ll need to configure your server to pull messages from the queue and process them.
However, for testing purposes in the sandbox, you can simply send the webhook events directly to your server’s URL without the need for an SQS queue. You can integrate SQS in production later if your app needs more robust message handling.
Let me know if you need any further clarification!