#alainux_best-practices

1 messages ¡ Page 1 of 1 (latest)

scarlet pineBOT
#

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

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

potent sirenBOT
drowsy wind
copper bloom
#

Hi! I am actually using the card that you mentioned (using the code pm_card_chargeCustomerFail). However when I retrieve the subscription and inspect subscription.latest_invoice.payment_intent it has status: requires_payment_method

What we are trying to test is when the invoice is marked as "uncollectable", so we are expecting to see that payment_intent.status = 'cancelled' .

Could this help? https://docs.stripe.com/api/invoices/mark_uncollectible

drowsy wind
#

it could but isn't what you're trying to test that it gets marked uncollectible automatically? so manually marking it as such would defeat the purpose

copper bloom
#

No, we are trying to test how our system responds to subscriptions which are marked as uncollectable.

We have a "churn recovery" screen that allows users with past due subscriptions to settle their bill, (we send the latest_invoice.payment_intent to the web client so we can retry a checkout with that clientSecret), which but we found that some users (those marked as "uncollectable") had their payment intent cancelled and so they cannot pay for it.

For these users we are creating a new subscription entirely and providing that payment intent to the client for payment.

drowsy wind
#

I see, I think. Then sure, you could just mark an invoice as uncollectible manually. Or as I described, you can use a TestClock to simulate it happening(I'm assuming you have the settings on the Dashboard https://dashboard.stripe.com/settings/billing/invoice set up to make the invoice uncollectible when all attempts are exhausted)

copper bloom
#

We do have configured Payment due for 30 days in there, but unfortunately both advancing the testclock by intervals of 2 days for 1 month doesn't ever have the effect of marking this user as uncollectable. It just creates a new draft invoice after the period.

And marking the invoice as uncolletable gives me an error telling me to void it instead.

For reference, this is the state that we want to achieve: https://dashboard.stripe.com/invoices/in_1P8RqxGXtcqHgDW88xAGvwdp as you can see, that subscription (https://dashboard.stripe.com/subscriptions/sub_1OxD4FGXtcqHgDW83jg1dkx1) is Past due , the invoice is open, but the payment intent that is associated with it (https://dashboard.stripe.com/payments/pi_3P8SntGXtcqHgDW83Fe0OnKe) has a status of canceled

I can see that the invoice has 10 charge retries.

I'm advancing the testclock 30 times, but cannot replicate this effect. Do I need to call an endpoint in between the test clock advancements that attempts a charge?

image.png
drowsy wind
#

no you don't need to call an endpoint.
do you have an example of the object inside the test clock you're testing with like the customer ID cus_xxx?

#

We do have configured Payment due for 30 days in there
that's for invoices that are collection_method:"send_invoice" though, it's not the same thing as retries on a "charge_automatically" recurring Invoice, which is what your example of what you want to achieve is.

#

these are the settings I'm talking about.

image.png
copper bloom
#

Our configuration there is "Leave the invoice past-due". However we use an external service called "Butter" that retries payments through the API. I think that is causing the cancellation of the invoice.

Here is a customer that I created in my most recent integration test and attempted to advance the test clock automatically 30 times: cus_Q3sruhpjRiZ6mV

image.png
drowsy wind
#

sorry this is getting really complex and ongoing over an hour now

#

Maybe Butter doesn't operate in test mode? maybe it ignores certain invoices or it detects if test clocks are used.
For cus_Q3sruhpjRiZ6mV I'm not sure what the issue is overall, what exact value or behaviour were you expecting to see in the API that didn't happen?

copper bloom
#

No worries! Thanks for the help. I think we will just do a unit test mocking the payment intent state for now.