# django-paypal: a Django plug-in for Payments Standard and Payments Pro, now in maintenance mode

> django-paypal integrates PayPal Payments Standard and Payments Pro into Django through a pluggable application with IPN and PDT handlers. Its own documentation warns that PayPal supports these methods poorly today and that newer PayPal APIs are not covered.

**spookylukey/django-paypal** — A pluggable Django application for integrating PayPal Payments Standard or Payments Pro

- Repository: https://github.com/spookylukey/django-paypal
- Stars: 728 · Forks: 214
- Language: Python
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/spookylukey-django-paypal

## What django-paypal actually integrates

django-paypal is a pluggable Django application that integrates with PayPal Payments Standard and Payments Pro. Both are legacy PayPal products, and the project is direct about their standing: it says they are now very old payment methods that are increasingly badly supported by PayPal, and that django-paypal has no support for any payment methods using PayPal's newer APIs.

That framing decides who should read this. The library is not a general PayPal client for Django, and it will not grow into one by itself. It is a maintained implementation of two specific flows, and the projects that benefit from it are the ones where the checkout process is already built on those flows and cannot be changed cheaply.

The package description calls it a pluggable application, meaning it drops into an existing Django project as an installed app rather than being a standalone service. The source layout backs this up. The import paths in the tooling configuration name three separate areas, paypal.pro, paypal.standard.ipn and paypal.standard.pdt, which map to the Pro integration and the two callback mechanisms that Payments Standard uses, Instant Payment Notification and Payment Data Transfer.

Supported versions are stated plainly: Django 2.2 and later, and Python 3.6 and later. Full documentation lives at django-paypal.readthedocs.org, and the project points users there rather than duplicating setup steps in the README.

## Where the two callback styles come from in the package layout

The most concrete signal about how the library is built comes from the packaging and lint configuration rather than from a tutorial. The isort settings force separate import sections for paypal.pro.tests, paypal.standard.ipn.tests and paypal.standard.pdt.tests, which tells you that Payments Pro and the two Payments Standard callbacks are distinct subpackages with their own test suites rather than one handler switched by a flag.

That distinction matters when you are integrating. IPN and PDT are two different ways PayPal tells your site that money moved, and the presence of separate test modules suggests each is implemented and tested on its own terms. The exact request and response payloads are not described in the README, and the documentation site is where that detail lives, so anyone writing an integration should read the relevant section there rather than assuming the two are interchangeable.

A third detail in the configuration is the migrations exclusion. The isort skip list contains a glob that excludes the migrations directory, so migrations are treated as generated artefacts that are not reorganised by the import tooling. For a plug-in that ships database models, that is a hint to review the migration files that arrive with a release before running them against a production database.

The project also distinguishes library packaging from application code with a first-party list containing only paypal, which is consistent with a single top-level package that gets installed once and shared.

## The maintainers have put the project into maintenance mode

The project status section is unusually direct. It describes itself as an open source project that is active but in maintenance mode, and lists the maintainers' primary responsibilities as three things: fixing critical data loss or security bugs, keeping the project up to date with new versions of Django or other dependencies, and merging well written patches from the community promptly.

What is explicitly not on that list is the important half of the sentence. Large scale development work and feature additions are not planned by the maintainers. There is no roadmap for adding support for the newer PayPal APIs, and there is no promise of new features arriving.

The consequence for an adopting team is that the library will keep running on new Django releases, but it will not gain capabilities. If your requirements change, you will be writing the change yourself, or paying a maintainer to write it. The project does say that large contributions, including implementations of newer PayPal payment methods, will be gladly accepted if they are implemented well, and it also notes that some maintainers offer paid support for bug fixes, new features, debugging and integration work. That is a viable route, but it means budgeting rather than waiting.

The maintenance policy is the reason to read the support boundaries before anything else. A library with no planned features is fine when your needs are frozen and bad when they are not.

## Untested code paths warn instead of failing quietly

The README draws attention to a specific weakness: some important parts of the code base are not covered by automated tests, and may be broken for some versions of Django or Python. The stated mitigation is that these parts currently issue warnings, and the maintainers are waiting for tests to be contributed by the people who actually need those parts, along with documentation where appropriate.

Warnings are a reasonable design choice here. A warning tells you the path is unproven; silence would not. But the warning only helps if it is visible in production logs, and it does not tell you the code is broken, only that nobody has proven it works with your version combination.

The same section sets expectations for the issue tracker. Unless a bug is a critical data loss or security bug, the maintainers say they are unlikely to work for free to fix it, and a new feature or tests for existing functionality will only be added by the maintainers if they need it themselves. New features are therefore a contribution you make, not a request you file.

Practical takeaway for a team: if you depend on a code path that emits these warnings, budget for writing the tests yourself and treat them as part of your own deployment, because the upstream project has no plan to add them.

## Dependency and version metadata you should read before installing

There is no install command in the README, so the distribution metadata is the concrete reference here. The setup.py file declares the package name and version, and lists the runtime dependencies:

```python
setup(
    name="django-paypal",
    version="2.1",
    author="John Boxall",
    author_email="john@handimobility.ca",
    maintainer="Luke Plant",
    maintainer_email="L.Plant.98@cantab.net",
    url=URL,
    python_requires=">=3.7",
    install_requires=[
        "Django>=2.2",
        "requests>=2.5.3",
        "pytz>=2015.4",
    ],
```

So the runtime needs are Django, the HTTP client library requests, and pytz for timezone handling. Nothing heavyweight is pulled in, and the dependency list is short enough to read at a glance.

One inconsistency deserves a closer look. The README says the library supports Python 3.6 and later, while setup.py sets python_requires to >=3.7. The difference is small, but a project on Python 3.6 will be blocked by the declared requirement even though the README says it should work. The classifiers tell a similar story, listing Django from 2.1 up to 4.0 and Python from 3.7 to 3.10, which is a narrower supported matrix than the README's prose implies for Django.

The project uses a pyproject.toml as well, and it is purely a developer tool configuration rather than a build definition. It pins formatting and linting behaviour:

```toml
[tool.black]
line-length = 120
target-version = ['py39']

[tool.isort]
profile = "black"
line_length = 120
known_first_party = ["paypal"]
default_section= "THIRDPARTY"
```

The line length of 120 and the black profile for isort tell you the code style the project enforces on contributors, and the target-version of py39 for black is the closest thing to a statement about the Python versions the code is actually shaped for.

## No releases, a version string of 2.1, and a master branch

The repository has no GitHub releases, yet setup.py carries a version of 2.1 and the repository keeps a RELEASE.rst file plus a release.sh script at the top level. So publishing happens through the project's own script rather than through GitHub release artefacts, and there is no tagged release feed to watch from the platform side.

The default branch is master, and the repository root shows the shape of the project: a paypal package directory, a docs directory, manage.py, runtests.py, tox.ini, setup.cfg and setup.py alongside pyproject.toml, plus requirements-dev.txt and requirements-test.txt, and a .pre-commit-config.yaml. The presence of tox.ini, a separate test runner script and pre-commit configuration tells you the project runs its tests across multiple environments and expects formatting to be checked before code is submitted.

For a team tracking upgrades, that has a practical edge: there is no release page listing changelog entries, so the commit history on master and the RELEASE.rst file in the repository are the places to look for what changed. Combine that with the maintenance mode policy and the expectation becomes clear. You are tracking a small number of dependency-compatibility commits, not a stream of features.

The licence is MIT, which permits use, modification and redistribution inside commercial and closed source products under the licence terms. That reading is factual rather than legal advice, and your own review of the LICENSE file is still the right step before shipping the dependency in a paid product.

## Conclusion

django-paypal is the right choice only for a Django project that already runs Payments Standard or Payments Pro and cannot move its checkout flow, because it is a mature, MIT licensed plug-in with a documented IPN and PDT structure that you can still patch. It is the wrong choice for any new project, since the project itself states that PayPal supports these payment methods badly and that newer PayPal APIs have no support here. Before adopting, read the version metadata against your own environment, because setup.py declares python_requires >=3.7 and classifiers up to Python 3.10 while the README claims Python 3.6 and later, and confirm which of paypal/standard/ipn and paypal/standard/pdt your flow actually needs, since parts of the code base are still not covered by automated tests.

## FAQ

### Does django-paypal support PayPal's newer REST APIs?

No. The README states that django-paypal does not have support for any payment methods using PayPal's newer APIs, and recommends looking at the documentation site for what the current integrations cover.

### Is django-paypal still being actively developed?

The project describes itself as active but in maintenance mode. The maintainers say their responsibilities are fixing critical data loss or security bugs, keeping up with new Django versions, and merging community patches, and that large scale development and feature additions are not planned.

### Which Python and Django versions does django-paypal require?

The README says Django 2.2 and later and Python 3.6 and later, while setup.py sets python_requires to >=3.7 with install_requires of Django>=2.2, requests>=2.5.3 and pytz>=2015.4. The classifiers in setup.py list Django up to 4.0 and Python up to 3.10.

## Sources

- [Issues](https://github.com/spookylukey/django-paypal/issues)
- [License: MIT](https://github.com/spookylukey/django-paypal/blob/master/LICENSE)
- [README](https://github.com/spookylukey/django-paypal/blob/master/README.md)
- [spookylukey/django-paypal on GitHub](https://github.com/spookylukey/django-paypal)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/spookylukey-django-paypal