#zlf_api

1 messages ยท Page 1 of 1 (latest)

wary saffronBOT
#

๐Ÿ‘‹ 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.

shut harbor
#

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

sour gulch
#

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.

shut harbor
#

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

sour gulch
#

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?

shut harbor
#

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)

shut harbor
sour gulch
#

How can this be resolved?

wary saffronBOT
sour gulch
#

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?

sour sphinx
#

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.

sour gulch
#

So what should I do now? Can you tell me what the bug is?

sour sphinx
#

I'm trying to piece together the best approach for you, please bear with me.

sour gulch
#

Alright, thank you so much!

sour sphinx
#

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.

sour gulch
#

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?

sour sphinx
#

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?

sour gulch
#

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?

sour sphinx
#

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.

sour gulch
#

Okay, but it will have to wait until tomorrow as the APP team has already finished work for the day.