#adaxer-checkout-3dsissue

1 messages · Page 1 of 1 (latest)

plush wingBOT
#

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.

lime locust
#

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?

trim laurel
#

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.
lime locust
#

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.

trim laurel
#

I reproduced it earlier today:

cs_live_b1fw9iTPH27pmZosobYsJDnWbRLfUZ1ngEMN3mWESE0jX1lELt5KI3FX3U

Do you want those IDs?

lime locust
#

What steps did you take with that session to see the behavior you're describing?

trim laurel
#
#

And this was on Chrome, on Safari it worked with the same credit card? Pretty weird.

lime locust
#

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.

trim laurel
#

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.

lime locust
#

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?

trim laurel
#

Perhaps this?

lime locust
#

The Network tab to the right of that Sources one you have selected

trim laurel
#

Is there something specific there you want to see or just a picture of it all?

lime locust
#

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

trim laurel
#

That's the picture after the payment, do you want to see anything from the authenticate one?

lime locust
#

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.

trim laurel
#

So this is not a stripe problem?

lime locust
#

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.

trim laurel
#

As I can't change to testing right now I'm doing an extensive test with a 1kr payment.

trim laurel
#

There is no way this is not a problem with stripe, I've had 10 failed payments with users having the same problem.

lime locust
#

Are they all using a card from the same issuer/bank?

trim laurel
#

No different ones, the pattern is that the only ones that have succeeded are those who have used apple pay.

lime locust
#

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

trim laurel
lime locust
#

I think this needs a closer look than I have the bandwidth to offer, looking for a teammate to take a closer look

lost cobalt
#

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?

trim laurel
#

Correct.

lost cobalt
#

Got it. And you haven't repro'd in test mode?

trim laurel
#

I haven't, I'm unable to do that.

lost cobalt
#

Why not?

#

All you need is your test api key to create the session

trim laurel
#

My staging server does not have an https so stripe doesn't want to accept it as a valid testing site.

lost cobalt
#

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

trim laurel
#

Sure, please do that.

lost cobalt
#

Are all your customers in a particular region?

#

Or are you seeing no pattern based on location?

trim laurel
#

All my customers are in Sweden.

#

It's a swedish based service.

lost cobalt
#

Gotcha

plush wingBOT
lost cobalt
#

Getting further help internally. Will keep you posted

pine fossil
#

adaxer-checkout-3dsissue

lost cobalt
#

That's causing the session to expire

#

Are you listening for invoice.payment_failed events and deleting the subscription there?

trim laurel
#

Yes I am.

pine fossil
#

Okay so that's the problem/what's causing this

trim laurel
#

Should I just completely remove it?

pine fossil
#

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

trim laurel
#

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.)

pine fossil
#

I guess the first question is: why would you cancel the Subscription on the first payment failure? That's really uncommon for a Subscription

trim laurel
#

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?

pine fossil
#

It did fail, 3DS was rejected and blocked the payment.

trim laurel
#

How come 3DS was rejected then? I never had the chance to complete 3DS?

pine fossil
#

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

trim laurel
#

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...

pine fossil
#

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

trim laurel
#

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?

pine fossil
trim laurel
#

Alright, I'll try to mix with some of my code and I'll be in touch.