#zlf_api
1 messages ยท Page 1 of 1 (latest)
๐ 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/1351490893273895023
๐ 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.
Hmm, did you intiailise the Payment Sheet with the customer's ephemeral key when you confirmed the payment? I suspect that's why it didn't attach
I'm not entirely sure either. I directly used the client_secret and had my colleague in the app trigger the payment component (same as in the screenshot). Then, I entered the card number 4242424242424242 for payment, and it showed as successfully completed.
Yeah I think you'll need to init the Payment Sheet with context of the customer the subscription/invoice is for, so you'd need to create an ephemeral key for them and pass that to Payment Sheet
The main issue I'm facing now is that after making a payment with a new card, the subscription's defaultPaymentMethod is empty. This could potentially cause the next payment to fail. Is there a way to resolve this?
The problem you have is that the pm_xxx was used (by confirming the payment) before it was attached making it 'redeemed'. So now it can't be attached to the customer and set as the default (hence the error)
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
Yes, that's the symptom of the actual problem here
How can this be resolved?
Please let me know whether this is to resolve the issue of failing to set defaultPaymentMethod or the issue of defaultPaymentMethod being empty.
Are you still there?
Hi there ๐ I'm taking over as my teammate had to step away. I'm digging in because I think this is being caused by a long-standing bug within Billing.
So what should I do now? Can you tell me what the bug is?
I'm trying to piece together the best approach for you, please bear with me.
Alright, thank you so much!
The gist of the problem is that setup_future_usage isn't being set on the Payment Intent generated by the Invoice.
My rough thinking right now, is that the best interim approach is for you to force setup_future_usage to be off_session when confirming the Payment Intent.
Do you mean that I should force setup_future_usage to be set to off_session before obtaining the client_secret and initiating the payment?
Oh, I was thinking of trying to do it during confirmation, but I'm not sure if that's possible (I'm not as familiar with this flow in React Native and was asking a teammate if that was possible).
Are you able to test this behavior in testmode? And if so would you mind testing if updating the Payment Intent first, trying to adjust it's setup_future_usage value to off_session before confirming client-side the way you're describing, completes without error?
What does "completes without error?" mean? Does it refer to the defaultPaymentMethod not being empty, or that calling the subscription's update method to set defaultPaymentMethod won't result in an error?
It means that making a request to update the Payment Intent succeeds successfully, and the intent can be confirmed successfully. We'll start with the basics, then if that can be done we'll double check whether that cascades into the behavior we want you to see.
Okay, but it will have to wait until tomorrow as the APP team has already finished work for the day.