#mattmiller_api
forest egretBOT
đ 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/1335976745865711649
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
reef wind
Hi, once you've setup in the payment method for future off_session payments you could use them. Yes, you can update the object at a later time, https://docs.stripe.com/api/setup_intents/update .
If you're attempting to not allow the customer to use the payment method at all, you can detach the payment method: https://docs.stripe.com/api/payment_methods/detach. You won't be able to use the payment method again.
In order to only allow on_session payments only, you can track this on your end after the payment method is created from the SetupIntent.
pseudo fossil
Thanks. So, to make sure I understand, is the recommendation here for me to track the setup intent ID on my end when the end customer first creates it, and then later update it by blanking out its payment_method_id if I want to restrict that payment method to on_session only?
reef wind
No, if you do not intend to use that off_session, why would you create the SetupIntent off_session in the first place?
pseudo fossil
Well, the customer might create a new payment method by setting up scheduled recurring billing on my site, and then some time later decide they want to use that payment method only for manual payments. I want to make it as easy as possible for them to switch between automatic scheduled billing and manual payments without recreating their payment methods.
reef wind
Ah, when you use off_session the customer may or may not be on session so you would not need to do anything on your end. The payment method is saved and you can use it lated for on_session payment methods, https://docs.stripe.com/api/setup_intents/create#create_setup_intent-usage. You just need to track this on your own end, use the metadata for instance, https://docs.stripe.com/api/payment_methods/update#update_payment_method-metadata to indicate this on your end.
pseudo fossil
Okay, that makes sense. It sounds like once the payment method has been optimized for off_session then there's really no way (or no need) to "revoke" that level of optimization. I guess my only concern was that from the card network's point of view off_session was putting the end customer's card at a somewhat greater risk than on_session, and if the customer doesn't intend to allow off_session any more I didn't want to leave that turned on. At the same time I didn't want to detach the payment method and make my customer type the card details in again just to change from off_session to on_session.
If detaching is the only way to change the optimization level then that's fine. I can decide how to handle that.
Does it sound like I'm understanding all this correctly?
reef wind
In that case, the only way is to collect the payment method again and pass on_session to save the payment method details.
Otherwise, given that off_session accounts for them being on session as well I think it would work technically. I can't speak to the network's point of view.
Like, if the bank wants additional steps like 3DS, they would ask it so you would need to bring the customer back on session anyways
pseudo fossil
Okay. Thanks for all that clarification. I'm good to go now.
reef wind
Sure