#adaxer-checkout-3dsissue
1 messages · Page 1 of 1 (latest)
Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- adaxer-checkout-failedpayments, 20 hours ago, 21 messages
Hi there 👋 this is a Checkout Session integration you're using, correct? Can you share a specific Checkout Session ID that encountered this behavior, and share when the customer attempted to access it? Are you able to reproduce this behavior in testmode?
I actually reproduced it on production, I don't have a https test server so I cannot integrate stripe there. This is how I create the checkout session:
line_items=[
{
'price': price_id,
'quantity': 1,
}
],
mode='subscription',
success_url=request.build_absolute_uri('/checkout/success/'),
cancel_url=request.build_absolute_uri('/checkout/error/'),
metadata={
'user_email': user_email,
'plan': plan,
},
allow_promotion_codes=True,
)```
The IDs I sent in my inital message should be payment IDs, is that enough for you to track back the checkout session id or do I have to find it myself? Not 100% how to do that in that case.
I'll need a specific ID. Those expiration messages may be expected depending on how much time has passed between the session being created and the customer tries to access the URL.
If you're able to see it with freshly created sessions, then that's something I'd want to take a closer look at, and would like to know exactly what steps you take to see that behavior.
I reproduced it earlier today:
cs_live_b1fw9iTPH27pmZosobYsJDnWbRLfUZ1ngEMN3mWESE0jX1lELt5KI3FX3U
Do you want those IDs?
What steps did you take with that session to see the behavior you're describing?
I created a session, inserted my credentials, clicked buy and then it instantly sent me to this url - https://checkout.stripe.com/c/pay/cs_live_b1fw9iTPH27pmZosobYsJDnWbRLfUZ1ngEMN3mWESE0jX1lELt5KI3FX3U#fidkdWxOYHwnPyd1blppbHNgWjA0SH1ANj1ATmR3cGFCUWNVbU1wNDJRZDBhNEFrPUx2MDRyf2tdNlVhYmNPVF9RVU0xN2pRUjRXMmthYFFocTZ0dW5HTE02SmZASmYxXG5VYDA8UX0wSkh2NTV8R1d2fXFwdicpJ2N3amhWYHdzYHcnP3F3cGApJ2lkfGpwcVF8dWAnPydocGlxbFpscWBoJyknYGtkZ2lgVWlkZmBtamlhYHd2Jz9xd3BgeCUl.
Essentially in English that means "The link has expired".
And this was on Chrome, on Safari it worked with the same credit card? Pretty weird.
Hm, are you able to reproduce this in testmode? I'd like to step through that, but I won't do so for live sessions that are actually processing payments.
Do you also have the full network logs of the requests that were made? I'm not sure why you would get redirected to another Checkout Session after completing one (or back to original one maybe, I'm still not sure I have enough details to know that). I'm wondering if you're getting sent out to your success_url and then back to Checkout.
What do you mean by full network logs?
In safari the 3DS verification come up, but in Chrome the "link has expired" error comes up.
Like from the browser logs, what network requests were made. 3DS2 allows for frictionless authentication, so there may be times where it's expected to not see an authentication modal but for authentication to still occur.
Do you see the same behavior if you use an incognito Chrome window?
Perhaps this?
The Network tab to the right of that Sources one you have selected
I want to see what network calls are made after you submit the payment, and the status of them. You can clear the logs before paying (I would really recommend switching to test mode if you haven't already to try to test this instead of triggering real payments) and show what network calls were made after the payment was triggered
that 400 by authenticate looks like it could be a problem
That's the picture after the payment, do you want to see anything from the authenticate one?
Nope, think I have what I need and am taking a closer look.
It looks like the 3DS authentication failed right now, but I'm looking at that more closely.
Yup, it looks like the payment failed because the issuer said the authentication failed.
Unfotunately I don't have insight into why the issuer deemed the authentication to have failed, that's a decision they solely control.
So this is not a stripe problem?
Not from what I'm seeing. The issuer is declining to approve the transaction, so the payment fails. Now that we know this happens when authentication fails, can you try to reproduce this in testmode using a test card that requires 3DS and simulate a failed authentication?
It could be unexpected for the session to be expired, that's the part I'm a bit unsure about.
The second card from this list could be a good candidate for testing, since it always requires authentication:
https://stripe.com/docs/testing#authentication-and-setup
As I can't change to testing right now I'm doing an extensive test with a 1kr payment.
What it looks like to me is that no one has been abled to pay with credit card.
The only ones that have succeed are the ones that have payed with apple. It seems like to me that it's an error with stripe that doesn't correctly handle 3DS authenticating, because the user doesn't even get a chance to complete it - it just sends the user to some error page.
There is no way this is not a problem with stripe, I've had 10 failed payments with users having the same problem.
Are they all using a card from the same issuer/bank?
No different ones, the pattern is that the only ones that have succeeded are those who have used apple pay.
And to clarify, with 3DS2 there are definitely times when it may be expected for authentication to happen without customer interaction, that's the frictionless authentication flow that the newer version of the standard supports.
It actually seems this isn't even isolated to card payment methods
That's right, it happens when someone tried to use link as well,
I think this needs a closer look than I have the bandwidth to offer, looking for a teammate to take a closer look
Catching up on context
So to clarify, the customer clicks the pay button and then they're immediately presented with the checkout session is expired page?
Correct.
Got it. And you haven't repro'd in test mode?
I haven't, I'm unable to do that.
My staging server does not have an https so stripe doesn't want to accept it as a valid testing site.
You don't need a server
You can just create a session with the test api key
I can try to repro in test mode now
Sure, please do that.
Are all your customers in a particular region?
Or are you seeing no pattern based on location?
Gotcha
Getting further help internally. Will keep you posted
adaxer-checkout-3dsissue
Ok so got help from a colleague on this. Looks like you are deleting the underlying subscription in this request: https://dashboard.stripe.com/logs/req_O5JB8UYbobdFmq
That's causing the session to expire
Are you listening for invoice.payment_failed events and deleting the subscription there?
Yes I am.
Okay so that's the problem/what's causing this
Should I just completely remove it?
you are basically stopping the payment attempt entirely in this flow, if you cancel the underlying Subscription or PaymentIntent then it causes the Checkout Session to expire
Ah, I see. Don't I need that webhook to manage payment renewals that are not going through though?
Is there an alternative webhook to listen to perhaps?
(That only sends if the renewing subscription fails.)
I guess the first question is: why would you cancel the Subscription on the first payment failure? That's really uncommon for a Subscription
I thought the invoice_payment_failed is only sent if a payment fails - like if you try to renew your subscription but for some reason your card is declined.
How come it is sent to my server even when it didn't fail?
It did fail, 3DS was rejected and blocked the payment.
How come 3DS was rejected then? I never had the chance to complete 3DS?
But still even if it does it's really uncommon to cancel the Subscription immediately. Almost all businesses who take recurring payments will also allow for failed payments and try to recover revenue
3DS isn't always visible, a lot of the transactions with 3DS happen through device fingerprinting for example and is invisible in the browser
I can certainly implement methods to avoid canceling it immediately; that's not a problem. But now you're suggesting that this isn't the root issue? It's hard to believe that 3DS authentication could fail for every person who has tried it, especially since it never fails when I make purchases on other websites with my card.
Why does the invoice.payment_failed event get triggered when someone attempts to make a payment if it hasn't actually failed? The reason I initially implemented that was to identify and handle errors with Stripe. Interestingly, when people use Apple Pay, everything goes smoothly, and the failed invoice event isn't triggered. So, I still have doubts that this is the underlying problem...
Apple Pay doesn't do 3DS at all so that's expected. I'd rather not get too much into the weeds of what's happening internally here. The problem is that because the payment fails, you cancel the Subscription, which blocks the Subscription instead of letting them remediate the issue
Okay so just removing the invoice.payment_failed would fix this issue? Or would I have to implement another way of catching an error with the payment?
https://stripe.com/docs/payments/checkout/fulfill-orders this is how you handle Checkout fulfillment
Alright, I'll try to mix with some of my code and I'll be in touch.