#bhaumik

1 messages · Page 1 of 1 (latest)

spiral sphinxBOT
clever fable
#

Let me double check this quickly...

wintry bridge
#

@clever fable I have tried that in the sandbox account, but it was not working.

I added one card from the customer detail page in the portal. At that time I added 123 CVV and when used code suggested by the link you sent I added 456 CVV.

It did not validate & payment was deducted even with the wrong CVV.

https://dashboard.stripe.com/test/customers/

Also, they have added one note to the document you sent me.

https://stripe.com/docs/payments/save-during-payment-cards-only?platform=web#web-recollect-cvc

clever fable
#

Also, they have added one note to the document you sent me.
Yes in fact, if you want to fail the payment besides updating the cvc you need to configure a Radar rule for that.

wintry bridge
#

so the reference you have shared is only updating CVV to a specific card and not validating it, correct?

Also about Radar rules, Stripe document says

"They are using ML/AI to block cards based on customer's historical data + behavioral patterns"

so there are chances that a fresh customer who is paying for the 1st time CVV check may fail because there is no payment history for the same customer.

clever fable
#

so the reference you have shared is only updating CVV to a specific card and not validating it, correct?
Yes

#

so there are chances that a fresh customer who is paying for the 1st time CVV check may fail because there is no payment history for the same customer.
Nope.

wintry bridge
#

I want to trigger wrong CVV error manually in the sandbox account.

so I can be sure that it will work in Produciton.

clever fable
#

Not sure if you can test that particular use case in test mode, because in test mode you can set any cvc when doing a payment if you are using the 4242 card for example.

wintry bridge
#

Will I be able to test the same on production with a real card?

so when adding a card I'll add proper CVV and at the time of CVV validation element & making payment, I'll add wrong CVV.

clever fable
#

You can test in production for sure like any normal card. But we strongly discourage doing tests in production because that may impact the risk analysis of your business.

spiral sphinxBOT
wintry bridge
#

ohh!

so there is no way to make sure if the wrong CVV check is actually working or not until the real customer (someone) accidentally adds wrong CVV.

correct?

clever fable
#

so there is no way to make sure if the wrong CVV check is actually working or not until the real customer (someone) accidentally adds wrong CVV.
In production the radar rules are taken into accounts. You can simply rely on them and fill free to come back if you have any issue with it.

wintry bridge
clever fable
#

You can set/use the radar rule without CVC element.

wintry bridge
#

but then how it would work?

we have 1 page where customers can create/save different payment methods (cards) without actually making payment from that.

And, 2nd page (checkout) is where we have listed all saved cards and customer chooses one card from that & makes a payment.

Radar rule might work on 1st page, to which we are attaching a new payment method. but how would it work on 2nd page (checkout) where customer is just choosing one card and we're passing that into stripe.confirmCardPayment

stripe
  .confirmCardPayment('{PAYMENT_INTENT_CLIENT_SECRET}', {
    payment_method: {PAYMENT_METHOD_ID}
dreamy belfry
#

Well we don't store the CVC outside of the initial time we collect the payment details so yes you'd need to implement CVC re-collection for subsequent payments if you want to enforce CVC checks

wintry bridge
#

okay, so re-collection of CVV + Radar rule both are required to ensure that CVV is correct on subsequent payment requests or not.

dreamy belfry
#

Yep, it is

#

You can perform CVC verification by providing the CVC value either when you create a payment with a new card payment method, or when you attach a new card payment method to a customer. To re-verify the CVC on a previously saved card, refer to the integration guide on CVC recollection.

wintry bridge
#

okay, understood.

sorry, but again repeating the same question.

is there any way in Sandbox, I can trigger wrong CVV error with (re-collection of CVV + Radar rule)

OR

as @clever fable mentioned

In production the radar rules are taken into accounts. You can simply rely on them and fill free to come back if you have any issue with it.

I can implement both (re-collection of CVV + Radar rule) and just be worry free in production 😅

dreamy belfry
#

There's a CVC decline card here: https://stripe.com/docs/testing#declined-payments

Test cards

Use test cards to validate your Stripe integration without moving real money. Test a variety of international scenarios, including successful and declined payments, card errors, disputes, and bank authentication. You can also test non-card payment methods.

#

Otherwise our tests cards accept any CVC value

wintry bridge
#

I'm sorry @dreamy belfry but that card will not work on the 1st page itself, at the time of creating a new payment method for a customer or attaching card.

I want to trigger incorrect CVV on 2nd page (checkout)

#

where card was already stored/attached to a customer and I ask CVV again.

dreamy belfry
#

Yeah I'm not sure that's possible as I stated our test cards accept any CVC really (which would never trigger a failed CVC check)

wintry bridge
#

Many Thanks!!

Then there is no way except to use production & real card and manually add wrong CVV on the checkout page, correct?

#

I'll have to accept the fact that adding the wrong CVV on production might create some issue.

as @clever fable mentioned.

You can test in production for sure like any normal card. But we strongly discourage doing tests in production because that may impact the risk analysis of your business.

dreamy belfry
#

Yeah, nothing I can think of unfortunately

wintry bridge
#

I'll give it a try and see,

Is it fine if I add any questions to this thread in the future?

when I actually implement the code.

dreamy belfry
#

We likely close the thread after a while, but can be re-opened if necessary