#S60-Cosminacho-subscriptoins

1 messages · Page 1 of 1 (latest)

bleak plover
#

I believe it'll only trigger customer.subscription.updated if the subscription is also modified when you updated the schedule - so i you were updating the current phase that would probably trigger the event

oblique ginkgo
#

okkk

#

I have an issue then

#

Imagine the following 2 processes:

We are doing this for a product that can be sold in instalments of 3 or 6 months.

The customer comes and pays the first instalments.

  1. Watch new subscriptions created --> create Schedule subscription --> Modify the number of phases to 3.

We are looking for a way to measure automatically when he pays the second instalment. For this we have the following process:

  1. Watch Subscription Events (customer.subscription.updated)
#

what seems to be happening is that whenever process 1 starts, it also triggers process 2. (I am trying to understand, how I could atleast filter out the triggers that I don't need .

bleak plover
#

Ah, let me clarify - a subscription that is on a schedule will still trigger customer.subscription.updated events. So when the subscription renews (for the second installment), that will still trigger a customer.subscription.updated event. If you only want to know about the specific event you want - you can check the billing start + end dates to make sure that the event was triggered because the subscription renewed

#

Does that make sense?

oblique ginkgo
#

not really, what do you mean by: " you can check the billing start + end dates"

bleak plover
#

To be specific, if you only care about certain customer.subscription.updated events, you should check that only the attributes you care about were updated. So in this case, you only care that the subscription renewed - so you'd make sure that current_period_start and current_period_end were included in previous_attributes on the event

oblique ginkgo
#

maybe I am a bit slow, but I don't really get it. why would I care about current_period_start and current_period_end.

#

let me research them a bit

bleak plover
#

Those are the dates of the current period, so they'd only be changed once a Subscription is renewed - since you only care about when a new "installment" has occured, that's the same as a new period occurring on a Subscription.

oblique ginkgo
#

I see

bleak plover
#

Alternatively, you could check that a new invoice is being generated (since that will also coincide with when the subscription renews)

oblique ginkgo
#

let me look into this a bit.

#

evt_1LD9fmBUHziHdjOswktOMf6t

#

is it possible to tell me what was updated here?

bleak plover
#

Yes, you want to look in previous_attributes on the event - you can see that includes cancel_at and canceled_at, so those are the two things that got updated

oblique ginkgo
#

you guys have a very interesting way of dealing with subscription events

#

take this for example

#

evt_1LD9rgBUHziHdjOsjt2rU8P1

#

This is for a subscription that I just essentially created.

bleak plover
#

Well all subscriptions start off as incomplete, but because you were able to pay it, it immediately transitioned to active

bleak plover
#

I'm going to archive this thread, but if you have any other questions feel free to ask