One of the parts of working on Spreedly that gets me personally excited is the fact that we empower merchants and consumers to explore payment options beyond credit cards. Now don't get me wrong: the credit card network has a lot of benefits. For one thing, it's virtually ubiquitous, and for another the speed and ease with which money can be moved by it is really handy. But it also comes with downsides, such as the fact that it's not exactly a hotbed of innovation, and that it's ridiculously expensive.
Choice is good, and I'd love to see a hundred different alternatives to credit cards bloom. But if you're a merchant, just the thought of that many options probably makes your head hurt, since each one brings with it new implementation challenges - unless, that is, you're using Spreedly. We already support Dwolla and GoCardless, not to mention the old faithful PayPal. These can all be great alternatives to credit cards, and both merchants and consumers are seeking them out.
While they have big benefits, the downside with each of these is that, unlike with a credit card transaction that can be run in one step right on your own site, you have to send your customer offsite to each of these providers to complete the transaction. And, if you want to do ongoing transactions on behalf of your customers, your transactions are locked in to whichever provider was originally used. You can do multiple transactions against a GoCardless account, but you can't flip a switch and just start running those recurring transactions against PayPal - it doesn't work like that. But what if you could, when it makes sense, transact directly against a consumers bank account? Even better, what if you could do it in a way that, just like credit cards, vaulted the details of that bank account so that you could switch out the backend at any time and just keep transacting away like nothing changed?
Well today I'm excited to announce that we've added a bank_account payment method to Spreedly, which is a fully functional sibling to credit_card payment methods.Adding a bank_account is simple
the fields are different than a credit_card, but otherwise it's just the same transparent redirect (or direct API call) as always. And once you've added a bank_account, you can treat it just like a credit_card account - retain it, redact it, and transact with it against any gateway that supports it. Speaking of gateway support, we're launching with bank_account support for Authorize.Net's eCheck.Net service, which means that as soon as you get eCheck.Net enabled on your Authorize.Net account, you can start using bank accounts right away. There's nothing new to configure on the Spreedly side - just add some bank accounts and go.
While bank accounts do not (yet) have an equivalent to PCI-DSS, Spreedly treats them with the same care we use for credit cards, so you and your customers can rest secure that the sanctity of their bank account is being taken very seriously. The big question we'd like to have our customers answer: what other gateways would you start using with bank accounts tomorrow if you could?
We want to start adding support where it makes sense, and our customers are always the best place for us to learn what's going to be the most useful. And don't feel like you're limited to traditional credit card processors that happen to have an ACH or echeck add-on; we're also open to reviewing services that only do ACH to see if they'd be a fit for adding to Spreedly. Thanks, and as always, we can't wait to hear your feedback on this new bank account support!