#reginbald_api
slim belfryBOT
👋 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/1445772343527080029
📝 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.
- reginbald_webhooks, 3 hours ago, 13 messages
wheat portal
s.client.V1SetupIntents.Create(ctx, &stripe.SetupIntentCreateParams{ Customer: stripe.String(input.CustomerId), PaymentMethod: stripe.String(input.PaymentMethodId), Confirm: stripe.Bool(true), Usage: stripe.String("off_session"), AutomaticPaymentMethods: &stripe.SetupIntentCreateAutomaticPaymentMethodsParams{ Enabled: stripe.Bool(true), AllowRedirects: stripe.String("never"), }, })
regal thistle
did you enable Radar for Setup Intents? https://dashboard.stripe.com/test/settings/radar
wheat portal
Here's the go code I'm trying out
yes it's enabled
Does it take time to take affect?
regal thistle
shouldn't, no
wheat portal
But does the code above look correct to you?
regal thistle
the code is fine and likely isn't the issue. I'm looking now
wheat portal
Do I maybe need to add the card via a setup intent and then perform the above request?
Ok thank you!
regal thistle
are you sure the rule(s) are configured on the correct account (acct_1SQQE2GqXH8OlxOw)?
wheat portal
Yes, here's the rule id ssr_1SaFYIGqXH8OlxOwfGoTjdVs
wheat portal
yes once sec
like this? :risk_score: < 100 and :is_setup_intent:
Seems to still work req_zYG79mWwf7ftJ1
regal thistle
yeah, don't think it matters actually. I tried testing with and without, doesn't seem to trigger
looking at the records it seems there's no risk score assigned
wheat portal
Does it need to be expanded
regal thistle
I don't think this is anything you can change, likely a bug/missing feature from us and no way for you to test this reliably
slim belfryBOT
wheat portal
Ok, this should catch whether a creditcard status changes, e.g. expires or becomes fraudulent ?
Is there a way for me to add a card and then expire it to test this out?
molten yacht
hey there, just steppong in for @regal thistle who needs to step away
wheat portal
No problem, Do you know if I can add a card and then expire it to test out the card verification via setup intent?
wheat portal
I don't think this is anything you can change, likely a bug/missing feature from...
Should I report this bug?
molten yacht
We have two cards that can be setup/attached then decline later:
4000008260003178 is a 3ds card you can set up, but payments later will decline
4000000000000341 can be attached to a customer but any payments will decline
I'm investigating to see how to report internally (i suspect this is a feature request, that the test card likely only works with payments currently)
If you want to get follow up about this, you will need to write in to support to have a case created: https://support.stripe.com/contact
wheat portal
Ok I'll do that, thank you
I tried 4000000000000341 but it seems to be valid for setup intents, do I need to use payment intents
molten yacht
yes both of those will succeed for setup/attach then decline for payments
molten yacht
No problem, Do you know if I can add a card and then expire it to test out the c...
i was offering a suggestion for testing on this path you asked about
Did you mean something different than that?
wheat portal
The card at least had a success status when I ran
s.client.V1SetupIntents.Create(ctx, &stripe.SetupIntentCreateParams{ Customer: stripe.String(input.CustomerId), PaymentMethod: stripe.String(input.PaymentMethodId), Confirm: stripe.Bool(true), Usage: stripe.String("off_session"), AutomaticPaymentMethods: &stripe.SetupIntentCreateAutomaticPaymentMethodsParams{ Enabled: stripe.Bool(true), AllowRedirects: stripe.String("never"), }, })
I would expected to fail right?
wheat portal
Ok do I need to create then a payment intent with an amount of 1$ and then refund straight away?
I just want to check whether a payment method is valid, not expired, not fraudulent, etc.
Before a user access a feature within my web app
molten yacht
Ok do I need to create then a payment intent with an amount of 1$ and then refun...
What, no. Don't do this. I thought you were asking about a way to set up a card that would later failed payments.
That what setup intents are for, so you should keep using that. What is the exact problem you're trying to solve here?
Also: i've since tested the elevated risk card with my own radar rules and it is blocked
wheat portal
Yeah, so I'm trying to add a card via setup intents and then later on I want to validate the card when a user tries to access a feature that requires a valid creditcard
so when I want to validated it I run the following go code above
molten yacht
The setup intent does that, so what would you be doing later? And why is this elevated risk card relevant to the flow then?
wheat portal
I was told that there aren't any webhooks to notify me that a payment method has become fraudulent or expired so I need to test it right?
molten yacht
Sure, i suppose you could do another setup intent. THat's a bit unusual though if you'd already set it up previously. More common is collecting payment for some premium features etc.
But let's put that aside: can you try separating the create & confirm step for the setup intent with this card? I did my test by creating then confirming client side with Payment Element and it was blocked as expected.
My colleague tested like your flow
wheat portal
Ok, is it not possible to do this only on the server side?
This is essentially for an auction software. Where the card needs to be check when a user registers for an auction
molten yacht
I'm able to have the card declined when confirming the setup intent with the elevated risk test card
Can you try doing that test with the test pm ID (payment_method: 'pm_card_riskLevelElevated') instead of the pm_123 of the card you saved in teh dashboard?
wheat portal
I get succeeded for setupIntent.Status when using pm_card_riskLevelElevated
I only check the status, should I check something else?
and if an error is returned
molten yacht
Can you share your request ID?
wheat portal
req_9tnfQpWEbPTgKR
molten yacht
Hmm interesting. That's basically identical to my own request which is blocked as expected 🤔
slim belfryBOT
wheat portal
Do I need to split up the create and confirm setup intent requests?
molten yacht
You shouldn't need to, no. Conceptually that would be a bug, but also I tested with a single create & confirm request and it was blocked.
wheat portal
The requests are made with an access token retrieved via a oauth2 stripe app that I've created. Do you think that might cause this?
So acct_1SQQE2GqXH8OlxOw installed a Stripe app that I created and during the install I get a refresh token and an access token.
molten yacht
This is part of my working theory, i can see that request was in fact scored
Where is the radar rule created?
On the app-owner account, or on the app-installing account?
wheat portal
The app owner is acct_1SPNmKGRQscie3ei the rule is in the app-installing account
molten yacht
ok hang on
wheat portal
Ok sorry, the rule wasn't enabled pm_card_riskLevelElevated is now blocked
molten yacht
we might have missed a step 0 way back at the start
wheat portal
what is step 0?
molten yacht
It looks like Radar is not enabled for setup intents on that acct_1SQQE2GqXH8OlxOw account
wheat portal
it's enabled right?
molten yacht
did you enable Radar for Setup Intents? https://dashboard.stripe.com/test/settin...
this piece seems to be disabled/off
You're sure that's the acct_1SQQE2GqXH8OlxOw account?
wheat portal
yes, the image is from https://dashboard.stripe.com/acct_1SQQE2GqXH8OlxOw/test/settings/radar
should I disable and re-enable?
molten yacht
Can we try that yea, something isn't adding up
Can you also show the specific rule config for the acct_1SQQE2GqXH8OlxOw account?
wheat portal
Yes,
renabled
Block if :risk_score: < 100 and :is_setup_intent:
rule id ssr_1SaGWYGqXH8OlxOwOSiUR0BS
req_ZD4vaASrdp474b for 4000000000000341
status = succeeded
pm_card_riskLevelElevated fails however req_ki0I5ohOA6vidy
molten yacht
So that one doesn't have elevated risk, so its not surprising. its the elevated risk card that i dont understand why you and i see different behaviour.
aha
wait so what has changed?
molten yacht
`pm_card_riskLevelElevated` fails however `req_ki0I5ohOA6vidy`
This is the expected result now, right?
wheat portal
Yes, correct!
molten yacht
‼️
wheat portal
So this should then work to verify cards programatically?
molten yacht
In terms of risk via radar, yes i would expect so
wheat portal
Can I try this with a card that I add to the customer?
molten yacht
You mean re-run a setup attempt for an existing attached card?
molten yacht
I'd expect yes, though you may encounter 3ds authentication etc
So is the only thing you changed here doing off-and-on-again for the radar on setup intents?
wheat portal
ok awesome, how would I do that. Can I add a card and then mark it as risk level elevated?
No sorry, I think the rule was just disabled unfortunately
molten yacht
I meant you can expect this to work for real, but I am struggling to think how you could test this in your sandbox.
I don't think we have an existing test card designed for this flow
wheat portal
I'm at least unable to add 4000000000000341 via the dashboard when the rule is enabled but if I disable it, add the card and then run the create setup intent with the payment method id it succeeds. I would expect it to fail in that case right?
molten yacht
Not the 341 card no, since i don't expect it to have elevated risk
if you did that with the 9235 card yes
wheat portal
ok let me try that
molten yacht
One you could consider for test flows is leveraging customer metadata
you could have the rule conditional on some customer metadata that you put in place after initial card collection
so the initial setup works (rule is ignored because risk-test metadata is not set), then update the customer, do the next setup intent and it should be blocked
eg add something like ::customer:test_risk_rule:: = 'true'
wheat portal
Ok i tried the 9235 card and that fails when adding it via the dashboard when the rule is enabled but if I disable it, add the card and then run the create setup intent with the payment method id it succeeds. It should fail right?
molten yacht
did you re-enable the rule before the later setup intent? generally I guess I would expect it to fail but:
1/ not sure if there's a delay here for that update to propagate
2/ not sure if the dashboard setup modifies the test card behaviour
i'd suggest setting up the card on the customer via API or Stripe.js confirm in your test sequence, not using the dashboard at all
wheat portal
Ok. I'll try that
molten yacht
The approach i'm suggesting should be stable since it doesnt require settings changes
wheat portal
So I was able to add the card to the customer via Stripe.js when the rule is disabled
After enabling the rule the setup intent create for the payment method id still has status succeeded
It feels like I'm missing something
Here's the request where I add it via client secret and stripe.js req_UfFWfdcS5AGskS
Here is the request when I try to "validate" the card req_1uVKCbk8DCGwxp
molten yacht
Yea i'm missing something too, i don't understand why that sequence would behave differently
wheat portal
Here is the request where I have the rule enabled and try to add the card via stripe.js and that fails req_gd78tEmgFnW7aa
Should I report this as a bug or what should I do?
I guess I can just trust that it will fail even though I can’t test it
molten yacht
After thinking about this it really does seem unexpected. It's possible reactivating the rule is not instant, which could be probed by tryint to set up the same 9235 again via ELements after the server-side revalidation step. If that succeeded, for example, it would indicate the rule is still not applying.
My other thought is that the recent setup success & mandate might referenced during the re-validation and its not actually re-running that.
If you have the time to try the metadata approach with the stable rule setting, that would also eliminate the unstable rule complexity
Ok i actually just finished testing that sequence, and while the rule condition works on initial setup, doing an additional setup intent for a previously set up pm_123 is not blocked
At this point i think we have a clear sequence that does not behave as expected
I'm going to have our bot send you a DM with a link to create a case with my team so i can report this to the Radar team to investigate/explain, in particular whether this would behave different in live mode.
slim belfryBOT
Hello @wheat portal, we have sent you a direct message, please check it at https://discord.com/channels/@me/1445813022592467118
- 🔗The message has instructions on how to open a direct support case with our Developer Support team, in order to help you more effectively.
wheat portal
Ok thanks, as a feature request It would be awesome if I could add a card and then mark it as expired, high risk, etc for testing
molten yacht
Yep, or a test card that you can initially set up that would later be fraudulent etc
THanks for your patience while i tested and investigated this a bunch of different ways
wheat portal
Thanks, I went to the link that the bot sent me and it's just the support page. Should I see a form to fill out?
slim belfryBOT
crimson palm
hey @wheat portal , sorry for the delay - the link should take you to the support page with a different prompt in the little chat window in the bottom right
wheat portal
This is what I see
