#skarmoryman_unexpected

1 messages Ā· Page 1 of 1 (latest)

hybrid crestBOT
#

šŸ‘‹ 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. Thank you for your patience!

ā±ļø We automatically close idle threads, which makes them read-only. Make sure you stick around to chat in realtime! If this thread is closed and you have another question you'll need to start a new thread.

šŸ”— 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/1212981331370315817

šŸ“ Have more to share? You can add more detail below, including code, screenshots, videos, etc.

velvet orchidBOT
zealous breach
#

It's really up to the card issuer to decide whether to check the cvc or not.

coral pollen
#

K so it’s not something wrong with our integration right?

zealous breach
#

No it's not.

coral pollen
#

Ok thanks. I did notice that on session payments made without the use of a customer id validate cvc at a much higher rate. Is it conceivable that saving payment methods is treated differently from on session payments?

zealous breach
#

No I don't see it's related.

coral pollen
#

Ok so is this weird that cvc seems to always be checked when making payments but not when doing setup tents?

#

By your estimation

velvet orchidBOT
coral pollen
#

There?

pure quiver
#

hey there, taking over here, can you share an example SetupIntent where you see the CVC as unavailable?

coral pollen
#

Hey. I cant share our prod data, but most of our setup intents show cvc check unavailable and still go through. Based on docs, and what I heard from the last gentleman this isn’t necessarily a problem.

#

What’s really confusing me is the fact that most(all) of our on session payments (I’ve checked several hundred) which don’t go through a setup intent all passed the cvc check.

#

Not sure why on session payments are being treated differently

pure quiver
#

okay so, some corrections to what was mentioned before, https://support.stripe.com/questions/check-if-a-card-is-valid-without-a-charge - To prevent card testing, Stripe is sometimes required to not check cvc and zip checks on card validations, so they may appear as ā€œunavailableā€.

#

Because of PCI regulations, we cannot store the CVC, so if you make a charge subsequently with that saved PaymentMethod, the CVC check would still appear as unavailable (since Stripe doesn't have the CVC anymore)

#

you can actually recollect the cvc for on-session payments too if you want to

coral pollen
#

Ok thanks. So we’ve established that cvc not appearing on off session payments (ie those made with payment methods that went thru a setup intnt process) makes sense.

#

Dors it make sense that all on session payments (no setup intent) all have cvc check? Sorry maybe you answered and I don’t fully follow.

#

Does card testing not apply here as wrll?

pure quiver
#

yep that makes sense cause you're actually making a payment and that gets passed on to the networks/issuers to process. hence cvc gets passed on at that point in time

coral pollen
#

Why’s cvc being checked all the time etc etc.

pure quiver
#

for a SetupIntent, you're essentially creating a PaymentMethod, and not yet making a payment

coral pollen
#

Ahh ok . So the fact that there’s no setup intent middleman causes the cvc to be checked.

pure quiver
#

yep, you can think of it that way

coral pollen
#

Kk cool. Just needed peace of mind that we weren’t screwing up our integration somehow.

#

Thanks for advising

pure quiver
#

you're welcome šŸ˜„

coral pollen
#

Sorry just one more question

#

So when saving cards cvc usually isn’t requested to reduce card testing fraud.

#

But what if someone happens to guess a correct card number (with wrong cvc) and we make a bunch of off session charges to it? Won’t we get a bunch of disputed? I heard stripe has some sort of machine learning model to deal with this , but I’m not familiar.

pure quiver
#

If you want to ensure that it's really the customer that is adding their card to make payment, probably the best way to go about this is to request for 3DS and then implement your own logic or use Radar Rules (which require RFFT : https://stripe.com/en-sg/radar/fraud-teams) to decide whether to block or accept the corresponding PaymentMethod