Django + Stripe Made Easy

dj-stripe

Last update: Dec 28, 2022

Related tags

Payment Processing python django stripe webhook payments connect billing subscriptions sigma dj-stripe

Overview

dj-stripe

Stripe Models for Django.

Introduction

dj-stripe implements all of the Stripe models, for Django. Set up your webhook endpoint and start receiving model updates. You will then have a copy of all the Stripe models available in Django models, as soon as they are updated!

The full documentation is available on Read the Docs.

Features

Stripe Core
Stripe Billing
Stripe Cards (JS v2) and Sources (JS v3)
Payment Methods and Payment Intents (SCA support)
Support for multiple accounts and API keys
Stripe Connect (partial support)
Tested with Stripe API 2020-08-27 (see API versions)

Requirements

Django 2.2+
Python 3.6+
PostgreSQL engine (recommended) 9.5+
MySQL engine: MariaDB 10.2+ or MySQL 5.7+ (Django 3.2.5+ required for MySQL 8 support)
SQLite: Not recommended in production. Version 3.26+ required.

Quickstart

Install dj-stripe with pip:

pip install dj-stripe

Or with Poetry (recommended):

poetry add dj-stripe

Add djstripe to your INSTALLED_APPS:

INSTALLED_APPS =(
    ...
    "djstripe",
    ...
)

Add to urls.py:

path("stripe/", include("djstripe.urls", namespace="djstripe")),

Tell Stripe about the webhook (Stripe webhook docs can be found here) using the full URL of your endpoint from the urls.py step above (e.g. https://example.com/stripe/webhook).

Add your Stripe keys and other settings:

STRIPE_LIVE_SECRET_KEY = os.environ.get("STRIPE_LIVE_SECRET_KEY", "<live secret key>")
STRIPE_TEST_SECRET_KEY = os.environ.get("STRIPE_TEST_SECRET_KEY", "<test secret key>")
STRIPE_LIVE_MODE = False  # Change to True in production
DJSTRIPE_WEBHOOK_SECRET = "whsec_xxx"  # Get it from the section in the Stripe dashboard where you added the webhook endpoint
DJSTRIPE_USE_NATIVE_JSONFIELD = True  # We recommend setting to True for new installations
DJSTRIPE_FOREIGN_KEY_TO_FIELD = "id"  # Set to `"id"` for all new 2.4+ installations

Add some payment plans via the Stripe.com dashboard.

Run the commands:

python manage.py migrate

python manage.py djstripe_sync_models

See https://dj-stripe.readthedocs.io/en/latest/stripe_elements_js/ for notes about usage of the Stripe Elements frontend JS library.

Running the Tests

Assuming the tests are run against PostgreSQL:

createdb djstripe
pytest

Changelog

See release notes on Read the Docs.

Funding this project

You can now become a sponsor to dj-stripe with GitHub Sponsors.

We've been bringing dj-stripe to the world for over 7 years and are excited to be able to start dedicating some real resources to the project.

Your sponsorship helps us keep a team of maintainers actively working to improve dj-stripe and ensure it stays up-to-date with the latest Stripe changes. If you're using dj-stripe in a commercial capacity and have the ability to start a sponsorship, we'd greatly appreciate the contribution.

All contributions through GitHub sponsors flow into our Open Collective, which holds our funds and keeps an open ledger on how donations are spent.

Similar libraries

dj-paypal (PayPal)
dj-paddle (Paddle)

Comments

Release 1.0.0
Overview

It's almost here! We've made significant changes to the codebase and are now compliant with stripe API version ~~2016-03-07~~ 2017-06-05.

I want to give a huge thanks to all of our contributors for their help in making this happen, especially Bill Huneke (@wahuneke) for his impressive design work, and @jleclanche for really pushing this release along.

Almost all methods now mimic the parameters of those same methods in the stripe API. Note that some methods do not have some parameters implemented. This is intentional. That being said, expect all method signatures to be different than those in previous versions of dj-stripe.

A few things to get excited for

Multiple subscription support (finally)

Multiple sources support (currently limited to Cards)

Idempotency support (See #455, #460 for discussion -- big thanks to @jleclanche)

Full model documentation

Objects that come through webhooks are now tied to the API version set in dj-stripe. No more errors if dj-stripe falls behind the newest stripe API version.

Any create/update action on an object automatically syncs the object.

Concurrent LIVE and TEST mode support (Thanks to @jleclanche). Note that you'll run into issues if livemode isn't set on your existing customer objects.

All choices are now enum-based (Thanks @jleclanche, See #520). Access them from the new djstripe.enums module. The ability to check against model property based choices will be deprecated in 1.1

Support for the Coupon model, and coupons on Customer objects.

Support for the Payout/Transfer split from api version 2017-04-06.

What still needs to be done (in v1.3.0)

~~Testing. I'm almost done fixing the tests.~~ DONE!

Documentation. Our original documentation was not very helpful, but it covered the important bits. It will be very out of date after this update and will need to be rewritten. If you feel like helping, we could use all the help we can get to get this pushed out asap.

Master sync re-write. This sounds scary, but really isn't. The current management methods run sync methods on Customer that aren't very helpful and are due for removal. My plan is to write something that first updates local data (via api_retrieve and sync_from_stripe_data) and then pulls all objects from Stripe and populates the local database with any records that don't already exist there.

Plan settings/models dynamic. We've decided to gut having plans as settings. Stripe should be your source of truth; create your plans there and sync them down manually. If you need to create plans locally for testing, etc., simply use the ORM to create Plan models. The sync rewrite will make this drop less annoying.

Significant changes (mostly backwards-incompatible)

Idempotency. #460 introduces idempotency keys and implements idempotency for Customer.get_or_create(). Idempotency will be enabled for all calls that need it.

Improved Admin Interface. This is almost complete. See #451 and #452.

Drop non-trivial endpoint views. We're dropping everything except the webhook endpoint and the subscription cancel endpoint. See #428.

Drop support for sending receipts. Stripe now handles this for you. See #478.

Drop support for plans as settings, including custom plan hierarchy (if you want this, write something custom) and the dynamic trial callback.

Orphan Customer Sync. We will now sync Customer objects from Stripe even if they aren't linked to local subscriber objects. You can link up subscribers to those Customers manually.

I kept a log of everything that changed. I believe this is everything; if you notice something I've missed, let me know and I'll add it. I'll go through and double-check before we officially release.

SETTINGS

The PLAN_CHOICES, PLAN_LIST, and PAYMENT_PLANS objects are removed. Use Plan.objects.all() instead.

The plan_from_stripe_id function is removed. Use Plan.objects.get(stripe_id=<stripe_id>)

SYNCING

sync_plans no longer takes an api_key

sync methods no longer take a cu parameter

All sync methods are now private. We're in the process of building a better syncing mechanism.

UTILITIES

dj-stripe decorators now take a plan argument. If you're passing in a custom test function to subscriber_passes_pay_test, be sure to account for this new argument.

MIXINS

The context provided by dj-stripe's mixins has changed. PaymentsContextMixin now provides STRIPE_PUBLIC_KEY and plans (changed to Plan.objects.all()). SubscriptionMixin now provides customer and is_plans_plural.

We've removed the SubscriptionPaymentRequiredMixin. Use @method_decorator("dispatch",subscription_payment_required) instead.

MIDDLEWARE

dj-stripe middleware doesn't support multiple subscriptions.

SIGNALS

Local custom signals are deprecated in favor of Stripe webhooks:

cancelled -> WEBHOOK_SIGNALS["customer.subscription.deleted"]

card_changed -> WEBHOOK_SIGNALS["customer.source.updated"]

subscription_made -> WEBHOOK_SIGNALS["customer.subscription.created"]

WEBHOOK EVENTS

The Event Handlers designed by @wahuneke are the new way to handle events that come through webhooks. Definitely take a look at event_handlers.py and webhooks.py.

Exceptions

SubscriptionUpdateFailure and SubscriptionCancellationFailure exceptions are removed. There should no longer be a case where they would have been useful. Catch native stripe errors in their place instead.

MODELS

Charge

Charge.charge_created -> Charge.stripe_timestamp

Charge.card_last_4 and Charge.card_kind are removed. Use Charge.source.last4 and Charge.source.brand (if the source is a Card)

Charge.invoice is no longer a foreign key to the Invoice model. Invoice now has a OneToOne relationship with Charge. (Charge.invoice will still work, but will no longer be represented in the database).

Customer

dj-stripe now supports test mode and live mode Customer objects concurrently (See #440). As a result, the <subscriber_model>.customer OneToOne reverse relationship is no longer a thing. You should now instead add a customer property to your subscriber model that checks whether you're in live or test mode (see djstripe.settings.STRIPE_LIVE_MODE as an example) and grabs the customer from <subscriber_model>.djstripe_customers with a simple livemode= filter.

Customer no longer has a current_subscription property. We've added a subscription property that should suit your needs.

With the advent of multiple subscriptions, the behavior of Customer.subscribe() has changed. Before, calling subscribe() when a customer was already subscribed to a plan would switch the customer to the new plan with an option to prorate. Now calling subscribe() simply subscribes that customer to a new plan in addition to it's current subsription. Use Subscription.update() to change a subscription's plan instead.

Customer.cancel_subscription() is removed. Use Subscription.cancel() instead.

The Customer.update_plan_quantity() method is removed. Use Subscription.update() instead.

CustomerManager is now SubscriptionManager and works on the Subscription model instead of the Customer model.

Customer.has_valid_card() is now Customer.has_valid_source().

Customer.update_card() now takes an id. If the id is not supplied, the default source is updated.

Customer.stripe_customer property is removed. Use Customer.api_retrieve() instead.

The at_period_end parameter of Customer.cancel_subscription() now actually follows the DJSTRIPE_PRORATION_POLICY setting.

Customer.card_fingerprint, Customer.card_last_4, Customer.card_kind, Customer.card_exp_month, Customer.card_exp_year are all removed. Check Customer.default_source (if it's a Card) or one of the sources in Customer.sources (again, if it's a Card) instead.

The invoice_id parameter of Customer.add_invoice_item is now named invoice and can be either an Invoice object or the stripe_id of an Invoice.

Event

Event.kind -> Event.type

Removed Event.validated_message. Just check if the event is valid - no need to double check (we do that for you)

Transfer

Removed Transfer.update_status()

Removed Transfer.event

TransferChargeFee is removed. It hasn't been used in a while due to a broken API version. Use Transfer.fee_details instead.

Any fields that were in Transfer.summary no longer exist and are therefore deprecated (unused but not removed from the database). Because of this, TransferManager now only aggregates total_sum

Invoice

Invoice.attempts -> Invoice.attempt_count

InvoiceItems are no longer created when Invoices are synced. You must now sync InvoiceItems directly.

InvoiceItem

Removed InvoiceItem.line_type

Plan

Plan no longer has a stripe_plan property. Use`api_retrieve()`` instead.

Plan.currency no longer uses choices. Use the get_supported_currency_choices() utility and create your own custom choices list instead.

Plan interval choices are now in `Plan.INTERVAL_TYPE_CHOICES``

Subscription

Subscription.is_period_current() now checks for a current trial end if the current period has ended. This change means subscriptions extended with Subscription.extend() will now be seen as valid.

MIGRATIONS

We'll sync your current records with Stripe in a migration. It will take a while, but it's the only way we can ensure data integrity. There were some fields for which we needed to temporarily add placeholder defaults, so just make sure you have a customer with ID 1 and a plan with ID 1 and you shouldn't run into any issues (create dummy values for these if need be and delete them after the migration).

BIG HUGE NOTE - DON'T OVERLOOK THIS

Subscription and InvoiceItem migration is not possible because old records don't have Stripe IDs (so we can't sync them). Our approach is to delete all local subscription and invoiceitem objects and re-sync them from Stripe.

We 100% recommend you create a backup of your database before performing this upgrade.
opened by kavdev 69
Extra/Empty Customer Instance Created During Checkout
Describe the bug

DJ-stripe is creating an additional customer object for each of my real Stripe customers upon creation. This extra (blank) customer is the one that is related to my User model, so when I try to access Stripe Customer data via the authenticated User on my site, the data comes back empty. The original Stripe Customer object (with all of the correct data) still lives in my database but is not related to a User.

I don't know if this is a bug or an implementation issue on my end, but if this rings a bell for anyone I'd appreciate your help. I am 99% finished with my integration, but I am unable to ship the Stripe Customer Portal because it is using the blank/extra Stripe Customer and therefore does not display any data as it should.

Software versions

dj-stripe version: 2.5

Python version: 3.8.0

Django version: 3.2

Stripe API version: 2020-08-27

Database type and version: psql (PostgreSQL) 13.2

Steps To Reproduce

This is my local configuration - to reproduce the issue your environment should match up with: STRIPE_TEST_SECRET_KEY = reach out to dev team for this STRIPE_TEST_PUBLIC_KEY = reach out to dev team for this DJSTRIPE_WEBHOOK_SECRET = reach out to dev team for this DJSTRIPE_WEBHOOK_VALIDATION = "verify_signature" DJSTRIPE_USE_NATIVE_JSONFIELD = True DJSTRIPE_FOREIGN_KEY_TO_FIELD = "djstripe_id" DJSTRIPE_SUBSCRIBER_MODEL = "myApp.User" DJSTRIPE_SUBSCRIBER_CUSTOMER_KEY = "djstripe_subscriber" DJSTRIPE_WEBHOOK_URL=r"^stripe/\$"

If you have a matching backend configuration and a frontend which allows you to complete the Stripe checkout process, you can reproduce the issue. Simply go through the standard Stripe checkout flow and then check your database to see if two records were created instead of one. One should have the full data that you entered in Checkout (credit card number, subscription, etc.) and the other one should simply have the name and email address.

Better yet, if you have the Stripe Customer Portal integrated on your frontend you may be able to see what I mean when the empty/inactive/extra Stripe Customer ID is presented instead of the one that maps to the request user.

Can you reproduce the issue with the latest version of master?

I believe so

Expected Behavior

I expect DJ-stripe to relate the request User with the corresponding Stripe Customer instance so that I can query and access this data on my frontend and allow users to interact with the Stripe Customer Portal to manage their membership.

Actual Behavior

There should be two database records and two Stripe customers viewable in your Stripe dashboard with the same email address. One of them will also have customer data such as payment method. The other one will be empty beyond email/name. The empty one will be related to an instance of .User.
bug
opened by alecdalelio 52
url 'djstripe:confirm' NoReverseMatch Found

=<a class="btn btn-primary" href="{% url 'djstripe:confirm' plan_id=plan.id %}" role="button">

NoReverseMatch: Reverse for 'confirm' with arguments '()' and keyword arguments '{'plan_id': 3}' not found. 0 pattern(s) tried: [] This button seems to call an action that is no longer in the URL since everything was switched to a call based view.

Can anyone tell me how to resolve this issue as its living inside the python package?

opened by wiprogrammer 47
Race conditions in Customer.get_or_create()
Since landing #440 I've been trying to figure out the race conditions in Customer.get_or_create().

The issue is the same as #429, except that in this case we don't have a stripe ID to play with. Let's look at the code:

@classmethod def get_or_create(cls, subscriber, livemode=djstripe_settings.STRIPE_LIVE_MODE): try: return Customer.objects.get(subscriber=subscriber, livemode=livemode), False except Customer.DoesNotExist: return cls.create(subscriber), True

When this path is reached by two threads at the same time and the customer does not exist in the local db, both of them reach the last line, which creates the customer. The Stripe API, having no concept of our per-user unique, will happily create both of them. dj-stripe will crash on the second thread because the unique_together constraint fails... but the customer is still created upstream; not only are we in a desynced state now, but the stripe db is polluted with a useless and confusing object.

So, what to do? The correct acid-compliant fix is to create the Customer object in the db beforehand. But... we don't have a stripe_id for it yet. We can save it with an empty stripe id, or a random one, but there is still a synchronicity problem: The second thread will be able to get the customer object, but the data on it is not current. That's detectable and not a problem right? Well, no, because we dont have a stripe_id, we can't sync it.

I'm a bit stumped. My first idea is we could create the Customer beforehand, attach the user id in the metadata and use that for synchronization? This is part of a larger overall issue of keeping customers in sync between downstream and upstream: If a customer is deleted locally, it's impossible to retrieve the upstream object.
discussion race condition
opened by jleclanche 47
Payment Intent and Checkout Session (SCA, EU Regulations)
Add models and functionalities to support SCA regulations (https://stripe.com/docs/strong-customer-authentication/migration)

New Models:

Payment Method

Setup Intent

Payment Intent

Checkout

Also, extra changes to support model additions such as:

Update Subscriptions with new pending_setup_intent field

Rename property payment_methods for Customer object to solve conflict: Due to addition of new Payment Method model, there has been a conflict in the name of property payment_methods on Customer object, hence the required name change.

Update migrations and test fixtures.

Add Charge.payment_intent + test fixture

This resolves #803, #897
opened by tiwariayush 35
Migration issue in postgres

I spent the week migrating from 0.9 to 1.0. Everything successfully works with django 1.11.0 and a clean database.

I cannot get it into the production server unfortunately. Running python manage.py migrate results in an error being thrown. cannot ALTER TABLE "djstripe_invoice" because it has pending trigger events

How can i successfully merge this without losing customer data?
bug migrations

opened by cpebble 33
New Stripe Order API Support

Hi. I’m planning on migrating over to the new stripe order api (from the session api) once it leaves beta. Will this be supported in this upcoming release (v2.7.0)?
discussion

opened by eliezerp3 32
Automatic sync of foreign keys
Special handling needed for InvoiceItem to avoid recursive Charge<->Invoice dependency

Removed redundant _attach_objects_hook's

Testing:

Added a test method to recursively check that all ForeignKeys not in a whitelist are set

Added a bunch of retrieve mocks since we're now fetching more

Resolves #681

Also a few other semi-related fixes as separate commits:

Fix inconsistent fake invoice id, to match FAKE_INVOICE

Patch Customer.save() to emulate stripe API .coupon -> .discount + Access coupon using dict style for consistency with test
opened by therefromhere 32

Add support for upcoming invoices w/ invoice items

Description

Adds support for Stripe's API for previewing upcoming invoices, and also adds support for subscription-based invoice items - This was a rather tricky one to implement given the ephemeral nature of the upcoming invoices. They aren't persisted to the database and their internals differ from the expected "norm" (i.e. they don't have a stripe ID).

An example of usage (as we have it in our application):

invoice = djstripe_models.Invoice.upcoming(
    customer=customer, subscription=sub, subscription_plan=plan)

An additional plan property accessor has been added to invoices - As detailed in the code comments, this was necessary for us to provide a consistent view for the invoice history. Instead of using the plan from the invoice subscription, it is now possible to use the plan for the from available subscription invoice item, and this access is encapsulated in the property.

The maximum length for stripe fields was also raised to 255, in accordance with the recommendations in the Stripe API Upgrades documentation. The main reason though was to make room for the longer composite key IDs used for subscription-based invoice items (necessary in order to ensure these remain unique per invoice). As per the plan change above, this also helps to provide a consistent view for the invoice history.

One odd thing to note is the use of the QuerySetMock for UpcomingInvoice. The reasoning behind this was to ensure that invoice.invoiceitems() for upcoming invoices still returned a queryset-like object that supports non-mutation operations such as iteration. I made a note in the documentation not to expect it to do anything else, so it's a bit like Stripe's own docs for upcoming invoices, they are not mutable. The main downside is the added dependency, so apologies for that!

Finally, I guess that the changes for _get_or_create_from_stripe_object might be contentious, which were required to handle the slightly different structure for the invoice items within the upcoming invoice, and to support things like not re-fetching the data from Stripe and not saving the created object. Both of the latter could be useful for some additional optimisations later.

I'll be happy to discuss any part of the PR during review!

Test Output

Ran: python runtests.py --skip-utc

Welcome to the dj-stripe test suite.

Step 1: Running unit tests.

nosetests . --verbosity=1
Creating test database for alias 'default'...
................................................................................................................................................................................................................S...S.........................................
----------------------------------------------------------------------
Ran 254 tests in 5.540s

OK (SKIP=2)
Destroying test database for alias 'default'...

Step 2: Generating coverage results.

Name                                             Stmts   Miss Branch BrPart  Cover   Missing
--------------------------------------------------------------------------------------------
djstripe/context_managers.py                         8      0      0      0   100%
djstripe/contrib/rest_framework/permissions.py       9      0      0      0   100%
djstripe/contrib/rest_framework/serializers.py      11      0      0      0   100%
djstripe/contrib/rest_framework/urls.py              5      0      0      0   100%
djstripe/contrib/rest_framework/views.py            36      0      2      0   100%
djstripe/decorators.py                              19      0      4      0   100%
djstripe/event_handlers.py                          44      0     16      0   100%
djstripe/exceptions.py                               7      0      0      0   100%
djstripe/fields.py                                  76      0     18      0   100%
djstripe/forms.py                                    7      0      0      0   100%
djstripe/managers.py                                37      0      0      0   100%
djstripe/middleware.py                              36      0     18      0   100%
djstripe/mixins.py                                  26      0      2      0   100%
djstripe/models.py                                 371      0    116      0   100%
djstripe/settings.py                                43      0     12      0   100%
djstripe/signals.py                                  3      0      0      0   100%
djstripe/stripe_objects.py                         485      0     75      0   100%
djstripe/sync.py                                    29      0      4      0   100%
djstripe/templatetags/djstripe_tags.py              20      0      4      0   100%
djstripe/urls.py                                     6      0      0      0   100%
djstripe/utils.py                                   35      0     14      0   100%
djstripe/views.py                                  133      0     22      0   100%
djstripe/webhooks.py                                25      0      8      0   100%
--------------------------------------------------------------------------------------------
TOTAL                                             1471      0    315      0   100%

Step 3: Checking for pep8 errors.

pep8 errors:
----------------------------------------------------------------------
None

Tests completed successfully with no errors. Congrats!

feature

opened by lskillen 32

Tests Fail with Django 1.9

Tests fail with Django 1.9 meaning that all new Pull Requests will fail given that the current requirements_test.txt has django>=1.7 which will result in 1.9 being installed during the build.

Example build - https://travis-ci.org/pydanny/dj-stripe/jobs/94795855

I wish I knew how to fix this but it's a little over my head as to how these tests actually work. :confounded:

======================================================================
ERROR: test_change_sub_stripe_error (tests.test_views.ChangePlanViewTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/virtualenv/python3.5.0/lib/python3.5/site-packages/mock/mock.py", line 1305, in patched
    return func(*args, **keywargs)
  File "/home/travis/build/pydanny/dj-stripe/tests/test_views.py", line 333, in test_change_sub_stripe_error
    self.assertIn("No such plan: test_id_3", response.context["form"].errors["__all__"])
KeyError: '__all__'
======================================================================
ERROR: test_post_new_sub_no_proration (tests.test_views.ChangePlanViewTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/virtualenv/python3.5.0/lib/python3.5/site-packages/mock/mock.py", line 1305, in patched
    return func(*args, **keywargs)
  File "/home/travis/build/pydanny/dj-stripe/tests/test_views.py", line 273, in test_post_new_sub_no_proration
    self.assertIn("You must already be subscribed to a plan before you can change it.", response.context["form"].errors["__all__"])
KeyError: '__all__'
======================================================================
ERROR: test_post_no_card (tests.test_views.ConfirmFormViewTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/virtualenv/python3.5.0/lib/python3.5/site-packages/mock/mock.py", line 1305, in patched
    return func(*args, **keywargs)
  File "/home/travis/build/pydanny/dj-stripe/tests/test_views.py", line 235, in test_post_no_card
    self.assertIn("Invalid source object:", response.context["form"].errors["__all__"])
KeyError: '__all__'

opened by alexphelps 32

Implement pydocstyle to enforce documentation
Enhanced documentation for ticket https://github.com/kavdev/dj-stripe/issues/307

[x] Adds flake8-docstringsto requirements.txt

~~Add the linter to runtests.py to enforce in development and builds~~ Not needed because of flake8-pydocstyle

~~Change Django version to hard requirement of !=1.9,>=1.8,<1.10~~ Done in another branch

[x] Add documentation to:

Decorators

Event Handlers

Managers

Middleware

Signals

[x] Adds docstrings to everything! Also put # noqa where parent class has a sufficient docstring.

[x] fix merge conflicts due to line reduction

documentation
opened by aleccool213 29
Fixed Django 4.1 version compatibility issue

Fixed Django 4.1 version compatibility issue. Fixed the issue that the stripe account id was not being retrieved due to Django 4.1 unifcation of m2m fields and the reverse related field model manager as mentioned here

Fix: #1855

opened by arnav13081994 0
added most of the supported currencies in stripe
added most of the supported currencies in stripe

sources:

https://stripe.com/docs/currencies

https://www.xe.com/symbols/

https://www.tradinghours.com/

https://www.investopedia.com/

https://economictimes.indiatimes.com/definition/currency-symbol and google with Wikipedia
opened by inoob26 2
added auto set customer name in stripe
Plans to set customer name in the following manner:

If the subscriber table has a name column use that as the customer name

Otherwise generate the customer name from their email

Reason:

Stripe does not allow export transactions if the customer name is not set in the stripe dashboard. Also, customers cannot set their billing name from the stripe-hosted customer portal.
opened by ak4zh 1
Add model to track sync of Stripe Objects
PR #1853 needs to be merged before this PR can be merged.

This PR contains the following changes:

A new model DjStripeSyncModelTrack to track history of syncs allowing the user to perform incremental syncs instead of always starting syncs from scratch.

A new strategy optional kwarg for the djstripe_sync_models management command to allow the user to control how they'd like to perform syncs of objects, either incremental (default) or full_refresh.
opened by arnav13081994 0

the product table doesn't contain default_price

Each product in the Stripe may contain a default_price but the djstipe doesn't include this in the product table. Stripe json:

{
  "id": "prod_MxjXI8ljapijqJ",
  "object": "product",
  "active": true,
  "created": 1670759533,
  "default_price": null,
  "description": "(created by Stripe CLI)",
  "images": [],
  "livemode": false,
  "metadata": {},
  "name": "myproduct",
  "package_dimensions": null,
  "provisioning": null,
  "shippable": null,
  "statement_descriptor": null,
  "tax_code": null,
  "unit_label": null,
  "updated": 1670759533,
  "url": null
}

bug

opened by HodaJafari 0

Releases(2.7.2)

2.7.2(Oct 21, 2022)
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

Source code(tar.gz)
Source code(zip)
2.7.1(Oct 20, 2022)
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)

Source code(tar.gz)
Source code(zip)
2.7.0(Oct 17, 2022)
!!! 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

Source code(tar.gz)
Source code(zip)
2.6.3(Oct 14, 2022)
Release notes

Update migrations missed in 2.6.2 (#1819)

Fix a crash with string representations of uninitialized Card objects

Source code(tar.gz)
Source code(zip)
2.6.2(Jul 2, 2022)
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)

Source code(tar.gz)
Source code(zip)
2.6.1(Feb 7, 2022)
Release notes

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

Source code(tar.gz)
Source code(zip)
2.6.0(Jan 15, 2022)
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.

Source code(tar.gz)
Source code(zip)
2.6.0rc1(Jan 12, 2022)

This is a release candidate for dj-stripe 2.6.0. Please see here for release notes.
Source code(tar.gz)
Source code(zip)
2.5.1(Jul 2, 2021)
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.

Source code(tar.gz)
Source code(zip)
2.5.0(Jun 6, 2021)
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.

Source code(tar.gz)
Source code(zip)
2.4.3(Feb 8, 2021)
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.

Source code(tar.gz)
Source code(zip)
2.4.2(Jan 24, 2021)
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.

Source code(tar.gz)
Source code(zip)
2.4.1(Nov 29, 2020)
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)

Source code(tar.gz)
Source code(zip)
2.4.0(Nov 19, 2020)
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".
Source code(tar.gz)
Source code(zip)
2.3.0(Apr 18, 2020)
The minimum version of Django is now 2.1, and Python 3.6.

Changed JSONField dependency back to jsonfield from jsonfield2 (see Warning about safe uninstall of jsonfield2 on upgrade).

Fixed handling of TaxRate events (#1094).

Fixed pagination issue in Invoice.sync_from_stripe_data (#1052).

Fixed pagination issues in Subscription & Charge .sync_from_stripe_data (#1054).

Tidyup _stripe_object_set_total_tax_amounts unique handling (#1139).

Dropped previously-deprecated Invoice fields (see https://stripe.com/docs/upgrades#2018-11-08 ):

.closed

.forgiven

.billing (renamed to .collection_method)

Dropped previously-deprecated enums.InvoiceStatus (#1020).

Deprecated the following fields - will be removed in 2.4 (#1087):

Subscription.billing (use .collection_method instead)

Subscription.start (use .start_date instead)

Subscription.tax_percent (use .default_tax_rates instead)

Added Invoice.status and enums.InvoiceStatus (#1020).

Added new Invoice fields (#1020, #1087):

.discount

.default_source

.status

Added new Subscription fields (#1087):

.default_payment_method

.default_source

.next_pending_invoice_item_invoice

.pending_invoice_item_interval

.pending_update

.start_date

Warning about safe uninstall of jsonfield2 on upgrade

Both jsonfield and jsonfield2 use the same import path, so if upgrading from dj-stripe~=2.2.0 in an existing virtualenv, be sure to uninstall jsonfield2 first. eg:

# ensure jsonfield is uninstalled before we install jsonfield2 pip uninstall jsonfield2 -y && pip install "dj-stripe>=2.3.0dev"

Otherwise, pip uninstall jsonfield2 will remove jsonfield's jsonfield module from site-packages, which would cause errors like ImportError: cannot import name 'JSONField' from 'jsonfield' (unknown location)

If you have hit this ImportError already after upgrading, running this should resolve it:

# remove both jsonfield packages before reinstall to fix ImportError: pip uninstall jsonfield jsonfield2 -y && pip install "dj-stripe>=2.3.0dev"

Note that this is only necessary if upgrading from dj-stripe 2.2.x, which temporarily depended on jsonfield2. This process is not necessary if upgrading from an earlier version of dj-stripe.
Source code(tar.gz)
Source code(zip)
2.3.0rc0(Nov 17, 2020)

Source code(tar.gz)
Source code(zip)
2.2.3(Feb 25, 2020)

Changed JSONField dependency back to jsonfield from jsonfield2, since jsonfield2 has now been merged back into jsonfield (See #1118).
Source code(tar.gz)
Source code(zip)
2.2.2(Jan 20, 2020)
This is a bugfix-only version:

Fixed handling of TaxRate events (#1094).

Source code(tar.gz)
Source code(zip)
2.2.1(Jan 14, 2020)
This is a bugfix-only version:

Fixed bad package build.

Source code(tar.gz)
Source code(zip)
2.2.0(Jan 13, 2020)
Changed JSONField dependency package from jsonfield to jsonfield2, for Django 3 compatibility (see Warning about safe uninstall of jsonfield on upgrade). Note that Django 2.1 requires jsonfield<3.1.

Added support for Django 3.0 (requires jsonfield2>=3.0.3).

Added support for python 3.8.

Refactored UpcomingInvoice, so it's no longer a subclass of Invoice (to allow Invoice to use ManyToManyFields).

Dropped previously-deprecated Account fields (see https://stripe.com/docs/upgrades#2019-02-19 ):

.business_name

.business_primary_color

.business_url (changed to a property)

.debit_negative_balances

.decline_charge_on

.display_name

.legal_entity

.payout_schedule

.payout_statement_descriptor

.statement_descriptor

.support_email

.support_phone

.support_url

.timezone

.verification

Dropped previously-deprecated Account.business_logo property (renamed to .branding_icon)

Dropped previously-deprecated Customer.account_balance property (renamed to .balance)

Dropped previously-deprecated properties Invoice.application_fee, Invoice.date

Dropped previously-deprecated enum PaymentMethodType (use DjstripePaymentMethodType instead)

Renamed Invoice.billing to .collection_method (added deprecated property for the old name).

Updated Invoice model to add missing fields.

Added TaxRate model, and Invoice.default_tax_rates, InvoiceItem.tax_rates, Invoice.total_tax_amounts, Subscription.default_tax_rates, SubscriptionItem.tax_rates (#1027).

Change urls.py to use the new style urls.

Update forward relation fields in the admin to be raw id fields.

Updated StripeQuantumCurrencyAmountField and StripeDecimalCurrencyAmountField to support Stripe Large Charges (#1045).

Update event handling so customer.subscription.deleted updates subscriptions to status="canceled" instead of deleting it from our database, to match Stripe's behaviour (#599).

Added missing Refund.reason value, increases field width (#1075).

Fixed Refund.status definition, reduces field width (#1076).

Deprecated non-standard Invoice.status (renamed to Invoice.legacy_status) to make way for the Stripe field (preparation for #1020).

Warning about safe uninstall of jsonfield on upgrade

Both jsonfield and jsonfield2 use the same import path, so if upgrading to dj-stripe>=2.2 in an existing virtualenv, be sure to uninstall jsonfield first. eg:

# ensure jsonfield is uninstalled before we install jsonfield2 pip uninstall jsonfield -y && pip install "dj-stripe>=2.2.0"

Otherwise, pip uninstall jsonfield will remove jsonfield2’s jsonfield module from site-packages, which would cause errors like ImportError: cannot import name 'JSONField' from 'jsonfield' (unknown location)

If you have hit this ImportError already after upgrading, running this should resolve it:

# remove both jsonfield packages before reinstall to fix ImportError: pip uninstall jsonfield jsonfield2 -y && pip install "dj-stripe>=2.2.0"

Note on usage of Stripe Elements JS

See Integrating Stripe Elements for notes about usage of the Stripe Elements frontend JS library.

In summary: If you haven't yet migrated to PaymentIntents, prefer stripe.createSource() to stripe.createToken().
Source code(tar.gz)
Source code(zip)
2.2.0rc0(Nov 17, 2020)

Source code(tar.gz)
Source code(zip)
2.1.1(Sep 30, 2019)
This is a bugfix-only release:

Updated webhook signals list (#1000).

Fixed issue syncing PaymentIntent with destination charge (#960).

Fixed Customer.subscription and .valid_subscriptions() to ignore status=incomplete_expired (#1006).

Fixed error on paymentmethod.detached event with card_xxx payment methods (#967).

Added PaymentMethod.detach() (#943).

Updated help_text on all currency fields to make it clear if they're holding integer cents (StripeQuantumCurrencyAmountField) or decimal dollar (or euro, pound etc) (StripeDecimalCurrencyAmountField) (#999)

Documented our preferred Django model field types (#986)

Source code(tar.gz)
Source code(zip)
2.1.0(Sep 13, 2019)
Dropped Django 2.0 support

The Python stripe library minimum version is now 2.32.0, also 2.36.0 is excluded due to a regression (#991).

Dropped previously-deprecated Charge.fee_details property.

Dropped previously-deprecated Transfer.fee_details property.

Dropped previously-deprecated field_name parameter to sync_from_stripe_data

Dropped previously-deprecated alias StripeObject of StripeModel

Dropped previously-deprecated alias PaymentMethod of DjstripePaymentMethod

Dropped previously-deprecated properties Charge.source_type and Charge.source_stripe_id

enums.PaymentMethodType has been deprecated, use enums.DjstripePaymentMethodType

Made SubscriptionItem.quantity nullable as per Plans with usage_type="metered" (follow-up to #865)

Added manage commands djstripe_sync_models and djstripe_process_events (#727, #89)

Fixed issue with re-creating a customer after Customer.purge() (#916)

Fixed sync of Customer Bank Accounts (#829)

Fixed Subscription.is_status_temporarily_current() (#852)

New models

Payment Intent

Setup Intent

Payment Method

Session

Added fields to Customer model: address, invoice_prefix, invoice_settings, phone, preferred_locales, tax_exempt

Changes from API 2018-11-08:

Added Invoice.auto_advance, deprecated Invoice.closed and Invoice.forgiven, see https://stripe.com/docs/billing/invoices/migrating-new-invoice-states#autoadvance

Changes from API 2019-02-19:

Major changes to Account fields, see https://stripe.com/docs/upgrades#2019-02-19 , updated Account fields to match API 2019-02-19:

Added Account.business_profile, .business_type, .company, .individual, .requirements, .settings

Deprecated the existing fields, to be removed in 2.2

Special handling of the icon and logo fields:

Renamed Account.business_logo to Account.branding_icon (note that in Stripe's API Account.business_logo was renamed to Account.settings.branding_icon, and Account.business_logo_large (which we didn't have a field for) was renamed to Account.settings.branding_logo)

Added deprecated property for Account.business_logo

Added Account.branding_logo as a ForeignKey

Populate Account.branding_icon and .branding_logo from the new Account.settings.branding.icon and .logo

Changes from API 2019-03-14:

Renamed Invoice.application_fee to Invoice.application_fee_amount (added deprecated property for the old name)

Removed Invoice.date, in place of Invoice.created (added deprecated property for the old name)

Added Invoice.status_transitions

Renamed Customer.account_balance to Customer.balance (added deprecated property for the old name)

Renamed Customer.payment_methods to Customer.customer_payment_methods

Added new SubscriptionStatus.incomplete and SubscriptionStatus.incomplete_expired statuses (#974)

Added new BalanceTransactionType values (#983)

Squashed dev migrations

As per our migration policy, unreleased migrations on the master branch have been squashed.

If you have been using the 2.1.0dev branch from master, you'll need to run the squashed migrations migrations before upgrading to >=2.1.0.

The simplest way to do this is to pip install dj-stripe==2.1.0rc0 and migrate, alternatively check out the 2.1.0rc0 git tag.
Source code(tar.gz)
Source code(zip)
2.1.0rc(Sep 13, 2019)

As per our migration policy unreleased migrations on the master branch (migration numbers >=0004) have been squashed.

If you have been using the 2.1.0dev branch from master, you'll need to run the squashed migrations migrations before upgrading to >=2.1.0.

The simplest way to do this is to pip install dj-stripe==2.1.0rc0 and migrate, alternatively check out this tag (2.1.0rc0).
Source code(tar.gz)
Source code(zip)
2.0.5(Sep 13, 2019)
This is a bugfix-only version:

Avoid stripe==2.36.0 due to regression (#991)

Source code(tar.gz)
Source code(zip)
2.0.4(Nov 16, 2020)
This is a bugfix-only version:

Fixed irreversible migration (#909)

Source code(tar.gz)
Source code(zip)
2.0.3(Nov 16, 2020)
This is a bugfix-only version:

In _get_or_create_from_stripe_object, wrap create _create_from_stripe_object in transaction, fixes TransactionManagementError on race condition in webhook processing (#877, #903).

Source code(tar.gz)
Source code(zip)
2.0.2(Nov 16, 2020)
This is a bugfix-only version:

Don't save event objects if the webhook processing fails (#832).

Fixed IntegrityError when REMOTE_ADDR is an empty string.

Deprecated field_name parameter to sync_from_stripe_data

Source code(tar.gz)
Source code(zip)
2.0.1(Nov 16, 2020)
This is a bugfix-only version:

Fixed an error on invoiceitem.updated (#848).

Handle test webhook properly in recent versions of Stripe API (#779). At some point 2018 Stripe silently changed the ID used for test events and evt_00000000000000 is not used anymore.

Fixed OperationalError seen in migration 0003 on postgres (#850).

Fixed issue with migration 0003 not being unapplied correctly (#882).

Fixed missing SubscriptionItem.quantity on metered Plans (#865).

Fixed Plan.create() (#870).

Source code(tar.gz)
Source code(zip)
2.0.0(Nov 16, 2020)
The Python stripe library minimum version is now 2.3.0.

PaymentMethod has been renamed to DjstripePaymentMethod (#841). An alias remains but will be removed in the next version.

Dropped support for Django<2.0, Python<3.4.

Dropped previously-deprecated stripe_objects module.

Dropped previously-deprecated stripe_timestamp field.

Dropped previously-deprecated Charge.receipt_number field.

Dropped previously-deprecated StripeSource alias for Card

Dropped previously-deprecated SubscriptionView, CancelSubscriptionView and CancelSubscriptionForm.

Removed the default value from DJSTRIPE_SUBSCRIPTION_REDIRECT.

All stripe_id fields have been renamed id.

Charge.source_type has been deprecated. Use Charge.source.type.

Charge.source_stripe_id has been deprecated. Use Charge.source.id.

All deprecated Transfer fields (Stripe API 2017-04-06 and older), have been dropped. This includes date, destination_type (type), failure_code, failure_message, statement_descriptor and status.

Fixed IntegrityError when REMOTE_ADDR is missing (#640).

New models:

ApplicationFee

ApplicationFeeRefund

BalanceTransaction

CountrySpec

ScheduledQuery

SubscriptionItem

TransferReversal

UsageRecord

The fee and fee_details attributes of both the Charge and Transfer objects are no longer stored in the database. Instead, they access their respective new balance_transaction foreign key. Note that fee_details has been deprecated on both models.

The fraudulent attribute on Charge is now a property that checks the fraud_details field.

Object key validity is now always enforced (#503).

Customer.sources no longer refers to a Card queryset, but to a Source queryset. In order to correctly transition, you should change all your references to customer.sources to customer.legacy_cards instead. The legacy_cards attribute already exists in 1.2.0.

Customer.sources_v3 is now named Customer.sources.

A new property Customer.payment_methods is now available, which allows you to iterate over all of a customer's payment methods (sources then cards).

Card.customer is now nullable and cards are no longer deleted when their corresponding customer is deleted (#654).

Webhook signature verification is now available and is preferred. Set the DJSTRIPE_WEBHOOK_SECRET setting to your secret to start using it.

StripeObject has been renamed StripeModel. An alias remains but will be removed in the next version.

The metadata key used in the Customer object can now be configured by changing the DJSTRIPE_SUBSCRIBER_CUSTOMER_KEY setting. Setting this to None or an empty string now also disables the behaviour altogether.

Text-type fields in dj-stripe will no longer ever be None. Instead, any falsy text field will return an empty string.

Switched test runner to pytest-django

StripeModel.sync_from_stripe_data() will now automatically retrieve related objects and populate foreign keys (#681)

Added Coupon.name

Added Transfer.balance_transaction

Exceptions in webhooks are now re-raised as well as saved in the database (#833)

Source code(tar.gz)
Source code(zip)