dj-stripe/dj-stripe

dj-stripe automatically syncs your Stripe Data to your local database as pre-implemented Django Models allowing you to use the Django ORM, in your code, to work with the data making it easier and faster.

dj-stripe - Django + Stripe Made Easy

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 >=4.2
• Python >=3.9
• PostgreSQL engine (recommended) >=12
• MySQL engine: MariaDB >=10.5 or MySQL >=8.0
• SQLite: Not recommended in production. Version >=3.26 required.

Installation

See installation instructions.

Changelog

See release notes on Read the Docs.

Funding and Support

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

We've been bringing dj-stripe to the world for over 10 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 use dj-stripe commercially, we would encourage you to invest in its continued development by signing up for a paid plan. Corporate sponsors receive priority support and development time.

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

Our Gold sponsors

Similar libraries

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

dj-stripe's Issues

Option to disable e-mail notifications

I'd like to handle e-mail notifications myself so it would be nice to have the option to disable the ones sent from dj-stripe.

The send_receipt stuff is quite inconsistent - perhaps this change needs to be part of a bigger review of this functionality.

Add better client-side validation for StripeSubscriptionSignupForm

For security reasons, we don't send any PCI data to the server. What this means is that if a user has a failure on the server side of registration, all of the credit card data is lost. Therefore, we need to improve client-side validation.

• email and username validation against the server
• password1 matches password2
• password is strong enough

Document how to check if a user has an active subscription

This should be very, very obvious in the documentation.

Need "in-process" animation for when AJAX is taking a while

Add status field to Invoice model

Tracking status by multiple booleans is not the right way to go.

Create unregistered user subscription helpers

Use case: User comes to site and as part of the registration form they have to put in their payment information

Single unit purchases

Change CurrentSubscription.status to rely on Choices

Checkout is broken

sync.py and djstripe_sync_customers management command

• Logic goes into sync.py
• Create management command

Internationalize all text strings

Add 'subscriptions' main page

Have things like:

• Choose subscription plan
• List available subscriptions

Improve navigation for dj-stripe

Need some sort of sub-navigation bar linking all the pages together. Place in a {% block %}

Review the rest_framework hooks

1. Where should utility hooks to third-party apps go? Probably not in the base repo. Perhaps a 'connectors' package?
2. Talk to @tomchristie and make sure I'm not doing anything silly with https://github.com/pydanny/dj-stripe/blob/master/djstripe/rest_framework/permissions.py

Use model_utils TimeStampedModel

Or something similar. I want both created and modified fields. Prefer that over 'created_at'

Admin level charts and reports

This would be incredibly useful.

Question about rationale for duplicating stripe data in our own schema

Originally from @coreyvelan

Why does django-stripe payments duplicate some stripe info (e.g. payments) in its own schema? Is this purely to make the site more responsive (since it wouldn't have to continually ask stripe for the info?) or is there another reason? Another reason would be that some features of the site would still work if stripe was down, but are there any other reasons?

Support decimal plans

Currently plans have to be in whole integers. But what if I want to charge $9.99/month?

Make sure Customer.has_active_subscription is in the right places

• Mixins
• Middleware

Middleware should except all of the djstripe urls

HOWTO Handle Migration from django-stripe-payments

A couple of the things to think about on handling migrations from django-stripe-payments is how?

If we make changes to models what is the best way to do migrations?

Or do we want to do a syncdb/migration then do a management command to move over all the data?

Plans: settings.py vs. models.py

@dmpayton said:

I wanted to raise the issue of having plans into settings.py vs. having a Plan model, and find out if hardcoding plans was an explicit design decision and why that decision was made.

Why? Well, on the app I'm building, users are able to create multiple sites and each site may be on a different pricing tier. In an ideal world, Stripe would support multiple subscriptions per user and these tiers would just be Stripe plans that the user is subscribed to for each site in my system. But Stripe doesnt, and their recommended workaround is a giant hack:

https://support.stripe.com/questions/can-customers-have-multiple-subscriptions

This removes a lot of the ease-of-use that Stripe is supposed to provide and forces you to add a bunch of extra code to make things work (i.e., prorating, the signal to calculate line items and send them off to Stripe).

If plans in django-stripe-payments managed were models, you could dynamically generate Stripe plans as needed (in my case, basic-2_pro-3 for users that have 2 sites on the Basic plan and 3 sites on the Pro plan). This would be a far simpler solution (with much less room for error) than to have to manually prorate and add line items to an invoice.

An added benefit is that plans could be more segmented (i.e., You could have a plan available only to a certain subset of users or groups) and those plans could be added without having to deploy the entire codebase.

Obviously this will require some discussion, but I would be absolutely willing to put in the work to make it happen if it's something you're open to.

JSON field exploration

• Is django-jsonfield the best choice?
• Can we allow for usage of PostgreSQL JSON field if the system detects the right module?

Trial plans

crispy-forms integration

This will make the development much, much easier.

Add support for RedisQ and Celery

The sync.sync_customer function is slow. It would be nice to provide these options:

1. Perform via management command (current)
2. Run when users do a Stripe action
3. Run via deferred RedisQ action
4. Run via deferred Celery action

In Django 1.6, CurrentSubscription.cancel_at_period_end must have a default

Per https://docs.djangoproject.com/en/1.6/ref/models/fields/#django.db.models.BooleanField

Django, by default, places a None in models.BooleanFields. This breaks because it violates a PostgreSQL constraint on the field.

The default needed is False

Provide both Bootstrap 2 and Bootstrap 3 based themes

Set via

DJSTRIPE_THEME = "bootstrap2"  # default

Cancel Subscription from Admin

If you cancel a subscription via a customer subscription field based on the model it doesn't update stripe. Need to add a mechanism for canceling in stripe when done in the back-end.

Consider another name for the index besides 'AccountView'

I've never, ever been a fan of the common Django development pattern way of using the term 'accounts'. The reason? Well, while it's really apt for a project like dj-stripe, it doesn't sit as well as it should because of prior-art in the Django community.

Prefix all settings with DJSTRIPE

Don't want no collisions with other apps.

Document Models

Add inline docs for document generation of all models, if there make sure they are updated.

django-admin2 integration

Display 'created' READONLY field in admin

Need it to help audit stuff.

"Cancel my subscription" does not cancel my subscription

Well, it's all in the title. Here is the flow:

• I click on the button "Cancel my subscription" (in the template cancel_subscription.html)
• I get redirected to the account page (account.html), where is displayed "Your subscription is active".
• And my messaging framework captures the info message "Your account status is now 'active'".

However, the cancellation does occur properly if I change in the code of djstripe.CancelSubscriptionView.form_valid:

current_subscription = customer.cancel_subscription(at_period_end=True)

To:

current_subscription = customer.cancel_subscription(at_period_end=False)

What do you think?
Are there supposed to be subscription configurations for which "at_period_end=True" does not incur a cancellation?

Thanks!
dollydagr

Evaluate removing context_processor

I don't like magically appearing values that are only needed for two views in templates across a site.

Improperly Configured Exception 'Module "djstripe.forms" does not define a "StripeSubscriptionSignupForm" class'

Hi,

After reviewing dj-stripe and django-stripe-payments docs, dj-stripe seemed more attractive! I am currently trying to integrate it into my project.

In the docs, I got to the "Subscription + Registration" step (http://dj-stripe.readthedocs.org/en/latest/usage.html) and followed the instructions (before that, everything went well -eventually- :-) ). The only difference is that I included djstripe as an app under my project (that comprises another app I am developing) so I can more easily do customizations.

Now, at the end of "Subscription + Registration" step, when I launch "http://127.0.0.1:8000/accounts/signup", I have an ImproperlyConfigured exception:

Exception Value: Module "djstripe.forms" does not define a "StripeSubscriptionSignupForm" class
Exception Location: /usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/allauth/account/forms.py in _base_signup_form_class, line 162

This seems to be triggered when adding to my settings.py

ACCOUNT_SIGNUP_FORM_CLASS = "djstripe.forms.StripeSubscriptionSignupForm"

I know that might not be enough information, but would you have an idea why this is happening?

Details about my environment:

• On Mac OS X 10.6.4
• Developing an app with Django 1.5, Python 2.7, Bootstrap 2.3.2, SQLite 3.6.12, jQuery, and using South for migrations.

Thanks!
Dolly

properly attribute the fork from django-stripe-payments

'Cause it's the right thing to do

Add South migrations

Tests on all the models!

This would be AWESOME.

SubscriptionPaymentRedirectMiddleware

Failure to have paid subscription redirects to the billing middleware.

Exceptions would be a list of URL names which will be evaluated against requests.

Write the views.CancelView

Change to use settings.AUTH_USER_MODEL in models.py ForeignKey to user.

What was I thinking?!?

Invoice status() should consider closed state

def status(self):
        if self.paid:
            return "Paid"
        return "Open"

but we also have closed, in some cases invoice.closed return True, but invoice.status() will return "Open"

Change card view

Upgrading and downgrading of subscriptions

Right now it just runs the form as-is. This probably ain't such a good thing.

Set Default Model Fields everything else allow null and blank

In many of the models there are fields that are not required, but they are not set to null=True, or blank=True.

As an example if you go to modify a subscription for a customer you have to set date fields for things you don't need to edit.

If I want to change a subscriptions length then I would have to set a trial date, and an end date, shouldn't need to do that.

Rebuild Index view layout (current AccountView)

Need a proper Dashboard with these options:

• Subscriptions
• Card management
• Payment History
• Show card

subscription_payment_required view decorator

For those using this with function based views.

Fully document installation process