#mayank_sharma.

1 messages · Page 1 of 1 (latest)

lean rootBOT
#

Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

humble zodiac
#

You'd write in to support as my colleague mentioned

pine quest
#

No, I mentione I will get back with the detailed issue here itself...

humble zodiac
#

Then you can explain your issue without the PDF/files

#

If you want to share attachements, support is the way to go

pine quest
#

Ok sharing here only

#

Problem Statement: Let's take a scenario where in my platform I have two time intervals which is Monthly and Yearly under both of which we have the Free Plan and Classic Plan (paid). Let's say a customer signs up on our platform and subscribes to the Free Plan First. These are the set of Webhook events triggered by Stripe and sent to us (only the relevant ones are shared here):

#

customer.created
invoice.created
invoice.finalized
invoice.paid
customer.subscription.created

#

After this the customer is sucessfully subscribed to the free plan. Now the customer is trying to upgrade the paid plain. These are the series of webhook events that we got from Stripe for the same (only sharing the event names)

  • invoice.created
  • invoice.finalized
  • customer.subscription.updated (Event ID: evt_1O9nQuSEyw5Of2ovGfKmhH9H)
    • with the new cycle and status as active with the attribute pending_update as
  • invoice.has_changed
  • invoice.paid
  • customer.subscription.updated (with pending_updates as null, status as active)
    After this the customer is successfully subscribed to our paid plan.

Now comes, the scenario for recurriing renewal of subcriptions. These are the set of events recieved for the same:

  • invoice.upcoming (1 week before the renewal date)
  • customer.subscription.updated (with status as active, pending_updates as null)
    • When we process this event on our side, we are doing some actions like sending the user emails for succesful renewal as the status coming to us is active and there are no pending updates.
  • invoice.payment_failed
  • invoice.updated (with status as open)
  • invoice.finalized
  • customer.subscription.updated with the status as past_due.

This flow is causing problems in how we process renewals at our end. So our question is why are we getting the customer.subsctiption.updated event with status as active and pending_updates as null before processing the payent/invoice at Stripe's end? Shouldn't it be something like this:

  • invoice.upcoming
  • invoice.payment_failed
  • invoice.updated
  • customer.subscription.updated with status as past_due.
humble zodiac
#

So your integration can't rely on the order of events recieved

pine quest
#

No that's fine, but why are we getting customer.subscription.updated with status as active it should be past_due in the case where even the event ordering is not guaranteed right?

humble zodiac
#

No, we'll always send an initial customer.subscription.updated even at the start of a new billing cycle that reflects the new timestamps and triggers Invoice creation (status will remains the same value here). Only after that do we attempt payment of the invoice and related events that follow (i.e. failure/success)

pine quest
#

So then, how do we differentiate these kind of events?

humble zodiac
#

You could look at the previous_attributes hash in the payload, for example

lean rootBOT