New Scheduled/Recurring Payments API!


(Gordon Zheng) #1

What’s new?

The ability to create recurring payments via the API has been, without a doubt, one of the most requested features over the past few years. Today, we’re excited to announce that recurring payments are finally here, in the form of Scheduled Payments. It’s Christmas in April.

Scheduled Payments

Scheduled Payments allow you to schedule a bank sourced payment for some time in the future. They can be one-time or recurring. When you create a scheduled payment, no money is transferred until the scheduleDate you provided. This is perfect for subscriptions and other payments that need to happen on a regular basis, like rent or membership fees. Read more about Scheduled Payments in our API docs.

Let’s say I want to send $9.95 to someMerchant@dwolla.com every other week on Mondays. I’d make an API call like this:

POST https://www.dwolla.com/oauth/rest/transactions/scheduled
Authorization: Bearer 10nNPKqaTfBy3qpe7Xnu+zlacHhjlct9cBgHN0NBWCuGkHxluA
{
  "destinationId": "someMerchant@dwolla.com",
  "pin": 9999,
  "destinationType": "Email",
  "amount": 9.95,
  "notes": "Biweekly subscription charge",
  "scheduleDate": "5-20-2015",
  "fundsSource": "5da016f7769bcb1de9938a30d194d5a7",
  "recurrence": {
      "frequency": "weekly",
      "onDays": "2",
      "repeatEvery": "2"
  }
}

It happens to be that I’ve connected a FiSync-enabled BBVA Compass account, so every other week starting 5-20-2015, $9.95 will be sent and made available to the recipient in real time.

Options for recurring payments are quite flexible. You can create a recurring payment that pays weekly, monthly, daily, every week on Tuesdays and Fridays, every 12th and 18th and 26th each month.

Every week on Tuesdays and Fridays:

{
  ...
  "recurrence": {
    "frequency": "weekly",
    "onDays": "3,6"
  }
}

On the 12th, 18th, and 26th of every month, until the year ends:

{
  ...
  "recurrence": {
    "frequency": "monthly",
    "onDays": "12,18,26",
    "endDate": "2015-12-31"
  }
}

New OAuth scope: Scheduled

We’ve added a new OAuth scope, Scheduled so your users can give your application permission to create, edit, and delete scheduled payments on their behalf. Before you get started, remember to add Scheduled to your app’s permissions and include Scheduled in your OAuth authorization request URL.

Give it a try

We’ve built a sample Ruby on Rails app that implements scheduled payments. Check it out!

Our node.js, ruby, PHP, and python libraries have been updated to support scheduled payments.

Feedback, comments, need help integrating? We’re always happy to help out. Reply below.


Dwolla API Libraries: Mass Update
API Update: Scheduled transactions
(Ankur Sethi) #2

Great news. Subscriptions are exciting. Do you plan to have a user interface for this like Paypal so that people can create subscriptions themselves without an app?

I think that is a super source of revenue for you guys. There are a lot of businesses using Paypal subscriptions and really there is no alternative out there. I am working with a CSA who does it. Now we need an app to implement your API.


(Ankur Sethi) #3

So the user must send his PIN to the app and the app creates the scheduled transaction?

As a developer this whole PIN based workflow is disappointing. This scheduled API is an improvement, but the whole PIN thing and requiring your own version of PCI compliance is disappointing. Plus users have to trust your app will not make a request for all their money using their PIN.

Frankly Paypal’s model is much easier to deal with. App’s send users to Paypal and get a token back with payment details. If it was done that way then we wouldn’t need apps to request a PIN to create a payment.

Dwolla expecting apps to request a PIN from a user looks to me like a fundamental architectural problem.


(Gordon Zheng) #4

Hey @Ankur_Sethi,

Thanks for your feedback.

To clarify, you won’t need to store a PIN at all to use Scheduled/Recurring payments. If the sending user is a Full user, you’ll just need to ask for and supply the PIN once, but not store it.

With the introduction of Dwolla Direct to our Off-Site Gateway last year and OAuth just this week, we predict that the majority of users on the Dwolla network will be lightweight Direct users.

Since Direct users don’t have PINs, a Direct user can send a scheduled payment with just an access token. Read more about Direct users and our new OAuth account creation improvement.


(Ankur Sethi) #5

So if there is no PIN the app can schedule any sort of recurring payment for a direct user?

It is not clunky, it is fundamentally insecure. You say the app doesn’t have to store a PIN. How does a user know that? The whole issue is you trusting apps completely.

I think the Paypal method is far superior. The app creates a subscription profile and then the user approves it on Paypal.

Now if a user disputes a transaction, are you going to ask the app for proof? Why isn’t Dwolla handling that? Why doesn’t Dwolla take responsibility for storing a user’s acceptance of payment terms?

I want to like Dwolla, but the way it is built discourages simple integrations. Is there some patent on the way Paypal does it? I still can’t believe noone is duplicating it and reducing costs.


(Gordon Zheng) #6

We appreciate your perspective and we carefully consider end user security with every feature we deploy.

As a part of this, we offer a variety of secure methods to access the Dwolla platform, allowing our partners to find the solution that both accounts for their payment needs and the needs of their customers.


(Ben Milne) #7

@Ankur_Sethi,

I think there are a few things that are worth noting for those who may be reading the thread as well.

You’ve asked a lot of good questions.

So the user must send his PIN to the app and the app creates the scheduled transaction?

A Dwolla member(user) carrying a full account will have to authorize your application with a PIN to schedule a recurring payment. Yes.

If you’re thinking about this in a CC world. The Dwolla PIN is kind of like a dynamic CVV code the account holder can change. I enter my CVV on every website I pay for something with my card.

If the account holder has an account with a PIN then you’ll need to ask for it in order to schedule a transaction in the Oauth flow.

requiring your own version of PCI compliance is disappointing.

PCI has a lot to do with the storing of sensitive data. In this situation developers do not need to store the PIN using this process which removes a lot of headaches.

Is there something specific you’re referring to that the team can address?

Do you plan to have a user interface for this like Paypal so that people can create subscriptions themselves without an app?

This will eventually end up in the Dwolla.com UI so that anyone can use it without an app.

You may also be thinking about recurring in the API using the offsite gateway where the user is in a Dwolla provided flow. We do see this as valuable in the future.

From a UI perspective, when the Paypal API is used I’m sure there are a lot of potential workflows but generally this is pretty similar at a high level to some of what PayPal has done.

I say similar as I think about how I use Paypal to pay for Spotify every month. I authorized with Paypal and then Spotify received back some tokens that can be cancelled at any point in time after my authorization. The experience is very similar to what I used when I signed up for recurring payments with Spotify. There may be other flows and we’re happy to talk through them.

We’ve been using this type of flow for quite some time and it works really well.

Now we need an app to implement your API.

This is true if in order to control the front end experience. For a API to be used there is a need for an app to be built in order to use it.

In this case there is a nice workaround and a way to test it.

Here is a open source app that’s cool to mess with that will show you all of this good stuff! If you’d like to skip deploying it and see what I mentioned above you can test it here - https://dwolla-recurring-heroku.herokuapp.com/

So if there is no PIN the app can schedule any sort of recurring payment for a direct user?

The app needs the users permission via the oauth scope to acquire the ability to schedule a recurring payment. This goes back to that similar situation where I authorized Spotify via PayPal to bill me monthly.

Now if a user disputes a transaction, are you going to ask the app for proof?

Dwolla, doesn’t really look at a recurring payment as any different than a regular payment. Keep in mind in many cases the application may not be the receiver of the payment.

The app in the example above just makes it easier to set up a recurring payment.

I am working with a CSA who does it

How can we help you get up and running with the CSA and what is the website? We’d be happy to help everyone get up and running. @gordon, @spencer, @David can be pretty helpful :smile:


(Ankur Sethi) #8

@bpmilne Thank you for the response. I am working with a CSA but do not want to build an app for just them. I don’t think it would be good for them to rely on a newly created app for their entire payments. They are looking for a Paypal alternative, but building a system for recurring payments using an API is not something we want to do.

The Dwolla PIN is kind of like a dynamic CVV code the account holder can change. I enter my CVV on every website I pay for something with my card.

Yes you can change your PIN and a user is trusting a website every time they pay with a card. That is where Paypal comes in. With Paypal I do not need to trust a website. Dwolla does not provide this. So you have a replacement for credit cards, not a replacement for Paypal. I hate to always bring up Paypal, but I am seeing they have some things right. Also PCI compliance and your PIN also includes simply receiving a PIN or credit card, not necessarily storing it.

The app needs the users permission via the oauth scope to acquire the ability to schedule a recurring payment. This goes back to that similar situation where I authorized Spotify via PayPal to bill me monthly.

With a Paypal you specifically authorized a single recurring transaction. The user bought something on Spotify’s website and checked out with Paypal. With the Dwolla API you would have to enter your payment information on Spotify’s website and authorize via an Oauth authorization and a PIN and the Spotify would create a transaction. It is just like giving your credit card details to Spotify and they would have a payment processor which would do scheduled transactions.

You can see why even a big company like Spotify would rather have Paypal handle PCI compliance for them.

Anyway I appreciate you taking the time to go through this with me. I look forward to something which can be integrated easily for a use case like a CSA.

Their use case is simple. They have a few different subscription options in a few different areas. We would want to put up some HTML and javascript. Have the user select their options, and then have a checkout on a payment processor (Like Paypal now). The CSA should get a list of active subscriptions with meta-data. Who subscribed to what in what location. That is what is missing in Paypal. They don’t have good support for metadata (and of course their costs are higher).

Anyway I hope to see the functionality on the Dwolla UI. You should get a lot of customers this way. There are a lot of medium to big sized companies using Paypal subscriptions because really there is nothing else out there.

Here is an example: http://www.ninjatrader.com/purchase-lease.php

Their monthly subscriptions are $50 a month. They must have tens of thousands of subscribers. All hooked up with a Paypal external checkout and organized with SugarCRM. A huge company like that did not have to use an API and does not have to deal with any sort of compliance issues.


(Ben Milne) #9

I am working with a CSA but do not want to build an app for just them.

Totally understand. I’ll type up what looks like the solution at the end of this post. I couldn’t find the CSA’s website above but I think I’ve got a decent handle on what you’re looking for.

not a replacement for Paypal.

Totally agree if you need to support card payments. Many CSAs for example support cards and Dwolla. Paypal being the card provider.

. With the Dwolla API you would have to enter your payment information on Spotify’s website and authorize via an Oauth authorization and a PIN and the Spotify would create a transaction.

You could do it this way but most merchants/billers probably will not. I imagine most merchants or companies doing recurring billing will just prompt the user to “agree” to a price and then hit the API with the payment instructions.

Their use case is simple. They have a few different subscription options in a few different areas. We would want to put up some HTML and javascript.

It sounds like what you are looking for is not a direct API integration where you build a bunch of functionality but rather a button that kicks off a offsite session that supports recurring based on a preset price.

This is coming soon for lighter integrations!


(Red Yates) #10

How flexible is editing a recurring payment after it has been created and approved? Do you have any plans for something similar to PayPal’s reference transactions or Stripe’s invoice objects?

W’d like to implement Dwolla as a payment method but we have a somewhat non-standard payment structure. Subscribers pledge a given amount per content release, and then are billed monthly for those pledges, which can be anywhere from 1 to 14 times their pledge amount.

Our PayPal and Stripe implementations allow us to generate automated line-item billing, initiated by our server on our schedule, all with a single authorization from the user when their subscription is created. How close to that could we get with Dwolla, and are there planed updates that would get us closer?


(Gordon Zheng) #11

Hey @Red. We can’t currently provide variable amount and variable timing for recurring payments today with a single authorization. While’s it’s technically possible with our API, we still need to investigate this further from a compliance perspective before we can fully support this on our platform.

Thanks so much for highlighting this use case for us. I’ll let you know if we have any solid plans to support it.


(Narayana Amuda) #12

Hi Sir, I’m new to the API’s but i’m happy to use the dwolla in our Project where i’m a member working on dwolla integration.

I’m able to integrate sending(transfer) money by using “PAYMENT BUTTON” integration. where the user login and enter his pin all in the dwolla website and i gets the status where i’m updating the status of the payment in our DB.

Now I’m need to integrate the recurring(Scheduled) Payments. I’m redirecting the user to Login and accepting the Permissions. And redirecting to my redirect url page. but i’m not asking for his 4 digit pin. where i need to ask him the pin and how to select the funding resource of his list. for the recurring(scheduled) payment.


(Spencer Hunter) #13

Hi @Narayana_Amuda ,

It sounds like you have implemented OAuth, which is a good first step in being able to initiate scheduled payments. (Note: you will need at least OAuth scopes: Scheduled and Funding) Since scheduled payments must be funded with a verified bank-funding source, you will need to pull in the list of funding sources for the user to select from. In addition, prompt the user to enter their Dwolla PIN. Once the user has selected their funding source and has entered their Dwolla pin you will make a POST request to /scheduled to create the scheduled transaction. From a UI perspective, here is an example of what it could look like to prompt the user for their PIN and funding source.

Also, be sure to check out this sample app for creating scheduled/recurring payments.

Feel free to reply back if you run into any issues in this process!


(Narayana Amuda) #14

http://www.files.com/shared/5556dd24e4bd6/Dwolla1.pdf

This is I done for the single payment using DWOLLA where user clicks the
button and redirects to DWOLLA website he logins
and selects fund resource and Enters his 4 digit pin number.

And the transaction
completes and it redirects to my redirect page
then I can update the status of the payments
with the response in our DB.

How to do the Scheduled payments with the similar screen
where I need to ask the user to select Fund Resource and Enter the 4 digit Pin

Scheduled(Recurring)

I’m able to create a LINK http://example.com/dwolla/act_sch.php

Where user is able to navigate
to DWOLLA website he ables to enter the Login details and if he loggedin successfully he his redirecting
to the redirect url of my website.

I’m able to get the Funding
Resources with using his access_token

But I’m not able to understand
where I need to ask him to select the Funding Resource
and to Enter 4 digit pin to complete the scheduled
payments.

Either in DWOLLA Website
: Then How to do(process)

Either in Our Website
: Then How to do(process)


(Spencer Hunter) #15

@Narayana_Amuda

This will need to be done on the client side in your own website. (You handle the UI).

After you get the users Funding Source list, you will need to render this data to the client (possibly in a dropdown list). Also, on that same page you can provide an input field where the user can enter in their Dwolla PIN. Once the user selects their funding source and enters their Dwolla PIN you will pass this data over to the server side where you will make an API call to create a scheduled payment.

Other items to keep in mind: Validation on the input data and handling API errors.

This is a high level overview of how this can be done. Also, test out this sample app, and take away ideas of how this can be implemented using Ruby on Rails. If you are running into issues implementing this, please feel free to create a new topic and we can walk through the code together. :slight_smile:


(Sreejil Veenakkad) #16

“fundsSource”: “5da016f7769bcb1de9938a30d194d5a7”, from where i get this value


(Spencer Hunter) #17

Hi @Sreejil_Veenakkad, I mentioned this briefly in my previous reply, but when you call [List Funding Sources][1] with the user’s OAuth token you will get back a list of funding sources which includes the fundsSource Id. Example below.
List of funding sources:

GET https://www.dwolla.com/oauth/rest/fundingsources/
Authorization: Bearer pBA9fVDBEyYZCEsLf/wKehyh1RTpzjUj5KzIRfDi0wKTii7DqY
        {
    "Success": true,
    "Message": "Success",
    "Response": [
        {
            "Id": "Balance",
            "Name": "My Dwolla Balance",
            "Type": "",
            "Verified": "true",
            "ProcessingType": ""
        },
        {
            "Id": "c58bb9f7f1d51d5547e1987a2833f4fa",
            "Name": "Donations Collection Fund - Savings",
            "Type": "Savings",
            "Verified": "true",
            "ProcessingType": "ACH"
        }
    ]
}

Create Scheduled Payment:

POST https://www.dwolla.com/oauth/rest/transactions/scheduled
Content-Type: application/json
Authorization: Bearer pBA9fVDBEyYZCEsLf/wKehyh1RTpzjUj5KzIRfDi0wKTii7DqY
{
  "amount":10,
  "destinationId":"812-114-7461",
  "destinationType":"Dwolla",
  "fundsSource":"c58bb9f7f1d51d5547e1987a2833f4fa",
  "notes":"Weekly recurring membership",
  "pin":"7890",
  "scheduleDate":"2015-05-04",
  "metadata":{
    "foo": "bar",
    "bar": "baz"
  },
  "recurrence":{
    "frequency":"weekly",
    "onDays":"2"
  }
}

Let us know if we can provide additional clarification!
[1]: https://docs.dwolla.com/#list-funding-sources


(Ankur Sethi) #18

It sounds like what you are looking for is not a direct API integration where you build a bunch of functionality but rather a button that kicks off a offsite session that supports recurring based on a preset price.

This is coming soon for lighter integrations!

@bpmilne It has been about a year. Any update on this?


(Cory Anderson) #19

(Cory Anderson) #20