#fallen-setupintent-confirm

1 messages ยท Page 1 of 1 (latest)

silk swallowBOT
charred loom
#

fallen-setupintent-confirm

grave socket
#

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?

charred loom
#

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

grave socket
#

so to collect a payment AND collect payment method details i'd have to use a payment_intent?

charred loom
#

kind of. You seem to use Subscriptions. So you never create those yourself. We do this for you

grave socket
#

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

charred loom
#

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

grave socket
#

so this is the flow in question...

#

a users has a trial subscription with no payment methods

charred loom
#

please pause

charred loom
#

Can you try and send one message with all the information at once and a clear question?

grave socket
#

sure

#
  1. user has trial subscription with no payment detals
  2. 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
  3. we collect billing and payment information
  4. AFTER that information is collected they still have the chance to modify their seats (units) or billing interval (monthly/annual)
  5. 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

charred loom
#

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?

grave socket
#

using the /invoice/upcoming endpoint

charred loom
#

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?

grave socket
#

in this case yes i want to update the subscription, save their payment information, and charge them immediately

charred loom
#

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

grave socket
#

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 ๐Ÿ˜•

charred loom
#

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?

grave socket
#

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

charred loom
#

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

grave socket
#

๐Ÿ‘ would it cause issues if i send that key and they were not on a trial?

charred loom
#

yep don't

grave socket
#

that appears to have worked WOOO

charred loom
#

woot!

grave socket
#

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...

charred loom
#

Hard to say without a lot more details ๐Ÿ™‚

grave socket
#

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.

charred loom
#

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

grave socket
#

and that would require on an update to 1 create the new payment method, then update the customer to set that field right?

charred loom
#

No, you're collecting the PaymentMethod already as part of your payment in what we've been discussing in this thread

grave socket
#

but when i do the confirmSetup call my subscription has no payment_method information

charred loom
#

but you have a SetupIntent, the PaymentMethod gets attached, you already have all you need to do what I said above

grave socket
#

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...

charred loom
#

but you had the SetupIntent, so look at that

grave socket
#

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!

charred loom
#

@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

grave socket
#

yeah.... that is a dream of mine too

charred loom
#

it's just super complex and full of edge cases ๐Ÿ˜…

grave socket
#

yeah, but so worth it because a payment method being able to be in any 1 of what 6 places is a nightmare