Python could certainly use a generic payments library—like what libcloud has done for cloud providers. And I don't want to demoralize you or ridicule the work d

Python could certainly use a generic payments library—like what libcloud has done for cloud providers. And I don't want to demoralize you or ridicule the work done already. However, there are a number of problems with the implementation as it stands that make it a bad idea to ask for contributors at this stage: 1. There are no tests. How can I be expected to contribute to your project when there's no way I can ensure a change doesn't break existing functionality, or even works itself? Testing remote APIs is a bit of a hassle, but it's what mocking was made for. Short of signing up for multiple payment gateways, there's no current way to test any change I make. 2. No setup.py support. This will likely further limit the number of people who contribute as it increases the barrier to entry. A proper project structure is a relatively easy thing that saves you a ton of time in aggregate. 3. There is no coherent developer API. Why does XMLGatewayInterface exist if only one gateway uses it? Why isn't there a generic GatewayInterface that abstracts things further, for non-XML APIs? If you're not going to use ABCs or strict interfaces (like zope.interface), you should at least have well-formed documentation: most ivar conventions (Foo.API_BASE, etc.) aren't mentioned anywhere. Why are there exceptions in the lib module that are only used by one gateway (or none)? 4. There are a multitude of minor design decisions that, if followed by contributors, will likely cause you pain down the road. Using print for debug output, relative imports, random error handling, "entrapping" functions (why would a function take two optional parameters that are immediately checked for non-None status?), etc. To be clear, I'm very glad you're working on this—it's a difficult (at least incredibly tedious) problem that I'm sure a lot of people would appreciate a Python solution for, myself included. But I don't think this is a very good time to be asking people to fork and contribute. You need a proper foundation built before trying to solicit contributions or you'll end up with a bunch of code you'll need to rewrite later instead of a comparatively small amount you should rewrite now. As the library author, it's your responsibility to build a cohesive, general-yet-customizable, clear interface upon which people can build and test their own gateway drivers. If you do that, I promise you you'll have contributors in no time. It's exactly what we did with libcloud and we now support almost every cloud provider out there and even have a nearly API-compliant Java fork (just to lend some credibility to my rambling).