renewal orders store the charged gross: create_new_order sets Order.gross_amount (django-plans 2.7.0) to the IPN’s mc_gross and derives the net with Order.net_from_gross() (coefficient method, tax = gross x rate / (100 + rate)). Multiplying a net cent value by a rate cannot reach every gross cent value, so a renewal after a tax-rate change could only pick the nearest net and was invoiced a cent below the charge (e.g. 14.89 at 21 %: 12.30 -> 14.88, 12.31 -> 14.90). The invoice now carries exactly what PayPal charged; the “closest total” workaround and its warning are gone

when the current rate cannot be determined, the copied values (RecurringUserPlan expectation, then the first order) are chosen by which one’s total equals the charged gross. Previously the expectation won even when PayPal had charged the first order’s total, so the order carried an amount other than the one received. If neither matches, Order.save() now rejects the order instead of invoicing an amount that was not charged

requires django-plans >= 2.7.0

tests: full 100 % line and branch coverage, and CI now gates on it (coverage report --fail-under=100). New coverage includes the sandbox business-email validation, stale cancellations for users without a recurring plan, VAT IDs reaching the taxation policy in full form, encrypted-form certificate wiring (sandbox vs. live), and a characterization of the week-unit period conversion (fractional p3 - PayPal documents an integer; left as-is deliberately, live subscriptions depend on current behaviour)

the received-amount check accepts, besides the first order’s total, the total implied by the armed RecurringUserPlan (net x current tax). This makes legitimate subscription-amount updates on PayPal’s side (e.g. after a VAT change) processable: update the RecurringUserPlan expectation, then change the amount at PayPal. Renewal orders without a taxation policy configured now also prefer that expectation over the first order’s frozen copy, so the invoice matches what was actually charged.

admin: PayPalPaymentAdmin now extends RelatedFieldAdmin - the __ paths in list_display only work on plain ModelAdmin since Django 5.1, so the admin was broken on Django 4.2/5.0

debug print() calls removed from the IPN hook and the payment view (the view printed the full payment dict incl. customer e-mail into logs on every order page view); the hook logs a single logger.debug line instead

tests: admin (system checks + changelist), IPN with empty custom data, cancellation with a foreign subscr_id, PayPal duration-unit selection and sandbox-flag isolation of the payment form (coverage 84 % -> 93 %)

release tooling: make release/make sdist use build + twine (setup.py sdist upload has been dead on PyPI for years), the broken setup.py publish shortcut and the stale .travis.yml are gone

CI: test matrix updated to Django 4.2-5.2 on Python 3.9-3.13 (dropped EOL Django 3.2-4.1 and Python 3.8), GitHub Actions bumped to current versions

CI: Codecov upload repaired - the deprecated codecov CLI uploader has been dead since 2023 (uploads failed silently, so no reports or PR comments appeared); now codecov-action@v5 with OIDC

packaging: classifiers and python_requires reflect the supported versions

renewal orders recalculate the tax rate for the user’s current billing data instead of copying it from the subscription’s first order forever. PayPal charges a fixed gross, so the new rate is applied top-down: the gross stays, the net amount adjusts (at most one cent off when no cent-exact net exists for the new rate). Without PLANS_TAXATION_POLICY, without BillingInfo, or on a failed VIES/rate lookup the previous behaviour (copied tax) is kept.

receive_ipn now processes each IPN in a single database transaction: a failure while completing the order no longer leaves an armed RecurringUserPlan and a recorded payment behind, so PayPal’s IPN retries start from a clean slate instead of dying on the leftover state as duplicates.

pending subscription payments (typically eChecks clearing) are recorded as PayPalPayment rows instead of being silently dropped – an in-flight payment is not a decline.

PaymentFailureView: redirect already-completed orders to the success page (with a warning log) instead of raising ValueError. PayPal can send the buyer to the cancel_return URL even after the IPN has marked the order as completed (browser back button, stale tabs, edge cases in the PayPal flow); the previous behaviour produced unhandled 500s for paid users. Reverses the 0.7.1 behaviour change.

handle empty/whitespace PayPal IPN custom data without logging an error; also catch ValueError from ast.literal_eval so future Python releases can’t break the parser

admin: add paypal_ipn__txn_id column to PayPalPaymentAdmin.list_display

drop conflicting isort lines_after_imports = 2 setting (project already uses profile = black) and reformat affected files; the lint CI job is green again

add more fields to admin list_display

fixes to taking the data from custom_data

create order more robust: take the data from custom_data

Support Django up to 5.2

fail if PaymentFailureView is requested on completed orders

migrate code to RecurringUserPlan.renewal_triggered_by

migrate data of RecurringUserPlans with payment_provider=”paypal-recurring” and renewal_triggered_by=TASK to renewal_triggered_by=OTHER

Fix amount received on recurring payments, add tests

allow only logged users to access the failure view

Fix tax received on recurring payments

More robust receiving original Order ID (if PayPal fails to handle custom_data)

update to Django 4.1

fix completing recurring payments if first order status is returned

only log error if custom data can’t be parsed

fix problem with duplicate payments

PayPalPaymentAdmin: display connected IPN fields

make parsing custom_data more robust

fix last release

add tests and test on all supported Django/Python versions through GitHub actions

fix problem if there was ‘ in custom payment data

fix problem with creating bad JSON

fix IPN field editing in PayPalPaymentAdmin

store also user e-mail in custom to enable search in IPN admin

create PayPalPayment before completing the order

fix problem with recurring payments

add created/modified/author auto fields

fix problem with other IPN types

cancel order after returning to failure URL

allow to set up encrypted PayPal form

fixes and improvements to the sandbox/production functionality

reverse sandbox logic - if no PAYPAL_TEST, the sandbox view would return production so nobody can pay through sandbox on production server

fix foregotten pudb

add sandbox view, so both production and sandbox can be used on one server

fix periods to complain with PayPal maximal durations

hook ipn.PayPalIpn object with plans.Order (for later usage e.g. determining PayPal fee)

set plan renewal for django-plans

Payment process without capturing should work

Automatic buttons generation

First release on PyPI.