He runs multiple sites with a common business model: accounts with plan subscriptions. So there’s an obvious need for a generic account billing application.
The app should not be too specific, as that limits your business flexibility. Also it should not be too generic: you’ll end up with an architecture from hell that way. And there’s the billing as such: you need to pay close attention to security and so. Hard problem!
What he’s making is django-plans for keeping track of the billing data, the plans, etc. And django-getpaid as payment processing app.
Some challenges for the actual payment integration:
He wants it to be generic and lightweight. He doesn’t want to pull in half of pypi for a payment processing app.
He wants a single API so that he can switch payment brokers if needed.
He wants it to be asynchronous. Synchronous processing blocks too long.
Multiple currency support.
None of the existing apps were good enough, so he made django-getpaid. It is stable and supports a lot of (Polish) payment systems and is pluggable if you need to add another one.
Pluggability is achieved with special backends you can enable in your Django settings. This way you can easily add more. Each backend can read its configuration from the settings, too (it looks a bit like the database settings).
Django-getpaid works through signals and listeners. You configure the listeners to accept the models that represent an order and to extract the necessary information from them. Yes, that means that is quite flexible. It are your models and you get to specify how to extract information. So getpaid doesn’t make many assumptions.
There are template tags for rendering the forms that are needed. Easy to
integrate. There are some assumptions django-getpaid makes of the backends. There
should be a specially-named PaymentProcessor class, for instance.
Core concept is a pricing table. Items you can buy in the rows, kinds of customers in the columns, plans in the cells. Plans can be marked as unavailable; there’s a quota system; you can price them; periods; etc.
A tricky thing: switching plans! There are so many things that can happen. Does the customer switch from cheap to more expensive? Or the other way around? Is his current period expired or is it halfway? And so on. So… it should be pluggable.
What also needs to be pluggable: taxation policy. There are lots of differences per country.
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):
