Nyxi

[wanton bough]

Off the top of my head I think it would be requres_action or processing, you should be able to change it when they are in requires_confirmation but I will double check that

[inland bluff]

Okay thanks

and requires_payment_method also, of course?

Sorry, I inverted my question in my own head there

Nvm

[wanton bough]

Yeah should totally be able to change it in requires_payment_method, that is the default status so we'd be in big trouble if you couldn't change it at that point

[inland bluff]

Yeah of course, I got it the wrong way around

So not in requires_action, processing and succeeeded. But if I can't do it in requires_action, then I would have to cancel the entire intent to start over?

I'm moving some code to automatic confirmation, so requires_confirmation won't be seen

[wanton bough]

I am double checking the requires action part now. If it is locked there I think you would have to start over but you may not have to

[inland bluff]

Cool, I'll wait

[wanton bough]

Updating payment intents in requires_action is definitely allowed but it will move the intent back to a state of requires_confirmation

[inland bluff]

but what if I use auomatic confirmation?

Would I have to use the confirm endpoint instead?

To do it in one go

[wanton bough]

I am blanking on the term automatic confirmation here. Do you just mean passing confirm=true when creating the intent? Or something else?

[inland bluff]

https://stripe.com/docs/api/payment_intents/create#create_payment_intent-confirmation_method

My current implementatino runs on manual confirmation, which doesn't play nice with all payment methods (we're implementing mobile pay via beta), so I have to move to automatic confirmation for all payment methods just to keep the flow identical

In this context, I need to know when to cancel and when to just update the payment intent if users choose a different payment method or if the amount changes (applying discount code for instance)

[wanton bough]

Gotcha, thank you for the clarification. You should still be able to change this payment intent on your backend whenever you want. That being said, without manual confirmation the user can just keep going without waiting for you to change things on your side.

We do have an upcoming beta that enables more functionality like this, basically you can wait until you create the payment intent and can again restrict the user from fully completing the payment client side.
https://stripe.com/docs/payments/defer-intent-creation

[inland bluff]

I already have access to this beta

[wanton bough]

Though that beta is a decently different flow and I am not immediately sure if it plays nice with the mobile pay beta

[inland bluff]

But we use that for manual confirmation

(via payment element, which only supports automatic otherwise)

I'm setting a meeting with Tim Fisher about Payment Element next week, because they wanted some feedback on it, so I can maybe figure out then what is best to do

And I think I can solve the race condition stuff by simply catching API errors on my end if I attemp to cancel a payment intent that has already been processed by the client, and if I do that, they should see an error and return to our site

[wanton bough]

I think I may just be misunderstanding your usecase here. So the scenario is that you generate the intent, send it client side, the user makes some selections, and you want to be able to adjust the amount/application fee based on that?

[inland bluff]

Yes, exactly. I was thinking I create the intent immediatley

It makes the flow easier to manage

but at that stage I don't know what payment method they will use or the final amount

[wanton bough]

Have you already tried using the secret_key_confirmation property? I think deferred intents gives you access to it https://stripe.com/docs/api/payment_intents/create#create_payment_intent-secret_key_confirmation

[inland bluff]

And I also want to be able to change the payment method and amount even after a faild payment attempt - say if they try a different card because one declines

Let me look, sec

Hold on I have to sign in, that doc is gated

[wanton bough]

That should allow you to prevent the intent from fully being confirmed client side. Though I may be mixing that up with something else

Whoops, always forget about my test account's access

[inland bluff]

It still doesn't load

I'm not 100% sure I have access to this feature

[wanton bough]

Yep, sounds like that is part of a different thing. Checking in to this and whether that property can help you here

[inland bluff]

I'm not looking to have any advanced flow, I'm trying to migrate to the recommended approach of client-side confirmation in all cases, so I'm not sure how this would help me?

[wanton bough]

Gotcha, thanks for correcting course there.

In that case I think your two main options are catching errors and surfacing to the user as you said or using that deferred intent functionality and waiting to create the intent until you know PM and final amount.

And I also want to be able to change the payment method and amount even after a faild payment attempt - say if they try a different card because one declines
Also to be clear this should definitely be possible regardless of method. If they get a decline the payment intent will go back to a requires_payment_method state and can be changed still

[inland bluff]

Yes, but you assume the payment actually fails and they don't just change their mind after requires_action

like "okay I cna't confirm this, let me try another method"

I guess in this case I would always provide a new payment method in retry, which would reset to requires_action or succeeded

but if I only changed the amount in requires_action, it would go back to requires_confirmation even if I don't use manual confirmation? I guess that's the core question

If that makes sense

[wanton bough]

Correct, it would go back to requires_confirmation but that means that your user can go right back to trying to confirm it client side.

[inland bluff]

And the SDKs would handle this automatically if I just pass them the intent ID and client secret?

Regardless if it's requires action or requires confirmation

JS, iOS, Android SDKs, I mean

https://stripe.com/docs/js/payment_intents/confirm_payment

[wanton bough]

Yes the Stripe.js client side calls should be able to continue the confirmation process regardless of whether the payment intent is in a requires_action or requires_confirmation state.

[inland bluff]

Great

I think I know what to do now

[wanton bough]

Awesome, glad this could help clarify.

[inland bluff]

Big regret that I didn't use automatic confirmation to begin with 🥲

[wanton bough]

Also one thing that I should mention in case you haven't seen is that we have a fetchUpdates function in Stripe.js for fetching the latest payment intent info when you change it server side. I think it is mostly for UI things (like making sure that Google/Apple pay display the right amount on their payment sheet) but your code should definitely make sure to call it when it knows you changed the amount or application fee client side https://stripe.com/docs/js/elements_object/fetch_updates

[inland bluff]

Don't you mean server side?

If the client updates it, why would it need to call this?

[wanton bough]

Indeed I did

[inland bluff]

But my client doesn't create payment intents or update them anyway

So it's all good

Thanks

Err, I mean, I should use this