This release removes a migration which caused a crash in certain cases.

It is not possible to upgrade to dj-stripe 2.8.0 from versions older than 2.5.0.
To upgrade from an older version, first upgrade to dj-stripe 2.5.0.

Release highlights

This release introduces support for Stripe Identity.

It is also slated to be the last major release before dj-stripe 3.0, which will introduce
significant, backwards-incompatible changes.

• Python 3.11 is now supported.
• Django 4.1 and 4.2 are now supported.
• Python 3.7 is no longer supported. Python 3.8 or higher is required.
• Added LineItem model.
• Added Discount model.
• Added SourceTransaction, VerificationSession and VerificationReport models.

Deprecated features

• DJSTRIPE_WEBHOOK_EVENT_CALLBACK is deprecated in favour of the new webhook signals.
• DJSTRIPE_WEBHOOK_TOLERANCE is deprecated in favour of the new UUID webhooks tolerance model field.

Breaking changes

• Remove legacy JSONField support. This drops support for installations with the
  DJSTRIPE_USE_NATIVE_JSONFIELD setting set to False.
  NOTE: No migration path is available yet.
  https://github.com/dj-stripe/dj-stripe/issues/1820
• Remove djstripe_sync_plans_from_stripe command (deprecated in 2.4.0).
  Use djstripe_sync_models price instead.
• Remove Customer.can_charge(), Customer.has_valid_source() ()
• Remove DJSTRIPE_PRORATION_POLICY setting (deprecated in 2.6.0)
• Remove deprecated prorate argument to Subscription.update() (Use Stripe's
  proration_behavior argument instead)
• Remove undocumented set_stripe_api_version() helper function
  and context manager stripe_temporary_api_version().
  The API version is now set on each request individually.
• Updated Charge.refund(...) helper function
  to correctly create the desired refund. Note that the
  created Refund object is now returned as opposed to
  the Charge object.
• Resolved ambiguity between LineItem and InvoiceItem models. We previously
  assumed that the lines List object on Invoice and UpcomingInvoice models only
  return InvoiceItem objects. Moreover LineItem objects can also be of type
  subscription if the user adds a Subscription to their Invoice as a lineitem.

Other changes

• Updated the Stripe API key and webhook django system check to warning instead of critical.
• Added various missing model field to CheckoutSession and Payout models.
• Added support for running tests using the real Stripe API calls.
• stripe.api_version is no longer manipulated by dj-stripe.
• New webhook signals are available:
  • djstripe.signals.webhook_pre_validate(instance, api_key): Fired before webhook validation
  • djstripe.signals.webhook_post_validate(instance, api_key, valid): Fired after validation (even unsuccessful validations)
  • djstripe.signals.webhook_pre_process(instance, api_key): Fired before webhook processing. Not fired if the validation failed.
  • djstripe.signals.webhook_post_process(instance, api_key): Fired after webhook successful processing.
• djstripe.signals.webhook_processing_error now also takes instance and api_key arguments
• Updated deprecated pkg_resources to importlib.

This is a maintenance release only fixing the installation of dj-stripe on Django 4.0 and 4.1.

Release notes

• Fix installing with Poetry on Django 4.0 and higher

Release notes

• Remove an enum value generating an extra migration
• Allow Django 4.1 as a dependency (Note: Running dj-stripe 2.7.x with Django 4.1 is
  untested)

!!! attention

It is not possible to upgrade to dj-stripe 2.7.0 from versions older than 2.4.0.
To upgrade from an older version, first upgrade to dj-stripe 2.4.0.

This release focuses on Webhook Endpoints. For more information on the reasoning behind
the changes, please see the discussion on Github:

https://github.com/dj-stripe/dj-stripe/discussions/1437

Release highlights

• Webhook Endpoints are now configured via the Django administration.
• Multiple Webhook Endpoints are now supported.
• Webhook Endpoints now have a unique, non-guessable URL.

Deprecated features

• The DJSTRIPE_WEBHOOK_URL setting is deprecated. It will be removed in dj-stripe
  2.9. It was added to give a way of "hiding" the webhook endpoint URL, but that is no
  longer necessary with the new webhook endpoint system.

Breaking changes

• Remove the deprecated middleware djstripe.middleware.SubscriptionPaymentMiddleware
• Remove support for the deprecated DJSTRIPE_SUBSCRIPTION_REDIRECT setting
• Remove support for the DJSTRIPE_SUBSCRIPTION_REQUIRED_EXCEPTION_URLS setting

Other changes

• Many Stripe Connect related fixes (Special thanks to Dominik Bartenstein of Zemtu)
• Allow passing stripe kwargs in Subscription.cancel()
• Various admin improvements
• Add support for managing subscription schedules from the admin

Release notes

• Update migrations missed in 2.6.2 (#1819)
• Fix a crash with string representations of uninitialized Card objects

This is a maintenance release to remove the generation of an unnecessary migration when
running dj-stripe on Django 4.0.
This release does not guarantee Django 4.0 compatibility. Run at your own risk.

Release notes

• Update migrations to be compatible with Django 4.0 (#1649)

Release notes

• Fix for failing webhooks, usually to do with customer subscriptions (#1588)

dj-stripe 2.6.0 (2022-01-15)

NOTE: It is not possible to upgrade to dj-stripe 2.6.0 from versions older than 2.3.0. To upgrade from an older version, first upgrade to dj-stripe 2.3.0.

Release highlights

• Support for Python 3.10 and Django 4.0.
• New models: Mandate, Payout, UsageRecordSummary, WebhookEndpoint (unused)
• Significant improvements and fixes to Stripe Connect features.
• Storing Stripe API keys by adding them to the Admin is now supported.
  This allows for use of multiple Stripe API keys (multiple Stripe accounts).
• Support for syncing Connect accounts via djstripe_sync_models.

Deprecated features

• The use of the old jsonfield-based JSONField is deprecated and support for it
  will be dropped in dj-stripe 2.8.0. django.models.JSONField is available since
  Django 3.1.0. To switch to the newer JSONFields, set DJSTRIPE_USE_NATIVE_JSONFIELD
  to True. Set it to False to remain on the jsonfield-powered text-based fields.
  A manual migration is necessary to convert existing databases from text to json.
• The DJSTRIPE_PRORATION_POLICY setting is deprecated and will be ignored in 2.8.
  Specify proration_policy in the Subscription.update() method explicitly instead.
• Customer.can_charge() is now deprecated. This was a very misleading method which
  resulted in incorrect behaviour when Customers had multiple payment methods. It will
  be removed in dj-stripe 2.8.0. You can use Customer.payment_methods.all() instead.
• For similar reasons, Customer.has_valid_source() is deprecated and will be removed
  in dj-stripe 2.8.0. You can use Customer.sources.all() instead.

Breaking changes

• Python 3.6 is no longer supported. The new minimum version of Python is 3.7.12.
• Django 2.2 and 3.1 are no longer supported.
• DJSTRIPE_USE_NATIVE_JSONFIELD now defaults to True. If you previously had it set
  to False, or did not have it set, you may want to explicitly set it to False in
  order to support a pre-existing database. A migration path will later be provided
  for this use case.
• The undocumented get_stripe_api_version() helper function has been removed.
• Settings for dj-stripe are now in djstripe.settings.djstripe_settings (as opposed
  to top-level in djstripe.settings)
• Customer.subscribe() method no longer accepts positional arguments, only keywords.
• charge_immediately support in Customer.subscribe() has been removed (deprecated
  in 2.4). Set collection_method instead.
• The at_period_end argument to Subscription.cancel() now defaults to False,
  instead of the value of DJSTRIPE_PRORATION_POLICY.

Other changes

• The Stripe Account that triggered an Event is now available on the field
  WebhookEventTrigger.stripe_trigger_account.
• Fixed recursive fetch/update loop errors in djstripe_sync_models.
• Migrations have been optimized and should be faster.
• dj-stripe now checks the apparent validity of API keys used and will raise
  InvalidStripeAPIKey if the API key looks completely incorrect.
• Customers can now be subscribed to multiple prices and/or plans by passing the items argument
  to Customer.subscribe().
• Checkout Session metadata can be used to create/link a Stripe Customer to the
  Customer instance specified by the djstripe_settings.SUBSCRIBER_CUSTOMER_KEY.

This is a release candidate for dj-stripe 2.6.0. Please see here for release notes.

Release notes

• Fixed migration issue for new setups using custom DJSTRIPE_CUSTOMER_MODEL.
• Display correct JSON for JSONFields in the Django admin.
• Fix manual syncing of SubscriptionItem.

NOTE: It is not possible to upgrade to dj-stripe 2.5.0 from versions older than 2.2.2. To upgrade from an older version, first upgrade to dj-stripe 2.2.2.

Release notes

• Minimum Python version is now 3.6.2.
• Support for Python 3.9 and Django 3.2.
• In keeping with upstream's cycle, Django 3.0 is no longer officially supported.
  (Note that it will still work, because Django 2.2 LTS is still supported.)
• SQLite versions older than 3.26 are no longer supported.
• New models: FileLink, Mandate
• Cards and Bank Accounts are now visible in the admin interface.
• Lots of model sync fixes since 2.4.0.

Deprecated features

• The FileUpload model has been renamed File, for consistency with Stripe's SDK.
  Although the old name is still supported, it will eventually be removed.
• Deprecate charge_immediately argument to Customer.subscribe(). It did not behave
  as expected on recent versions of Stripe. If you were using it set to
  charge_immediately=False, you can instead pass collection_method="send_invoice",
  which will send the Customer the invoice to manually pay, instead.

Breaking changes

• When calling Customer.delete() in prior versions of dj-stripe, the Customer object
  would be deleted in the upstream API and the Customer object would be retained but
  with a date_purged attribute. This was the only model behaving this way, and it is
  no longer the case. If you wish to purge a customer like before, you may call
  Customer.purge() instead, though that method may be removed in future versions as
  well.
• Remove deprecated DRF integration (djstripe.contrib.rest_framework)
• Remove deprecated djstripe.decorators module
• Remove deprecated djstripe.middleware module
• Remove deprecated fields Account.business_vat_id and Subscription.tax_percent
• Remove deprecated method Account.get_connected_account_from_token(). Use
  Account.get_or_retrieve_for_api_key() instead.
• Remove deprecated Charge.account property. Use Charge.on_behalf_of instead.
• Remove deprecated Customer.has_active_subscription() method. Use
  Customer.is_subscribed_to(product) instead.
• FileUploadPurpose enum has been renamed FilePurpose.
• FileUploadType enum has been renamed FileType.

Thanks to Podpage.com for sponsoring the fixes in this release!

• Fix webhook error when processing events that contain a reference to a deleted
  payment method (such as a refund on a payment whose card has been detached or
  removed)
• Fix a couple of regressions in djstripe_sync_models management command.

Release notes

• Fix error in Customer.add_card() due to Stripe's sources deprecation. (#1293)
• Fix Subscription.update() usage of the deprecated Stripe prorate argument.
  dj-stripe now explicitly uses proration_behavior, setting it to "none" when
  prorate is False, and "create_prorations" when prorate is True.

Release notes

• Upgrade default Stripe API version to 2020-08-27. Although we documented doing so
  in 2.4.0, it was not correctly set as such. This has been fixed for consistency.
• The Price model was incorrectly released with an amount_in_cents property,
  matching that of the Plan model. However, Price amounts are already in cent. The
  property has been removed, use unit_amount instead.
• Fix Price.human_readable_price calculation
• Fix non-blank nullable Charge fields
• Fix Price.tiers not being synced correctly with djstripe_sync_models (#1284)
• Fix sync model recursion loop (see #1288)

See our full release notes on Read the Docs.

dj-stripe 2.4.0 release notes (2020-11-19)

Attention: To upgrade to 2.4.0 from older versions of dj-stripe, scroll down to the Upgrade Guide.

Introducing sponsorships and our first sponsor

We're excited to introduce our Sponsorship tiers. Individuals may back dj-stripe to assist with development. Larger backers may choose one the paid support plans available to receive support on top of ensuring the long-term viability of the project!

And this release was made possible by none other than… Stripe! Our very first Gold sponsor. Their financial backing has allowed us to pour a lot of work that could not have otherwise happened.

Release notes

• Support for Django 3.1 and Python 3.8.
• Minimum stripe-python version is now 2.48.0.
• Default Stripe API version is now 2020-08-27.
• First-class support for the Price model, replacing Plans.
• Support multi-item subscriptions.
• Support for API keys in the database (see Managing Stripe API keys).
• Support for syncing objects for multiple, different Stripe accounts.
• Use Django 3.1 native JSONField when available.
• The field djstripe_owner_account has been added to all Stripe models, and is automatically populated with the Account that owns the API key used to retrieve it.
• Support for subscription schedules (#899).
• Add support for Reporting categories and TaxIds
• Update many models to match latest version of the Stripe API.
• Fixed Account.get_default_account() for Restricted API Keys.
• Allow passing arbitrary arguments (any valid SDK argument) to the following methods:
  • Customer.charge()
  • Customer.subscribe(),
  • Charge.capture()
  • Subscription.update()
• New management command: djstripe_update_invoiceitem_ids. This command migrates InvoiceItems using Stripe's old IDs to the new ones.
• Hundreds of other bugfixes.

New feature: in-database Stripe API keys

Stripe API keys are now stored in the database, and are now editable in the admin.

Warning: By default, all keys are visible by anyone who has access to the dj-stripe administration.

Why?

As we work on supporting multiple Stripe accounts per instance, it is vital for dj-stripe to have a mechanism to store more than one Stripe API key. It also became obvious that we may want proper programmatic access to create and delete keys. Furthermore, API keys are a legitimate upstream Stripe object, and it is not unlikely the API may allow access to listing other API keys in the future, in which case we will want to move them to the database anyway.

In the next release, we are planning to make WebhookEndpoints (and thus webhook secrets) manageable via the database as well.

Do I need to change anything?

Not at this time. The settings STRIPE_LIVE_SECRET_KEY and STRIPE_TEST_SECRET_KEY can still be used. Their values will however be automatically saved to the database at the earliest opportunity.

What about public keys?

Setting STRIPE_LIVE_PUBLIC_KEY and STRIPE_TEST_PUBLIC_KEY will be deprecated next release. You do not risk anything by leaving them in your settings: They are not used by Dj-Stripe outside of the Dj-Stripe mixins, which are now themselves deprecated. So you can safely leave them in your settings, or you can move them to the database as well (Keys beginning in pk_test_ and pk_live_ will be detected as publishable keys).

Deprecated features

Nobody likes features being removed. However, the last few releases we have had to remove features that were not core to what dj-stripe does, or simply poorly-maintained. To keep up with the trend, we are making three major deprecations this release:

Creating Plans from the Django Admin is no longer supported

The Plan model was special cased in various places, including being the only one which supported being created from the Django administration. This is no longer supported. We have plans to allow creating arbitrary Stripe objects from the Django Admin, but until it can be done consistently, we have decided to remove the feature for Plans (which are deprecated by Stripe anyway). The only object type you should be dealing with from the admin is the new APIKey model.

Along with this, we are also deprecating the djstripe_sync_plans_from_stripe management command. You can instead use the djstripe_sync_models management command, which supports arbitrary models.

Deprecating the REST API

We are dropping all support for the REST API and will be fully removing it in 2.5.0. We're doing this because we wish to keep such an API separate from dj-stripe. Work has already started on a new project, and we will be sharing more details about it soon. If you're interested in helping out, please reach out on Github!

Deprecating djstripe.middleware.SubscriptionPaymentMiddleware

Large parts of dj-stripe, including this middleware, were designed before Stripe's major revamps of the old Plan model into Prices, Products, and multi-plan subscriptions. The functionality offered by the middleware is no longer adequate, and building on top of it would not be particularly robust. We may bring similar functionality back in the future, but the middleware as it is is going away (as well as the undocumented djstripe.utils.subscriber_has_active_subscription utility function).

If you want to keep the functionality for your project, you may wish to copy the latest version of the middleware.

Deprecating djstripe.mixins

This is being deprecated for similar reasons as the SubscriptionPaymentMiddleware. However, the mixins module was undocumented and never officially supported.

Other deprecations

• The account field on Charge has been renamed to on_behalf_of, to be consistent with Stripe's upstream model. Note that this field is separate from djstripe_owner_account, which is set by dj-stripe itself to match the account of the API key used.
• Account.get_connected_account_from_token() is deprecated in favour of Account.get_or_retrieve_for_api_key(), which supports more than just Connect accounts.
• Customer.has_active_subscription() is deprecated in favour of Customer.is_subscribed_to(). Note that the former takes a plan as argument, whereas the latter takes a product as argument.
• The tax_percent attribute of Invoice is no longer populated and will be removed in 2.5.0. You may want to use Invoice.default_tax_rates instead, which uses the new TaxId functionality.
• Customer.business_vat_id is being deprecated in favour of using TaxId models directly.

Breaking changes

• Rename PlanBillingScheme to BillingScheme.

• Remove Plan.update_name() and these previously-deprecated fields:

  • Customer.business_vat_id
  • Subscription.start
  • Subscription.billing

Upgrade Guide

Before you upgrade to dj-stripe 2.4.0, we recommend upgrading to dj-stripe 2.3.0. Upgrading one major release at a time minimizes the risk of issues arising.

Upgrading directly to 2.4.0 from dj-stripe versions older than 2.2.0 is unsupported.

To upgrade dj-stripe, run pip install --upgrade dj-stripe==2.4.0.

Once installed, you can run manage.py migrate djstripe to migrate the database models.

Attention: If you are doing multiple major dj-stripe upgrades in a row, remember to run the migrate command after every upgrade. Skipping this step WILL cause errors.

Note: Migrating the database models may take a long time on databases with large amounts of customers.

Settings changes

A new mandatory setting DJSTRIPE_FOREIGN_KEY_TO_FIELD has been added. If you are upgrading from an older version, you need to set it to "djstripe_id".

Setting it to "id" will make dj-stripe use the Stripe IDs as foreign keys. Although this is recommended for new installations, there is currently no migration available for going from "djstripe_id" to "id".

• Ported internals from django-stripe-payments
• Began writing the views
• Travis-CI
• All tests passing on Python 2.7 and 3.3
• All tests passing on Django 1.4 and 1.5
• Began model cleanup
• Better form
• Provide better response from management commands

• Admin working
• Better publish statement
• Fix dependencies

• Added account view
• Added Customer.get_or_create method
• Added djstripe_sync_customers management command
• sync file for all code that keeps things in sync with stripe
• Use client-side JavaScript to get history data asynchronously
• More user friendly action views

• Change PaymentRequiredMixin to SubscriptionPaymentRequiredMixin
• Add subscription_payment_required function-based view decorator
• Added SubscriptionPaymentRedirectMiddleware
• Much nicer accounts view display
• Much improved subscription form display
• Payment plans can have decimals
• Payment plans can have custom images