#arthurtoper
1 messages · Page 1 of 1 (latest)
hi, i think this is it: acct_1hANScPqurIzqONypnZ6
checking it
I see that the response you got is sufficient to unblock you
what else may we help you with?
we haven't yet been provided with a full explanation as to how to change our processes in order to resolve this problem
is it that you are advising us to adjust all of our subscription payment intent calls, or only renewal ones?
how is the discrepancy of our year 2+ renewals working explained by this approach?
and what assurances can be provided by Stripe that if we make these changes now we will not see further problems in a year's time?
i would also like to understand a timeline for the introduction and subsequent resolution of the bug which caused us this problem
ok let's go back one step
would you mind describing the issue in one sentence?
and giving some details about how you're integrating with Stripe
if i must, but we have been going through this for several weeks with Stripe support, so you should have a full history of the issue
I'm answering 12 other users on discord right now, and haven't had the chance to catch up on your ticket
sure, i don't hold you personally responsible, i'm just doing what i've been told to do by Stripe support
if you want you can reply to the ticket and ask your other questions and get a reply async
which I totally disagree with from the first place, but that's another story.
thanks, i'll feed this back and try to resolve with your colleagues again. sorry for wasting your time
I can help you, but you need to cooperate
like giving me some brief context, and explaining how you integrate
and what's the ask
so I can know what am I trying to help you out with
and give you an appropriate answer
the context is that on 1st May 2023, our SCA exemption rate suddenly dropped, causing a large proportion of our annual renewal payments not to go through as usual:
our integration consists of a front-end ReactJS Stripe form, using Stripe Elements, and a back-end system written predominantly in Ruby which makes use of the Stripe SDK to raise PaymentIntents, create Customers, use SetupIntents, etc.
i don't know what you mean by 'what's the ask', sorry
the ask = the question or the issue
okay
nvm, I'll happily answer
regardless of the exemption rate dropping down, which is not something I can investigate right away on discord, but your integration should be resilient to any ad-hoc request from the issuing bank demanding SCA/3DS auth for a Payment Method that is setup for future usage
would you mind sharing a PI ID or a request ID where this happened?
taking a look
ok 2 things to discuss here
1- you're saying that this is a recurring payment, but you're not using Subscriptions and instead you're using PaymentIntent, which is not ideal. but that's not the major issue
2- you're using setup_future_usage: "off_session" instead of off_session: true
yes; this has been in place and working since 2019
when you first save a PM you use s_f_u: o_s, but when you want to make a payment obo your customer without them being on_session. you need to pass off_session: true otherwise the issuing bank wouldn't know that this is an off_session payment and they can require SCA for every single payment
and this has changed from May 2023?
no not really, it has been the case since a very long time
in which case, how do you reconcile the sudden drop-off from 1st May with this?
were the PIs before May recurring as well? or were they related to new payment methods
they were essentially identical in every way, yes - what we'd term 'renewal payments'
i spent some time carefully checking the payloads before and after May in order to try to rule out some accidental change from our side
i assume this is where the bug your colleague mentioned comes in
however, he did not really provide an adequate explanation of how this affected us, nor a timeline
furthermore, only our 'year 1 renewals' appear to be affected by this, as we've explained in our dialogue with Stripe support
i'm not sure how that can be explained by the off_session thing
would you mind sharing a PI that wasn't failing before May?
taking a look
maybe a card network or an issuing bank hasn't requested 3DS (for whatever reason) even when you're not passing off_session: true but in all cases, this should be changed for the future
and as I mentioned the best way to approach this is to be resilient to the fact that even when passing off_session: true sometimes the issuing bank will respond with an SCA request translating into having a status of requires_action on the PaymentIntent
the thing is, we had very few 3DS instances on renewal payments before May
we have a process to deal with it, but as i'm sure you can understand, getting customers back into the payments flow is not that easy
which you should have a flow to help get your customer back on your page and authenticate the payment
I totally agree, and adding off_session: true should reduce that to a certain extent
i appreciate that, but as i said, a sudden unexpected overnight change was suspicious
my company is nervous about the prospect of further tinkering when, from our perspective, the current situation has not been adequately explained
i need to go AFK for a little while, but i will keep this open and check back later
thanks for your assistance thus far, incidentally - it is appreciated
ok just went through the internal investigation once more, the response that you receive is quite accurate plus the explanation I gave you here. For you to see your exemption rate go back to normal you need to treat your PI in 2 different ways:
for new Payment Methods use setup_future_usage: "off_session"
and for recurring payments use off_session: true