#oboxodo-checkout-fingerprint

1 messages ยท Page 1 of 1 (latest)

bold carbonBOT
serene snow
#

Hello ๐Ÿ‘‹
I think you'd need to configure radar rules for both usecases.

maiden sedge
#

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?

serene snow
#

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

maiden sedge
#

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?

maiden sedge
# serene snow Not sure about the radar plan but it should work with 1/. however, it would requ...

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.

serene snow
#

Apologies for the delay, the server is running a little busy

#

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.

maiden sedge
#

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? ๐Ÿค”

serene snow
#

No, you can't prevent users from changing their payment method in a checkout session

#

But the idea is that you don't need a checkout session anymore since you've collected the PaymentMethod already

#

You can just start a subscription OR create an invoice by calling the API directly