#usamarashad_subscription-schedule-events

1 messages · Page 1 of 1 (latest)

knotty marshBOT
hollow islandBOT
#

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.

knotty marshBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1235988214360182874

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

silver snow
#

Hello

#

Can you provide the Subscription ID here so I can take a look?

tawny nacelle
#

sub_1PCOTHDVf1B7CjYu7D4MlOiE

#

yes sure

#

and this is the PI created by the first month.

#

pi_3PCOTJDVf1B7CjYu04T8pFF3

silver snow
#

Thanks looking

#

Looks like you canceled the Subscription

#

Which turned off Auto advance

#

So it never charged

tawny nacelle
#

yes i did, thinking that it did not work. I did not want to charge the customer. Should i have left the subscription active for longer?

#

I was expecting that the first invoice would be charged immediately.

silver snow
#

No there is a 1 hour delay until charge when using a Subscription Schedule: https://docs.stripe.com/billing/subscriptions/subscription-schedules#managing

Unlike when you create a subscription directly, the first invoice of a subscription schedule with collection_method set to charge_automatically behaves like a recurring invoice and isn’t immediately finalized at the time the schedule’s subscription is created. The invoice begins in a draft status and is finalized by Stripe about 1 hour after creation.

tawny nacelle
#

Noted. To get around this limitation , I am retrieivng the subscritions latest invoice using the expand option and finalizing that invoice using the API like so :

#

// Get the ID of the lastest invoice created. This will be the the one in a draft state.
let subData = subscriptionSchedule.subscription as Stripe.Subscription | null;
if (subData) {
// Get the latest invoice from the subscription object and finalize it
let latestInvoice = subData.latest_invoice;
if (!latestInvoice) {
console.log(📚 The first invoice of the subscription could not be finalized. );
} else {
await stripe.invoices.finalizeInvoice(latestInvoice.toString());
}
}

silver snow
tawny nacelle
#

So like this ?

#

// REmove this
await stripe.invoices.finalizeInvoice(latestInvoice.toString());
// Add this
await stripe.invoices.pay(latestInvoice.toString());

silver snow
#

Yep

tawny nacelle
#

Got ya.. Let me try it. May I ask another question here ? Or start a new thread ?

silver snow
#

Yep you can ask another here

tawny nacelle
#

I have 4 phases in my subscription schedule. When I create a subscription , i backdated it so it was 1 week into the last month. I noticed an additional amount added to the first invoice which was created on today's date. I am sure its due to proration being enabled. So I have set the proration behaviour for each phase like so :

#

// Create the subscription schedule with phases
let subscriptionSchedule = await stripe.subscriptionSchedules.create({
metadata: { reservationNumber: reservationNumber },
customer: customer.stripeID.toString(),
start_date: startDateUnix, // Get the current time stamp . No need to backdate
end_behavior: "release",

  default_settings: { collection_method: "charge_automatically" },
  expand: ["subscription"],
  phases: phases.map((phase, index) => ({
   ** proration_behavior: "none",**
    items: [
      {
        price: prices[index],
        quantity: phase.quantity,
      },
    ],
    iterations: 1,
  })),
});
#

Is this the correct way?

silver snow
#

Yes that looks fine

#

Best thing to do is test it out

tawny nacelle
#

Got it. Thanks bismarck.

silver snow
#

👍

tawny nacelle
#

So yes I can confirm that it worked. Thanks once again. Stripe seems to be sending a payment confirmation web hook once the payment succeeds. Any way I can ask stripe to not send me web hooks for subscription events ?

#

The problem is that I have webhooks listening for card payments via the stripe payment element. How do I differentiate between those and subscription payment events?

silver snow
#

Nope you can't prevent Events being sent if you are listening for that Event type. You just return a 200 in your handler and ignore them in this case. Or update your Webhook endpoint to not listen to that Event type if you don't care about it.

#

Ah

#

Yeah a couple ways to do that

#

You either add metadata

#

That is the most reliable way

#

So for your one-time payments you might set metadata: {one-time: true} or something

#

Then in the payment_intent.succeeded Event you check if that metadata is present

#

If so, handle the Event

#

If not, ignore it and just return a 200

tawny nacelle
#

ok I understand. Where do I add the meta data ? Like so :

#

let subscriptionSchedule = await stripe.subscriptionSchedules.create({
metadata: { reservationNumber: reservationNumber, isSubscription : "true" },

silver snow
#

Depends

tawny nacelle
#

how will that go down to the PIs ?

silver snow
#

Yeah that doesn't, which is why I said it depends.

tawny nacelle
#

i figured...

silver snow
#

Do you care about payment_intent.succeeded Events in your Subscription flow?

#

Mostly you don't need to -- you can just rely on customer.subscription.updated

tawny nacelle
#

no I dont. but I have stripe card element which is sending 'payment_intent.succeed.

silver snow
#

So instead, I'd set metadata on your one-time payment flows, meaning when you create your PaymentIntent for that flow you set the metadata (like I mentioned above) on the PaymentIntent on creation

tawny nacelle
#

ah ok.. so flip it around and do it.

#

got it .

silver snow
#

Yep

#

That is the easiest way to handle things here

tawny nacelle
#

noted.

knotty marshBOT