I have a marketplace that uses Dwolla exclusively for payments. It has worked out great except for the fact that it excludes most of the world from participating (those outside of the US) but that is not their fault.
Bank account verification like this is a huge improvement over the we'll-deposit-some-pennies-in-your-account scheme. We require users to have a verified funding source in Dwolla... and the 2-3 day wait I'm sure has been a turn off for many, so this is a cool feature.
Ben Milne seems like a good CEO and the company seems to be run from a long-term perspective, which is refreshing. Their decision to completely eschew the credit card processors and provide no-cost online transactions and micro-payments is also a breath of fresh air.
Dwolla is completely unscrupulous and cannot be trusted.
They claimed for years their transactions were 'irreversible' and then went ahead and secretly reversed (read: just deleted them from the db and claimed not to know about them) a bunch of transactions that bankrupted Tradehill. Disgusting company.
They marketed their service as free of chargebacks.
1. The fact that a payment company connected to ACH, a reversible payment method, would claim something like this demonstrates gross incompetence at best.
2. If they didn't want high risk customers like TradeHill they should have politely kicked them off the service, not kept them on while silently defrauding them of their money and hoping they wouldn't notice.
> Using an online payment service for currency trading is not the best idea.
What, TradeHill should have expected Dwolla to violate their own terms of service (no chargebacks) and therefore it's their own fault? That's asinine.
I would tend to agree that a lot of "random" sites asking for your online banking username/password is not ideal. This is potentially a step in the right direction since it's "iframed" so the host site presumably never has access to your credentials. But then you have to worry about who Dwolla (or Plaid) is which I'm guessing most of America doesn't.
This is pretty common nowadays, there are companies that have designed APIs specifically for bank account verification using username and password (Yodlee, Plaid, etc..).
Well, with oauth, you are not telling dwolla your password. You are telling the 3rd party, that dwolla (or whoever) can have an access token to your account, verified via popup to facebook, or a redirect to facebook.
Imagine if "login with facebook" meant "tell my startup your facebook password".
Because banks say: "We're the bank. We're run by Masters of the Universe, we are the smartest people in the room, and you can trust us and our data-handling practices!"
To be serious: Having to disclose the same credentials that give you access to the web UI for your bank accounts to a random third-party in order to use their service is insane.
The whole "enter your banking credentials" thing is definitely a bit weird, but I understand why they do it.
A slightly different use-case, but does anyone know of a good service that replaces the need for nightly ACH batch processing that works with good old fashion routing number and account number (and maybe some other details OTHER than banking credentials)?
This is great. If you are a subscription service or anywhere you need recurring payments, it's nice to provide this option to users because one of the reason lot of people stop subscriptions is because credit cards are flacky, expires or get cancelled. Also large transactions upwards few thousand dollars can benefit because many people don't have sufficient credit limit left. Are there any other scenarios?
I think Dwolla should go one step further. How about exposing APIs to get statements? Getting statements is one of the PITA with banks and many analytics application scenarios would open us with these APIs if they were easier to use than that of Yodlee.
This is on their website..
<Quote>
Dwolla, Inc. is an agent of Veridian Credit Union and Compass Bank and all funds associated with your account in the Dwolla network are held in pooled accounts at Veridian Credit Union and Compass Bank. These funds are not eligible for individual insurance, including FDIC insurance and may not be eligible for share insurance by the National Credit Union Share Insurance Fund. Dwolla, Inc. is the operator of a software platform that communicates user instructions for funds transfers to Veridian Credit Union and Compass Bank.
</Quote>
So they are effectively piggybacking on IFX calls on these bank servers and still using ACH (Account Clearing House?). This is a programmer friendly easily embeddable api for web sites etc. but still using the standard stuff. To call it "Transfer Platform" is a bit confusing to me. I would be damned if Dwolla is actually doing an IFX SignOn with those user name and password, for verifying accounts.
looks to be US only, but banking systems in other countries may not need something like this. And with each country having different rules and regulations, it's probably a very big nut to crack for a single US based company.
In the UK, for example, I can easily transfer money to other people's or business's accounts and it will arrive within 2 hours, and generally it's immediate.
If you need to transfer between countries, then it gets more interesting and you get forex's involved.
Stripe ACH service has been in "beta" for at least two years. I contacted them that long ago and was told it would be available by the end of 2014 and it is still in "beta" and not generally available. As the co-founder of an enterprise SaaS app startup where our average per use charge for a customer to use our app (we charge on a per use basis not straight subscription) starts in the hundreds of dollars and can run into the thousands paying the standard 2.9% + credit card fees for every payment vs. $.10 - $.50 max for an ACH charge is a complete non-starter for us and our customers. All of Stripe's competitors have had ACH forever including Balanced who we talked to but Stripe continues to drag its feet and not provide ACH. Clearly it isn't for technical reasons but because they make significantly more revenue and profit by not offering ACH where their transaction fee is much less. So while I respect what Stripe did early on to make integrating payments into an app much easier than the previous generation payment providers requiring a lot of up front fees, merchant accounts, etc. we will never consider them again unless and until they offer ACH and I'm sure there are lots of other enterprise app companies who won't use them either without ACH because customers demand it vs. having to run up huge monthly charges on their company credit cards. Too bad that Stripe management is proven to put their profits (and greed) ahead of providing cost effective solutions for their customers.
Is it really misleading? Where did you expect the integration with banks to come from? It doesn't even seem like a remote possibility that could be provided without using/including a library from someone. Now one is able to integrate this functionality as easily as one might add Stripe checkout. That's a win, isn't it?
This library aside, I've grown accustomed to every "Do complex thing X in a few lines of code" announcement to, as a rule, mean "as long as you're using our sparkly new library." So much so that it seems rather silly to even mention a library is required. Of course it is. The hard work was wrapped up into a nice interface for everyone to use.
As much as I've grown tired of the automatic developer default to include third-party libraries to do everything, things such as financial transactions seem like one area where it's unlikely one will ever be able to do anything without libraries in a few lines of code.
Agreed with your comment and I'd like to extend it.
It's worth pointing out here that every practical hello world program that I'm aware of invokes thousands of lines of library code beneath it (many years ago I was agog when looking at printf source code). Let's skip any talk of how python or ruby are only a few lines of code :)
Maybe you are too smart for that, write it in assembly! Just a few opcodes and some other dark magic. Well then there's an operating system you invoke. But wait, even if you got around all of that, there are thousands of lines of RTL code that created your CPU, i.e. an entire and much more obscure library stack sitting beneath all of that.
So yeah, you are sitting at some of level of abstraction in the technology stack, and your responsibility should just be a few lines of code ;) I am always blown away at how much leverage we have now (for example, am still just enamored with rails, regardless of any further refinements in the arena, it is still simply amazing to me), just compared to a few years ago, and it keeps getting more powerful.
The integration with banks happens on Dwolla's servers, not in any client libraries they may offer.
This library in question is just a thin wrapper around validation and AJAX for talking to Dwolla's HTTP API.
The code for a Dwolla API consumer to make a bank transfer could be just a few lines, without any libraries, which is what I was expecting to see, not that this demo isn't cool too. Showing off that your API is so straightforward you don't need a client library to use it would be good marketing to me.
Here's an example from another payments startup that used to make similar posts on HN:
I think calling this title misleading is more than a bit off the mark. Any competent developer should be able to achieve a few lines of code talking to APIs without a library. I also don't consider a curl command to be a line of code anymore than I consider an ls or rsync command to be a line of code.
That a post doesn't meet a reader's expectations doesn't in any way mean the post is being misleading. Unless, of course, they'd added some additional language to the title to imply they weren't talking about using their tools. Which almost never happens on HN.
Pure checksum verification (used for some account number plausibility checks) can actually be done in a couple of lines of code. This is something different entirely.
Please don't get me wrong - this doesn't mean I don't appreciate the library. I just think adding "with our library" wouldn't have hurt.
Bank account verification like this is a huge improvement over the we'll-deposit-some-pennies-in-your-account scheme. We require users to have a verified funding source in Dwolla... and the 2-3 day wait I'm sure has been a turn off for many, so this is a cool feature.
Ben Milne seems like a good CEO and the company seems to be run from a long-term perspective, which is refreshing. Their decision to completely eschew the credit card processors and provide no-cost online transactions and micro-payments is also a breath of fresh air.