Please fork, contrib & push Paython (Payments in Python) forward | Hacker News Reader

Please fork, contrib & push Paython (Payments in Python) forward

github.com

87 pointsauston35 comments

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!

I'll definitely read that & look into using in future iterations.

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?

http://www.satchmoproject.com/

http://bitbucket.org/bkroeze/django-bursar

http://bitbucket.org/diefenbach/django-lfs/

http://www.plonegetpaid.com/

Definitely will do tomorrow!

Thus far, Paython is standalone. Planning to add tests, unifying conventions & wrapping all gateways up into something much easier to use.

This is a seriously necessary project.

I recently used this: http://github.com/simplegeo/python-fpys2

Perhaps you would be interested in merging it? I have some additional example documentation the author emailed to me as well.

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.

Dan, those are my aspirations. I would not place a PCI compliance stamp on the project because no matter what, people can use it "incorrectly".

I am not against supporting ARB, but it is a big vendor lock in & I think it makes sense to have options.

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.

How about WePay support? Documentation is at https://www.wepay.com/developer Rough Python example code at https://www.wepay.com/developer/python

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.

This is awesome.

Do you have support for recurring charges built in?

Not yet, but the goal is to get to something like that.

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.

For those looking for something adventurous in the payments world, we're just starting to look for feedback on the FaceCash API, which is brand new.

http://www.facecash.com/developers

It doesn't process plastic, but it does allow you to integrate mobile payments for any kind of retail transaction.

Another similar project is django-bursar[1] which is supposed to be integrated into the Satchmo[2] webshop in the (far) future.

[1] http://bitbucket.org/bkroeze/django-bursar

[2] http://www.satchmoproject.com/

One of the sad things about the Django community is that they create useful things that aren't usable outside of Django.

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.

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.

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.

We're working on it! And we'd love to talk to you about integrating your menu data.

... with your payments system?

At any rate, happy to talk: scott (at) marksmenus.com

EDIT: Ah, I'm guessing you're thinking for FaceCash? Sounds good -- shoot me an email!

If your into this space, I'd highly recommend Dee Hock's book: One from Many: VISA and the Rise of Chaordic Organization

it tells the tale about how he created VISA

http://www.amazon.com/gp/product/1576753328?ie=UTF8&tag=...

I was hoping someone would eventually do this.

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.

Tedious, but necessary!

Cool. Anyone know if something like this exists for .NET? Otherwise it might be good for my first open source contribution :)

Do you have a plan to certify the gateway code?

Can you please explain what you mean by "certify"?

Typically a payment processor has a certification process to validate code talking to their system.

Ahh, if it costs money, probably not.

If it doesn't, I don't see why I wouldn't try?

Reply on news.ycombinator.com