#wsnookum_api

1 messages · Page 1 of 1 (latest)

maiden perchBOT
#

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

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

nimble schooner
#

How can we get the corresponding payment_intent ID and error message when smart retries are enabled?
Do you have a Payment Intent ID I can look at?

#

where the payment_intent.payment_failed were not sent to the webhook.

kindred loom
#

evt_1TFTL8ISm7ug71bb8fbW20HB, evt_1TFTL8ISm7ug71bbDwrR27Cz. there was no payment intent failed webhook sent even when included in the target events. only invoice uncollectible and invoice payment_failed appeared.

#

payment_intent.succeeded appears if it is successful. but payment_intent.payment_failed does not appear when it fails when smart retries are enabled

nimble schooner
#

Could you give me access to view your dashboard to investigate this further

maiden perchBOT
#

Hello @kindred loom, we have sent you a direct message, please check it at https://discord.com/channels/@me/1486976460039389435

  • 🔗 The message has instructions on how to grant read and write access to your Stripe Dashboard for our Developer Support team, in order to help you more effectively.
kindred loom
#

approved

nimble schooner
#

Ok, so there was no payment_intent.payment_failed event in the first place. Dashboard: https://dashboard.stripe.com/acct_1QAmkAISm7ug71bb/test/workbench/inspector/pi_3TFTJ4ISm7ug71bb0TIYYKQX/events?date[lte]=1774593329

payment_intent.payment_failed event are sent when there was an attempt to create a payment: https://docs.stripe.com/api/events/types#event_types-payment_intent.payment_failed

In this case, a payment attempt was not even tried for invoice in_1TFTHlISm7ug71bbtdlAmjOe because there was no default_payment_method under the Subscription (sub_1TFTDiISm7ug71bbjJFnJQiE) or the Customer (cus_UDuccJGxbWK1mw).

kindred loom
#

but invoice payment failed event does not include the payment intent ID

#

I need the payment intent ID and the error message for failure

#

there is a payment method attached. it's the test card that declines after attach

#

4000000000000341

#

how can I get the payment intent ID and error message from the invoice webhook?

#

btw, it's not true that there was no payment attempt. if you look at invoice payment_failed -- "attempt_count":
9,
"attempted":
true,

nimble schooner
#

Apologies for the confusion caused, when i said payment attempt, i meant that an actual charge object (ch_xxx/py_xxx) was created. In which case, no charge object was created for the pi_3TFTJ4ISm7ug71bb0TIYYKQX
https://dashboard.stripe.com/acct_1QAmkAISm7ug71bb/test/payments/pi_3TFTJ4ISm7ug71bb0TIYYKQX

The payment attempt count you are referring to is from the perspective of the payment retry schedule. And yes, it is 9 at the latest failed event

"Number of payment attempts made for this invoice, from the perspective of the payment retry schedule. "
https://docs.stripe.com/api/invoices/object#invoice_object-attempt_count

how can I get the payment intent ID and error message from the invoice webhook?
Unfortunately, it might be a bit tricky, this will require an API call (GET /v1/invoice_payments) right after receiving the Incoice.payment_failed event

curl -G https://api.stripe.com/v1/invoice_payments
-u "sk_test_xxxx:"
-H "Stripe-Version: xxxx"
-d invoice=in_xxxx
After which, the Payment Intent ID will be there, and you would have to check it's status for issue. In this case, pi_3TFTJ4ISm7ug71bb0TIYYKQX status was stuck in

"status":
"requires_payment_method",

kindred loom
#

when can i retrieve the error message on the card? i.e. expired/insufficient funds etc?

nimble schooner
#

Those error messages are returned when the charge is created but failed. So the Test card you were using was correct. [0] The error message would be there when payment for an Invoice is attempted with a default payment method either attached to the Customer (has to be set on customer.payment_method [1] AND invoice_settting.default_payment_method [2]) or on the Subscription's default_payment_method [3]

After the payment attempt is made and the charge failed, you will get two events: payment_intent.payment_failed and charge.failed, Of which you can see the failure_message field or last_payment_error field which would give the exact error message. I just tested the flow out and the error message would look like:

"failure_code": "card_declined",
"failure_message": "Your card was declined.",

[0] https://docs.stripe.com/testing#declined-payments
[1] https://docs.stripe.com/api/customers/create?api-version=2026-02-25.preview&rds=1#create_customer-payment_method
[2] https://docs.stripe.com/api/customers/object?api-version=2026-02-25.preview&rds=1#customer_object-invoice_settings-default_payment_method
[3] https://docs.stripe.com/api/subscriptions/create?api-version=2026-02-25.preview&rds=1#create_subscription-default_payment_method

kindred loom
#

In your testing with smart retries, does it send payment_intent.payment_failed message? I'm confused because mine does not.

nimble schooner
#

Or was this a different test and invoice altogether?

kindred loom
#

it that how smart retries works?

#

I would think that it should charge because successful case has the payment intent succeeded

nimble schooner
kindred loom
#

Smart Retries reattempts the charge according to your specifications for the number of retries and the maximum duration. --- maybe it's a bug?

#

there is a charge attempted but no record of the payment intent

#

or at least the webhook message

nimble schooner
#

Smart Retries reattempts the charge according to your specifications for the number of retries and the maximum duration. --- maybe it's a bug?

nope, it's not a bug. If you take a look at the docs i sent you. we explicitly state it here: https://docs.stripe.com/billing/revenue-recovery/smart-retries#payment-method-ordering

When retrying, Stripe uses the first available payment method in this list, in this order:

Priority Payment method API attribute
1 Subscription default payment method subscription.default_payment_method
2 Subscription default payment source subscription.default_source
3 Customer invoice default payment method customer.invoice_settings.default_payment_method
4 Legacy Customer default payment source customer.default_source

Which means your Subscription/Customer were missing the default_payment_method, hence a Charge would not even be attempted.

#

Furthermore, the docs reccommends to track invoice.payment_failed not payment_intent.payment_failed.

For both Smart Retries and custom retry schedules, Stripe reattempts the charge according to your specified schedule. Use the invoice.payment_failed webhook to receive subscription payment failure events and retry attempt updates.

kindred loom
#

there is a payment method.

#

4000000000000341

#

it's the default payment method

#

you can see it in the dashboard

#

only that this will decline the payment

nimble schooner
#

nope

#

It has to have the word "Default" beside it

image.png
#

You can click on the "..." beside it to set it as default and try again