#fallen-setupintent-confirm
1 messages ยท Page 1 of 1 (latest)
fallen-setupintent-confirm
i partally resolved this by using confirmSetup instead of confirmPayment. but it didnt seem to immediately bill the customer. i can only assume that's due to how the subscription was updated?
confirmSetup() will confirm a SetupIntent which is used to collect payment method details without any payment. If a payment happened, it's unrelated at least
so to collect a payment AND collect payment method details i'd have to use a payment_intent?
kind of. You seem to use Subscriptions. So you never create those yourself. We do this for you
yeah the subscription exists, what im doing in this case is 1. updating the existing subscription
then calling elements.fetchUpdates (a support member suggested this)
then i want to collect payment details and payment
yeah I don't really get why you'd do fetchUpdates() here. Sorry seems like you might be mixing up multiple separate things at this point
so this is the flow in question...
a users has a trial subscription with no payment methods
please pause
they go to this dialog after selecting a plan, https://p181.p1.n0.cdn.getcloudapp.com/items/eDunKv1W/e11d4fd0-8d89-4fc7-b161-63a583c07be0.jpg?v=03007a785a132ad5b6da4b1ad6fc667d
Can you try and send one message with all the information at once and a clear question?
sure
- user has trial subscription with no payment detals
- user selects a plan they want to "purchase" and go to this dialog https://p181.p1.n0.cdn.getcloudapp.com/items/YEuDwmyn/03cbdfbd-44d8-42e0-9625-866aa82aba1a.jpg?v=34eca1afdfb2cf34cd8cdfe3f1f1e4ff
- we collect billing and payment information
- AFTER that information is collected they still have the chance to modify their seats (units) or billing interval (monthly/annual)
- so we need to update the current subscription THEN update the intent for the elements so ti uses the right subscription info THEN collect payment if nessesary
#5 is the part im confused with atm
previously a support person said i should use a setup-intent then call elements.fetchUpdates after i update the subscription before calling confirmPayment but with a setupIntent obviously confirmPayment is unhappy
This flow can be really tricky and it depends on a lot of factors. That's why I asked for one clear message with your exact question(s). I still don't really grasp waht you're describing at all yet (which is normal).
What happens at step #2? Like how do you calculate how much you are going to bill them?
using the /invoice/upcoming endpoint
okay so you never update the Subscription synchronously to accept a payment or anything. You are just collecting card details for when their trial ends?
in this case yes i want to update the subscription, save their payment information, and charge them immediately
Then there's no reason to use a SetupIntent at all
you should ask them what Price they want to switch to, update the Subscription which would give you a real Invoice with a real PaymentIntent associated with it and then use that PaymentIntent to collect the payment
when i update the subscription the response i get back's current_invoice.payment_intent field is null
so it looks like it created pending invoice items instead of an invoice ๐
did you read our detailed docs on Subscription update, proration, etc.?
Also you said you're in the middle of a trial, so there'd be no proration at all either
Can you share some example code + an example Subscription id sub_123?
i think i have it, when i was updating a subscription this user was not on a trial in my dev env. but i also needed to set the prorationbehavior to always invoice when updating the subscription
sub_1MSR71KjI0M1O6BOjhHv9ncZ is the subscription in question
yeah if the customer is not on a trial period you need that. If they are on a trial, you need to pass trial_end: 'now' to explicitly end the trial period immediately
๐ would it cause issues if i send that key and they were not on a trial?
yep don't
that appears to have worked 
woot!
but a question, is there a single place i can look to get the payment method for a subscription? because when i update the subscription or get the current one it's latest_invoice.payment_settings.default_payment_method is null, it's also null on the customer but your admin ui finds it if i go to update the subscription...
so what im trying to do is when i go back to this dialog after they have payment information saved. is to not require them to enter them again in the stripeElements.
Usually you keep track of all of this yourself
The best option is to always set the right default payment method id on the Customer. That's what I'd do
and that would require on an update to 1 create the new payment method, then update the customer to set that field right?
No, you're collecting the PaymentMethod already as part of your payment in what we've been discussing in this thread
After that, you make it the default using https://stripe.com/docs/api/customers/update and passing invoice_settings[default_payment_method]: 'pm_123'
but when i do the confirmSetup call my subscription has no payment_method information
but you have a SetupIntent, the PaymentMethod gets attached, you already have all you need to do what I said above
right, it's attached but the subscription response i get back doesnt have that payment method id in it's payload anywhere to send for the customer update...
but you had the SetupIntent, so look at that
OOOOOOOHHHH the setupintent returns the payment method id... i see!
thank you so much! sorry my brain is smoother than polished marble sometimes.
okay. that's all i need. i'll get out of your hair. thank you so much for your help!
@grave socket all good. Mostly the thing my team dreams of is that there's an option somewhere to make the new PM the default always on the customer
yeah.... that is a dream of mine too
We have https://stripe.com/docs/api/subscriptions/object#subscription_object-payment_settings-save_default_payment_method but it's always on the Subscription itself. One day we'll be able to design the same for the Customer and you will never have to think about it
it's just super complex and full of edge cases ๐
yeah, but so worth it because a payment method being able to be in any 1 of what 6 places is a nightmare