News

Special thanks to CalvinHP, Claytron, and ChrisW for enthusiasm for taking on the taxes in GetPaid.

At the Plone Symposium in New Orleans, we did some collaborative design of the needs and requirements for tax infrastructure. Then, on last Friday, Calvin, Clayton, and Chris busted out the infrastructure!

Calvin's update reports:

The Symposium in New Orleans was a hotbed of GetPaid collaboration. We jump started a collaborative design process for integration PloneFormGen with GetPaid based on the nifty Salesforce.com adapter for PFG. Now, a week after we left New Orleans, already work is rapidly evolving:

• SteveM added a new feature to PFG (so action adapters can fail) and the code is tested and ready to release - thanks SteveM!!
• DanielHolth and perrito666 have been furiously hacking away and sharing code in a mercurial repository.
  
• Daniel's update today:
  perrito666 and I have been developing this at a rapid pace. So far we
  have something that's addable to the form and does a little bit of
  work. My end adds 0 of all the products in a given folder into the
  cart, and then the user might update their cart to select how many of
  each they want.
• Last I saw, perrito666 was working on pre-populating the PFG folder with the required GetPaid forms.
  

GetPaid's report at Ohloh has been updated to give stats on the project. We are now up to 14,937 lines of code. Other interesting factoids:

• 3 person-years worth of code (in about a year's time)
  
• 44 contributors
• 112 people following the mailing list
• 750+ downloads of the first release (plus many users with buildout)
• Over 170 downloads of the second release (only out for 2 weeks so far)
• 4 sprints
  

Payment Express is a Visa and MasterCard certified solution, developed by DPS, which facilitates electronic payments seamlessly from multiple access points i.e. Web, EFTPOS, Billing, Interactive Voice Responce, CRM, Vending, MOTO (Mail Order / Telephone Order) and Wireless.

DPS are certified with banks in Australia, New Zealand, Pacific Islands, Singapore, South Africa, USA and United Kingdom.

The payment processor is distributed as an egg getpaid.pxpay and is available on http://pypi.python.org/pypi.

This processor plugs in to the final step of the checkout. It provides the mechanism to securely authorize payment offsite.

See: http://code.google.com/p/getpaid/source/browse/trunk/getpaid.pxpay/src/getpaid/pxpay/README.txt for more help/discussion.

Thanks to Matt Halstead for integrating this and Darryl Dixon for kicking off the development!

For those joining the Plone Symposium in New Orleans this week, I will be giving a talk on "Social Sourcing" tomorrow (Wed) at 3pm.

Social sourcing is the participative organizing model with an entrepreneurial backbone, an established role for non-developers, and an ongoing process to make open source software projects sustainable that we used to organize the GetPaid project. Check out the notes and video from the social sourcing talk in Naples. This talk should include some updates (including from the questions in Naples and taking into account the Plone Strategic Planning Summit).

A while ago, we created the release branch for GetPaid's second major release, 0.6. However, we didn't officially release it (with packaged code etc), and in the meantime, several fixes and changes came in. So, we are now releasing 2 versions.

0.6.0: This is the originally branched code. Works well and preserves "backwards" compatibility for those using customized GetPaid code.

0.6.1: This is a final release. Includes API refactoring and unicode fixes. May break your customized GetPaid code but not too much :)

Both of these work on Plone 2.5 and 3.0, and apparently on Plone 3.1 also (though we currently aren't providing a buildout for 3.1).

To check out the changelogs, see http://groups.google.com/group/getpaid-changes 

Ain't integration fun!? We hope so... Lots of talk recently about integration GetPaid with PloneFormGen (for flexible forms leading into transactions) and Salesforce.com (to write transaction data into the CRM). These have long been areas of interest in the community, and I wanted to point out a couple threads of conversation going on around these (yes, I have been instigating some discussion again...).

PloneFormGen + GetPaid = single page checkout

At least, we hope! Ever since the first release of getpaid, we realized that a flexible  donation/payment form making option was desired for GetPaid. We know that everyone wants their donation form slightly different, so an option like
PloneFormGen, which also has wide adoption in the community, seemed like  an obvious choice.

One/Northwest and others have worked on an adapter for mapping PFG data into salesfoce.com, which seems like a great model for this use case. This leverages the flexible form making and integrates it into another system for storing/manipulating what was collected in the form - brilliant! For more on
this, see this blog post.

The concept would be similar for Getpaid integration with PFG: map fields from a form into GetPaid cart and/or checkout process. Some potential use  cases:
  - Make a single page checkout (so you enter all on one page and that generates the order directly)
  - Ordering multiple items from a single page

See an example of both of these at: http://tinyurl.com/53yr8o

See and contribute to thread here.

Salesforce + GetPaid = tracking those customers

See and contribute to thread here

And one day...maybe there will be a GetPaid + PloneFormGen + Salesforce.com integration! Oh the bliss!!

We would  appreciate your ideas, feedback, questions, and offers to contribute :)

Throughout the history of GetPaid, there have been several people interested in multiple currencies in GetPaid.  I was excited to hear from Jean-François Roche of Affinitic today about his progress in getting multiple currencies working in the context of GetPaid. I found out that he already has some useful use cases working and is waiting to get them in production to be able to merge them back into GetPaid.

Code monkeys can check out the latest in an svn repo. For those of us who prefer English explanations...a brief summary of what I learned about the work:

• The work grew out of the need to manage currency based on the country of the buyer
• The UI gets the price from the buyer at first entrance in the shop and then a utility that manages policies for the link between the country and currency picks which price to show.
  
• Each country defined in the policies then has a separate price
  

As of earlier today, we had 258 tests passing on 2 versions of Plone (2.5 and 3.0) - yippeee!

So, with much joy, we are moving the trunk to the 0.6 branch for this release.

Next we will tag a 0.6.0 release candidate.

This release got a new directory of documentation as well as a lot of work on new features for shipping, fulfillment and reporting. Have a look at the latest buildout!