#oboxodo-checkout-fingerprint
1 messages ยท Page 1 of 1 (latest)
Hello ๐
I think you'd need to configure radar rules for both usecases.
Mmm... I think I briefly used Radas years ago for #2. Had forgotten about it. But Not sure if Radar would be able to cope with #1. Do you know if it will?
Would I need some higher Radar plan?
Not sure about the radar plan but it should work with 1/. however, it would require a lot of manual work.
The idea is to keep track of card_fingerprint and not allowing a trial if they've gotten one already
https://stripe.com/docs/radar/rules/reference#:~:text=example%2C US).-,card_fingerprint,-Case%20Sensitive%20String
Instead of radar, I can think of you can listen to webhook events checkout.session.completed and cancel the trial if you find that the card was already used before
I'm looking at https://dashboard.stripe.com/settings/radar and I don't think it's showing the old rules I had configured years ago. Is it possible this feature has been moved to Radar for Teams? Isn't there some minimum set of rules I should be able to use without upgrading to teams?
Yeah, what you're describing as a workaround using webhooks is what I had in mind. But it's quite bad UX to allow them to start and then cancel them immediately.
We currently keep track of the fingerprints and prevent the free trial from start but we're using Stripe Invoices via the API and we're looking for leveraging Stripe Checkout instead, to try and delete all (or as much as we can) of our invoicing-related code.
Apologies for the delay, the server is running a little busy
I think the rules are located under Payments > Fraud & risk
https://dashboard.stripe.com/radar?startDate=2022-07-26&endDate=2023-01-23
Yeah, what you're describing as a workaround using webhooks is what I had in mind. But it's quite bad UX to allow them to start and then cancel them immediately.
We currently keep track of the fingerprints and prevent the free trial from start but we're using Stripe Invoices via the API and we're looking for leveraging Stripe Checkout instead, to try and delete all (or as much as we can) of our invoicing-related code.
I see. Unfortunately, there aren't any workarounds for this at the moment. The PaymentMethod needs to be tokenized in order to get the fingerprint and compare. With Checkout, it might not allow for a good UX. You may want to build your own integration using elements instead.
mmm... so we could collect the credit card using elements, then use the API to create the customer with the payment method already vetted... and only then create the checkout session... but we'd have to forbid the customer from changing the payment method in the session. Can we do that? ๐ค