#asolove - Sca
latent brook
pi_3KYhoPBmBV2o9vP519kPyOcA, ch_3KYhoPBmBV2o9vP51pPx87vm is an attempt for the user to pay on HIP that fails with a decline but never tried to run 3DS.
pi_3KbAWDBmBV2o9vP50z1F7azb ch_3KbAWDBmBV2o9vP50dmplzhe is an attempt done by us manually through dash that succeeds, also ofc without 3DS because it's off-session.
I would 100% believe that both should fail. And I could see the first needing to run 3DS because it's marked as being on a metered billing subscription. But I can't see why it's totally declined without trying to auth.
We've seen this happen repeatedly for India users and never for EU ones, which is what makes me think it may be a weird interaction of internal Stripe logic (and wonder if the first is a real bank-level decline or a synthetic one)
static glen
For that first one, since it's a straight up decline by the bank, I would have the customer reach out to the bank and see what they say
That's our recommended flow
static glen
Yeah it's a "do not honor" by the bank
latent brook
huh any idea why it succeeds when we charge the same card, the same amount, via dashboard?
static glen
Not sure I would first have the customer reach out to the issuer/bank to see why they declined that particular transaction at first
latent brook
so the bank says it's because the first was considered an off-session recurring, which is odd because they are on-session
so if you can see the iso8583, is stripe saying it's off-session or that 3ds is not supported?
pine plinth
👋 @latent brook
pi_3KYhoPBmBV2o9vP519kPyOcA, ch_3KYhoPBmBV2o9vP51pPx87vm is an attempt for the user to pay on HIP that fails with a decline but never tried to run 3DS.
It's not that from what I can see. The Charge was created in the request https://dashboard.stripe.com/logs/req_2q2vQob54x5yRl which is a manual attempt to pay the invoice with a previously saved card, from the Dashboard, from someone at your company (it says who on that page)
Since it came from the Dashboard, it's not on the hosted invoice page and it can't go through 3DS
pine plinth
pi_3KbAWDBmBV2o9vP50z1F7azb ch_3KbAWDBmBV2o9vP50dmplzhe is an attempt done by us manually through dash that succeeds, also ofc without 3DS because it's off-session.
Same here, this charge was created by https://dashboard.stripe.com/logs/req_CLcklhObUJtqkQ which is a Dashboard manual payment from the same person
latent brook
ok sorry must be wrong id, i'll come back
pine plinth
(deleted since there's my name publicly, but hi 🙂)
You also mentioned Indian cards, those definitely come with more complex requirements than normal cards or even SCA since you need authentication on most transactions
latent brook
yeah! that's why I was surprised we've never seen HIP try 3DS before these get declined. Let me find the right examples.
pine plinth
yeah the rules in India are basically "3DS on session for all transactions. Off session declines unless you have an approved mandate already"
latent brook
Sorry for providing the wrong id. Reasonably sure I have this right now.
ch_3KYhoPBmBV2o9vP51QyoNZJf looks to me like it's via HIP and 3DS is supported, but not even attempted, and Stripe gives a synthetic decline.
I have a guess that since we tried to charge the card off-session, when we come back and let the user try on-session, Stripe gives a synthetic decline to avoid us spamming retries. Is that possible?
pine plinth
cc @azure fable I'm taking notes in a meeting for now, can you take over and investigate that one?
azure fable
Copy that
@pine plinth
This charge was also listed as do_not_honor returned via the bank
pine plinth
cc @spare plume this is an IN-based card so I would also have assumed we would do 3DS or their authentication instead of just declining, is that expected to you?
spare plume
Yep, I would expect 3DS to be run here but it is dictated by the issuer anyway in this case. So possible the issuer just decided they were going to decline regardless?
pine plinth
yes but it's an IN-based card, I'd expect us to try 3DS. Isn't it mostly required by now for all transactions in India?
latent brook
if the Invoice/PI were first created and tried in our auto billing flow (with user off-session) is it possible the subsequent attempt on the same PI via HIP is sending cached off-session-like signals to the Stripe rules or issuer so that it doesn't try?
pine plinth
I would say no