Stripe Customers & Multiple Subscriptions Support

[Eric Brown]

Greetings,

We've been in communication with support over this issue, but it's quickly becoming a big problem for us.  So to the point where we're now working on building up code that will create multiple customers all so we can have each one in a different subscription.  We have different product offerings all with different billing cycles and we REALLY need the ability to have support for adding a single user to many subscriptions.

We've been told by support that this is something being worked on, but I was wondering if I could get a better idea on when this might be possible from here. :)

I also am a programmer so I understand how schedules, issues that crop up and can cause schedules to slip, so, I by no means intend on holding anyone to information provided, but I'd love even a ball park idea on when we might be able to expect this functionality to be supported by Stripe.

Thanks in advance for answering!
Eric

[Ankur Kalra]

We have the same problem, and speaking purely for my company, we'd be perfectly happy with just seeing where it fell in your prioritized backlog if you're uncomfortable mentioning calendar dates. You can even redact confidential projects if you like.

We too are considering building a bunch of hack-y machinery to support our subscription use-cases, and the absolute worst-case would be that we spend a bunch of time complicating the model with hacks everywhere.. only to have you announce a week later that you now have awesome first-class support for it.

It would help us prioritize if we could tell the difference between 'something you are actively thinking of doing very soon' vs 'something that sounds like a neat idea to do someday maybe'.

Ankur

--
You received this message because you are subscribed to the Google Groups "Stripe API Announcements and Discussion" group.
To post to this group, send email to api-d...@lists.stripe.com.
Visit this group at http://groups.google.com/a/lists.stripe.com/group/api-discuss/.

To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss...@lists.stripe.com.

[Amber Feng]

Hey Eric, Ankur,

Sorry about all the hassle around this! We know it's one of the top
not-great aspects of Stripe, and are working toward fixing it.

Without being too specific in terms of timelines (we generally really
don't like revealing these publicly because of engineering deadline
estimates, etc, etc), I can say that this is something that is being
worked on full-time right now, and is a reasonably high priority
project.

Amber

[Blaine Sanders]

Would you be able to postulate on whether or not this would be a backwards-compatible upgrade?

[Amber Feng]

Hey Blaine,

We definitely won't break anyone else using an older version of the
API when we release this, if that's what you mean.

The upgrade itself may not be backwards compatible. (:

Amber

[Eric Brown]

Thanks for the response.  We're currently working on implementing a very nasty solution - creating one customer account per subscription we need.  With one of our products this is going to get out of hand rather quickly...   We allow users to create advertising campaigns in our application... In order to add them to the recurring subscription we'll wind up creating one new customer record per campaign. :(

Hoping to see this feature released soon as this solution has hacktastic written all over it. :)

Along those lines one thing that would be really nice is for you guys to provide us with an arbitrary data field that we can use to return data to our systems.  In the example above we would store the new customer id with the campaign record and when you call our stripe web hook we'll use that identifier to figure out what campaign the transaction is referring to for further action.  What would be even better is if I could give you our campaign id and have you simply round trip that value back to me in the stripe handler json data.

Just food for thought that would add a rather nice degree of flexibility for how we make use of the data coming from your guys calling our web hook.

Thanks in advance,
Eric

[Amber Feng]

Hey Eric,

On Thu, Aug 22, 2013 at 1:16 PM, Eric Brown <csha...@gmail.com> wrote:
> Thanks for the response. We're currently working on implementing a very
> nasty solution - creating one customer account per subscription we need.
> With one of our products this is going to get out of hand rather quickly...
> We allow users to create advertising campaigns in our application... In
> order to add them to the recurring subscription we'll wind up creating one
> new customer record per campaign. :(
>
> Hoping to see this feature released soon as this solution has hacktastic
> written all over it. :)
>
> Along those lines one thing that would be really nice is for you guys to
> provide us with an arbitrary data field that we can use to return data to
> our systems. In the example above we would store the new customer id with
> the campaign record and when you call our stripe web hook we'll use that
> identifier to figure out what campaign the transaction is referring to for
> further action. What would be even better is if I could give you our
> campaign id and have you simply round trip that value back to me in the
> stripe handler json data.

Yep -- we're currently playing around with a couple of ways to do
this. No ETA yet, but it's definitely on our radar.

Amber

[Eric Brown]

Sweeeet!  This will make our lives a lot easier as well as any others using your awesome web hooks - Thank you!

Your quick replies are greatly appreciated,
Eric

[Alexey Panteleev]

If it's interesting to anyone we've implemented multiple subscriptions by encoding "primitive" planIds into ID of Stripe plans.

Lets say you have porductA and productB, lets call give them the "primitive" ids prodA & prodB.
Then depending on a user subscription we create the following plans in stripe:

prodA
prodB
prodA,prodB

and if #users is involved (un1,un2):

prodA:un1
prodB:un2
prodA:un1,prodB:un2
...

So any time a user subscribes to a new configuration of the primitive plans, potentially a new stripe plan is created with the ID that encodes the configuration: prodA:un1,prodB:un2,prodC:un3,... And when you retrieve such a Stripe plan you can always de-code it into those primitive plans:

prodA for un1 usrs
prodB for un2 users
prodC for un3 users

...

Cheers,
Alexey

[Eric Brown]

This is interesting..  Does this support different billing cycles?  For example if a user is in prodA and prodA uses, say a weekly billing cycle and is also in prodB, but prodB uses a monthly billing cycle, will this work?

Thanks for the added information Alexey!

Eric

[Alexey Panteleev]

Right now we use monthly and yearly cycles only so that info I also encode into the stripe-plan-id.

Monthly goes like this: prodA:un1,prodB:un2

and yearly like this: prodA:un1;prodB:un2;

The single product ids: prodA (monthly) and prodB; (yearly)

Switching from one billing cycle to another is switching from ,,, plan to ;;; plan

It's a hack and you end up with alot of plans in Stripe (one per specific configuration) but the approach has been working pretty well for us.

-Alexey

[Andrew Cohen]

Eric,

have you considered using the 'quantity' attribute of a customer's subscription? You mentioned that your users can have an arbitrary number of ad campaigns, that "sounds" just the kind of use case that works nicely with this functionality.   It's true that it doesn't take much to out grow the usefulness of the quantity attribute and I don't know what your other requirements are, but I thought Id mention it, as it often gets overlooked.

It's also true, that it is reasonably simple to manage a recurring cycle internally.  For those use cases that haven't a chance of lining up with one provided for by the Stripe API, you can always have stripe maintain a customer record with a credit card and no subscription.  Then just tell stripe explicitly when and how much to charge.  This method requires slightly more setup but, still gives you all the other niceties that come with Stripe.

One other technique that I find myself using more often than not, is to have stripe process a basic subscription for you.  Then just listen for Invoice.created hooks, to prompt you when it's time to iterate over your local representation of a customer and tack on LineItems for each of your customers various subscriptions or usage fees each month.  There is one gotcha to be prepared for with this approach.  That is that the first charge takes place immediately following creation of the base subscription object.  The solution is, that after you create your customer, but before you create her subscription, you walk through your process of tacking on appropriate line items.  Once that first Invoice is created it will pick up your line items instantly and then pay itself like it does.

I hope some of that was helpful.  Iv done my share of hair pulling in front of the ever evolving Stripe API, but I'll be damned if at the end of the day, there is a use case that it can't account for in some way.

-Andy

[Manu J]

I'm trying to do handle this case (a user can have multiple subscriptions with multiple billing cycles) by creating a customer record each for monthly and yearly subscriptions and using the quantity field. The biggest problem I'm facing right now is that I'm not able a attach a single card to both the customers. I'm using stripe-js and the token can be used only once. Is there a way around this?

[James Gillmore]

Is this done yet? It was being worked on full time and reasonably high priority 2 months ago. 

[Jim Danz]

On Sat, Oct 5, 2013 at 3:41 AM, Manu J <manu...@gmail.com> wrote:
> I'm trying to do handle this case (a user can have multiple subscriptions
> with multiple billing cycles) by creating a customer record each for monthly
> and yearly subscriptions and using the quantity field. The biggest problem
> I'm facing right now is that I'm not able a attach a single card to both the
> customers. I'm using stripe-js and the token can be used only once. Is there
> a way around this?

Hi Manu,

Unfortunately there is not a way around the fact that tokens can only
be used once. Of course, you could design a user-flow where when
somebody signs up for a second subscription, you ask for their credit
card details again. However, I understand that that is highly likely
to be quite suboptimal for you and I do apologize that we do not
support this better.

Another option would be use monthly subscriptions as the base, and use
Invoice Items to attach the payments for the yearly subscriptions.
Again, I realize that this is not an optimal solution, just a
workaround.

Jim

[Jim Danz]

On Tue, Oct 8, 2013 at 6:51 PM, James Gillmore <jamesg...@gmail.com> wrote:
> Is this done yet? It was being worked on full time and reasonably high
> priority 2 months ago.

Hi James,

Yes, it's very much fair for you to circle back on this given that we
called it high priority nearly 2 months ago. It remains high
priority, but I am still not able to give a date for when it will be
available. I am comfortable to say as a conservative estimate that it
will be available before the end of the calendar year (Dec 31), and we
will strive to hit a date target more aggressive than that, but I am
not able to give a more precise projection at this time.

Jim

[Manu J]

Hi Jim,

Just to be clear, neither tokens or saved cards are currently reusable i.e a saved card can be attached to only one customer.

 

When you are supporting multiple subscriptions, please try to ensure that we can use our saved cards. I can deal with non backwards compatible API, but getting customers to input their payment information again would be really painful.

I'm currently asking for the payment information again when somebody signs up for a subscription with a different

billing interval. 

 --

Manu

[Vladimir Andrijevik]

Hi Manu,

One way to avoid this, which has not been mentioned so far, is to use Stripe Connect’s Shared Customers (https://stripe.com/docs/connect/shared-customers) feature. It’s a bit more one-time work on your end, but you would avoid asking customers to enter their payment information twice.

The way this would work is:

1. You create a Stripe Application.

2. You have separate, different, Stripe accounts for monthly billing and yearly billing. Since Stripe accounts are free to create, this shouldn’t be a big deal, and since you already have one account you could just create one more.

3. You connect each of your Stripe accounts as users of your Stripe application.

4. You create Customers in the account which owns the Stripe application (as outlined on https://stripe.com/docs/connect/shared-customers), enabling you to create Customers in both the monthly and yearly billing accounts without entering payment information again.

Since your Customers are stored in the single Stripe account that you currently have, if you use that account to create a Stripe Application, the Customer ids you already have should be able to be used for creating Customers in the other account afterwards. Can someone from Stripe confirm that this is the case – that Customers in the Stripe account which owns a Stripe Application can be used as Shared Customers even if they were created before the Application existed?

I hope this helps – it is a bit more involved to set up, but should enable you to provide a better experience for your customers.

Cheers,

Vlad

[Jim Danz]

On Wed, Oct 9, 2013 at 5:10 AM, Manu J <manu...@gmail.com> wrote:
> Hi Jim,
>
> Just to be clear, neither tokens or saved cards are currently reusable i.e a
> saved card can be attached to only one customer.

Correct.

> When you are supporting multiple subscriptions, please try to ensure that we
> can use our saved cards. I can deal with non backwards compatible API, but
> getting customers to input their payment information again would be really
> painful.

Yes -- "multiple subscriptions" will be "multiple subscriptions per
Customer," so that you would not need to re-ask for payment info.

[Sat]

I didn't realize it thus far that we cannot have multiple subscriptions for a single customer. We are a startup working on a new product. When it came time to cancel subscriptions, the developers reported this problem. We have customers that sign up for different subscriptions at different times. We don't want to create PlanAPlanB or $1 techniques after knowing you are working on it actively. I'll add my vote as well to it so you know yet another small company is waiting for you to roll this out.

[Jason Venable]

Wow, I sort of took for granted it would be possible for a customer to have multiple subscriptions. 

We are in the process of deploying Stripe so add us to the list of companies that really needs this functionality.

On Tuesday, August 20, 2013 9:56:57 AM UTC-7, Eric Brown wrote:

[Shyam Habarakada]

Agree that this is one of the biggest (and few) shortcomings stripe has.

All that ability to create new subscriptions via the API is kind of lost without the ability for a single customer to have multiple subscriptions.

shyam habarakada  |  www.10000ft.com  |  www.twitter.com/10Kft

--

[John Obelenus]

I must admit that I've been enjoying the ability for a customer in my system to have multiple customers in Stripe (since email is not a unique field). Could this potentially be a workaround for you? Instead of storing a customer key from stripe for each customer in your system, you create a subscription each time you need to, and when you do that you also create a new customer.

I guess the viability of this approach matters with how much you are using the stripe dashboard/manage tools in your process.

[Sat]

Based on this thread, the fix is being worked on right now. Although we thought about this approach of multiple Stripe customers records for each of our customer record, we decided against it because it would cause headaches once the fix is out. For example, how would you then leverage the fix that allows multiple subscriptions for all of your existing base? You will have a migration problem on your hands unless Stripe provides for one. You will be troubled with maintaining this "old" baggage for a long time. We hate the idea of calling our customers and asking for data re-entry. The other approach would be to leverage the new fix for new customers and have the old data lying around. Then we have to support two ways of doing things. All of this nonsense is avoidable if only Stripe can get this fix out as fast as possible.

[Jason Venable]

For those of us that have/will adopt the multiple stripe customers for "1" true customer it would be nice if there was a way to merge Stripe accounts once this multiple subscriptions piece is delivered. I would say this is low priority, way lower than just delivering multiple subscriptions first, but for those of us that have/will create 'duplicate' stripe customers it would help us clean up our data once this feature is released.

I can totally see merge functionality introducing compliance issues with moving cards between accounts so this would be very low priority and not a requirement for deliver multiple subscriptions.

On Tuesday, August 20, 2013 9:56:57 AM UTC-7, Eric Brown wrote:

[Manu J]

How are you adding a card to each new customer? You are asking for payment details again?

[Jason Venable]

Another option I haven't seen much mentioned here is simply to handle your own recurring billing cycles. This will vary in complexity depending on the platform you are building upon but this is the route we decided to take. We decided to have nightly cron job that will run through all of our internal subscriptions and charge customers/cards as necessary. We also don't use any of Stripes pricing logic so that helps us be able to do this. 

[Shyam Habarakada]

Not ideal if you want to support basic scenarios like prorated upgrades, downgrades or cancellations. Now you're building all that which already exist in stripe.

--

[Jason Venable]

Agreed, it won't work for everyone. Our pricing model was too complex for Stripe to handle so we had to do it all in house anyway. Just another option, not the best or worst.

[Anuraj Ennai]

I am also veering towards rolling my own billing code and using stripe to store customer cards and charging. Our billing model too requires customers to have multiple plans with different trial periods and billing cycles. Tried accommodating the same with a stripe 1 cent plan with multiple quantity - and it became too complex to handle. For single plan customers, Stripe i/f really works well.

regards
Anuraj

[Michael Dobbins]

We are working on integration of the Stripe API for an application, for which we hope to set up multiple subscriptions per shared customer. We have even tentatively decided to forgo the implementation of some of the features in hopes that there will be a release addressing the multiple subscriptions before the 2013 year end. I know there is no official date yet when we can expect this functionality, but I have seen some unofficial ETAs like 'at least by Dec 31 2013'. I do really like Stripe for the most part so far, and haven't found a whole lot of limitations that can't be worked around other than that. I was contemplating creating multiple customer records per user in my app to handle the multiple subscriptions, but if there is going to be a fix before the year's end, I think it might save a lot of headaches if we postpone development of multiple subscriptions in our app, rather than introduce the kludge of multiple customer recs per user, and then have to deal with the fallout of trying to merge these multiple customer records later when the api supports multiple subscriptions. I also think it would lead to a better overall customer experience if we could natively subscribe customers to multiple plans without any of the hacks I have seen mentioned in the past.

There is one thing which I have not seen anyone ask about in the forums yet, and that is, how would the coupons/discounts be handled when there are multiple plans (subscriptions) per customer? That is one of the things I found a little odd in the beginning when working with the Stripe API documentation; discounts/coupons are applied to a customer, not a subscription. What would be ideal is if the discounts could be applied when creating/updating a subscription (adding or modifying a subscription to a customer). That way if we have a customer who subscribes to a plan for monthly community membership to our app AND the customer subscribes to another monthly service plan (which may or may not be paid to a 3rd party using Stripe Connect access_tokens, i.e. 'shared customers'), then the discount would only apply to the subscriptions we specify, and not be applied to EVERY plan to which the customer is subscribed.

Does anyone have any insight into how coupons and discounts might work when the new multiple-subscriptions-per-customer updates are released? If I understand correctly, currently discounts are only applied to recurring subscriptions, and NOT to one-off 'charge' transactions. I want to be sure that they won't get applied to every subscription automatically, as this could be a real deal killer for us.

I would also love to see some better examples of handling customer subscriptions with shared customers and Stripe Connect. I am having some trouble getting subscriptions of shared customers to work when subscribing to a 3rd party plan.

[Jim Danz]

Hi Michael,

The fact that discounts currently apply to customers rather than
subscriptions is a known issue that will absolutely be addressed as
part of multiple subscriptions.

We may or may not continue to support discounts being applied to
customers. We will certainly need to support that for backwards
compatibility, and I suspect that some merchants may find
customer-based discounts to continue to be idiomatic, even in the face
of multiple subscriptions (eg, "Foo has a 10% off for life discount,
regardless of what subscription(s) he is on").

But, we know that we need coupons/discounts to be able to be applied
to particular subscriptions, as part of a feature-complete multiple
subscriptions offering.

Regarding your second point about shared customers and subscriptions,
I'm not aware of better examples that we have to share at the present.
However, if you're having any issues with your implementation, we'd
be happy to chat with you about it and possibly look at code snippets.
If the public forum isn't the best place for that, feel free to reach
out to sup...@stripe.com.

Cheers,
Jim

[Sat]

Just checking back to see what the status of this issue is. We are nearing the year end which was about the time when Stripe folks said they might be able to release this API. Are we anywhere close?

[Amber Feng]

Hey Satish,

A private beta is currently in the works -- can you (and anyone
else who is interested) email sup...@stripe.com so we can put
you on the notification list? (:

Amber

> --
> You received this message because you are subscribed to the Google Groups

> "Stripe API Discussion" group.

[Jim Danz]

Hi all,

It's been communicated on a few channels at this point, but I wanted
to circle back on this thread in particular: we have (finally!)
launched public support for multiple subscriptions per customer.

https://stripe.com/blog/multiple-subscriptions
https://support.stripe.com/questions/whats-new-with-multiple-subscriptions-per-customer-january-2014

Cheers,
Jim