null request in customer.subscription.deleted event

166 views
Skip to first unread message

Yoni Rabinovitch

unread,
Jan 10, 2017, 7:21:04 AM1/10/17
to Stripe API Discussion
The Stripe documentation states: "You can see that a subscription was canceled automatically–as opposed to by your request–if the customer.subscription.deleted event’s request property is null."

However, if the subscription had cancel_at_period_end set to "true", the customer.subscription.deleted event’s request property is null even if the subscription ends "naturally" at the end of the period, and not as a result of failed payment attempts.

Why is that, and is it possible to change this so that the "request" field could be used to reliably identify a customer.subscription.deleted event generated as a result of failed payment attempts? In the case that a subscription ended at the end of a period because cancel_at_period_end had been set to "true", why not store the id of the request that set cancel_at_period_end to true in the "request" field?

Alternatively, is it possible to provide some other mechanism by which it will be possible to reliably identify a customer.subscription.deleted event generated as a result of failed payment attempts?

Remi J.

unread,
Jan 10, 2017, 7:41:53 AM1/10/17
to api-d...@lists.stripe.com
Hey Yoni,

At the moment, there's no way to distinguish with the event whether a subscription was canceled automatically at the end of the period or if it was due to too many retries. In both cases, the event will have `source: null` as expected. This event is not triggered by a direct API request that your code would have just made so it would always have `source: null`.

As mentioned by a user in your StackOverflow question [1], the easiest solution really is to track this on your end. That way when the subscription is canceled you'd be able to confirm in your own database that you had marked it to cancel at the end of the period and then you could log this properly.

Otherwise, another solution is to rely on the latest invoice and it's associated latest failed payment. When you get the event, you'd find the latest invoice for that subscription. You'd then check whether this invoice has been paid successfully or not. If not, you'd look at the latest charge [2] to see when it was created and when it failed and whether there's another attempt [3] scheduled on the invoice. Based on this information, you can then decide whether the subscription was canceled automatically or due to that latest payment.

I definitely agree that it would be easier to have a field on the subscription that said whether it was canceled by your code or by our system and I'll make sure to share it with the engineering team.

Hope this helps!
Remi


--
You received this message because you are subscribed to the Google Groups "Stripe API Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss+unsubscribe@lists.stripe.com.
To post to this group, send email to api-d...@lists.stripe.com.
Visit this group at https://groups.google.com/a/lists.stripe.com/group/api-discuss/.

Yoni Rabinovitch

unread,
Jan 10, 2017, 9:00:05 AM1/10/17
to Stripe API Discussion
Thanks Remi!
I would also suggest to update the documentation on this point, since currently it is misleading.
To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss...@lists.stripe.com.
Reply all
Reply to author
Forward
0 new messages