django-payments: One Payment Interface, Different Providers Behind It

A Single Layer Over Several Payment Providers

django-payments describes itself as universal payment handling for Django, and more precisely as a Django integration for receiving payments with different payment providers. It includes backends with support for a few payment providers, and it is also usable with community-maintained backends for additional providers.

That second clause matters. The core package does not try to cover every provider, it defines the interface and ships a small number of backends, and the rest of the ecosystem is expected to fill the gaps through separate packages that plug into the same interface. The documentation links to the list of community backends as a first class part of the story rather than an afterthought.

The topics attached to the repository show the shape of that ecosystem, with braintree, google-wallet, paypal, sagepay, sofort and stripe named, and the pyproject.toml carries optional dependency groups for braintree, cybersource, mercadopago, sagepay, sofort and stripe. So the bundled set and the community set overlap, and the two are not the same list.

The documentation is hosted at django-payments.readthedocs.io, and the project is a Jazzband project, with the Jazzband badge at the top of the README, while the package metadata names Mirumee Software as the author.

Provider Libraries Are Optional Extras You Install Yourself

The dependency structure is the part to understand before you install anything.

The required dependencies are short. They are django>=5.2,<7.0, requests>=1.2.0, and django-phonenumber-field with the phonenumberslite extra at 5.0.0 or newer. The phone number field is there because payment flows routinely need to collect a phone number, and the lite extra keeps the phonenumbers data small enough to bundle.

Everything provider specific is an optional extra, and each one pulls in the SDK for that provider:

braintree = ["braintree>=3.14.0"]
cybersource = ["suds-community>=0.6"]
mercadopago = ["mercadopago>=2.0.0,<3.0.0"]
sagepay = ["cryptography>=1.1.0"]
sofort = ["xmltodict>=0.9.2"]
stripe = ["stripe>=7.8.0"]

So a project that only wants Stripe installs django-payments with the stripe extra and gets the Stripe Python SDK, and a project that wants two providers installs both extras. Nothing provider related is pulled in by default, which keeps the base install small and means a security update to one provider SDK does not force an upgrade of the others.

The extras also tell you what kind of provider each backend talks to. Stripe and Braintree have their own client libraries, Sagepay's extra is a cryptography requirement rather than a Sagepay SDK, Sofort's is an XML parser, and Cybersource's brings in suds-community.

The Version Numbers Tell Two Different Stories

The release history and the dependency constraints do not agree, and an evaluation should notice it.

The tags are 0.14.0 from 2021-02-01, 0.12.4 from 2018-09-07 and 0.12.3 from 2018-03-30. The package is at 0.14.0, which is under the 1.0 mark, and the last published release is from early 2021.

But the current metadata says requires-python of 3.10 or newer, django>=5.2,<7.0, and the classifier list covers Django 4.2, 5.1, 5.2, 6.0 and 6.1 and Python 3.10 through 3.14. The Django 6.0 and 6.1 classifiers and the Python 3.14 classifier are recent, and they cannot have been present in a 2021 release.

So the project is being worked on and published in some form without cutting a new version tag, or the tags are simply not where the work is recorded. The repository is not archived and the last push was on 2026-10-12, and the CHANGELOG.rst at the root is where the history would show which happened.

One inconsistency inside the metadata is worth flagging too. The classifier list includes Django 4.2, but the dependency declaration requires django>=5.2, so a Django 4.2 project cannot install this version of the package even though the classifier suggests it can. When you check compatibility, the dependency constraint is the one that will stop your install.

Jazzband Governance and the Community Backend List

The project sits inside the Jazzband organisation, which is a community of Python projects that maintain shared infrastructure, and the Jazzband badge appears at the top of the README. The repository also has a CODE_OF_CONDUCT.md and a CONTRIBUTING.md, and a pre-commit configuration for the hooks.

The community backend list is a documented extension point rather than a marketplace. The README points to the backends section of the documentation for the list of community-maintained backends, and the documentation page for backends is the place to find out which providers exist beyond the bundled set.

That model has a clear consequence for the maintenance question. The core package is maintained by its own contributors, but each community backend has its own maintainer, its own release cadence and its own compatibility with the core interface. A provider that is present in the ecosystem may lag behind a core release, and the core interface may change in a way that requires a matching change in a community backend.

So the evaluation step for a specific provider is: check the community backend's own repository for its Django support and its release date, not just the core package's. The core being healthy says nothing about the third party package that carries your actual provider.

The Package Layout and the Test Harness

The repository is a conventional Django library layout. The payments/ directory holds the package, docs/ holds the documentation sources with a .readthedocs.yaml for Read the Docs, testapp/ is a Django project used for testing, and test_settings.py is the settings module for that test project.

The test configuration is tox.ini, and the project is built with setuptools through a pyproject.toml that requires setuptools 45, wheel and setuptools_scm at 6.2 or newer. The version is dynamic, declared as dynamic = ["version"], which means it comes from setuptools_scm reading the repository tags rather than being typed into the file. That explains the version numbers, and it is a strong hint about how releases are produced: a release happens when a tag is pushed.

The dev dependency group is thorough and says what the project expects of a contributor. It has coverage, pytest with pytest-cov and pytest-django, mock, django-stubs with the compatible-mypy extra, and type stubs for braintree, dj-database-url, requests, stripe and xmltodict. Those stubs are the giveaway that the project is type checked rather than merely annotated, and the type stubs for stripe and braintree correspond directly to the two optional backends with a native SDK.

There is also a docs extra with the Sphinx RTD theme, so the documentation is built with Sphinx and published to readthedocs.

Where the Boundaries Are

It is worth being explicit about what this library does not do.

It does not run a checkout. There is no basket, no address form, no payment session and no card collection in the core package. What it provides is the model and view layer for the payment record, the status handling and the provider conversation, which means you build the customer facing flow yourself, which is usually what you want anyway since a checkout is where your product design lives.

It does not abstract away the differences between providers. Each backend speaks its own protocol, with its own error shapes and its own notion of a pending or a failed payment, and the library's job is to give you a consistent way to record what happened rather than to make the providers interchangeable. A project that switches provider later will find the switch is in the view and template code, not only in settings.

And it is at version 0.14, which in packaging terms means the interface may still change between minor versions. The CHANGELOG.rst is the place to check what changed, and it should be read before an upgrade rather than after one.

None of that makes it a poor fit for what it does. For a Django project that needs to take money through more than one provider, or plans to, it removes the per provider integration work and keeps the data model in one place, which is the thing that actually costs you time when you add the second provider.

Editorial conclusion

django-payments fits a Django shop that wants one integration layer for more than one payment provider, or that plans to add a provider later, since the provider specific code is isolated behind optional extras and the model layer stays the same. It is a poor fit if you need a provider that only exists as a community backend, and a poor fit if you are on Django 4.2, because the declared dependency is django>=5.2 while the classifier list still mentions 4.2. Before adopting it, check which optional extra your provider needs and install it explicitly, since none of the provider libraries are pulled in by default, and read the backend documentation rather than assuming a provider behaves like the one you already know. The package is BSD licensed, the newest release is 0.14.0 from 2021-02-01, and the last push was on 2026-10-12.

Frequently asked questions

Official sources

1. Issues
2. jazzband/django-payments on GitHub
3. Project website
4. README
5. Releases