
 Please fork, contrib & push Paython (Payments in Python) forward - auston
http://github.com/abunsen/Paython
======
tdavis
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).

~~~
auston
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!

------
hartror
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!

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

------
pbh
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/>

~~~
auston
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.

------
Mizza
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.

------
dangrossman
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.

~~~
auston
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).

~~~
dangrossman
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.

~~~
auston
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.

------
wizard_2
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.

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

------
Aegean
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.

~~~
mattdawson
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.

------
vessenes
This is awesome.

Do you have support for recurring charges built in?

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

~~~
vessenes
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.

------
thinkcomp
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.

------
ciupicri
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/>

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

~~~
enjo
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.

------
rsbrown
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.

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

~~~
rsbrown
... 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!

------
agentultra
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!

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

------
mey
Do you have a plan to certify the gateway code?

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

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

~~~
auston
Ahh, if it costs money, probably not.

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

