Research: Using Dwolla (0.5% fee) as our payment processor

I decided to just go ahead (and take an “individual action”, in holocracy terms?) and start communication with one of our prospective payment processors, Dwolla. Their platform is very promising (see the updated wiki page), but like most of these companies, their website alone is still slightly inadequate to answer all of our/my questions when researching whether Dwolla can do everything we want from a payment processor.

They seem to have no public contact method whatsoever, except for a “Contact Sales” page where you must fill out a form. I’m making this thread as a placeholder for when they respond. I assume they will return my email, even though I’m not inquiring about “sales” yet (we would almost certainly start with their fee-free option for the forseeable future) and have stated as much in the limited form fields they give you.

When they do, I plan to get clarity about things like:

  • Whether their platform can include multiple recipients of a single payment (a.k.a. the user’s monthly donation, to all the patronized projects)
  • Verifying their (quite low!) per-transaction fees apply only once even in the case of such transactions
  • The software licensing information of their Dwolla.js file

…and anything else I can’t quite gauge from their pretty thorough Features page. (Note that I have decent workarounds in mind in case the answers to the above are not optimal.) I’ll post again here when I’ve heard back from someone at Dwolla.

I’ve already told them who we are, and our website should hopefully do the talking. I was very vague about “expected number of transactions per month”, so let me know if you have more concrete info about that other than “at least one for each of our users”.

If there’s anything else you want asked, but don’t want to contact them yourself, feel free to post below.

3 Appreciations

Hi! This sounds like beneficial work, but I have to register a concern. Adding more payment processors will provide some value, but will incur a complexity cost. Besides the upfront cost of implementing support for multiple processors (which, I foresee, would be a few weeks’ worth of full-time team effort), there is the never-ending maintenance burden.

The value of having multiple processing options doesn’t seem to justify this cost. What do you think?

I think the proposal here is to switch payment processors, not add an additional one. That does involve the cost of asking our ~110 patrons to re-enter payment info.

The main reason it may be worth the cost is that Dwolla supports direct bank transfers with much lower fees (half a percent, minimum 5¢, no flat fee), which allows us to lower the maximum pending payment from $3.79 to $0.50 (or reduce the fee threshold).

I think this is an acceptable cost, given the messaging we’ve put out so far (those 100 people know we’re still early in development), although on the other hand there is definitely a time cost to switching processors that I’m not sure we want to pay.

My biggest concern is that some people may not want to hook up Dwolla to their bank (ie, prefer a card). I think (but am not sure) they also support credit cards, with higher fees, but at that point there is not much benefit in switching.

2 Appreciations

Yep! The idea was never to add more payment processors, but to choose one. Stripe is partially implemented now, but we didn’t yet make a full-blown commitment - and we’ve had this list of ideas for a while now, but not a thorough investigation (which is what I’m helping with). So yes, it would be a complete switch, to a system that more easily fits our goals. Dwolla can handle our use case a lot more natively than Stripe, and costs less. Actually, using bank accounts costs substantially less than anything that goes through the credit card network, and avoids that treachery entirely.

I’d say, having fees this much closer to “negligible” aligns pretty well with our FLO values and feels more like a “donation”. That said, Dwolla brings other benefits over Stripe, such as per-user wallets and mass payment features.

And even if @smichel17’s point about some users possibly preferring credit cards over bank accounts is true, a) the opposite is likely true as well and b) they use Plaid to make the account-entering process so frictionless that it actually takes less steps than entering a credit card. So the list of reasons to prefer credit is a lot smaller.

That said, we can later support credit cards if desired by integrating a credit card service with Dwolla itself - so funds can be deposited into the user’s wallets directly - which means no additional API work for us. However, that can be down the line when we have a lot more users and work with Dwolla directly.

P.S. Currently, our Stripe integration isn’t even possible without leaving our site or using proprietary JS. With something like Dwolla, we get full access to an API that lets us do it all on our own - no need to depend on proprietary tools.

So I got a generic response (despite my specific details) that seems somewhat automatic:

Hey there,

Thanks for your recent interest in Dwolla! After reviewing the company and use case information that you provided, we suggest that you consider signing up for the Pay-as-you-Go service and pricing at

After registering, you will be asked to submit your application for review and approval. From there, you will get access to the dashboard where you can create and transfer money to Receive Only Users.

After approval, you will hear from our integration team about integrating with our API to provide a programmatic solution with more functionality. More information about that functionality can be found on our pricing page.
Thanks and good luck!

The Sales Team

You are receiving this email in response to your expression of interest in doing business with Dwolla. Please do not reply to this email. If you have questions, or believe that this message has been sent in error, please contact [email address] or visit our support page.

However, we now have access to that email address above (in the fine print at the bottom of the email) that lets us contact a real human. That’s not something that was divulged on their website, so it’s progress!

However, they also mention that “support page”,, which now redirects to, which is… A Discourse instance! Check it out:

So I think I may just be able to ask away in that forum.

2 Appreciations

Yes, in fact the main reason Stripe costs what it does is that they themselves have to pay for access to the payment networks.

But note that if we only went through bank accounts, I myself would no longer be able to contribute. :slight_smile: My Finnish debit card, linked to Visa, is the only way I could pay into a US-based business. So unless you’re comparing apples to apples (what does Dwolla cost for card users?), I don’t think the lower cost of Dwolla is relevant.

Indeed, that list of ideas is older than our decision to use Stripe! :smiley:

When you talk about “partially implemented” and “full-blown commitment”, do you mean support for patronizing multiple projects through Snowdrift? It’s been a couple years since I looked at it, but I’m not sure we even know what that looks like. It’s true that the options that payment processors provide could influence the design — but really, they’re all playing by the same strict rules, and if we try to use some niche feature of one of them to do something “funny”, we’ll most likely get lumped in with the same fraudsters that made all the strict rules necessary in the first place.

I would rather suck it up, play in the existing Visa/MC system, and figure out multiple projects, before spending time moving away from Stripe. (Incidentally, Stripe has great non-financial features, like a nice API, good docs, and an entire mock system for doing tests.)

1 Appreciation

Yup, I know, that’s why I’ve said it’s old. I was actually around when the page was created. I just haven’t seen any evidence that going with Stripe was a “decision” as permanent as you imply. But I could be wrong.

Actually, nearly all of the options on the list that are meant for running a payment platform (e.g. Braintree) also support the ideas we need. Plus, using wallets and per-user accounts (where money is held by the provider, not us) is not that ‘funny’ or niche of a feature IMO.

I’m not sure why you would say that. Care to clarify? We’d just be implementing the Snowdrift crowdsharing algorithm.


Good point, the international support of Dwolla is another thing I have to look into. You’re right, Stripe does support that well.

1 Appreciation

Update: I started the dialog regarding the freedom of Dwolla.js on their Discourse over here:

1 Appreciation

Hey, thank you for addressing all my concerns! Sorry if I came on strong. I support the fact-finding that you are doing.

3 Appreciations

As much as I strongly wish we could do this, I’m super skeptical.

All the other platforms that have ever tried this have run into difficulties. Gratipay did this and it ended up with fundamental problems and then legal advice that pushed them to accept the in-arrears (running balance) method (which we’re doing now). Liberapay forked the original Gratipay code to keep the wallet-approach in France only to later get cut off by MangoPay, go through hassles, and eventually switch to non-wallet approach with all-at-once payments for multiple weeks of patronage.

I’m not aware of any platform that is doing the wallet approach successfully that we could model on. I’m doubtful that any of these services (Dwolla, Stripe, Braintree, etc) would actually approve of us doing the wallet approach (and skeptical that if we find one that does, it might be because they are not being careful enough, and it actually will bring up some concerns at some later point, as happened with Gratipay and Liberapay).

I wish this wasn’t so. The wallet approach just seems simpler, both in the general model and in the coding. But I doubt we’ll be able to do it.

I know of your concern, but I must point out the difference - bank accounts. None of the other historical platforms you mentioned revolve around bank accounts, they revolve around the more expensive “credit card network” layer above it all. Those are the only ones that have run into the issues you describe, from what I can tell.

That said, even if that doesn’t make the difference legally, the defunct platforms you mentioned are/were highly niche compared to Dwolla. Dwolla is, from what I can tell, way bigger than any of those - in fact it’s on a similar scale to Stripe and Paypal. Those just happen to be more popular.

I’d invite you to poke around Dwolla’s website, to get a feel for how established (and “not going anywhere”) Dwolla is - or the Discourse with all their clients (many of whom are presumably doing wallet-style platforms). They even have explanations for how the wallet system works (it’s all just earmarked funds in a big Dwolla-held account anyway).

1 Appreciation

I think now-defunct Balanced (which originally supported Gratipay) and MangoPay (Europe based) were/are on par with Dwolla. Those weren’t/aren’t so obscure, and Dwolla has not reached anything like Stripe and Paypal in their scope and market share etc.

At any rate, I have some inclination toward Dwolla, similar to how we did with Balanced. We actually used Dwolla when they first offered a direct donate function before they shut that down in favor of only marketplace API stuff.

I believe that credit-cards were not relevant to the legal issues with holding funds in escrow accounts.

So the question is: can we find any examples of wallet-based platforms to reference? Can we find a platform of any sort that uses a wallet-style approach via Dwolla?

1 Appreciation

I’m on it.

3 Appreciations

Platform size

I can see why it might appear that way, so I’ve researched the numbers, and they show otherwise:

So it seems that if this applies to the first two:

…it should apply to the latter. By these metrics, Dwolla blows them away.

But when compared with Paypal’s Braintree, which moves $50 billion a year, Dwolla seems more in that realm than the others.

Wallets on Dwolla, in the wild

Actually, that seems to be used by most of their customers. And they host some pretty big platforms, like GasBuddy (an app I use). One perfect wallet-using example might be Bitmo, a platform for gift cards without the plastic.

3 Appreciations