#inexorable-invoice-paid
wheat quarry
aahhhhh yes.. it seems it is ... that would explain it - free trial. However .....
ok - I've misunderstood something then... I am listening for the invoice.paid webhook event and checking the billing_reason == subscription_create in order to grab the payment intent (from the first invoice) and attach it to the subscription (as per docs)
buuut I didn't see anything in the docs about "but not if it's a free trial or zero value invoice"
makes perfect sense - but I need re-orientating I think ... how would I then do the said "get payment_intent from the first invoice" when it will never have a payment intent 🤔 ... hehe ... got myself in a pickle here
vague pecan
Yeah so you won't need to grab the payment_intent in this case. You will want to set the PaymentMethod that is attached to the customer as the default PaymentMethod for the Subscription (or for the Customer).
wheat quarry
It would be really good to have one consistent reliable way to do this whether the subscription has a trial or not ... is it sensible/normal to always get the paymentmethod from the customer instead of the payment_intent method in the docs?
or is there a good reason to seek out the payment_intent if there was no trial and the paymentmethod if there was ... am I making sense?
vague pecan
The docs that you are looking at do not involve using a trial so they are the canonical way to do that when there is no trial. However, with a trial the initial invoice does not have a PaymentIntent and is automatically paid. So you basically just need to set up the Customer/Subscription for renewals (future invoices).
wheat quarry
I think I'm with you - and thanks for your patience - I'm just wondering if it's safe to always do it that way (the trial way) so I can simplify the webhook code
🤔 the event doesn't have a payment method associated to the customer - or a source or invoice settings. I feel like i've misunderstood something about payment links.
vague pecan
Sorry, missed your last comment!
Okay so let's back up.
You are trying to use Payment Links to start a trial Subscription?
wheat quarry
I'm mid way through testing a subscription integration (not using payment links) and just thought "what happens if my client issues a payment link to someone" ... so I made one, did a test purchase and my webhook handler exploded because it's expecting the payment_intent. So, it was worth the test - but now I realise my webhook handler will explode even without payment links (normal checkout.session) if the subscription has a free trial. I can stop them issuing payment links 🙂 ... but not free trials
but while I'm here it would be good to understand how I would do it if it was a payment link with a free trial
to recap, my event has no payment_intent, the associated customer has no default_source or invoice_settings
vague pecan
Got it, thanks for the details!
For Subscriptions with a free trial you need to collect the PaymentMethod up front, or bring the customer back on-session to collect a payment method when the Subscription renews.
Payment Links aren't really built to handle this end-to-end as they don't currently force the collection of a payment method.
wheat quarry
the payment link took a payment method
vague pecan
Can you share your Subscription ID that was created?
wheat quarry
lol - I'm sure of it ... or at least I was.
yeah of course ...
evt_1KdGQ0K2FI13bfKBIZ5BGIQN
sub_1KdGPxK2FI13bfKBpGR6YzWZ
cus_LJuExhC719bEph
I used the 4242424242424242 test card
keen quarry
👋 I'm hopping in since @vague pecan needs to head out soon - give me a minute to catch up
wheat quarry
Hi Karbi - thank you
Let's simplify things and forget payment links - that's just how I fell into the rabbit hole. My problem is how to get hold of the payent method to associate to the subscription (on first zero invoice) when the subscription has a free trial
I'm currently listening for invoice.paid and checking if the billing_method == subscription_create and then looking for the payment_intent - but of course there isn't one because it's a zero invoce for the trial
🤦♂️ 🤦♂️ 🤦♂️
Is it possible that your system automagically sets the subscription default payment method if it has a free trial - but not if it doesn't?
keen quarry
I don't believe we automatically set the subscription's default payment method if it has a free trial - where are you seeing that?
wheat quarry
lol - yeah me too - but I think I just confirmed it does. Follow me here. I turned off the CLI webhook listener and closed my development solution. My webhook for sure is offline. I then used a payment link to sign up for a subscription. Used the CLI to get the subscription .... aaaaaand ...
sub_1KdHfxK2FI13bfKBZp2ey5H1
the subscription has a default payment method.
sooooo .... yeah .. fixed? hmmmm...
keen quarry
Ahhh you're referring to the subscription having a default payment method (I thought you were referring to the customer)
I believe with Checkout and Payment Links, it's expected behavior that the subscription default will be set when you go through the checkout process
wheat quarry
Do you know if that should always be true - or just if the subscription has a free trial?
keen quarry
It should always be true
wheat quarry
ok - I really appreciate your time Karbi - thank you.
I followed the docs that said we should catch the invoice.paid event, check for billing_reason of subscription_create and then set the subscription default payment method - now I'm confused if it's already set all the time.
I wonder if I was actually following old Stripe Github samples 🤔
keen quarry
That flow is specifically if you're using Stripe elements to collect payment details
wheat quarry
I suppose my safest bet is to start again and test it all and see what happens. Thanks again for your time - I'll come back here if I find anything too conflicting.
elements .... have I mixed up flows? hmmm.... lol - good lead 👍
keen quarry
Are you just using Checkout/Payment Links, or are you also using Elements?
wheat quarry
I'm trying to do it all too quickly is what I'm doing. I am using a checkout session to start the subscriptions using that flow of processing the checkout.session.complete but it explodes when the subscription has a trial because there's no payment_intent to grab (the payment links was just a test that made me realise the trial problem)
sorry... let me clarify.... using a checkout session to start the subscription with (sometimes with a trial) .... then catching the invoice.paid event using the above flow of trying to set the defalt payment method
so no, I'm not using elements
keen quarry
Gotcha - so since you're not using Elements, you don't need to set the default payment method on the subscription at all since Checkout will do that for you. You'll only need to set a default if you want to also set it for the customer (by updating the customer and setting invoice_settings.default_payment_method)
If you're following a guide, make sure to follow one specifically for checkout like this (https://stripe.com/docs/billing/subscriptions/build-subscriptions?ui=checkout)
wheat quarry
I've found my source
I've been completely submerged in Stripe docs for 6 days straight and I think I've wandered off down a GitHub rabbit hole that maybe you didn't intend me to go down
most of my build has come from the main docs but I think some of the GitHub code has taken up space in my brain pretending to be from the docs.
keen quarry
Yeah, that sample integration you've found is meant to be used with Elements, and isn't written with Trial support in mind
wheat quarry
Thank you karbi - I will step through my code and make sure everything is as it should be. I really appreciate your time and attention 👍
I posted this earlier .... I hope some of you ssee it - thank you
sooo now I'm back on track that has actually made my integration - and life - even easier - you lot are just my heroes!
keen quarry
thank you for saying all that! and I hope the rest of your integration goes smoothly!