#oliviakristiansen-paymentelement-subs
final kilnBOT
Hello! We'll be with you shortly. 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.
- oliviakristiansen, 3 hours ago, 13 messages
- oliviakristiansen-deferred-intent-subscription-start-discounted-to-free, 5 days ago, 49 messages
pseudo dragon
here is a request ID req_GVYzX7r7aIfmIb
What I am specifically trying to do is do a downgrade of a subscription, but we create a secondary "trialing" subscription that hangs out until the end of the billing period for the current "active" subscription. Thus, the amount is 0, so I was under the impression doing a SetupIntent for $0 purchases is what I need to do
do I need to do a SetupIntent if the customer already has a payment method attached? or if a subscription already has a payemnt method attached?
magic torrent
Hi 👋 that error happens when using our deferred intents flow, if you use mismatched approaches for determining what payment method types should be offered to the customer.
Right now it sounds like you used dynamic payment methods (previously automatic payment methods) when initializing your frontend, but then created the Setup Intent in your backend explicitly passing payment_method_types instead.
You'll need to adjust your flow so that your frontend and backend use the same approach.
Are you using the approach shown here to initialize Elements in your frontend?
https://stripe.com/docs/js/elements_object/create_without_intent
pseudo dragon
those are the options I'm sending
is it because I'm sending the setupFutureUsage?
magic torrent
Offhand I don't think so, but I'm taking a closer look because the error message doesn't seem to line up with the way you created the intent.
pseudo dragon
tried it without, didn't make a difference
magic torrent
Can you share the ID of a request from where you removed it? I was starting to think that may be the cause here, but if removing it doesn't resolve the error I'll keep looking 😅
pseudo dragon
I think this one req_lrsvvFZitRiZv0 but I can do it again to be sure lol
k this one definitely req_eQwbGkhTUEClcw
the status of the setup intent is "requires_payment_method" does that sound right?
maybe you have a better idea of what I can do in this case. I basically just want to save the payment method to the subscription for a $0 purchase, so when the secondary trialing sub rolls into "active", it charges
I wish you could send a token and save it to the user like you can with the card element saving to default_source
pseudo dragon
hanzo! you help me a lot lol
sour kettle
busy*
NP! 🙂 it seems like there's a bit more context here.
Can you give me a quick summary of the issue while I catch up?
pseudo dragon
yup!
so basically, I am updating from card element to payment element. I am working to get our downgrades to work as well (I have initial purchase and upgrades working), but we don't prorate downgrades - we create a secondary "trialing" subscription that hangs out until the "active" sub is done and the secondary sub can roll into "active." Because of this, when a user downgrades, they make a $0 purchase. But I still want to save the payment method they input in this case, so I was told to create a SetupIntent for the next non-0 payment. I have followed docs, but I'm getting this error "Payment details were collected through Stripe Elements using automatic payment methods and cannot be confirmed with a Setup Intent configured with payment_method_types." when trying to confirm the setup (I have screenshots above of my code)
initially Toby said the backend and frontend were misaligned, but then said the error doesn't match with how I've done the setupIntent, so I'm not sure whats up
sour kettle
Gotcha. taking a step back, if the customer has a payment method attached/default payment method then you don't really need to collect a new payment method right?
In that case, you can just create a new subscription with trial
pseudo dragon
yes that is true, but we definitely have scenarios that people don't have a payment method on file (i.e. they purchased only with subscription credit and no payment method inputted)
so if they want to change their sub and add a payment method and its $0, we need to save the payment method
sour kettle
Gotcha. So technically in this case, you're not using the defer intent approach since the SetupIntent already exists by that time (once you create a sub with trial, it generates a SetupIntent by default)
So you don't really need to specify mode or setupFutureUsage client-side
You can just use the SetupIntent client-secret to render elements and collect the PaymentMethod information
https://stripe.com/docs/payments/save-and-reuse?platform=web&ui=elements#collect-payment-details
You'd find that SetupIntent on subscription.pending_setup_intent parameter
pseudo dragon
okay so for $0 purchases, I can just do that client side to save the PaymentMethod info
sour kettle
Yes because when you call /v1/subscriptions API to create a sub with trial, it creates a SetupIntent automatically
pseudo dragon
what about saving payment method info for users purchasing with subscription credit that covers the whole cost and they input a payment method? That won't be a trialing sub
sour kettle
when you say "subscription credit", are you referring to customer credit balance?
sour kettle
All good, even then the $0 invoice gets generated in which case there should be a pending_setup_intent
pseudo dragon
okay sweet, so I don't need to create the setupIntent on the backend
sour kettle
Correct, you don't need to create it separately. Subscriptions API will do it for you.
sour kettle
NP! 🙂 I'd recommend giving it a go in test mode to be 100% certain of the expected behavior
pseudo dragon
oh yeah I'm just updating on my local env and trying to get our crazy subscription code to work lol
sour kettle
👍
Coming back to the error, the reason you are likely seeing the error is because automatic_payment_methods on SetupIntents defaults to true only on latest API version. The API version you're on is older, so you'd need to specify the above explicitly.
https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web&type=setup#create-intent
pseudo dragon
ah okay got it. thanks!
well I'm retrieving the SetupIntent attached to the subscription instead of manually creating it and am passing the client secret back to the front end, but i'm still getting the same error. The only thing I'm doing differently (from the doc you shared for setting up future payments) is not creating the client secret first, but relying on it after the subscription is updated, but I would assume that shouldn't matter
do I need to set the automatic_payment_methods on the subscription? not sure if that is possible
sour kettle
So it does somewhat matter with mode | setupFutureUsage parameters
can you comment those out?
sour kettle
no you don't need mode since you already have a SetupIntent
mode is used when you want to collect payment method before creating any sort of intents
pseudo dragon
ahh okay, trying now
oh, but its saying if I don't pass in mode, I have to pass in the client secret, but I don't have that yet
sour kettle
you do, though
Ah you need to expand subscription.pending_setup_intent for the SetupIntent client secret
and use that
pseudo dragon
I don't have the subscription object until after the payment element is mounted and they click 'submit'
then I create the subscription with the selected level
sour kettle
Oh.. I think I'm confused.
Can you describe the flow from API/code perspective?
Customer wants to create a sub -> do you call subscriptions API first or do you collect the PaymentMethod info first?
pseudo dragon
we collect the PaymentMethod info, then they click submit where I create/update the subscription, and I am trying to confirm the setup here upon success of the subscription change, but thats where its failing for me. Then in the webhook (assuming I get this figured out eventually), I attach the payment method used on the subscription to the customer
so if you have a better way of just saving the payment method for $0 purchases, let me know. I don't think we want to create the subscription first before the user actively purchases anything
I was trying to follow this doc https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web&type=setup#create-intent
final kilnBOT
sour kettle
Okay so there are two separate flows here right?
if the customer already has an attached payment method, you create subscriptions server-side with a trial
if the customer doesn't have an attached payment method,
1/ you would collect payment method details client-side using mode: subscription
2/ once payment method has been tokenized, you'd create a subscription using this flow instead
https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web&type=subscription
pseudo dragon
yeah, I mean, thats what I feel like I'm doing. Its just $0 purchases that aren't working
or more precisely, I don't know how to handle
sour kettle
The error you're seeing is on a SetupIntent confirmation (a SetupIntent you're creating by calling the API separately)
you don't need to use mode: setup anywhere
pseudo dragon
right, but I don't have a client secret at the point of doing stripe.elements(options)
because I'm updating the subscription after the element is mounted
sterile briar
👋 Hopping in here - give me a minute to catch up
pseudo dragon
oof, good luck
sterile briar
oliviakristiansen-paymentelement-subs
You create the SetupIntent after after collecting the payment details, right?
pseudo dragon
well, I was doing that manually, but hanzo told me the subscription does it automatically, so I am no longer doing SetupIntent.create in the ruby, I'm just getting the client secret from the SetupIntent attached to the subscription
but I'm creating the subscription after collecting paymnet details, so the answer is "yes" I think
sterile briar
Yeah, so I think the main change you'd need to make client-side is instead of doing mode:setup you can do mode:subscription
pseudo dragon
even for $0 purchases?
thats the key
I have it working for non-0 purchases
its if the user isn't paying anything. I was told that doing a SetupIntent is what I want because when doing mode: 'subscription' the amount cannot be 0
is that wrong?
sterile briar
Yes, even for non-0 purchases - if it's for a Subscription then you want mode: subscription
pseudo dragon
oh
huh maybe I misunderstood someone in here the other day. I just wanted to save payment method for $0 purchases and was lead to SetupIntent
sterile briar
Yeah, generally that's the advice we give, but if you want to do future one-off payments, but the guidance is different if it's for a Subscripton that you want to create immediately
Because Subscriptions that dn't owe any payment up front will create SetupIntents for you, it's way better to use that Setup Intent that's generated w/ mode: subscription