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).
That's a reason I put this out, to get harsh realistic feedback. You're right, I do need tests - someone has come forth & offered to write them since I put this online.
I want to improve what I've got but, IMO, I cannot do so by myself. Hence my call to arms. If you want something like this, please help improve it!
Different contributors join at different stages for differing motivations. There's absolutely nothing wrong w/ putting this out there now and asking for help. There is never a perfect time. You can always have more tests. The well designed, general-yet-comprehensive, clear API you thought you needed might actually be entirely wrong once 5 or 10 people start submitting patches.
It is never wrong or a bad idea to ask for help. Whether you're at the idea stage, only have some hacked up barely working code, or are a mature project with a stable set of APIs. Asking for help is well, exactly that... asking for help.
Oooh nice, a payment system not encumbered with a framework.
What would be really awesome is for this to turn into something like the standard database api spec PEP249 (http://www.python.org/dev/peps/pep-0249/) but for payment gateways!
If you have already looked into this (and decided to write your own), it would be great to see a blog post or similar on the current state of payments in Python (and what you intend to do differently).
It seems like there's Satchmo, various Satchmo forks, and GetPaid, but I can't tell which are directly or indirectly tied to various frameworks (Django, Plone). Are people just coding directly to payment APIs? Is everyone running on Django or Plone?
You should say that you support Authorize.net AIM. You'll eventually want modules for Authorize.net ARB and Authorize.net CIM as well, for those doing recurring payments. Each has a separate API unfortunately.
Hey Dan, the plan is too eventually be a standalone recurring billing system. ;) So things like ARB become optional not required & things like switching gateways are not impossible (as would be the case with stuffing all of your customers into ARB).
Have you thought it through that far? That implies building a PCIDSS certified solution, with tons of additional requirements. I doubt there are (m)any individuals, small businesses or startups that can legally do their own gateway-independent recurring billing. The physical security, documentation, policy and extra hardware requirements in addition to the huge (half a million dollars per violation) liability make it infeasible.
If someone just downloads your code and starts storing the cardholder data on the same server, even encrypted end to end, that's still not nearly PCIDSS compliant, so they're violating their merchant account agreement and hugely liable if it leads to any kind of data theft.
It would be wonderful if there was an easy way to be payment gateway independent for recurring charges without meeting the 3-digit number of PCIDSS requirements, but I don't think that can come from any code project.
I recently spent about a week trying to hack Django Bursar into something useful. I was woefully surprised at the lack of payment libraries available in python. I highly recommend stealing as much as you can from existing systems (including Bursar and Satchmo) it will save you some time.
I don't like the name. Hard to pronounce, also stealing thunder from a language name for no solid reason; a programming language is in a different mental category than an application service.
I don't wholly disagree with you, but Python developers are more prone than most to name their packages with at least a py prefix, if not something punny like this.
That would be cool. I think some thought would need to go into the API there, as the provider market fragments pretty quickly over how and what they offer.
Although there have been projects (like Celery) that have started as Django projects until they achieved relatively maturity, at which point they were broken out into more general libraries.
Yes, you're right. I've mentioned it hoping that the two authors will merge their projects into a Python library and a smaller Django specific application/library.
My team tried to use Bursar, and found it wasn't really viable as a standalone project w/o a Satchmo store in front of it.
At this point, we've created our own payment gateway wrapper. At an API level, it doesn't look terribly different from Paython, so I'm cautiously hopeful that we'll be able to port our PayFlow Pro and stored credit gateway backends if it looks like Paython is gaining traction.
Just so you know, the reasons why a decent payments solution has not emerged are not technical in nature.
For significant change to occur in the payments space, a business model to rival Visa must be developed and led by someone with the political savvy to drive it home.
I wrote PyMoneris a while ago simply because there wasn't one and have been hoping someone would start a project like this that I could hand that code over to.
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).