6 ms·

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

87 points by auston 16y ago

Mizza 16y ago
This is a seriously necessary project. I recently used this: http://github.com/simplegeo/python-fpys2 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.
mey 16y ago
Do you have a plan to certify the gateway code?
- auston 16y ago
  Can you please explain what you mean by "certify"?
  - mey 16y ago
    Typically a payment processor has a certification process to validate code talking to their system.
    - auston 16y ago
      Ahh, if it costs money, probably not. If it doesn't, I don't see why I wouldn't try?
hartror 16y ago
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/ http://www.python.org/dev/peps/pep-0249/) but for payment gateways!
- auston 16y ago
  I'll definitely read that & look into using in future iterations.
vessenes 16y ago
This is awesome. Do you have support for recurring charges built in?
- auston 16y ago
  Not yet, but the goal is to get to something like that.
  - vessenes 16y ago
    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.
wizard_2 16y ago
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.
ciupicri 16y ago
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 http://bitbucket.org/bkroeze/django-bursar [2] http://www.satchmoproject.com/ http://www.satchmoproject.com/
- lost-theory 16y ago
  One of the sad things about the Django community is that they create useful things that aren't usable outside of Django.
  - ciupicri 16y ago
    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.
  - enjo 16y ago
    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.
- rcoder 16y ago
  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.
dangrossman 16y ago
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 16y ago
  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 16y ago
    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 16y ago
      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.
Aegean 16y ago
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 16y ago
  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.
thinkcomp 16y ago
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 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.
rsbrown 16y ago
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 16y ago
  We're working on it! And we'd love to talk to you about integrating your menu data.
  - rsbrown 16y ago
    ... 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!
- deleted 16y ago
  [deleted]
- dantheman 16y ago
  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=dangag-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1576753328 http://www.amazon.com/gp/product/1576753328?ie=UTF8&tag=...
tdavis 16y ago
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 16y ago
  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!
rll 16y ago
How about WePay support? Documentation is at https://www.wepay.com/developer https://www.wepay.com/developer Rough Python example code at https://www.wepay.com/developer/python https://www.wepay.com/developer/python
pbh 16y ago
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://www.satchmoproject.com/ http://bitbucket.org/bkroeze/django-bursar http://bitbucket.org/bkroeze/django-bursar http://bitbucket.org/diefenbach/django-lfs/ http://bitbucket.org/diefenbach/django-lfs/ http://www.plonegetpaid.com/ http://www.plonegetpaid.com/
- auston 16y ago
  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.
agentultra 16y ago
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 16y ago
Cool. Anyone know if something like this exists for .NET? Otherwise it might be good for my first open source contribution :)

87 points by auston 16y ago

Mizza 16y ago

This is a seriously necessary project. I recently used this: http://github.com/simplegeo/python-fpys2 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.

mey 16y ago

Do you have a plan to certify the gateway code?

auston 16y ago
Can you please explain what you mean by "certify"?
- mey 16y ago
  Typically a payment processor has a certification process to validate code talking to their system.
  - auston 16y ago
    Ahh, if it costs money, probably not. If it doesn't, I don't see why I wouldn't try?

hartror 16y ago

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/ http://www.python.org/dev/peps/pep-0249/) but for payment gateways!

auston 16y ago
I'll definitely read that & look into using in future iterations.

vessenes 16y ago

This is awesome. Do you have support for recurring charges built in?

auston 16y ago
Not yet, but the goal is to get to something like that.
- vessenes 16y ago
  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.

wizard_2 16y ago

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.

ciupicri 16y ago

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 http://bitbucket.org/bkroeze/django-bursar [2] http://www.satchmoproject.com/ http://www.satchmoproject.com/

lost-theory 16y ago
One of the sad things about the Django community is that they create useful things that aren't usable outside of Django.
- ciupicri 16y ago
  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.
- enjo 16y ago
  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.
rcoder 16y ago
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.

dangrossman 16y ago

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 16y ago
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 16y ago
  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 16y ago
    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.

Aegean 16y ago

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 16y ago
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.

thinkcomp 16y ago

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

rsbrown 16y ago

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 16y ago
We're working on it! And we'd love to talk to you about integrating your menu data.
- rsbrown 16y ago
  ... 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!
deleted 16y ago
[deleted]
dantheman 16y ago
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=dangag-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1576753328 http://www.amazon.com/gp/product/1576753328?ie=UTF8&tag=...

tdavis 16y ago

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 16y ago
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!

rll 16y ago

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

pbh 16y ago

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://www.satchmoproject.com/ http://bitbucket.org/bkroeze/django-bursar http://bitbucket.org/bkroeze/django-bursar http://bitbucket.org/diefenbach/django-lfs/ http://bitbucket.org/diefenbach/django-lfs/ http://www.plonegetpaid.com/ http://www.plonegetpaid.com/

auston 16y ago
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.

agentultra 16y ago

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 16y ago

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