Person to person for banks, in a line of code

Developers building software for banks have the same difficulties developers in the non-bank world have. It’s hard to get money from point A to point B. While you would think this would be easy for a bank… It isn’t.

Dwolla’s network is designed to solve problems here and can also help developers building bank software make payments from one account to another via the network.

Screen Shot 2013-01-14 at 2.52.46 PM

Today, we give you Guest Send. Which does just that.

We’ve been thinking. Assuming you had all the compliance done, what is the easiest way to get money from 1 location to another? Just send the data to an endpoint with no complicated scope and let Dwolla do the heavy lifting.

Person to person payments, or person to anything payments have typically been a long drawn out thing for financial service providers and banks alike. Now, all bank providers and banks alike can just request access to our API and drop it into their app. That could be:

  • Mobile banking
  • Internet banking
  • Billing
  • Anything else you can dream up

Technically, a request must include this data:

curl https://www.dwolla.com/oauth/rest/transactions/guestsend \
-X POST \
-H ‘Content-Type: application/json’ \
-d ‘{\
“client_id”: “”, \
“client_secret”: “”, \
“amount”: “”, \
“firstName”: “”, \
“lastName”: “”, \
“emailAddress”: “”, \
“routingNumber”: “”, \
“accountNumber”: “”, \
“accountType”: “”, \
“assumeCosts”: “false”, \
“destinationType”: “Dwolla”}’

That’s it!

A whole person to person platform in 1 API endpoint. This allows you to tell us what account to get the money from and where to deliver the money to.

No complicated negotiation process or wonky contract. Just payments

Your software simply hits our endpoint and we take care of the money movement. Enjoy ;)

  • Ben

    “This is a one line proof if we start sufficiently far to the left.”

    • http://twitter.com/bpmilne Ben Milne

      So you’re saying it’s possible?! :) – Happy to expand on something if you have any questions. Let em’ rip.

  • http://bernardi.me/ Stefano Bernardi

    This is awesome, but how do you handle security?
    I mean, doesn’t the “guest” have to approve the transfer? Otherwise I just need to get their info once and can “withdraw” an infinite amount from their account..

    • http://twitter.com/bpmilne Ben Milne

      Stefano – The only way to handle risk is to embrace risk :)

      If you’re authenticated into a CIP compliant application, it’s really unlikely you’re not subject to some security already given the exceptional risk the provider is absorbing to serve you as a customer. Risk exists at the exposed party. That’s banking software and just part of life for us and everyone else in the space. The difference between providers is simply how hard, expensive, and open the platform is when you (as a CIP compliant platform) get up and running.

      Happy to jump on the phone to discuss at any time. Drop me a line and we’ll figure out a time – http://www.benmilne.com/contact-ben-milne/

  • timrpeterson

    Dwolla rules. Comment thread destroyed.

    • bpmilne

      It is very similar. This is true. We drink our own Kool-Aid. Guest checkout was the first go-round with this. Obviously, Dwolla (a CIP compliant software platform) is a user of our own services. We’re now making it available to everyone else.

      If you are not operating a CIP compliant platform yourself you can still use Guest Checkout for non-member incoming payments.

      • timrpeterson

        ok thanks, my platform is not CIP compliant.

        Is there any abbreviated explanation of rules for websites/startups to become CIP compliant?

        Perhaps it would be good to provide that (and/or a pros and cons of seeking CIP compliance) in your “Guest send” documentation?

        • bpmilne

          Pro – A lot of freedom.

          Con – A lot of risk.
          Con – A lot of cost.
          Con – A lot of knowledge to acquire.

          Others may chime in, but this is how I see it at a high level.

          To my knowledge, there is not a simple how-to guide on becoming CIP compliant. At least not one that is analogous to a “Guide to being PCI Compliant” outline you may find on various web sites.

          You can still use Guest Checkout. We’d love to work with you on creating the best experience possible.

          • timrpeterson

            thanks, last question, is one of the cons: – A lot of money? I.e., one need some kind of asset threshold ($millions?) to even apply?

            yeah Guest Checkout is all I need for now, will keep Guest send in mind though…

      • JetForMe

        I don’t think you want to drink your own Kool-Aid so much as you want to eat your own dog food. “Food” for thought…

  • Michael OBrien

    Do you see this as eventually being available (perhaps via a 3rd party that does due diligence on clients) to small companies wanting to use Dwolla-like low-cost billing without exposing the Dwolla interface to their clients? I’ve been searching high or low for something like this – I have no idea what CIP is but I assume it’s not easy for a 10-person shop to attain :)

    • bpmilne

      Michael – In my naive opinion it’s inevitable someone will eventually resell the API functionality under their name for a bit of markup.

      CIP is tough for a 1-person shop but a 10-person shop should be able to pull it off. Here is something to get you started – http://www.fincen.gov/statutes_regs/guidance/html/finalciprule.html

      Worst case we’ll be making it easier to create accounts on third party platforms where the experience remains on your site. If you wouldn’t mind drop this guy a line for more details he can be really helpful ==> twitter.com/baconseason.

      If we can work with you on on version 1 of an update before a public release we’re happy to do that.

      • Michael OBrien

        Thanks much, super exciting! Will ping Michael.

  • Eric

    So does this essentially provide me with ACH capabilities so my business can collect ACH-style payments?

    • http://twitter.com/BaconSeason Michael Schonfeld

      Yes, it essentially gives you the ability to charge customers using ACH. That said, we do require that you verify your customers (CIP compliant verification) before you do…

  • Stuart Grimshaw

    Is this for the US only, or should it work worldwide?

    • CaityJones

      Right now, Dwolla is only available in the U.S. But looking forward to going international!

  • http://twitter.com/wadearnold wadearnold

    Guest Send the PPD file creator killer: awesome! What is the settlement period? If the destination account has a Dwolla account, bur we dont know it, does it end up their or in there dda account ? Could it end up in there Dwolla account settled faster than their dda?

    • http://twitter.com/BaconSeason Michael Schonfeld

      The settlement period is that of normal ACH – Typically, the answer is 48-hours to actually process. Settlement in 72 hours.

      The destination will always have to get a Dwolla account. If you don’t know it, and you set the destination to an email address, that user will receive an email from us prompting them to create a Dwolla account and withdraw the funds…

  • http://twitter.com/markarake Mark Karake

    Hi Ben, we are working on a start-up that would need exactly what you have done here. I would like to learn more. Are all banks on board or is the system transparent to them? Are there any gotchas?

    • http://twitter.com/BaconSeason Michael Schonfeld

      Hey Mark! – All banks are “onboard”, since this API still utilizes standard ACH rails. The only “gotcha” here is that you have to verify your customers as per CIP compliance rules…