#aaronactu_webhooks

1 messages · Page 1 of 1 (latest)

cursive nymphBOT
languid reefBOT
#

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.

cursive nymphBOT
#

👋 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/1215349148606267473

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

dusky sedge
#

Also, for test purposes can we force subscription ids when we use stripe trigger ? Couldn't find a way, even with overrides

languid reefBOT
wispy hemlock
#

Between those two events, you should be able to catch all of the cancellations. I will double check but I think updated only happens for the subscription "cancellations" for subscriptions that were never active in the first place, so that event may not be necessary depending on what you want to track.

#

Checking in to how override would work here

#

It looks like you can't use the override here. The CLI will always try to create a new subscription. You can't cancel an existing one with the trigger command

#

Though actually for that you can just make a delete call from the CLI

dusky sedge
#

yes I launch an undocumented trigger which is called subscription.payment_failed

wispy hemlock
dusky sedge
dusky sedge
# wispy hemlock Though actually for that you can just make a delete call from the CLI 
aaron ~ stripe trigger subscription.payment_failed
Setting up fixture for: payment_method
Running fixture for: payment_method
Setting up fixture for: customer
Running fixture for: customer
Setting up fixture for: attach_payment_method
Running fixture for: attach_payment_method
Setting up fixture for: default_payment_method
Running fixture for: default_payment_method
Setting up fixture for: product
Running fixture for: product
Setting up fixture for: price
Running fixture for: price
Setting up fixture for: subscription
Running fixture for: subscription
Setting up fixture for: invoice
Running fixture for: invoice
Trigger succeeded! Check dashboard for event details.
#

It does create everything needed to make it active, right ?

#

You are right, the sub is in the "Incomplet" status

#

I triggered subscription.payment_succeeded instead, and cancelled the subscription. Indeed, I do have the customer.subscription.deleted webhook received

#

👍

#

(after the subscription.payment_succeeded I notice the sub is active)

wispy hemlock
#

Awesome, I was just seeing in our docs we always refer to the incomplete -> incomplete_expired status change as an "update". Once the subscription, an automatic cancellation from something like missing payments should trigger a customer.subscription.deleted https://dashboard.stripe.com/settings/billing/automatic

dusky sedge
#

Oops, missed that part

#

RTFM @me

wispy hemlock
#

Yep yep, the two most common ways to create a subscription now give the subscription an initial status of incomplete which gives the customer up to 24 hours to complete their first payment, at which point it goes to active. If it isn't paid it goes to incomplete_expired.
This doc (TFM) explains a bunch about subscriptions if you haven't already read it https://docs.stripe.com/billing/subscriptions/overview

dusky sedge
#

What if we do not have any payment yet (based on usage) or there is just no payment method ?

#

My workflow :

  1. User register
  2. Creates a default project --> create and attach a subscription to it
  3. We ask the user to go in the billing section to add a payment method (or s.he's screwed, we block all actions :))

Do you think that if the user doesn't setup a payment method within de 24h, the automaticaly created subscription will expire ?

wispy hemlock
#

As in there is no payment upfront but you still want to collect a payment method? You should test this in test mode to confirm but I think we would move that subscription to an active state right away.

#

If that is the case, you can still enforce that requirement, but I'd need to think for a bit on how to best do that

dusky sedge
#

Yup, we do not have subscriptions fees. Indeed, the default subscription price is 0EUR, then if the user uses our solution it's get added to the subscription thanks to the usage api.

I am checking what's happening when the user adds a payment method

However, I don't really know what would happen if no payment method is added within 24h (then I guess the subscription will still be incomplete and might go to incomplete_expired?)

wispy hemlock
dusky sedge
#

On it

#

Wow, actually the subscription is active (even without any payment method setup on the customer account)

cursive nymphBOT
dusky sedge
#

maybe it is due to the policy I use when I create the subscription

#

nah, actually I don't do much :

    const sub = await StripeService.stripe.subscriptions.create({
      customer: billingInformations.customer_id,
      automatic_tax: { enabled: true },
      items: [
        { price: SubscriptionPrice.Server },
        { price: SubscriptionPrice.Storage },
      ],
    });
wispy hemlock
#

It is because there is no payment upfront. Your main ways to enforce the need for a saved payment method would be to either:

  1. Use a SetupIntent to collect the PM and only create the subscription after it has been confirmed
  2. Schedule your server to check if a PM has been saved and cancel the user's subscription otherwise
dusky sedge
#

Yup, looking into it 🙂

dusky sedge
#

Actually I just realized the current workflow isn't that bad but maybe not the better in terms of architectural patterns

true jewel
#

Hello! I'm taking over and catching up...

dusky sedge
#

Hey Rubeus 😉

Working on a diagram for documentation purposes, so you'll have a better overall 😉

true jewel
#

Sounds good, just let me know how I can help!

dusky sedge
#

(I am sorry I know it's super general, but I am genuinely interested into having an expert advice)

#

I'm sorry, there is a lil mistake in this one, just wait 🙂

true jewel
#

No worries!

dusky sedge
true jewel
#

Okay, looking at this. What quesitons do you have about this?

dusky sedge
#

Do you think this workflow is safe to use for production according to the stripe guidelines ?

Knowing that :

  • The subscription automatically turns 'active' as soon as it is created even without any PM setup on its stripe customer account because we only bill for what the user uses (no upfront payment)
  • We use the Usage API behind to update consumption, and therefore the subscription price (which may be different every cycle)

P.S. : Would be greatly interested in having some internal patterns/guidelines for this particular case 😉

true jewel
#

Yeah, I don't see anything that alarms me or anything in your flow. If your goal is to make sure their Subscription is active and they have a Payment Method on file before they can use your platform it looks like this should work.

dusky sedge
#

Thank you a lot Rubeus

Do you have any internal doc about this kind of integration ?

true jewel
dusky sedge
#

Have a good day 🙂

true jewel
#

You too!