jarrett

[short sorrel]

You can set the default directly on the subscription and this will take precendence: https://stripe.com/docs/api/subscriptions/create#create_subscription-default_payment_method

[wooden trout]

But I don't have it yet

I need the payment intent

if the customer didn't have one, i'd create a subscription and then confirm the payment intent with Payment Elements.

[short sorrel]

So in the above beta you linked the flow is to create the payment method prior to creating the subscription. So why can't you just pass the payment method that is created in the step you linked when doing this step: https://stripe.com/docs/payments/defer-intent-creation?type=subscription#create-intent

[wooden trout]

because that is an optional step and it won't be attached to the customer at that point

I didn't think it was necessary. and from what I know you're not supposed to use the attach to customer API and instead are supposed to use setup intents.

which means now I need an entirely separate flow to handle someone that has an existing card which seems really silly

[short sorrel]

I think this param should take care of it then: https://stripe.com/docs/api/subscriptions/create#create_subscription-payment_settings-save_default_payment_method

When payment succeeds it'll just save the pm used as the sub's default

[wooden trout]

so i can give it a PM that isn't on the customer?

[short sorrel]

When you go through that flow that you linked and pay the subscription payment, the payment method will be automatically attached to the customer and if you pass https://stripe.com/docs/api/subscriptions/create#create_subscription-payment_settings-save_default_payment_method it will be set as the subscription's default

In fact, we mention passing that param in the example on that page even: https://stripe.com/docs/payments/defer-intent-creation?type=subscription#create-intent

[wooden trout]

i am passing that param

i just am not setting the default_payment_method on the subscription

[short sorrel]

That param will set the default payment method on the subscription once payment is successful

[wooden trout]

Ok, let me back up on this

The problem is that when you run the server side part of this

it defaults to using the customer's default payment method

so are you telling me that if create the payment method client side, pass that value in and set it on default_payment_method for the subscription creation that will work?

[short sorrel]

Yes

But if you pass the param I linked, the customer's existing default shouldn't be used

Can you share a subscription id where you saw this behavior?

[wooden trout]

sub_1Mhb5dF6KG2nMs1lAettUSOz

[short sorrel]

Gotcha. One sec

Can you share the code for confirming the intent? It doesn't look like the payment method details you provided in the frontend were passed when confirming

[wooden trout]

i think i might have found the issue

i'm confirming without the elements cause I was handling the situation when i'm using an eixsting payment method

let me make a quick modification

this might be my own mistake

[short sorrel]

Yeah you need to pass in the elements

Take a look at this step: https://stripe.com/docs/payments/defer-intent-creation?type=subscription#submit-the-payment

[wooden trout]

yeah, I realize. silly mistake. I need to conditionally pass it in

if i create the sub with an existing PM I just want to confirm

all works as expected

sorry about that

[short sorrel]

No worries

[wooden trout]

is there a way to always confirm client side

[short sorrel]

Glad you got it sorted out

[wooden trout]

for example, i find myself having to write code to look at payment_intent.status in multiple places

[short sorrel]

You can confirm client side with: https://stripe.com/docs/js/payment_intents/confirm_payment

[wooden trout]

but for example, lets say I pay an invoice with a card that doesn't require confirmation and can go directly to success

i call pay on the server side and now I have to consider all the PI statuses right there instead of waiting for my return url to handle it

[short sorrel]

Wait I'm confused. Is this a different flow where you create invoices and attempt to pay them serverside? You shouldn't have to do that at all with the originally linked flow here: https://stripe.com/docs/payments/defer-intent-creation?type=subscription#create-pm

[wooden trout]

I'm talking about something separate from subscriptions now lol. We have a checkout process for invoices and there are two ways you can pay. You can choose an existing PM or create a new one. If you choose an existing one, we finalize the invoice and pay it server side. if you choose a new one, we finalize it and confirm it client side.

it would seem the only alternative would be to update the default_payment_method on the invoice, then finalize it and then defer the confirm to client side for payment

whereas I can pay it server side and set the PM at the same time

unless there is a way to specify the PM on the client side confirmation using an existing PM id

and the documentation on confirmPayment only says it takes elements unless it's not documented and it can be passed a PM string somehow

[gleaming escarp]

Hi 👋

Yes you can pass a Payment Method ID when confirming the Payment Intent client side.

It's not super clear because we didn't want to overload this page but you can see here: https://stripe.com/docs/js/payment_intents/confirm_payment
that we say any of the parameters in the server-side /confirm call is also valid client side

Which means this is a valid parameter: https://stripe.com/docs/api/payment_intents/confirm#confirm_payment_intent-payment_method

[wooden trout]

i must not be passing it in the right spot cause I get "You cannot confirm this PaymentIntent because it's missing a payment method. To confirm the PaymentIntent with cus_Inj4oBLfgXAR8N, specify a payment method attached to this customer along with the customer ID."

I'm currently doign confirmPayment(clientSecret, payment_method: 'pm_XXX',...)

i thought it would've gone in confirmParams but that gives me IntegrationError: stripe.confirmPayment(): Expected either payment_methodorpayment_method_data, but not both.

Oh, I'm interpretting the latter error wrong

i jsut realize that i had it in the right spot but i have both things

[gleaming escarp]

Yeah, if you just replace the payment_method_data with the payment_method parameter that should work

Sometimes it just takes saying the problem to make the answer easier to see

[wooden trout]

yeah once i pasted it in i realized

the amount of flows, options and stuff involved in all this is a whirlwind. i have no idea how you guys organized any of this. super impressive!