#stephen-crosby_webhooks

1 messages ¡ Page 1 of 1 (latest)

wind hemlockBOT
#

👋 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/1331739176202145885

📝 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.

sour cosmos
#

But I think those should be the only two scenarios, so I think checking if attempt_count is 0 and the invoice's billing_reason is subscription_create or something about a trial then you can ignore.

wind hemlockBOT
tawdry oak
#

ok i'll test a declined case

#

I got attempt_count=1 for 4000000000009987 (lost card)

#

I bMy plan is to ignore this event entirely if attempt_count == 0 and it seems like I won't miss anything. Can't think of any other reason I might get this type of payload with attempt_count == 0?

grim heath
#

Hi, I'm taking over as my teammate needs to step away. Let me catch up

#

Ok, so what is your follow up question here? It's what Pompey said right?

tawdry oak
#

yes. i'm just double checking. i don't want to miss any important events. we use this event to cancel customer subscriptions when they haven't paid, but it seems unlikely we'll miss any even if we ignore all the events where attempt_count = 0

#

a more straightforward question is "What does attempt_count=0 mean in the context of an invoice.payment_failed event?"

#

It seems to mean a payment failed, but it was never attempted. But that doesn't make sense

grim heath
#

We document how we define attemp_count on invoices here: https://docs.stripe.com/api/invoices/object#invoice_object-attempt_count

Any payment attempt counts as the first attempt, and subsequently only automatic retries increment the attempt count. In other words, manual payment attempts after the first attempt do not affect the retry schedule. If a failure is returned with a non-retryable return code, the invoice can no longer be retried unless a new payment method is obtained. Retries will continue to be scheduled, and attempt_count will continue to increment, but retries will only be executed if a new payment method is obtained.

#

I recommend testing things carefully and confirm the different behaviors with the different flows you have above

tawdry oak
#

The docs are missing a description of how this attempt_count can be zero. Is there a way to get some clarification on that point?

grim heath
#

I see what you're asking now. attempt_count can be 0 due no payment attempt being made if the payment is in requires_action due to 3DS etc.

#

Declined will count as 1 since there was an attempt to a payment

tawdry oak
#

i think I understand. are there any other reasons attempt_count can be zero? aside from 3DS or Captcha?

grim heath
#

not off the top of my head but let me thinking through this

#

You can test this on your end by marking an invoice paid out of band as well

tawdry oak
#

ok. i'll check that. thank you!