Report-out from the Seattle GetPaid recurring payment mini-sprint
Groundwire organized a mini-sprint this past Thursday-Saturday to work on adding support for handling recurring subscription-based payments using PloneGetPaid. I had the honor of coordinating this work, and am happy to report that we had a very productive sprint and surpassed my goals for what we should accomplish.
We added support for creating a recurring payment subscription to the Authorize.net and Paypal payment processors. This will be done instead of a standard one-time payment if the cart contains a "recurring line item," with a corresponding interval and total # of payments. (Carts containing multiple recurring items, or a mixture of recurring and non-recurring items, are not supported.)
We also created two ways to get recurring line items into the cart. The first way is similar to the way that other types of payment are configured in GetPaid: Add a marker to an arbitrary piece of content by selecting "Make recurring payment" from the action menu, and then enter the price, interval, and total # of payments. (This can be done as long as the current payment processor supports recurring payments.) Once an item is configured as a recurring payment, a portlet displays with an "Add to Cart" button that can be used to being purchasing.
The second way to get recurring line items into the cart is via a new package, pfg.donationform, which provides a shortcut to set up a PloneFormGen form for making a one-time *or* recurring donation. (Aside from the recurrence part this was possible before using getpaid.formgen, but the new package streamlines the setup.) Selecting "Donation Form" from Plone's Add menu gives the site manager an opportunity to enter several settings which affect the creation of the standard PloneFormGen form. The created form includes a custom "Donation Fieldset" which allows selecting from predefined donation levels or entering a custom amount, and specifying whether the payment should be one-time or recurring, and for how many months it should recur. The donation form may also optionally be populated with fields to collect contact and billing info so that checkout can happen in a single step (at least with an on-site payment processor like the Authorize.net one). When the donation form is submitted, line items will be added to the GetPaid cart based on the settings in the Donation Fieldset, and checkout will be initiated.
Along the way, we also found time to add tests to getpaid.authorizedotnet and getpaid.formgen, which had no working tests before.
All of this work has been on branches so far. In the next week or so we'll be working on adding a few more tests, merging the changes, and making new releases of the relevant packages. If you would like to review the work before that happens, please feel free. Just check out the getpaid development buildout, and build it using recurring-payment.cfg, to get the relevant branches.
Thanks to the other sprinters and their employers for giving your time: Alex Tokar and Fulvio Casali of Web Collective, Jesse Snyder of NPower Seattle, Cris Ewing of U. of Washington Radiology, and Rob Larubbio. (And welcome aboard as GetPaid committers, Alex, Fulvio, Jesse, and Cris.) Thanks also to ifPeople and Juan Pablo Gímenez who did some work in 2008 that provided a helpful starting point for our work, to Zvezdan Petkovic from Zope Corporation for making new Zope 2.12-compatible releases of zc.ssl and zc.authorizedotnet, and to Groundwire for giving us a space to work and buying us lunch on Friday.
Organizing a mini-sprint
Some scattered thoughts on organizing an effective sprint:
- Sprints don't have to be large, expensive, or difficult to organize. If you have a few local Plonistas, a place to meet, and a clear shared goal, you can have a great sprint. A small sprint means fewer brains, but increased communication and focus.
- Not everyone participating in the sprint needs to have a deep familiarity with the product you're working on, but if you want to maximize productivity, everyone should have prior experience working on some Plone product. And at least one person needs to have enough familiarity with the product and the sprint goal to produce a list of tasks ahead of time that can be easily divvied up amongst the participants.
- A small amount of effort by the sprint coordinator in advance can make sure half the sprint isn't wasted on initial setup and bootstrapping tasks that don't benefit from more people. Prior to the sprint, I made sure that Juan's previous branches were up-to-date against GetPaid trunk with passing tests (well, mostly). I also made sure that all participants had commit access to the GetPaid repository, and tried to make sure that they ran the development buildout ahead of time.