#laura_code
near grottoBOT
👋 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/1326247522859225219
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
somber cipher
Hello! I wish I could help, but this chat is focused on developers and technical questions. Our support team will be able to assist you with Radar rules better than I can: https://support.stripe.com/contact/email
rain stratus
I was told to ask here, and choose any topic. The support team cannot help me. Anyone there than knows this and can help please?
somber cipher
Who directed you to ask here?
And when you say the support team can't help you, why is that?
rain stratus
Nathan Skarie
I have been back and forth for weeks with support, finally got someone to talk with us on a call (Nathan), but then got no where, and still in the same position as I was when I started. He is telling me to ask on here.
somber cipher
Thanks for that context. I'm checking with Nathan for further context, but custom Radar rules aren't generally something we can help with here. That said, I'll give it a shot....
You mentioned installment payments. That can mean a lot of things. Can you give me the ID of an example payment I can take a look at?
rain stratus
yes, one moment
thank you very much
this is an installment gift that was rejected due to zip block (for no reason): ch_3Q92lfGZo2KOB80R1t0FV3w7
this is the first recurring gift: ch_3PyK74GZo2KOB80R1ntOMUJV
somber cipher
I deleted that last message because this is a public server, so you shouldn't share email addresses here.
rain stratus
we have had like 1,000 recurring gifts blocked due to zip mismatch, when their first gift went through perfectly fine, and zip never changed (and they didnt move)
somber cipher
Anyone can see this conversation.
rain stratus
ah okay sorry, I forgot that, thank you
(I call them gifts because we are a nonprofit - but by gifts I mean payments)
somber cipher
Ah, okay, so all of these are just one-off Charges created via our legacy Charges API. These are not recurring in the sense that Stripe recognizes them as recurring, which is why is_recurring isn't working. is_recurring applies to things like recurring Subscription payments, but you're not using Subscriptions here. The only indication that these are "recurring" is the description you're adding to the Charges, which is just that, a description, not some meaningful flag.
I recommend you add metadata when you create these Charges to indicate they're recurring (like recurring: true or similar), then you can use that metadata in your Radar rules: https://docs.stripe.com/radar/rules/reference#metadata-attributes
somber cipher
Yeah, the API requests to create the Charges would need to change.
rain stratus
alright, thank you, I understand
somber cipher
There is charge_description which you could also probably use: https://docs.stripe.com/radar/rules/supported-attributes#card-info
That seems a bit fragile, though.
If you're certain the description content is something you can depend on, though, that might be another path forward.
rain stratus
is that what appears under "description" when looking at a customer record in Stripe?
somber cipher
Yes.
You can see where the description parameter is being set in this request to create one of the Charges you mentioned above: https://dashboard.stripe.com/logs/req_tB2v0vWGFIM5Sv
rain stratus
so, there are two descriptions which refer to the installments "Recurring charge" and "Recurring payment" - if I want to write the radar rule, how do I do an "OR" so that it looks for both of those?
:address_zip_check: = 'fail' AND :charge_description: != 'Recurring payment' OR 'Recurring charge'
The OR there is not right. Also, otherwise, does the rule work?
I know the radar rules aren't your thing - I appreciate your help!
somber cipher
So instead of doing that, you should probably do something like :charge_description: LIKE 'Recurring%' I think. See the LIKE operator here for more info: https://docs.stripe.com/radar/rules/reference#operators
If you do want to stick with the OR approach I think it would be something like :address_zip_check: = 'fail' AND (:charge_description: != 'Recurring payment' OR 'Recurring charge')
rain stratus
yeah because it has to be NOT LIKE (is that possible?)
somber cipher
The parenthesis group the two OR conditions into their own thing, so it means "if zip fails and either of these two other things are true".
Oh, I missed that.
near grottoBOT
somber cipher
One sec...
rain stratus
I'd prefer to do an "Allow" rule, to allow the transaction if zip fails and its a recurring payment, BUT the system wont let me
so I was thinking then to do the opposite?
somber cipher
Maybe this? :address_zip_check: = 'fail' AND NOT (:charge_description: LIKE 'Recurring%')
Wait... the idea is to block transactions which fail the zip check unless they're recurring, right? Meaning if they're recurring the zip check shouldn't matter?
Yeah, if so, I think this would be the full rule? Block if :address_zip_check: = 'fail' AND NOT (:charge_description: LIKE 'Recurring%')
What happens when you try that?
rain stratus
correct - the test I ran looked good
somber cipher
The other version, I think, would be Block if :address_zip_check: = 'fail' AND (:charge_description: != 'Recurring payment' OR :charge_description: != 'Recurring charge')
somber cipher
Oh, I'll bet that last one should be Block if :address_zip_check: = 'fail' AND NOT (:charge_description: = 'Recurring payment' OR :charge_description: = 'Recurring charge')
But in any case the LIKE one is probably the better option.
So are you all set?
rain stratus
yes, I think so! Thank you so much for your help
somber cipher
No problem. Sorry about the trouble getting routed around, and support not being able to help. I've talked with Nathan with the hope of improving things going forward.
Have a great day!
rain stratus
you as well! I am going to spend some time later with my colleagues ensuring the rule is right. if we have any issues, can I just chat here again to you?
somber cipher
Probably not, no. We close idle threads, and depending on when you return the people here may not be able to help.
I've been working at Stripe for many years, which is why I was able to help as much as I did, but we're focused on technical/developer questions on this server (code, APIs, webhooks, etc.) so our Radar knowledge is quite varied, with some of us knowing very little. That's why I attempted to redirect you to support in the beginning.
I think now that you have a working (or mostly working) rule you should be able to get better help from support by including it and asking specific questions if needed.
I'm guessing the main issue earlier was that the term "recurring" meant very different things to the people you were talking with via support.
You will be able to reference this thread at any point in the future, though. You can bookmark the URL to it and can review it even after it's closed: https://discord.com/channels/841573134531821608/1326247522859225219
rain stratus
ok, thank you, have a good day