#vpatel1093_api
exotic sierraBOT
👋 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/1222625360223408212
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
deft cliffBOT
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.
- vpatel1093_api, 48 minutes ago, 8 messages
quaint sleet
Okay and what error are you seeing exactly?
Do you have a request ID related to the error that you can provide?
tiny osprey
I put the error in the original thread let me find an I’d
quaint sleet
Yeah just the error message doesn't really show me what you are doing
tiny osprey
The last occurrence was a webhook with id: we_1JulTVChVhoxEXClz1q2YVMc
We released and encountered this on 3/19 and rolled back that deploy, so anything we investigate should be on that date
quaint sleet
A webhook endpoint ID really doesn't help. I need the request ID of the specific error
quaint sleet
lol
Looks like https://dashboard.stripe.com/logs/req_mc8WVqmgwzEK7P might be an example of what you are talking about
tiny osprey
req_O2zIjV0vrl7TX8
quaint sleet
req_O2zIjV0vrl7TX8
This is a successful request
Okay so the failure request I linked above is because you are trying to update a Customer to set their invoice_settings.default_payment_method to a PaymentMethod that was not attached to the Customer (which is due to the fact that you didn't pass setup_future_usage for the PaymentIntent that involved that PaymentMethod initially)
tiny osprey
Thanks for finding that for me, still learning Stripe
So wasn't the suggestion to omit that parameter in order to create a one time PM?
quaint sleet
Yep which is what you did, but this is a separate request in your integration that is taking place afterward
So you need to remove this parameter that is setting the default from that request if it is a one-time PaymentMethod
You'll want to look in your code for where you are making a Customer update request: https://docs.stripe.com/api/customers/update
tiny osprey
So high level, I am trying to set a default payment method to a one time PM which results in an error, should I just not send those customer update requests for that situation or do they always need a default regardless?
quaint sleet
A default is only used with Subscriptions/Invoices
You can't set a PM as the default unless it is attached to the Customer
It is only attached if you set setup_future_usage or attach it explicitly in a separate request
So for this "one-time" flow you have, you want to exclude trying to set the default
When you have your recurring flow, you should set the default
tiny osprey
So to summarize:
- Recurring payment methods - my application is already configured to do this, no change needed and changes to support one time payments should not affect this flow
- "One time" payment methods - to add support for this, my existing workflow of checking out a cart remains the same, but in the case of checkout for a non-subscription item, payment intents should not be created with a 'setup_future_usage' parameter. Customer default payment method setting should not occur. No other changes?
quaint sleet
Yep that seems right to me
Recommend making the change and testing both flows end-to-end
tiny osprey
Ok just want to make sure there aren't other webhooks/events to be aware of changing/withholding. Especially with the user/payment intent/PM
quaint sleet
There shouldn't be, but I don't know exactly how your integration is set up so yeah most important thing to do is to test it out in test mode end-to-end