#kt_code
icy pilotBOT
👋 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/1229943561986904195
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
leaden warrenBOT
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.
swift breach
hello! gimme a while to take a look!
swift breach
hrm, i can't seem to find sub_1P6JKNAFQUUIWEfkGZol anywhere in your account, could you try checking to see if you've gotten the subscription id right?
minor fjord
oh weird, my bad, not sure where I got those subscription IDs from lol. good subscription: sub_1P6JLpAFQUUIWEfkkxZmlxIi
bad subscription: sub_1P6JKNAFQUUIWEfkGZolRnXs
same customer, purchased the exact same way
swift breach
the payment for sub_1P6JKNAFQUUIWEfkGZolRnXs looks like it failed though
where as for sub_1P6JLpAFQUUIWEfkkxZmlxIi, the payment is successful
the payment method should only be attached if payment is successful
minor fjord
yeah but they're using the same test payment method so they should both pass?
on the failed invoice the error message says
There is no default_payment_method set on the associated Customer, Invoice, or Subscription. Set a default on one of those objects, or specify the Payment Method you wish to use in the payment_method parameter.```which I guess is what you were saying about the default payment method not being added to the subscription because the payment failed...
swift breach
ah i think there's a slight misunderstanding here, so the save_default_payment_method: "on_subscription" saves the payment method as the default payment method on the Subscription
when you create a Subscription, the Subscription checks if there's a default payment method on the Customer, or on the Subscription. So for the second Subscription, because there's no default payment method defined on either, the Subscription can't charge any payment method
minor fjord
gotcha, but sometimes the setup we have works, where we call stripe.createPaymentMethod() and then create the subscription and then call stripe.confirmSetup() and the payment method is successfully added to the subscription, and sometimes it doesn't
swift breach
do you have such an example subscription id?
minor fjord
yeah the subscription sub_1P6JLpAFQUUIWEfkkxZmlxIi
the payment intent for the failed payment doesn't have a payment method on it, but shouldn't that be handled automatically by stripe with the elements? pi_3P6JKQAFQUUIWEfk02z7adx1
swift breach
sorry, i'm a bit confused, what did you expect to automaticallay be handled by Stripe with elements?
from what i see you're using the deferred flow : https://docs.stripe.com/payments/accept-a-payment-deferred?platform=web&type=subscription to collect the payment method first then create a subscription?
minor fjord
yep I am using that
I guess I mean if stripe.confirmSetup() is successful with the payment method from stripe.createPaymentMethod(), then the payment intent for the subscription would automatically have that payment method attached to it.. maybe I'm misunderstanding something
it's just so odd that it sometimes works and sometimes doesn't, not sure what could be causing inconsistent behavior
swift breach
subscriptions are a bit complicated so let me make sure i'm understanding your flow correctly. For sub_1P6JLpAFQUUIWEfkkxZmlxIi, i'm assuming you followed https://docs.stripe.com/payments/accept-a-payment-deferred?platform=web&type=subscription to create it
for sub_1P6JKNAFQUUIWEfkGZolRnXs, were you using the deferred flow also?
minor fjord
yep that's exactly what my code looks like for creating the subscription
and then my confirmIntent looks the same as weel
swift breach
i don't see any attempt to confirm the PaymentIntent for sub_1P6JKNAFQUUIWEfkGZolRnXs?
minor fjord
it should be hitting confirmSetup since the type returned from create subscription is "setup"? so maybe it's just not not hitting that for some reason?
swift breach
to clarify, the type returned from create Subscription can be either a SetupIntent or PaymentIntent
if the Subscription first invoice is $0 (usually as a result of a trial), then a SetupIntent will be returned
if it's a non-zero Invoice, then it will return a PaymentIntent
minor fjord
ohhh, interesting
swift breach
for sub_1P6JKNAFQUUIWEfkGZolRnXs, in_1P6JKNAFQUUIWEfkETGK6q6K is not zero