#lil-nasty_best-practices
primal heathBOT
👋 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/1266413142750269552
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
hushed parcelBOT
umbral sand
Hi there 👋 you can use this endpoint to preview the next upcoming Invoice for a Customer:
https://docs.stripe.com/api/invoices/upcoming
When using that endpoint, you can use subscription parameter to ensure you're only previewing the upcoming Invoice for the Subscription you specify.
proper light
So there's no way to check the upcoming invoice price via expansion when fetching the user's current subscription, right?
I want to avoid the extra request to create a test invoice if possible, but it seems that it's not possible
umbral sand
Correct, the Subscription object cannot give you insight into the amount of the next Invoice before that Invoice is generated. The request I'm referring to doesn't create an Invoice, it only generates a preview of the Invoice.
primal heathBOT
proper light
What's the best way to attach a customers default payment method to a subscription when creating it? If I have the stripe customer, would I pass the default_payment_method field to the create subscription function with default_payment_method as customer.invoice_settings.default_payment_method?
Or is there a simpler way to have it just automatically attach the customer's default payment method?
silent halo
If you want to charge customer's default payment method then you shouldn't set default_payment_method parameter when you create the subscription. And make sure you're using collection_method: charge_automatically
That way Stripe will attempt to charge the default payment method the customer has saved under invoice settings
@queen mason please dont jump into other threads.
sorry about that
proper light
No worries!
Will these fields interfere with collection_method: charge_automatically?
silent halo
Yeah you don't need payment_settings field in this case
proper light
The thing is we're supporting trial subscriptions and standard subscriptions (charge immediately) so I worry removing payment_settings might break that?
silent halo
Ah okay.. I don't think it would interfere with the flow though.. You can try it out in test mode to be 100% certain
proper light
charge_automatically seems to be the default for collection_method... I dont' set it so I think that's prob not the cause behind the subscription not collecting
The subscription in the sandbox shows
But the payment shows
silent halo
can you share the subscription ID?
proper light
Ah, ok! So I need to ensure it is set as the default when it gets added, right?
silent halo
yup
proper light
When a user pays a subscription is there anyway to have the payment method used automatically attach to the customer as the default method?
Or at least to have it save the payment method on the customer? Our webhook handler will set any new pm as the default for a customer object
silent halo
If you set payment_settings.save_default_payment_method then it sets it as default on the subscription but I think the payment method does get attached to customer when the subscription is created.
proper light
Do you mean it gets attached to the customer when the subscription is paid?
Because created (at least in our case) happens before a payment method is ever created, at least in the non-trial flow
silent halo
Hang on, i think we're talking about multiple different flows of creating a subscription here..
Like the example you shared earlier for a customer, saved the payment method using a SetupIntent..
Now you're suggesting there's trial involved as well..
proper light
I'll clarify, hang tight while I type it all up
We have 2 flows
- No Trial Offered
- We create the customer object
- Then we create a subscription object and pass the client secret to the frontend
- The user enters payment details with the client secret, immediately initiates collection
- PM is attached to subscription, life carries on
- Trial Offered
- We create the customer
- We create a setup intent for the customer
- Customer enters payment details
- We save the payment details
- Our webhook handler sees a pm has been added and the user has a trialPriceId and initiates a subscription w/ a trial period using the trialPriceId and customerId
The trial offered flow is simple enough, I need to ensure the pm is set as default on the customer and when the trial ends the invoice will charge the default method successfully.
The no trial offered flow is where I want to ensure that the payment method used to pay the subscription (via client_secret) is attached to the customer
If it's attached to the customer then our webhook handler will make it the default, I just need to ensure it gets attached
silent halo
Gotcha.
No Trial Offered
- We create the customer object
- Then we create a subscription object and pass the client secret to the frontend
- The user enters payment details with the client secret, immediately initiates collection
- PM is attached to subscription, life carries on <-- I think at this point, PaymentMethod would also be attached to the customer too
Do you have an example subscription for the above? You can try retreiving the customer's attached payment methods to validate
proper light
Good thinking! I just validated and it does seem that it attaches it. If the webhook comes through this should work perfectly
Thank you! I'll test now and see how it does
silent halo
👍
proper light
That did it! Thanks for all the info! Very helpful 🙌