#forcewill
primal anchor
Yes
We use both radar rules and Smart retries
And this payment pi_3NY22GIYOry9WQXw1R1jfCXv seem like it went into Smart Retries
It does match our setting of retrying during 3 Weeks in the dashboard
however we would not expect that logically that a payment blocked by radar would enter into the retries flow 😓
left cedar
Gotcha let me double check.
Huh yeah interesting. I would not have expected this to retry either but yeah clearly it is doing so.
I will flag this internally so we can look further into this behavior.
floral craneBOT
left cedar
Ah actually @primal anchor I do believe this is expected since this is your own Radar block list here that you added this value to. The idea is that you might remove that value from your block list sometime in the retry process, so it actually is expected that the PaymentIntent does go through the full retry schedule.
primal anchor
I would expect it not to go into the retry schedule if it matches a rule.
And if I remove the rule it would only affect future payments.
deft salmon
👋 hopping in here since bismarck had to head out
primal anchor
Hi @deft salmon I will have to also head out soon
Even with bismarck last reply, it does not make sense to me the current behaviour
could you still raise this internally?
We have setup a radarrule to block certain customers to comply with legal rules
And if the current behaviour is the expected behaviour
It means our customers that fall into that rule
Are getting our product for free for 3 weeks
deft salmon
Yeah I'm taking a closer look
deft salmon
I think your particular ues case is just not one that we handle very well currently. As an example, if you had a block rule where you don't allow cards from certain countries then one attempt could fail, but if your customer updated their payment method to provide a different card some users may still want to allow that user to pay.
For the specific payment you shared, payment failed with a generic decline which we (Stripe) considers to be a retriable failure (in that a user could come back and try with a different payment method)
If you want to stop automatic retries after a generic decline it would be up to you to implement this yourself (either by voiding the invoice, or updating the invoice to set auto_advance: false
primal anchor
I understand and that makes sense, but this particular rule is set as client_ip_country_blocklist
unless the customer tries to trick the system by using a VPN or such
The user country ip is not expected to change
deft salmon
Yeah that's fair - it's just not something we support today and it'd have to be a feature request. You can definitely flag it to support (https://support.stripe.com/contact) as feedback, but if it's something you need urgently then right now your best option is to disable auto-advancement yourself