Retrieve canceled subscriptions from API

[Michaël Gallego]

Hi,

I need to retrieve old subscriptions that were canceled. However it seems that once the subscription has been canceled, I cannot retrieve it from the API using the "getSubscription" method, even if I know the exact ID of the subscription.

Is there any way to achieve this?

Thanks!

[Michaël Gallego]

Similarily, I can't retrieve deleted customers using the get list method. However the doc indicates the opposite: "Unlike other objects, deleted customers can still be retrieved through the API"

Is there a bug here?

[Jim Danz]

No, this is not currently possible.

> --
> You received this message because you are subscribed to the Google Groups
> "Stripe API 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.

[Michaël Gallego]

Thanks. What about the customers issue? It seems to be wrong according to the doc :(. Currently the only workaround I’ve found is iterating through all the invoices and get the customers, but this is really cumbersome...

----------------------------------------

Michaël Gallego

Tel. : 06-98-82-62-38

mic.g...@gmail.com

[Jim Danz]

> Similarily, I can't retrieve deleted customers using the get list method.
> However the doc indicates the opposite: "Unlike other objects, deleted
> customers can still be retrieved through the API"
>
> Is there a bug here?

No. Deleted customers can be retrieved (when you have their ID).
However, they will not show up in list calls.

Additionally, when you do retrieve a deleted customer, you just see
their id and "deleted=true", you don't get the full object.

In general, there should be no reason to delete customers. We provide
it for completeness, but it is unlikely to serve a practical purpose.

[Jim Danz]

> Thanks. What about the customers issue? It seems to be wrong according to
> the doc :(. Currently the only workaround I've found is iterating through
> all the invoices and get the customers, but this is really cumbersome...

Oops -- looks like this email came in while I was working on other one.

In any case, definitely sorry if our abstractions are causing you
trouble here :(. I'd be happy to discuss further either on-list or
off-list (jim@) about what'd be the best way to get you what you need.

[Ilia Sretenskii]

Jim, but how does that match the support page about resuming a canceled subscription?

If the cancelation already went through (that is, your customer no longer has an active subscription), you'll still want to use the update subscription API call. Keep in mind that we'll immediately start your customer on the plan again since we're starting a new billing cycle, so this could result in a new charge.

By the way, I have already tested subscriptions listing a bit.
Once a subscription was canceled, it will not be displayed at customer subscriptions list.

[Ilia Sretenskii]

If anyone is interested please read what response was given by the technical support team.

Unfortunately, pausing/resuming a subscription is not something we *technically* support. All of the proposed solutions are workarounds, with the following caveats:

1) If you cancel a subscription WITHOUT `at_period_end`=true, it's gone and cannot be resumed.
2) If you cancel a subscription WITH `at_period_end`=true, you can resume it by POSTing to the endpoint before the end date.
3) If you cancel a subscription WITH `at_period_end`=true, and the period end comes and goes, it's gone and cannot be resumed.

[Michaël Gallego]

Hi again,

This issue is still causing me a lot of troubles and complications :(. Would it be possible for you to add a new parameter for the GetCustomers method to include deleted customers, like "include_deleted"? Actually, what I only need is really the id of the customer, so I don't really care if I don't have all the other info!

Thanks!

Le lundi 3 mars 2014 19:21:35 UTC+1, Michaël Gallego a écrit :

[Andy Cohen]

Have you looked into webhooks?  

If I understand the issue, then it seems that listening for subscriptions to be canceled/customers deleted, and then storing those resources for later analysis might be a good solution.

-Andy

--

[Michaël Gallego]

Hi,

I need to import data from existing accounts so webhook is too late! Of course, for upcoming events this work but not for everything older than 30 days.

Envoyé de mon iPhone

[Jim Danz]

Hi Michael,

We're not set up to support this right now, in the sense that it
wouldn't be just "flipping a switch" because subscriptions can also
change over time. We would like to find a way to expose information
about the history of subscriptions in a more principled way, but
unfortunately it's not just a drop-in right now.

I'm curious about your comment about really needing the id of the
customer. It sounds like what you're going for is perhaps some type
of reconciliation.
In terms of reviewing the past, what I can most recommend at this
juncture is to review the "invoice" history. Invoices know about 1)
which customer they are owned by, and 2) which subscription, if any,
they billed for. Hence they are the source of truth surrounding when
actual payments were made for subscriptions, by which customers, when.
Note that even a "free" ($0) subscription will generate invoices;
they will simply be marked as paid.

So, tl;dr, it is true that we don't have the best story around
subscription history, and I do apologize for that. But the invoices
are going to be the best *record* of what *happened* with customers
and subscriptions, and you can list invoices indefinitely reaching
into the past.

Jim

[Michaël Gallego]

Hi Jim,

I've realized long time ago that invoice is the only source of truth. There are two problems with this:

* It does not include one-off charges that may have been done with a deleted customer that have been deleted.

* If you want to import everything from Stripe, using invoices needs a LOT MORE time and harder processing. For instance, let's say that you have 20 000 customers, all of them having a weekly subscription for one year. Using invoices, you would need to iterate (20 000 * 4 * 12) = nearly 1 million lines, + the hassle of creating an identity map to make sure you don't duplicate customers, VS just retrieving those 20 000 customers directly from Stripe using the /customers endpoint.

The thing is that I really want a simple toggle switch. If Stripe returns me deleted customers with only the id, I can then retrieve all the charges and invoices made by this customer (because Stripe allows to retrieve charges and invoices from deleted customers using the id, from my experience).

What I'd like is:

GET /customers {"include_deleted": true}

returns something like:

{"object": "list", "data": [{"id": "cus_abc", "deleted": true}, {"id": "cus_def", ... all the fields if not deleted} ]}

That alone would help me a lot!

I hope it makes sense.

[Michaël Gallego]

Furthermore, that would make much more sense with your current documentation. You clearly say in the /subscriptions endpoint for instance that it only returns ACTIVE subscriptions, so I'm really not expected retrieving any sort of subscription history.

However, for customers, you CLEARLY indicates this: "Unlike other objects, deleted customers can still be retrieved through the API". Including them in your /customers endpoint may be a breaking change for people not expecting customers, but at least I'd expect some sort of switch to be able to retrieve them, as indicated in the doc!

Le mercredi 28 mai 2014 01:18:52 UTC+2, Jim Danz a écrit :

[Jim Danz]

A long time ago, we allowed users to specify their own customer ids.

A decision that we made at that time was to allow customer ids to be recycled. Ie, create customer foo, delete customer foo, now you can create a new customer foo.

We've long since deprecated the ability to specify your own customer ids, but the smell of this "id recycle" design decision unfortunately lives on.  If you could see deleted customers in list requests, then you could potentially see 2 or more different customers with the same id.

All that aside, I certainly realize that listing deleted customers could be useful.  So while we wouldn't be able to make the best guarantees in the world about it given the caveats explained above, the pros of the functionality may outweigh the cons of these caveats. I'll raise this with my team.

[Michaël Gallego]

Ha, didn’t know about this historical caveat. This means that I could potentially have two customers with id « cus_abc » and « cus_abc » ? Anyway, not sure that’s a big problem for me. I suppose that people that used to use this feature tried to reuse the same id if the customer is the same (otherwise that must have been very hard for them to follow their Stripe customers ^^).

Let me know about this feature, it would really be a life-saver for me =).

----------------------------------------

Michaël Gallego

Tel. : 06-98-82-62-38

mic.g...@gmail.com

[Jim Danz]

On Wednesday, May 28, 2014, Michaël Gallego <mic.g...@gmail.com> wrote:

Ha, didn’t know about this historical caveat. This means that I could potentially have two customers with id « cus_abc » and « cus_abc » ?

Yes. In general though I think that people who specified their own ids didn't follow our "cus_" id format.  We let people specify ids in any format, so sometimes people would just use numbers.  Anyway, that's just to say that if the customer ids that you're seeing look like ids generated by Stripe (in the cus_123abcdef45 format), they're most likely ids generated by Stripe.

 

Anyway, not sure that’s a big problem for me. I suppose that people that used to use this feature tried to reuse the same id if the customer is the same (otherwise that must have been very hard for them to follow their Stripe customers ^^).

Good point. I agree :).

 

Let me know about this feature, it would really be a life-saver for me =).

Will let you know as soon as we can!

--

[Michaël Gallego]

Still no news about the possibility to make deleted customers appear with the getCustomers endpoint? Did the team refuse the feature? :) It's still making my life a lot harder :/

[Michaël Gallego]

After a lot of tries, it appears deleted customers can be retrieved by passing the query parameter "deleted" to true when calling the "getCustomers" endpoint. Interestingly, you not only retrieve the identifier, but also the default card and some data about the customer. Is this a new feature I can rely on?

[Michaël Gallego]

Hi again Jim,

Sorry to ping you again about this particular topic, but this is pretty important to me and I'd like to have some "official" answer about what is going on :). As I said before in this thread, Stripe lacks capabilities for retrieving deleted things. I'm thinking about plans and customers, more importantly.

With customers, as I've said, I have found a hack through the "deleted" boolean for list. But the behaviour is so strange that I'm afraid of using it (currently, I have a very very defensive approach in my code, but it's still hacky):

1. Create a customer, let's say its id is cus_abc and attach a card, some metadata, ...

2. Delete it.

3. Get the customer through /customers/cus_abc: returns only the id and a "deleted" boolean whose value is true.

4. Retrieve the deleted customers using the non-supported endpoint /customers?deleted=true => it returns the customer, but instead of deleted attribute, it returns the last card used, the email, description, metadata... which is NICE (this information can prove to be useful, even for deleted customers).

Now, I've contacted support. They told me it was a feature used inside the dashboard, so I think I can "safely" use it, but really, the difference between the two endpoints bug me. Of course, the best way to solve this would be to have the "deleted" boolean in ALL customers, and return them all, so that this inconsistency is completely solved (actually, I thought that using the "include" parameter you use for total_count would be useful, like : /customers?include[]=deleted&include[]=total_count)

Thanks and, once again, sorry for spamming a bit about the deleted customers issue (side note : having a same for plans would be awesome too: /plans?include[]=deleted)

[Jim Danz]

Hi Michaël,

Undocumented or otherwise, we are loathe to remove features,
especially in a way that would propagate across all API versions. If
we were to consider removing the "deleted" parameter to GET
/v1/customers, we'd at the very least audit current users of it and
give appropriate notice.

That being said, the honest answer is that I had not personally been
aware of the existence of the deleted parameter to GET /v1/customers.
So, that was a gap in my own knowledge when addressing your question
initially -- apologies there.

With regard to plans, the ID caveats are much, much stronger. We
still allow user-specified plan IDs, and we still allow "recycling" of
plan IDs (delete plan with id foo, then create new plan with id foo).
And, anecdotally, I do think that we have plenty of people re-using
plan ids. So the semantics of listing deleted plans are arguably more
problematic.

Since you will always see plans that were used by querying customers
and/or invoices, do you have a bonafide need to list out the deleted
plans? We can consider it, but again, with the ID recycling issue, it
has so many caveats that I wonder if releasing it does more harm than
good...

Jim

[John Bambach]

We are using Stripe for credit card transactions and a year ago, Stripe had indiciated they hoped to be able to integrate checks similar to creidt card transactions.  I sent an email to support yesterday and Stripe responded they are not working on this capability.  DOES ANYONE HAVE SUGGETIONS WHO TO USE THAT WORKS IN A SIMILAR MANNER AS STRIPE?  We provide online registrations so we charge a fee and then have the balnce ACH'ed to client through stripe.  Thank you