#dubmon
grizzled fractal
royal ruin
Hey there!
haughty elm
hi bismarck 🙂
royal ruin
You are talking strictly about format validation here? Or you want to block if the issuer responds that the expiration date is incorrect?
haughty elm
not format validation... block if the issuer response that the expiration date is incorrect
I had a user input an incorrect year for the credit card expiration and Stripe accepted it... but later in on our workflow we use a different 3rd party credit card service and it declined the transaction because the expiration year was wrong. I would like to align on this stricter rule
royal ruin
Thanks for clarifying
This isn't possible because issuers don't actually provide a response about whether the expiration date is correct/incorrect
Sometimes issuers do use an "expired card" decline code as their reasoning for a decline.
But this also doesn't always match up with the expiration date, as it can be an indicator of a stolen/lost card.
haughty elm
oh interesting....
royal ruin
But the only thing the issuer provides a response for is CVC and AVS (postal code)
haughty elm
does the expiration date play into the CVC response?
royal ruin
No, that's totally separate.
haughty elm
it just happens that when the user provided the incorrect expiration year, the CVC check came back as "failed"
so I've added a custom rule in Radar to block the transaction if the CVC check fails
and I've added a block if postal code is wrong too
royal ruin
Yeah the expiry date and CVC are mutually exclusive
So just a coincidence really that both failed in this case.
haughty elm
gotcha
it's interesting that Moneris (the other credit card processing company) failed it just on a bad expiration year... year was 2026 instead of 2025
royal ruin
Hmm yeah I'm not sure how they source that data. We don't get an expiry response which is why you don't see any Radar rule options for that
haughty elm
thanks bismarck... last question (I promise)
here's how I generate the card token
def generate_card_token(cardnumber,expmonth,expyear,cvv):
data= stripe.Token.create(
card={
"number": str(cardnumber),
"exp_month": int(expmonth),
"exp_year": int(expyear),
"cvc": str(cvv),
})
card_token = data['id']
I'm not passing in the postal code.. is there an option on this call to include the postal code?
royal ruin
Yep! You want address_zip: https://stripe.com/docs/api/tokens/create_card#create_card_token-card-address_zip
haughty elm
that's great bismarck!
if the user inputs a bad CVC code, does that require my custom Radar rule to catch this? or will it block out of the box?
royal ruin
Well you don't need a custom Radar rule for that, as we provide that as a default Radar rule. But yes, if you always want to block on CVC then you should enable the radar rule.
haughty elm
with the default Radar rule for this, does it not block by default? curious what the behavior will be
royal ruin
What do you mean "by default"?
haughty elm
you mention it's provided as a default Radar rule
royal ruin
If the rule is on, and the issuer responds that the CVC check failed, then yes the rule will block
Yep the Block if CVC verification fails
haughty elm
but I need Radar for that? without radar, does the transaction simply go through?
royal ruin
Is a default rule that you can toggle on/off on all accounts
Ah I see
Basically it depends
Sometimes issuers will still approve an authorization even if the CVC check fails
It is basically completely up to their fraud models for what they want to do
So if you never want to allow an authorization to go through with a bad CVC then you enable that Radar rule