#alexb
south fjord
lucid kiln
Can you provide the event id or subscription id?
final zephyr
I thought it wasn't permitted to give/get account specific info here
This question is more general, I guess I am asking how do I tell who/what caused a given subscription cancelation, and what does Automatic mean here
lucid kiln
Event and subscription id's aren't sensitive and we ask for them all the time. Just asking because I believe you're correct, but I want to verify something on that specific event
final zephyr
I'd still appreciate help on the general question
I have other events to consider too
and future events...
evt_1M4fXYDgTpZ042BgdLeosF1k
is one
lucid kiln
Yeah source is API if it's due to an API request. Automatic means the event was due to some internal process (renewals, etc.)
final zephyr
gotcha thanks.
I have a follow on question then, we've seen 3 cases like this, where our customer is charged, but their subscription is canceled, and they complain to us that they cannot use our product even though they've paid...
It seems to me like this subscription was canceled by stripe evt_1M4fXYDgTpZ042BgdLeosF1k then charged by stripe
can i share the charge id here?
lucid kiln
Yeah go for it
That's not sensitive
Just don't ever share api keys
Or webhook endpoint secrets
lucid kiln
Object id's are ok
final zephyr
so at this point I am hoping to first confirm/correct my understanding of the events, then if my understanding is correct figure out how to avoid this
it seems like stripe canceled the subscription, then stripe charged the customer, making us look like we're stealing their money
which isn't a. good look
lucid kiln
Gotcha. Looks like you cancel subscriptions immediately if payments fail?
You could extend the window a bit to give customers a chance
final zephyr
I don't think we do, we have 14 days of retries
regardless, why cancel the subscription then charge the customer?
lucid kiln
It's because it's an unpaid invoice that was created prior to subscription cancellation. They never paid the invoice, but it was issued during their payment period. No further invoices will be created, though. If you want to avoid this in the future, you can void the invoice: https://stripe.com/docs/api/invoices/void
final zephyr
I'm not really understanding... You cancelled the subscription, you also made the invoice... Why charge a customer and not give them a subscription?
Eg why is this a good thing that it works this way? Our customers are very upset about it
So we sent the user to you to buy a subscription, they paid for it, later you canceled it due to no payment, then you charged them for it, and this is our fault?
Wouldn't it make more sense to not charge them after you cancel it for non payment?
lucid kiln
Here: https://dashboard.stripe.com/settings/billing/automatic you can change this setting to modify the behavior a bit. But for that Subscription you linked, it wasn't retried for 14 days. Subscription was cancelled on the 15th and invoice was created on the 12th
final zephyr
these are our settings, unchanged
what is it I'd modify?
When you say "Subscription was cancelled on the 15th and invoice was created on the 12th", just so we're clear its:
Stripe created the invoice on the 12th, and Stripe canceled the subscription on the 15th
We have over 1100 subscriptions, all created by sending users to a stripe checkout session, all have the same 2 weeks retry.
The 3 subscriptions that have seen the issue above are all in India, where I think payments are more complex
I don't think changing our retry settings is going to help here.
final zephyr
ok so saying this back to you: if we dont' change this, our indian (and only our indian) customers get charged AFTER their subscription is canceled
but if we change this as you suggest, then this won't happen to our indian customers any more..
are there any other implications I need to be aware of when making this change?
have you guys documented this somewhere? eg do this so your indian customers don't get pissed off
hmm, that setting says If all retries for a payment fail, but thats not what happened, you retried and it succeeded
you also said But for that Subscription you linked, it wasn't retried for 14 days
so it doesn't seem to me like this will help here, since stripe was still retrying, and one of the retires suceeded
lucid kiln
Oh hold on. I apologize. I was working under the assumption the subscription was cancelled due to all retries being exhausted
Let me take another look
final zephyr
thx
meager spire
Hello! I'm taking over and catching up...
final zephyr
Ok thx
meager spire
Had a look at the Invoice associated with that Charge, and because it's an IN Invoice it cannot be retried due to regulations, so the associated Subscription was canceled after all retries (zero) were attempted.
IN recurring payments are subject to a lot of special behavior which is documented here: https://stripe.com/docs/india-recurring-payments
final zephyr
Ok.. do you know how/why the customer was charged?
meager spire
Looks like the Invoice was paid in this request: https://dashboard.stripe.com/logs/req_PzQS9crRDNT3LR
Probably from the hosted Invoice payment page, or possibly from your integration if you provide the ability to pay outstanding Invoices by confirming the associated Payment Intent.
final zephyr
We don't do anything specific here. Did Stripe send the customer an email requesting payment?
meager spire
As my colleage mentioned, the outstanding Invoice can still be paid as it's considered an outstanding debt unless you tell Stripe to mark it as uncollectible or otherwise void it.
Looks like we did send them an email for this one, yes.
final zephyr
This really feels like you're passing the buck. We didn't make the invoice. We didn't cancel the subscription. We didn't collect payment. We didn't email the user
Stripe made the invoice, stripe canceled the subscription, stripe emailed the user, then charged the card
This only happens for our indian users
Is this 110% how stripe thinks things should work? Eg this is good, and correct?
How do we avoid it?
It's very frustrating for these Indian customers to have their cards charged and be left unable to use our product
meager spire
You avoid it by changing the setting as described above to mark Invoices uncollectable when all retries fail.
final zephyr
ok. just double checking, I thought you said no retires could happen here
Eg will stripe still mark the invoice uncollectible after 0 retires? I guess/hope it would, just wanted to be sure
meager spire
Sorry, I probably wasn't completely clear. IN Invoices cannot be retried, so the retry count is zero. Thus, even though you have smart retries enabled, they don't apply. So then the next thing that happens after all retries have failed (which are zero retries for IN Invoices) the If all retries for a payment fail Invoice setting behavior kicks in.
Yes, that's correct.
final zephyr
Ok great.
I thought this same thing happened to two other customers, but after talking to Stripe support and escalating, I got a different explanation and solution... Can you help me confirm if these two situations are indeed different?
The timeline and associated events of this payment invoice can be checked here:
https://dashboard.stripe.com/invoices/in_1M1kYvDgTpZ042BgWaDIsnJz
https://dashboard.stripe.com/payments/pi_3M1lW4DgTpZ042Bg4BDLNDoN
I hope this explains. Should you have other concerns or inquiries in the meantime, don't hesitate to reach back out.```Also, Is it just a fluke that this has never happened for our 1000+ non indian subscribers?
meager spire
Your non-IN Subscribers get the smart retry behavior, which takes time. It's likely that people who intend to pay do so within that timeframe, but with IN Invoices where there are zero retries the Subscription cancelation happens immediately.
Looking at the other question now...
final zephyr
Right but wouldn't some of the other 1000 have invoices that are still collectable after the subscription was cancelled?
We have many who don't pay within the timeframe.. ah I gotcha, so the theory is it could happen, just no one who wants to pay ever paid after the 14 days?
meager spire
Yep, exactly.
This other Invoice is the same situation; looks like we sent an email and they paid the Invoice from the hosted payment page after the initial payment failed and the Subscription was canceled.
final zephyr
Ok. So the explanation from escalated support is wrong?
meager spire
Seems like it. Their message implies the payment was automatically made via retries, but it was not. The customer made the payment manually in this request: https://dashboard.stripe.com/logs/req_J8i9QPZ0eJWxGU
final zephyr
They were quite insistent that the solution is to disable smart retries
Ok thanks for clarifying. This has been incredibly frustrating
It is SO hard to get a correct answer out of stripe
meager spire
Sorry about the confusion here. IN Invoices and their unique behavior is often vexing. 😅