#simon-radar-help

1 messages · Page 1 of 1 (latest)

mental spear
#

@river rivet we don't know much about Radar here but I can try to help

river rivet
#

thanks.

#

We want to turn on Radar for a region. We do monthly billing but use a preauth when we capture payment details to validate the payment method. The integration looks like this:

  • Create the payment method client side using card element in stripe.js
  • Pass the payment method id to server side
  • create customer server side
  • Create payment intent to preauth the customer and check the card
  • Cancel the the payment intent
#

Looking at the radar docs I have the following questions

  • On which call do we apply the radar rules? Can we apply radar rules on the creation of the payment method? Or just on the payment intent?
  • if we are using radar on the payment intent api call, do we still have the Advanced fraudsignals available that come from stripe js?
mental spear
#

So first off all, let me say that this flow is definitely not allowed and not something you should even be doing. You're not supposed to validate cards that way, especially not by taking an authorization and releasing it

#

Beyond that, Radar applies to payments (or if you checked the box in the settings it also applies to SetupIntents)

#

in your example, the only thing Radar would apply to is

Create payment intent to preauth the customer and check the card
specifically when you confirm the PaymentIntent

river rivet
#

Let me double check that flow then. I may have misunderstood.

mental spear
#

I assume you just built it that way because it works for your use-case, but it's definitely discouraged and card networks don't like that

river rivet
#

While I figure that out, do you have any info on the second part: if we are using radar on the payment intent api call, do we still have the Advanced fraud signals available that come from stripe js?

mental spear
#

yes since the PaymentMethod is created client-side

river rivet
#

👍

river rivet
#

Okay, so we are using that flow. We are calling the payment_intent endpoint with the expected first billing amount, but setting the capture_method property to manual so that we only do the authorization. With that in mind, is this flow still not something we should be doing?

mental spear
#

it is not

#

you're doing this to "validate the card" and it's not okay

river rivet
#

you're doing this to "validate the card" and it's not okay
Well, that's where I might have presented this wrong. We are doing this only in the case where we are going to immediately invoice the customer. So not to validate the card.

mental spear
#

but you said you authorize and then immediately cancel the PaymentIntent

#

it doesn't make sense if you're immediately charging them

river rivet
#

We have provisioning steps in between for new customers/orgs so I assume we want to authorise before we do any of that. Invoicing is handled by a separate system and at purchase time we only have an approximation of what the first invoice charge will be.

#

I'm surprised we wouldn't have been notified that we are doing this wrong before now.

#

But I'll raise it with our team and we can chat to our account manager.

mental spear
#

So you literally do this
1/ Authorize $100
2/ Refund $100
3/ Separately create an Invoice for $100 and charge $100

#

right?

river rivet
#

Yeah, I guess that's how it would look from the stripe side

mental spear
#

we don't care

#

card networks do care. And customers too since many banks will hold funds for multiple days

#

so you hold $200 for like a week

river rivet
#

Understood. Will take it up with our account manager and understand from my team why it was done that way. We are switching to payment elements region by region so that may be a chance to change how we are doing it.

mental spear
#

sounds good