Django + Stripe Made Easy

Overview

dj-stripe

Documentation Sponsor 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

Stripe Logo

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

Issues
  • Release 1.0.0

    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

    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

    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()

    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)

    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

    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
  • Automatic sync of foreign keys

    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

    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

    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

    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
  • Add Coupons for Customers

    Add Coupons for Customers

    Stripe has Coupons! :smiley: dj-stripe does not. :frowning: We should fix that!

    Per this conversation on a related feature, we saw that it might be good to have Coupons available.

    The general use case is: "I want to offer my customers a sale." Maybe this is for only certain customers. Maybe I send the code in an email. Maybe I can set a flag to show it on the subscription page, or it auto-calculates for all users.

    This should probably follow the same workflow as Plans will soon have: you can create Coupons via settings.py, or models (via the Admin).

    Maybe, since nobody has really asked for this, it's not that important:question: Give it a :+1: if you like it!

    feature 
    opened by briandant 29
  • Updated Subscription.__str__ to check for null products

    Updated Subscription.__str__ to check for null products

    This is because subscription associated plans can have null products.

    Description

    This PR contains the following changes:

    1. Fixed Subscription.str to not error out if the subscription associated plan's product is null.

    Checklist:

    • [X] I've updated the tests or confirm that my change doesn't require any updates.
    • [X] I've updated the documentation or confirm that my change doesn't require any updates.
    • [X] I confirm that my change doesn't drop code coverage below the current level.
    • [X] I've updated migrations or confirm that my change doesn't make changes to any model.
    opened by arnav13081994 0
  • Updated validate_stripe_api_version check to allow for beta Stripe API Versions

    Updated validate_stripe_api_version check to allow for beta Stripe API Versions

    …I Versions

    Description

    This PR contains the following changes:

    1. Updated validate_stripe_api_version check to allow for beta/alpha Stripe API Versions.

    Checklist:

    • [X] I've updated the tests or confirm that my change doesn't require any updates.
    • [X] I've updated the documentation or confirm that my change doesn't require any updates.
    • [X] I confirm that my change doesn't drop code coverage below the current level.
    • [X] I've updated migrations or confirm that my change doesn't make changes to any model.

    Rationale

    dj-stripe will work when a user sets the Stripe API Version of the format 2020-08-27; orders_beta=v3

    opened by arnav13081994 0
  • Add automatic_pending_invoice_item_invoice to InvoiceBillingReason enum

    Add automatic_pending_invoice_item_invoice to InvoiceBillingReason enum

    Description

    Adding automatic_pending_invoice_item_invoice to InvoiceBillingReason

    This PR contains the following changes:

    1. Fixes #1692

    Checklist:

    • [x] I've updated the tests or confirm that my change doesn't require any updates.
    • [x] I've updated the documentation or confirm that my change doesn't require any updates.
    • [x] I confirm that my change doesn't drop code coverage below the current level.
    • [x] I've updated migrations or confirm that my change doesn't make changes to any model.

    Rationale

    Webhooks will break without this change if pending_invoice_item_interval is used with subscriptions

    opened by steverecio 0
  • API change for Invoice.billing_reason

    API change for Invoice.billing_reason

    It seems to be undocumented (docs) but the InvoiceBillingReason enum is missing the value automatic_pending_invoice_item_invoice. Stripe is sending this undocumented value which is causing my webhooks to fail due to the max_length of the Invoice.billing_reason field (currently calculates to a max_length=22 due to the missing field).

    I propose adding this new enum value to InvoiceBillingReason.

    Relevant Note: I am using the pending_invoice_item_interval option when I create subscriptions.

    api change 
    opened by steverecio 3
  • Added ShippingRate Model

    Added ShippingRate Model

    Please merge PR https://github.com/dj-stripe/dj-stripe/pull/1688 before merging this.

    Description

    This PR contains the following changes:

    1. Added ShippingRate Model.
    2. Added Corresponding Tests.

    Checklist:

    • [X] I've updated the tests or confirm that my change doesn't require any updates.
    • [X] I've updated the documentation or confirm that my change doesn't require any updates.
    • [X] I confirm that my change doesn't drop code coverage below the current level.
    • [X] I've updated migrations or confirm that my change doesn't make changes to any model.

    Rationale

    Fix #1663

    opened by arnav13081994 0
  • Updated Admin Custom Action to leverage built in functionality

    Updated Admin Custom Action to leverage built in functionality

    Description

    This PR contains the following changes:

    1. Overrode admin.ModelAdmin.get_urls(). This was done to re-use django's built in admin view functionality.
    2. Removed redundant ConfirmCustomAction.dispatch() as admin_site.admin_view() automatically prevents unauthorised access.
    3. Updated Corresponding Tests.

    Checklist:

    • [X] I've updated the tests or confirm that my change doesn't require any updates.
    • [X] I've updated the documentation or confirm that my change doesn't require any updates.
    • [X] I confirm that my change doesn't drop code coverage below the current level.
    • [X] I've updated migrations or confirm that my change doesn't make changes to any model.

    Rationale

    This PR is essentially a rewrite of the commit: 4744fbccab484140b7b5488dff6057e09119338f as it would reduce the code to achieve the same functionality.

    opened by arnav13081994 0
Releases(2.6.1)
  • 2.6.1(Feb 7, 2022)

  • 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)

  • 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)

  • 2.2.3(Feb 25, 2020)

  • 2.2.2(Jan 20, 2020)

  • 2.2.1(Jan 14, 2020)

  • 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)

  • 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:

    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)

  • 2.0.4(Nov 16, 2020)

  • 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)
  • 1.2.4(Nov 17, 2020)

    This is a bugfix-only version:

    • Allow billing_cycle_anchor argument when creating a subscription (#814)
    • Fixup plan amount null with tier plans (#781)
    • Update Cancel subscription view tests to match backport in f64af57
    • Implement Invoice._manipulate_stripe_object_hook for compatability with API 2018-11-08 (#771)
    • Fix product webhook for type="good" (#724)
    • Add trial_from_plan, trial_period_days args to Customer.subscribe() (#709)
    Source code(tar.gz)
    Source code(zip)
  • 1.2.3(Nov 17, 2020)

  • 1.2.2(Nov 17, 2020)

    This is a bugfix-only version:

    • Fixed an error with request.urlconf in some setups (#562)
    • Always save text-type fields as empty strings in db instead of null (#713)
    • Fix support for DJSTRIPE_SUBSCRIBER_MODEL_MIGRATION_DEPENDENCY (#707)
    • Fix reactivate() with Stripe API 2018-02-28 and above
    Source code(tar.gz)
    Source code(zip)
  • 1.2.1(Nov 17, 2020)

    This is a bugfix-only version:

    • Fixed various Python 2.7 compatibility issues
    • Fixed issues with max_length of receipt_number
    • Fixed various fields incorrectly marked as required
    • Handle product webhook calls
    • Fix compatibility with stripe-python 2.0.0
    Source code(tar.gz)
    Source code(zip)
  • 1.1.1(Nov 17, 2020)

    This is a bugfix-only release for Python 2 and migration issues found in dj-stripe 1.1.0.

    If you are on an older version of dj-stripe, you should upgrade to 1.1.x first with pip install "djstripe<1.2" before upgrading to 1.2.x.

    Please make sure to read the 1.1.0 release notes below.

    Source code(tar.gz)
    Source code(zip)
Owner
dj-stripe
Django + Stripe Made Easy
dj-stripe
A Django app to accept payments from various payment processors via Pluggable backends.

Django-Merchant Django-Merchant is a django application that enables you to use multiple payment processors from a single API. Gateways Following gate

Agiliq 984 May 24, 2022
Adyen package for django-oscar

Adyen package for django-oscar This package provides integration with the Adyen payment gateway. It is designed to work with the e-commerce framework

Oscar 13 Jan 10, 2022
PayPal integration for django-oscar. Can be used without Oscar too.

PayPal package for django-oscar This package provides integration between django-oscar and both PayPal REST API, PayPal Express (NVP) and PayPal Payfl

Oscar 134 May 4, 2022
A pluggable Django application for integrating PayPal Payments Standard or Payments Pro

Django PayPal Django PayPal is a pluggable application that integrates with PayPal Payments Standard and Payments Pro. See https://django-paypal.readt

Luke Plant 652 May 18, 2022
Django library to simplify payment processing with pin

Maintainer Wanted I no longer have any side projects that use django-pinpayments and I don't have the time or headspace to maintain an important proje

Ross Poulton 25 May 25, 2022
payu payment gateway integration for django projects

Django-PayU This package provides integration between Django and PayU Payment Gateway. Quick start Install 'django-payu' using the following command:

MicroPyramid 36 Jan 7, 2022
Django + Stripe Made Easy

dj-stripe Stripe Models for Django. Introduction dj-stripe implements all of the Stripe models, for Django. Set up your webhook endpoint and start rec

dj-stripe 1.2k May 26, 2022
Forms, widgets, template tags and examples that make Stripe + Django easier.

Overview Zebra is a library that makes using Stripe with Django even easier. It's made of: zebra, the core library, with forms, webhook handlers, abst

GoodCloud 185 Apr 22, 2022
Portfolio and E-commerce site built on Python-Django and Stripe checkout

StripeMe Introduction Stripe Me is an e-commerce and portfolio website offering communication services, including web-development, graphic design and

null 2 Apr 28, 2022
Python library for the Stripe API.

Stripe Python Library The Stripe Python library provides convenient access to the Stripe API from applications written in the Python language. It incl

Stripe 1.2k May 27, 2022
A Program that generates and checks Stripe keys 24x7.

A Program that generates and checks Stripe keys 24x7. This was made only for Educational Purposes, I'm not responsible for the damages cause by you

iNaveen 11 May 2, 2022
This Python based program checks your CC Stripe Auth 1$ Based Checker

CC-Checker This Python based program checks your CC Stripe Auth 1$ Based Checker About Author Coded by xBlackx Reach Me On Telegram @xBlackx_Coder jOI

xBlackxCoder 7 Mar 15, 2022
Paid roles for discord using Stripe, Python, Flask & Docker

Welcome to Paycord Paid roles for discord using Stripe, Python, Flask & Docker. Setup Production On stripe dashboard, go Developers ➡️ Webhooks ➡️ Add

Ward 7 Apr 13, 2022
django-quill-editor makes Quill.js easy to use on Django Forms and admin sites

django-quill-editor django-quill-editor makes Quill.js easy to use on Django Forms and admin sites No configuration required for static files! The ent

lhy 121 May 12, 2022
Django-google-optimize is a Django application designed to make running server side Google Optimize A/B tests easy.

Django-google-optimize Django-google-optimize is a Django application designed to make running Google Optimize A/B tests easy. Here is a tutorial on t

Adin Hodovic 37 May 10, 2022
Django-Audiofield is a simple app that allows Audio files upload, management and conversion to different audio format (mp3, wav & ogg), which also makes it easy to play audio files into your Django application.

Django-Audiofield Description: Django Audio Management Tools Maintainer: Areski Contributors: list of contributors Django-Audiofield is a simple app t

Areski Belaid 163 May 21, 2022
Industry ready custom API payload with an easy format for building Python APIs (Django/Django Rest Framework)

Industry ready custom API payload with an easy format for building Python APIs (Django/Django Rest Framework) Yosh! If you are a django backend develo

Abram (^o^) 5 Apr 25, 2022
Django module to easily send emails/sms/tts/push using django templates stored on database and managed through the Django Admin

Django-Db-Mailer Documentation available at Read the Docs. What's that Django module to easily send emails/push/sms/tts using django templates stored

LPgenerator 246 May 2, 2022
Django URL Shortener is a Django app to to include URL Shortening feature in your Django Project

Django URL Shortener Django URL Shortener is a Django app to to include URL Shortening feature in your Django Project Install this package to your Dja

Rishav Sinha 4 Nov 18, 2021
Your own movie streaming service. Easy to install, easy to use. Download, manage and watch your favorite movies conveniently from your browser or phone. Install it on your server, access it anywhere and enjoy.

Vigilio Your own movie streaming service. Easy to install, easy to use. Download, manage and watch your favorite movies conveniently from your browser

Tugcan Olgun 132 May 20, 2022
Easy-apply-bot - A LinkedIn Easy Apply bot to help with my job search.

easy-apply-bot A LinkedIn Easy Apply bot to help with my job search. Getting Started First, clone the repository somewhere onto your computer, or down

Matthew Alunni 3 Jan 4, 2022
A Lighting Pytorch Framework for Recommendation System, Easy-to-use and Easy-to-extend.

Torch-RecHub A Lighting Pytorch Framework for Recommendation Models, Easy-to-use and Easy-to-extend. 安装 pip install torch-rechub 主要特性 scikit-learn风格易用

Mincai Lai 34 May 20, 2022
:truck: Agile Data Preparation Workflows made easy with dask, cudf, dask_cudf and pyspark

To launch a live notebook server to test optimus using binder or Colab, click on one of the following badges: Optimus is the missing framework to prof

Iron 1.2k May 17, 2022
Delorean: Time Travel Made Easy

Delorean: Time Travel Made Easy Delorean is a library for clearing up the inconvenient truths that arise dealing with datetimes in Python. Understandi

Mahdi Yusuf 1.8k May 22, 2022
Python datetimes made easy

Pendulum Python datetimes made easy. Supports Python 2.7 and 3.4+. >>> import pendulum >>> now_in_paris = pendulum.now('Europe/Paris') >>> now_in_par

Sébastien Eustace 4.8k May 27, 2022
Model Serving Made Easy

The easiest way to build Machine Learning APIs BentoML makes moving trained ML models to production easy: Package models trained with any ML framework

BentoML 3.5k May 27, 2022
Spam filtering made easy for you

spammy Author: Tasdik Rahman Latest version: 1.0.3 Contents 1 Overview 2 Features 3 Example 3.1 Accuracy of the classifier 4 Installation 4.1 Upgradin

Tasdik Rahman 134 May 19, 2022
Python dependency management and packaging made easy.

Poetry: Dependency Management for Python Poetry helps you declare, manage and install dependencies of Python projects, ensuring you have the right sta

Poetry 19.9k May 26, 2022
🌐 URL parsing and manipulation made easy.

furl is a small Python library that makes parsing and manipulating URLs easy. Python's standard urllib and urlparse modules provide a number of URL re

Ansgar Grunseid 2.3k May 23, 2022