dsaldeno

[alpine moth]

Hello, are you using a Stripe hosted page like Checkout or are you including Stripe Elements in your own page?

Typically the way to do this is by checking the fingerprint of the PaymentMethod object that you just created and comparing it to fingerprints of already saved cards. If it matches an existing fingerprint, you would then either not attach the new card in the first place or you would detatch one of the cards if both are already atatched

[thin gust]

Thank you. This is perfect.
One last question, I found that I am able to add a card using incorrect zip codes for example 00000 and also process payments using this zip code on the card being used. Is there a way to avoid the use of non-existing zip codes when adding a card or processing the payment?

[alpine moth]

Is this in test mode or are you seeing it in live mode?

By default there should be a radar rule on that blocks payments when the bank says the postal code doesn't match their records https://stripe.com/docs/radar/rules#traditional-bank-checks

[thin gust]

I see it on live mode.

it's odd I am able to process the payment.

[alpine moth]

Do you have the ID for a specific payment that you saw this with (pi_123? Honestly it might be that the bank approved the payment an didn't do the check, so your radar rule didn't block it because the check didn't specifically fail

[thin gust]

I just tested with this: pi_3O0m7cGIcDWf4swC0fDnOqs6

I later canceled the payment manually. I was just testing if it was going through with the "00000" zip code.

[alpine moth]

Interesting I do see address_postal_code_check: "fail", on that payment. Looking further...

Ah it looks like your postal code check rule for radar has been disabled

https://dashboard.stripe.com/settings/radar/rules

[thin gust]

I see, thank you for the help on this!

[thin gust]

Hey - just made the changes and did some test and have a couple of other questions.

• Is there a check rule for expiration date? Currently able to book the class in live mode with a wrong expiration date.

[alpine moth]

Good question, looking in to that. As far as I know, banks only typically return address and CVC check info. I think the postal code can throw off the CVC check for some banks, but not all of them it sounds like

Unfortunately I am not seeing an expiry related attribute in our supported attributes doc https://stripe.com/docs/radar/rules/supported-attributes

If you talk to our support team they may have more info on this but unfortunately at the moment I am not seeing a way to do this

[thin gust]

Got it. Understood.
Last question I have, is that currently in our app we have first a page to add credit card information and then after adding a credit card and save it, users are able to process a booking.

After adding the rules, the User is able to save a card with the wrong CVC or Zip Code but they are not able to process the payment. I was wondering if there is a way to already detect and not allow users to save the card with this incorrect information.

For example when the User is adding a wrong card number it will tell them on the pop-up to save the card. I was just trying to see if we can get the same type of error for incorrect CVC or Zip Code.

[alpine moth]

You can turn on Radar for SetupIntents in your dashboard settings https://dashboard.stripe.com/settings/radar

That will apply the same radar rules to setups, so if the bank returns failures on those checks we should block the setup

[thin gust]

Thanks. I just turn it on, however still able to add cards with incorrect zipcode/CVC. Should I wait some time before able to test?

[shrewd edge]

Hi 👋

I'm stepping in as @alpine moth needs to go. Zicpode and CVC checks occur when the authorize cards with the banks. Do you have an example payment method ID I can review?

[thin gust]

Thanks. Where can I find payment method id?

[shrewd edge]

On your account

When you attach the card

[thin gust]

On Stripe I have this number not sure if this is: cus_OQXpAXjLV9OIfF

[shrewd edge]

That is a customer. But is that the customer you are attaching cards to?

[thin gust]

yes, I just attached this card to this customer

[shrewd edge]

Okay so the address and zipcode checks have not occurred yet. If you look that the payment method, they are unchecked.

[thin gust]

do you mean this?

[shrewd edge]

Yes

[thin gust]

Yes, so my question is how can we check them when they are setting up the payment the same way we check the credit card

How can I get this error when User is setting up a wrong CVC or Zip Code

Currently is only checked when the User is processing a payment. I want to check it when they are setting up the credit card.

[shrewd edge]

You cannot

We can determine as the customer enters the number if it matches certain checks

But only the issuing bank knows if the address is correct or not

So we pass the values when we attempt a charge and they return with the check value

[thin gust]

Got it so Stripe only passes the values when attempting the charge.

I though based on this message below that we could set-up the radar rules and block the payment set-up:

"You can turn on Radar for SetupIntents in your dashboard settings https://dashboard.stripe.com/settings/radar

That will apply the same radar rules to setups, so if the bank returns failures on those checks we should block the setup"

[shrewd edge]

In that specific message, my colleague states this will occur only if the bank returns failures on those checks. We still need to make the checks

Sometimes banks with autorize charges even if those checks fail

Turning on the radar rule will prevent those charges from going through

[thin gust]

So to make the checks we need to try to process the payment correct?

Where the link says: "Use radar on payment methods saved for future use." - this is about blocking banks authorizing charges in case the checks fail?

Where it says: "You will be charged per SetupIntent confirmation attempt" this is also talking about processing payment? I am asking is because it all sounds like setting up the payment (adding the credit card).

[shrewd edge]

What text are you referring to?

[shrewd edge]

Yes that is because we will make an authorization charge which incurs a fee from the issuing bank

[thin gust]

but that's when setting up the payment

not when processing it

[shrewd edge]

Yes. How are you creating and attaching your payment methods?

[thin gust]

Stripe UI. So then if I am being charged if I turn on this I should be able to confirm the CVC and Zip Code at this stage when setting up the payment

[shrewd edge]

And you are using Setup Intents to initialize the Payment Sheet?

[thin gust]

yes correct.

[shrewd edge]

Can you share the ID of the latest setup intent?

[thin gust]

seti_1O0npRGIcDWf4swCtX6Jlt5v

[grizzled depot]

👋 hopping in here - since snufkin had to head out

Setup Intents do not always result in us talking to the bank (sometimes we determine whether we believe setup will success or fail based on the information we have)

We talk about this a bit more here: https://support.stripe.com/questions/check-if-a-card-is-valid-without-a-charge

So yes, in this case that setup intent was allowed to succeed because we didn't talk to the bank and didn't get back information on whether the cvc and zip were valid

[thin gust]

OK, but there are cases where set-up intents results in Stripe talking to the banks correct?

I am trying to understand better as Pompey share the link and mentioned that it could be done but then Snufkin said something completely different and than it will only check when processing. When I shared the link and copy with Sufkin it seems he understood it could be done I guess that's why he asking me for the ID on the set-up intent.

[grizzled depot]

Yes, there are some setup intents where stripe talks to the bank but it's not something you can force/guarantee for all setup intents

[thin gust]

OK, and the only way for Stripe to check sometimes if is this in on. In case this is off (screenshot) then it will result in Stripe never checking the validity of the CVC or Zip Code until processing the payment correct?