#delgesu1745_api
proper iglooBOT
👋 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/1356826336727138397
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
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.
- delgesu1745_api, 8 hours ago, 48 messages
- delgesu1745_api, 22 hours ago, 16 messages
- delgesu1745_api, 1 day ago, 26 messages
solemn marlin
Can you share the request ID (req_xxx) of the error? Here’s how you can find it: https://support.stripe.com/questions/finding-the-id-for-an-api-request
I managed to find one example request with an error on this Setup Intent: https://dashboard.stripe.com/test/logs/req_oJPziNcw6eyinG
The issue was because the Setup Intent has confirmed successfully in https://dashboard.stripe.com/test/logs/req_Qp5hhlGpEjhOMF, but you attempted to confirm it again
Once the Setup Intent was confirmed successfully, you couldn't confirm it again
You can see the history of the Setup Intent here: https://dashboard.stripe.com/test/logs?object=seti_1R9GBwK4OwuAC0l7DEjQBMtW
carmine saffron
So I'm using a payment element with setupintent to capture payment info and charge later, but what if someone puts in a method and then hits the button to submit the form but wants to go back before finishing their signup with us and change the payment method?
solemn marlin
Which integration flow are you following? Can you share the doc link?
By default, creating the Setup Intent and pass its client secret to Payment Element to collect the payment method, the payment method can't be changed after the successful confirmation.
You will need to create a new Setup Intent to collect a new payment method
carmine saffron
solemn marlin
If you follow this doc, then the behaviour will be what I mentioned earlier:
By default, creating the Setup Intent and pass its client secret to Payment Element to collect the payment method, the payment method can't be changed after the successful confirmation.
You will need to create a new Setup Intent to collect a new payment method
If you want to collect the payment method details first, then save the payment method later, then deferred intent flow should be used: https://docs.stripe.com/payments/accept-a-payment-deferred?platform=web&type=setup
carmine saffron
Ahh ok, this would probably make more sense for our flow. And what if we have a customer who's already got a payment method on file and we want to give them the ability to update or change it as part of the renenrollment process?
solemn marlin
Currently, Payment Element doesn't support update a payment method details in a deferred intent flow.
You will retrieve the saved payment method list on the customer and provide your own UI to update the details.
Payment Element in deferred intent flow supports removiing saved payment method: https://docs.stripe.com/payments/accept-a-payment-deferred?platform=web&type=payment#enable-saving-the-payment-method-in-the-payment-element with a caution:
Allowing buyers to remove their saved payment methods by enabling payment_method_remove impacts subscriptions that depend on that payment method. Removing the payment method detaches the PaymentMethod from that Customer.
carmine saffron
Is there any flow that allow updating?
Is there any documentation on providing our own UI to update the details, as in how we would make sure that it's PCI compliant, etc?
solemn marlin
What do you want to update specifically? An existing payment method such as card shouldn't need to be updated. A new card number will be considered as a new payment method
carmine saffron
Yeah, no I'm just thinking that for returning customers who need to reup on the signup contract, I want to allow them to change their payment method. But I guess what's best is to show them the one we've been using just by fetching it from the api and displaying it and then if they want to change it we can give them a button for the deferred setupintet new payment option and then just set that as the default card to be used on the customer object after they submit it.