It would be nice if there were tests for the AJAX subscribe view and the regular subscribe view.

I m not sure if I have done something wrong in installation but I all get when I visit change/card/ is
Your subscription is .
Current Card
You do not currently have a card on file.
And the update button.
There is no form to enter my credit card info.
Any idea?

Hey guys! Looks like a pretty good library here. We'd like to use it, but there's no LICENSE file, therefore have to assume we can not use it. Can you please add one? Thanks!

As mentioned on #25, it has been discussed with @brosner, an alternative to shipping default templates or no templates at all. We need to figure out this solution and put it in place before calling this a 2.0 release.

We have a couple of projects in the works on Python 3. I will be taking a stab at making this work and will submit a PR today or tomorrow.

The charge data object contains a 'dispute' key, not a 'disputed' key as assumed at https://github.com/eldarion/django-stripe-payments/blob/master/payments/models.py#L411 so a KeyError is raised in record_charge.

My SaaS needs to allow the same customer to have multiple subscription (plans). It is a multi-tenant SaaS, and the user may want to have multiple tenants, and therefore multiple plans.The customer field is a OnetoOneField and that restricts a single customer to a single plan. Would changing it to a ForeignKey create problems?

How do you unsubscribe someone from a subscription? The customer has a subscribe method I was kind of thinking there would be an unsubscribe.

Do you just change the quantity to 0?

I advocate adding trial_period_days to the command init_plans.py. Without that, init_plans cannot create plans that have trial periods.

I'm trying to understand the meaning of the Customer has_active_subscription method and how it interacts with canceling a subscription.

Specifically in order for has_active_subscription to be True the CurrentSubscription object checks if self.status in ["trialing", "active", "canceled"]. Why does the "canceled" state still count as having an active subscription?

In my testing canceling a subscription results in a subscription with status "canceled" (as you might expect) but has_active_subscription will still return True.

There are two cases in the code that approach this problem slightly differently:

1. In the ActiveSubscriptionMiddleware class has_active_subscription is used to determine if the user has access to this site
2. In payments/subscribe.html subscription.status is specifically checked against the keyword active to determine if the user already has a subscription

Can anyone clarify the proper usage? I'll submit a pull request to the documentation once I understand the correct behavior.

I've setup an example site to use django-stripe-payments and I can't seem to get the url named "payments_subscribe" to work. When I select a plan and hit the subscribe button it redirects to the ajax view and displays a JSON response with an HTML form in the JSON.

I assume this is because I'm missing some javascript in my site_base.html template. I added the following but that doesn't seem to do the trick.

<script src="https://checkout.stripe.com/v2/checkout.js"></script>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.js"></script>

Any suggestions?

Show admins of the site when subscriptions are expected to expire with drill down of a list of status

These seem to be new

Howdy,

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.

For some reason the table CurrentSubscription is not showing up in admin view

Line 6 currently reads:
Your currently have the {{ request.user.customer.current_subscription.plan_display }} plan.

I've been working on trying to get django-stripe-payments setup so I can allow users to either subscribe to a monthly or yearly plan. I've merged in huxley's changes and added an example site for testing to my own dev branch.

I'm not clear on what the user flow is for a user to subscribe to a plan. I currently don't see anyway for a new user to subscribe to a plan, because their isn't a way for a user to add their credit card information. I would like to help make things more clear and get things working correctly but before I start hacking away it would be nice to collaborate on a plan so that my changes could get merged back in.

Here is my proposed flow for a user subscribing to a plan.

1. A new user registers on the website (i.e. creates an account)
2. The user goes to /payments/subscribe/ selects a plan and because they don't have a credit card on file the form shows fields for them to add their Credit Card information.
3. The user clicks subscribe
4. The user gets redirected to the success page

If that flow is acceptable I can get started on making this work. If anyone has recommendations on the best way to add in the CC form, please let me know.

If a stripe customer is deleted out of band (e.g., through the web interface), attempting to delete the corresponding payments.Customer object will throw an exception such as:

stripe.InvalidRequestError
InvalidRequestError: No such customer: cus_xxxxxxxxxxxxxx

There exists at least an undocumented requirement to use https://github.com/eldarion/bootstrap-ajax

It also appears from the documentation that site_base needs to have checkout.js included, but that isn't explained anywhere.

As it exists today, the views and templates provided in this library aren't functional -- at least not in django 1.4.5. If the library isn't currently ready for use, or certain parts aren't yet ready, it would be a good idea to put a note of that in the readme.

Finally, however you've got pypi wired up it is grabbing head by default, not 1.3 (though, as I look at it it doesn't look like 1.3 was production ready either)

I've been thinking about the init_customer and sync_customers management commands and have been wondering if it would be better to just create a stripe customer when it's needed. For example, when a user goes to subscribe you could wait until the subscribe ajax view to create the stripe customer if the current user didn't already have stripe customer id associated with their Django user account.

On the project I'm going to use Django-stripe-payments, we already have approximately 25K customers and I would prefer not creating stripe customers on all those customers because only a small fraction will be premium subscribers.

I'm happy to make a pull request if this sounds like a reasonable approach.

Instead of /change/card it becomes /a/change/card/ with the following output ( i have added bootstrap-ajax.js but doesnt help) :

{"html": "\n<div class="subscribe-form">\n\t

\n\t \n\t Your currently have the Calling VIP ($50/month) plan.\n\t \n\t

\n\t \n\t Current card on file is a Visa\n\t ending in the digits 4242.\n\t \n\t

Currently, the design of this is heavily influenced by using it mostly on subscription based sites where you define plans in a setting. Should take a pass through thinking about scenarios where you would want to just charge one-offs and don't care about recurrence.

Just wanting to confirm my reading of the code, but when a charge is made from a subscription renewing then an email is not sent? I can't find a spot where the signals call charge.send_receipt().

Are there any plans for more documentation? I have been reading through code off and on for the last few days, working on side project. There is a lot of good code, but it is highly opinionated so I am not sure how to use some of it because I don't understand some of those opinions. Granted I am still learning about stripe as well.

I feel like about the only thing I can re-use is the webhooks code, but other than that I am on my own. A couple of things that I have been trying to figure out:

1. Using stripe.js instead of Checkout
2. Re-using templates, I have been having a hard time trying to use the templates you provide. Is it best to just copy them out and re-implement?
3. On the opinionation what is the best practice eldarion sees for the urls? doing everything on the root or something else?

There is a lot of good work here, but I am spending time figuring out "how" to use it over being able to use it.

I also see you are about to do a version 2.0 release so maybe I just found it at the wrong time. lol.

There is a race condition that if a user cancels immediately after signing up for a site that has a free trial period and thus hasn't accepted a credit card yet, the Invoice Payment Succeeded webhook will fire for a $0 invoice, sometimes after the user has canceled and therefore when then code:

https://github.com/eldarion/django-stripe-payments/blob/master/payments/models.py#L508

Queries the subscription, it's None and thus this raises an exception.

This is a minor thing that shouldn't impact end users at all, however, it's a bug nonetheless that we should clean up.

Not an issue but would be cool to have. I feel would make this app even better.

A view to handle one-off charges and not necessarily subscriptions.

I added a customer for testing and on stripe it shows paid on Nov 25th. However on customer's payment history payment it doesnt show anything. Am I missing sth?

We currently have this implemented at the site level for a number of sites and there is a lot of commonality. Consider shipping with something basic to hit the 80% case that can either be extended or used as an example and replaced.

Line 9 should be:
{% if request.user.customer.current_subscription.plan and request.user.customer.card_kind %}

Currently, it is as shown below:
{% with request.user.customer.current_subscription as subscription %}
{% if subscription %}
{% if subscription.status == "active" %}

It might be worth noting in the installation docs that django-forms-bootstrap is required to be installed for the default templates to work. There are quite a few 3rd party apps that support as_bootstrap as a tag and not a filter that it took me a few times to figure it out. Also, the javascript + css files might not be as obvious to newer users and might be worth having in your installation docs too.

There are some good examples of this in some sites Eldarion has built that we should pull into DSP and open source and ship with the 2.0 version.

Summary by month for:

• transfers report
• charges report
• active customers by plan
• active subscriptions (total and by plan)
• cancellations (total and by plan)
• new subscriptions (total and by plan)
• churn (total and by plan / cancellation/total active subscription)

To enable deleting customer records from stripe dashboard

I've added docs in the README for the example site I created on how to setup webhooks, if you want to copy or borrow them for the DSP docs.

I don't think we can be so bold as to build a comprehensive test suite but for 2.0 release I want to cover some basic cases initially as well as have something in place to quickly add tests for bugs/regressions that happen going forward.

Is there any documentation on how to process a single payment using this plugin or is it purely for subscriptions?

You mention that this is a great plugin for one-off payments but there is literally no single piece of documentation for making a one-off payment with a variable amount. From a look at the code, I can only imagine that the "one-off" payment refers to paying a one-time "subscription".

I apologize in advance if I've missed something.

I couldn't find a mailing list for django-stripe-payments, so I apologize if this is an inappropriate place to ask a question.

I have a pretty simple question. 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?

Thanks,
Corey

I am using django-stripe-payments with django-social-auth + github. So I don't always get an email address captured. This causes and error, and the user to not get their email about subscribing even though it successfully charges them.

I am going to try and think of a solution, but until then thought I would bring this up.

One of my quick thoughts was if on error it just returns the invoice in plain text so they can print it themselves.

Did a pip install django-stripe-payments. It automatically installed django-jsonfield. But trying to do a syncdb failed. I installed jsonfield==0.9.4 and was able to syncdb and tables created successfully.

Update format here:
https://github.com/eldarion/django-stripe-payments/blob/master/payments/templates/payments/history.html#L21

Running manage.py sync_customers fails for customers with multiple invoice items with:

django.db.utils.IntegrityError: duplicate key value violates unique constraint "payments_invoiceitem_stripe_id_key"

Looking quickly at the code, the issue seems to be that the stripe_id (inherited from StripeObject) isn't always unique for an invoice item.

Suggest make a change like this to forms.py

from django import forms
from payments.settings import PLAN_CHOICES
sorted_plan_choices = sorted(PLAN_CHOICES)

class PlanForm(forms.Form):
# pylint: disable=R0924
plan = forms.ChoiceField(choices=sorted_plan_choices+ [("", "-------")])

Hi I made some progress with your code and now am stuck at /subscribe/ when user enters a card number I get
Stripe error: Object {code: "invalid_number"}
Stripe error: Object {code: "expired_card"}
Stripe error: Object {code: "invalid_cvc"}
Please help

I added {% load payments_tags %} to _change_card_form.html to see if that will help getting the form to show up.
Now I have a new error
'payments_tags' is not a valid tag library: ImportError raised loading payments.templatetags.payments_tags: cannot import name CardTokenForm
Please help.

Either supply a custom built form using stripe.js or convert over to shipping with Stripe Button by default.

as reported via a comment on #47 by @surfer26th

Should document PAYMENTS_TRIAL_PERIOD_FOR_USER_CALLBACK and how to use it in main settings.py