Welcome to django-getpaid’s documentation!

django-getpaid is a carefully designed multi-broker payment processor for django applications. The main advantages of this django application are:
  • instead of only one payment broker, you can use multiple payment brokers in your application, what is wise considering ane single payment broker downtime,
  • payment brokers have a flexible architecture each one based on a django application structure (they can introduce own logic, views, urls, models),
  • support to asynchronous payment status change workflow (which is required by most brokers and is architecturally correct for production use),
  • support for payments in multiple currencies at the same time,
  • uses just a minimal assumption on your code, that you will have some kind of order model class.

The basic usage is to connect you order model class with django-getpaid. Because the AbstractMixin is used, Payment model class uses a real ForeignKey to your order class model, so it avoids messy django content_type relations.

This app was written because there still is not a single reliable or simple to use payment processor. There are many payments related projects out there like Satchmo, python-payflowpro, django-authorizenet, mamona, django-paypal, django-payme, but none of them are satisfying. Mamona project was the most interesting payment app out there (because of general conception), but still has got some serious architectural pitfalls. Therefore django-getpaid in the basic stage was aimed to be a next version of mamona. django-getpaid took many architectural decisions different than mamona and therefore has been started as a separate project, while still borrowing a lot of great ideas from mamona, like e.g. using AbstractMixin, dynamic model and urls loading, etc. Thanks mamona!

Disclaimer: this project has nothing in common with getpaid plone project. It is mostly based on mamona project.

Versioning

Semantic Version guidelines will be followed in this project versioning.

Releases will be numbered with the following format:

<major>.<minor>.<patch>

And constructed with the following guidelines:

  • Breaking backward compatibility bumps the major (and resets the minor and patch)
  • New additions without breaking backward compatibility bumps the minor (and resets the patch)
  • Bug fixes and misc changes bumps the patch
  • Major version 0 means early development stage

For more information on SemVer, please visit http://semver.org/.

Developing

Project leader:

Contributors:

You are welcome to contribute to this project via github fork & pull request.

If you create your standalone backend (even if you don’t want to incorporate it into this app) please write to me, you can still be mentioned as third party payment backend provider.

Indices and tables