For historical reasons, ACH is approximately as fast as airmailing someone money. When all the stars line up correctly, it is as fast as Fedexing money. Credit cards are like emailing money (and Paypal was, very explicitly,about emailing money). Dwolla is based on ACH.
There's probably a lot that can be done with cheap, user-friendly ACH in an API, but I don't know if folks really understand the "Your transaction takes 100 hours to settle" bit.
I organize conferences (Strange Loop, Clojure/West). I pay at least $10 per person in credit card fees (multiply by 500-1000 people). Personally, having the transaction clear a few hours later is hugely unimportant to me vs paying $10 less per transaction.
But aren't most of your attendees traveling on their company's dime, meaning they need to use their corporate credit card in order to pay? If so, this wouldn't work.
I think they try to get around this by allowing you to 'preload' your account. What they've built is an electronic checking account.
I only write checks to pay my rent and I don't carry cash. If I had to get cash, I couldn't. I don't know the pin numbers to my debt or credit cards. This is something I would use if I knew more people accepted it and I didn't have to divide transactions between a credit card and this. I'd miss the cash back on the CC side though.
CCs are convenient but the dark side is that every transaction you make is being recorded, with a certain probability of being held against you at some point in the future.
I think so. I know they have a "big announcement" in 15 days, so I expect it to be related to this. Previously there has been some news about a service I think was called "CU link" where credit unions can offer Dwolla as a sort of service and the ACH is accelerated. I sent an email to my CU bugging them to get this and they gave me an answer like, "we pay attention to what is going on". My CU has some sort of ties to Members Group and I use Dwolla for online payments so my fingers are crossed.
> But Dwolla is not in a position to either fix or replace the ACH system.
On the contrary, based on the little PR that they have made, I feel that replacing the ACH system is their primary desired endgame. They are actively selling their payment network as an alternative to ACH for their member institutions.
Yup. Further complicating things, ACH isn't truly settled for a 6 months!
ACH's can be charged back for 180 days and there is no adjudication process, like with credit cards. If an ACH gets charged back, you lose the money, that's it.
The other major complication with ACH is that most Americans use credit cards for the credit (70% hold a balance). That is something that won't be solved. Others like the benefit of rewards (miles, dollars, whatever). To get payers on board, you need credit, rewards, and exclusivity (i.e. is this the only payment method available at somewhere where I want to shop). The last 2 meaningful companies were paypal and discover card. PayPal had millions of Ebay sellers using PayPal AND they initially paid people to become members. Discover card started the cashback movement and was the only electronic payment option at Sears (largest retailer in the world at the time).
ACH's are essentially free - there are some costs but Dwolla is part-owned by a credit union which probably helps lower the costs. They have major fraud-related costs, but given that fraud under $10 should be very small, their costs aren't much
> The other major complication with ACH is that most Americans use credit cards for the credit (70% hold a balance). That is something that won't be solved.
I doubt Dwolla needs to solve this problem to be profitable. I'm pretty sure there are still a very large number of cash and debit transactions occurring daily.
> Others like the benefit of rewards (miles, dollars, whatever).
I've seen this argument raised a few times and I still don't understand it. Couldn't merchants (especially online merchants) discount sales that don't use credit cards? The money saved by not offering rewards has to go somewhere.
I've seen "convenience fees" for credit card usage a few times, specifically when renewing car registration or paying parking tickets online. But there, credit card payment was the only option.
As for enforcement for B&M shops, I think it all comes down to wording and appearances. Card companies will accept a gas stations offering a cash discount because that isn't being portrayed as a card tax (negative connotation).
When gas stations advertise $3.69 in giant numbers over the highway, and only when you pull off the highway and into the station do you see $3.79 for credit card or $3.89/$3.99 for plus/premium, I do view that as a card tax. Maybe the CC companies don't, but as a consumer, that's how it feels.
Dwolla is not part-owned by a credit union. It has an investor that has credit unions as customers. From what I can tell, the company has encouraged this false impression to escape regulatory scrutiny.
"About The Veridian Group
The Veridian Group is a wholly-owned subsidiary of Veridian Credit Union, based in Waterloo, Iowa. As a credit union service organization (CUSO), The Veridian Group is committed to providing valuable financial services to credit unions and credit union members."
The distinction between a "credit union" and a CUSO matters. If the credit union is extending its charter to cover Dwolla, Inc., then that makes a big difference in terms of regulatory implications. As far as I can tell, The Veridian Group, Inc. (which does not have a charter) has invested in Dwolla, Inc., and Veridian Credit Union (which does have a charter) owns The Veridian Group, Inc.
Because it is tied to the checking system, where checks were routinely flown across the country from bank to bank before they could be settled? (Even after we had electronic systems that should make this unnecessary?)
Based on our collective confusion it is clear that the number one obstacle to using Dwolla is their own web site. When the "how it works" page starts with "First there was bartering, then there was coinage, and of course paper tender followed with checks right behind." I'm fading fast.
I want a description of how a transaction goes down. I got that you set up Dwolla by attaching to a bank account for ACH. I got that you use your phone--somehow. Can anyone explain the somehow? How about sending cash to a friend, is there any online demo of the interface for that?
I'm actually feeling physically uncomfortable trying to decipher their website. It's making me nervous and frustrated. I just want to know what the user experience is for making a payment. Do they have to pull out a credit card? Create an account? ARGH.
I want to know this too. Also, does the consumer have to deposit money into a Dwolla account before buying things? Can devs use there api with checking account and routing numbers so that Dwolla is invisible to the user? Is there a delay before payments post?
You give Dwolla your checking account and routing numbers. They make two random deposits of a few cents within a few days, then you go back to Dwolla and tell them how much the deposits were for. Once your bank account is linked to Dwolla in this way, payments to other Dwolla users are instant. It takes a few days for them to withdraw from Dwolla into their bank account.
For a company that I'm entrusting my money to, they could really use a full-time designer on board to keep their site looking trustworthy. The obvious spacing issues even just on their blog post is really off-putting.
I've been following Dwolla for a while now, and I think this is a good step for them. I still have two big concerns, though:
1. Credit cards. Consumers like using them--they offer something that debit cards don't: an "undo" option. Dwolla seems to have gone all in on pleasing merchants, but I think there are still huge barriers to get consumers to use their service. What's the value proposition? Why should I deposit money into a Dwolla account when I can just swipe a card?
2. This might seem petty, but their site needs a re-design. When it comes to payments, your site needs to inspire confidence and trust. Compared to Square [1] and Stripe [2], Dwolla's blog and main site all look like amateur hour. Until recently their developer docs consisted of stickies in phpBB-esque forum.
Can't see the phpBB-esque forum, so I'll have to take your word for it, but I'm interested in hearing what elements of their current homepage seem amateurish and what you think they're missing that would inspire trust.
Tried registering - the 20 chars limit on their password field is not mentioned. For a company that should be aware about security implications, an upper limit should not be there.
Also, I connected my Facebook account from the start, so Dwolla should know my country of origin before my attempt to register. However, only when I got prompted for my address info (third screen) I saw the message "U.S. only...for now", but hey, my city name got filled in.
And before that I tried looking around, going to their Help section, searching - I found no mention of this US-only thing.
What I have never understood is how password length limits come into existence. Is there really some developer out there who things long passwords are bad? Are they using some sort of shitty technology that doesn't permit it for some reason and are too lazy to get around it? I just don't get it.
A 20-char password limit makes sense in one setting: When the password is stored as fixed length plaintext in a database. This is a really, really bad sign to see with a payment processor.
Possibly a holdover from the old, bad days of storing passwords in plaintext in the database, somebody said "nobody's going to need more than X characters," and it became a hard limit.
And then, later, when we all switched over to storing hashes instead of storing passwords, the idea of character limits never got quite all the way to the front end. (I'm working on a system right now that has a 35-character password limit. Granted, it's for mobile phones, where typing that much is a huge pain.)
Seriously, get rid of that limit - not all people type their passwords manually.
For instance, I have an online password generator that does a HMAC_SHA256 from a key + the domain name. I don't have to type the result - I just copy/paste !!!
I also get pretty annoyed when the validation in place asks me to also put an upper char or a number in it - as if a 15 chars password like that is any less safer than a 70 chars password that's made of only dictionary words + padding, which would be easier to remember but a lot harder to brute force.
Seriously, password validation these days is totally screwed.
Over-validation. There's a setting called "length" there... Sure, it's technically optional, but it's calling out for you to put in a safe, sensible number like 20.
it's calling out for you to put in a safe,
sensible number like 20
Safe for whom?
It's very easy to have a password that's a lot longer than that - you can learn a poem or something. And such a password will be a lot harder to break than an incomprehensible 15 chars password that has at least one lower char, one upper char and a number, a password that you could otherwise forget.
Also, personally I have a password generator that produces passwords of 32 chars. I don't have to memorize it because I don't have to. I don't have to type it either, I just copy/paste. Nothing gets stored locally either, I just generate it every time I need it.
Plus there's also the usability issue - I had to find out by myself that the maximum length is 20 by trial and error. That's fucked up.
Okay, but I think you're missing my point. There's no reason it has to have a maximum length, but the database has the capability, so as a developer you feel an irrational pressure to put some number in there. Of course any maximum is going to be a problem for someone, whether it's 8 or 128, but you don't think about that-- you just put something reasonable like 20 and move on.
If you're hashing the password (like you're supposed to do), then all password hashes will get stored with a fixed length, so the actual passwords that people use could be an entire novel of 600 pages, as long as bandwidth for uploading it or the server's processing power doesn't become a problem.
The result of a hash function you would use will be something like 64 chars for SHA256, 128 chars for SHA512 and 60 chars for bcrypt - and that's the only permanent storage you need for storing a password. 20 chars is not reasonable. A reasonable size would be at least something like 128 chars, to allow people to give hashed passwords managed by external software, instead of real passwords. And you can trim hashes to 20 chars, but 20 chars can be brute-forced much more easily.
For instance, if you find the password for one of my websites (I use 32 chars, which seems reasonable even when copy/pasting doesn't work), it would take you years and years of processing to find my master key for generating the passwords to my other websites - so basically I have the same password all over the place, HMAC-ed with a salt specific to each service/website. The password itself is long but easy to remember. The algorithm for hashing is very sound, for now at least. Brute forcing it to find my key for all websites is for all practical purposes unfeasible.
Sorry, s/database/text field/. The box is only 20 characters long, why would someone need more?
Look, I understand what you're saying. I'm not saying this is right, I'm saying they just don't think. Security gets confused with validation, so they just put in a number and move on.
Ben isn't running a charity. If he thinks this strategy will help increase the user base, he could be right. The only problem is that if that strategy works, he'll be losing money on almost every transaction. (ACH transfers are cheap, but they're not free.) Dwolla also has pretty limited fraud detection at this point, and no bonds in most states to serve as nominal protection (see http://www.facecash.com/legal/brown.html). So at some point the price will need to rise again.
If the strategy does not work, then this will just hasten the company's demise. There's a remote chance it could help catalyze an acquisition, but that's really remote.
I then thought for a minute that perhaps this was a step toward operating legally in states like Pennsylvania (see http://www.thinkcomputer.com/corporate/whitepapers/heldhosta...), which waives its money transmission regulations only if you do not charge a fee (a la Venmo), but since you'd have to pay a fee at $10.01, that doesn't make sense.
So honestly I'm not sure I get what's going on here.
It's a tech/UX/product demo. Consumers outside of startup Valley aren't going to understand the concept or remember the silly name. If Dwolla succeeds, it will be getting bought and helping deploy the next iteration of online bill pay, which is exactly what dwolla is.
So "it's a network" is your clue to working out how they're being 'acquired' and by whom. I'm going to go with integration in to Facebook because I have absolutely no clue ...
Also, ACH transfer fees are presumably set by the bank at the terminal ends of the transactions and so are likely, IMO, to be varied if the bank thinks that they're being exploited to avoid other types of payment fees.
ACH fees are set by Dwolla's banks that connect them to the fed network. ACH transfers tend to be free for the individual who is getting or sending money, unless you have a bank that charges you per transaction. ( think bill pay, or direct deposit).
While I don't know what rates Dwolla is getting, I'm going to guess that they're under 10c per transaction, and they may be as low as 1-2 cents per. I certainly hope they are for their sake.
What may save them a bunch, in cost and fraud, is if they can do the clearing between their accounts internally, and not hit the ACH network for most transactions.
Exactly. If you have a business model where Dwolla being free is integral to your success, then you're in a very bad place. Always assume you'll have to pay your suppliers/service providers, and keep a healthy margin on top of that to protect yourself from price fluctuations.
For a more concrete example, look at Chargify. For a while they were free to anyone under a certain size. Then, they changed their prices and started charging $39/mo (originally it was $99) for the lowest tier. A lot of hackers got burned by that move.
1) How it works: Dwolla works by leveraging the Automated Clearing House (ACH) system. But to do that, you have to link your Dwolla account to a checking account. The ACH system is not the credit card system, so it can avoid the requirement to pay a toll, and thus can avoid passing on those fees to their users.
2) How is it different? Dwolla doesn't charge a percentage of the transaction. They only charge $0.25. And now $0.00 for transactions under $10.
2) Probably a lot to begin with. There is a perceived "security" in using cards online (thanks to years of marketing and PR by issuers, authorisers and gateways).
However, running Dwolla side-by-side with a card solution - with the reduced price option - I think it will be surprising to see how many customers start to see Dwolla as the favourite.
The trick is to create that difference for customers to see. And remember... just because your cost per transaction may go down, doesn't mean your prices have to! Why not use it as an opportunity to stick card fees on top?
I'm sure that will give customers plenty of incentive to the point where it makes no sense to use a full-time payment gateway... just stick Paypal's 'free' web payments solution on there to catch the drifters
What's the quickest way to load funds to a Dwolla account?
If you already have bitcoins, then you simply trade them for USDs on an exchange such as Intersango.com or MtGox. Then withdraw those USDs to your Dwolla account and the funds are available for spending right away. From bitcoins to Dwolla USD, in a matter of minutes -- even including the time it takes to sign up for Dwolla!
If you don't already have bitcoins, you can probably find someone willing to trade their Dwolla funds for your PayPal funds. The #bitcoin-otc marketplace has traders who have Dwolla USDs but for whatever reason need to move those funds to PayPal. Oftentimes they will accept a 1:1 trade (e.g., your $50 PayPal buys $50 Dwolla USD.)
http://bitcoin-otc.comhttp://webchat.freenode.net/?channels=#bitcoin-otc-foyer
Based on earlier comments by their founder, I imagine it's only a matter of time before they compete directly with credit cards using NFC. He's suggested that their goal is to compete directly with credit card companies like Visa.
Dwolla is currently making most of their revenue and customers from large landlords on rent payments. If Dwolla can produce an NFC badge or keychain (until NFC catches on in more phones) and can somehow become synonymous with NFC payments before the credit cards become big there, then I can see a huge market opening up for them. Vendors hate transaction fees and customers love convenience.
Does anyone know how hard it is to spin up a service like this on their own? Given they use relatively cheap ACH transfers, wouldn't you just need to find a bank that manages the money for you, and the rest is just doing a bunch of those ACH transfers?
Also, I'm not very familiar with US banking system, but it seems as Dwolla can withdraw funds from your account after you "verified" the account. It's a pretty common thing in Germany, but I have never heard of that in the US. Can any business do it or is it a Dwolla-specific thing?
I run FaceCash, which is based on accounting software I already had started writing ten years prior to starting in with payments. It's pretty difficult. Between the technology, regulatory and accounting hurdles, it's not a business for the faint of heart.
Practically, you've got to groom relationships with banks, convince them of your risk management process, get a decent rate for transfers, and a whole host of other details.
It can be done, but I'm not sure it can be done profitably for $.25 a transaction to the general public, especially with the risk management and the potential for returns coming back after 6 months.
I like what Dwolla is doing, but unfortunately without a faster way to move money out of Dwolla (transfer to PayPal, debit card, etc.) it's pretty useless for me right now.
The devs have told me that's completely against all they stand for, blah blah, but I think if they're trying to take down PayPal and the credit card companies they really need to budge a little bit to make the transition more palatable. I don't mind eating transaction fees until I can get some clients to use it.
Since Dwolla funds are kind of like cash, it is much easier to move them to something like PayPal.
This conversion happens frequently on the #bitcoin-otc marketplace as those selling bitcoins end up with excess Dwolla USDs. At the same time, there are others needing Dwolla USDs to buy Bitcoins, and will pay using PayPal USDs.
Is Dwolla a competitor to https://www.simple.com/ ? I'm not sure exactly what their service does - I know it's different than paypal and google checkout from previous articles. Can you use it to pay at brick and mortar stores like a debit card? It seems like it would only be useful if all merchants already accept it. Am I missing something or can someone explain it to me better?
Thanks - so essentially they're just a better digital currency exchange platform? Better pricing and more features, but still have to build up their network of people who accept their transactions?
Bitcoin is squarely at the bottom of the dip in the Gartner Hype Curve right now. It's a little bit of a gamble, but it could pay off. The risk to Dwolla of facilitating Bitcoin transfers is pretty minimal.
> Bitcoin is squarely at the bottom of the dip in the Gartner Hype Curve right now.
Similarly, the Gartner hype curve is at the peak of the Gartner hype curve.
Gartner doesn't change the fact that bitcoin is deflationary and will die as a currency for the same reason that precious metals died: They are deflationary.
You guys are referring to Gresham's Law which is only applicable due to legal tender laws. Without legal tender laws, the "good money" wouldn't be driven out by the "bad money" (i.e. US currency).
Also, the reason the US government went completely off the gold standard in 71 was to increase deficit spending without having to pay our debts in gold or something of real value. The Fed has a policy of steady inflation, only through debt liquidation can we ever expect to pay off the huge amounts we owe. That is, we borrow 10 trillion and inflate 50% over a certain time, now we only owe 5 trillion.
End the legal tender laws, allow alternative commodity-based currencies and end the central planning of interest rates. This is the solution. It has nothing to do with gold (or Bitcoins) being a deflationary currency. It has everything to do with big corrupt government.
edit- I don't want that last sentence to color my whole statement. I'm an Austrian, not a Republican. I worked for Obama last time and will vote for him again. For a better perspective on this, check out (future Fed Chairman!) James Grant's Interest Rate Observer http://www.grantspub.com.
But Bitcoins are digital, which means you can trivially replenish your spending wallet using USDs or whatever other currency you choose to use. Incidentally, using Dwolla to transfer funds to a Bitcoin exchange is often the easiest and quickest method available today!
If you want to convince people who don't already agree with you, you might consider explaining why you consider "deflationary" a bad thing. Personally, I think it falls squarely in the "we could do worse, and we do" category.
It doesn't create an incentive to not spend money; it creates an incentive to not spend money wastefully, on things that provide insufficient value. That doesn't stop people from spending money for things they want or need. For most things people want or need, having them now provides more value than having them later.
After all, by exactly the same argument, why buy a computer today when you could wait and get a more powerful computer tomorrow? You could apply that logic indefinitely, except that the sooner you get a computer, the sooner you start getting value from it. At some point the balance changes, and you decide to buy one anyway.
There's probably a lot that can be done with cheap, user-friendly ACH in an API, but I don't know if folks really understand the "Your transaction takes 100 hours to settle" bit.