#onur-eker_api

1 messages · Page 1 of 1 (latest)

kindred tokenBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1423391696367911114

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

chilly dirge
#

HI 👋

You shouldn't be using confirmCardPayment wit the Express Checkout Element. You should be using confirmPayment. Let's start there

reef valve
#

yeah, the issue is; I'd like to test triggering this first in our dev environment. But either using 3155 or 3184 in Klarna flow doesn't trigger an additional authentication.

chilly dirge
#

So you are loading the Klarna UI and attempting to provide a Stripe 3DS test card number?

reef valve
#

correct

chilly dirge
#

Yeah that doesn't go through the same process as testing native card payments with Stripe

#

We are handing off to a Klarna sandbox environment

reef valve
#

looks like most of the time Klarna is handling it even for 3184

chilly dirge
#

So you should not expect Stripe test cards to work the same way

reef valve
#

Some not

chilly dirge
#

I cannot use a dashboard link. Please just provide the request ID

reef valve
#

req_UzgFpknKwMDPk5

chilly dirge
#

Also, as I said, we hand code execution off to a Klarna managed sandbox. I cannot offer guidance on exactly what makes some payments succeed or fail. Klarna will have their own logic for handling any additional authentication required by card issuing banks but unfortunately our testing docs don't provide the specific details to trigger the flow you are after

#

Well I see it succeeds but I don't see any 3DS being handled by Stripe

reef valve
#

yeah the issue is; payment intent's status is changed to requires_action, and our system then triggers side effects with that.

Maybe if it is a Klarna payment; and intent requires_action; we skip those side effects.

#

I will test that scenario

#

one problem is; I haven't even seen an additional authentication step in Klarna UI too

chilly dirge
#

Any Payment Intent that expects a Klarna payment method will transition to a requires_action status. This is what prompts our SDK to redirect to Klarna

kindred tokenBOT
reef valve
#

I don't think all of them transition to requires_action status.

req_YOFUdgH4vfAgjC -> requires_payment_method

Then transitions to

req_UzgFpknKwMDPk5 -> requires_capture

I have a lot of payment intents with Klarna; that wasn't switched to requires_action ever

teal meteor
reef valve
#

sorry, I think I pasted the wrong ones. Here:

req_7lFknoNzN5WNv7
req_RZbH8Bcuebk54V

#

I am just trying to understand in what circumstances requires_action is triggered with Klarna payments.

This is easy to trigger with card payment flow with the test card ending with 3184.
But I tried a few other cards including 3DS cards in Klarna UI; haven't seen any additional authorization steps.

#

My theory is 3DS is handled on Klarna modal (which I wasn't able to trigger yet) and no action is required on our side to seperately confirm this on the frontend.

Normally when we get requires_action status response; we use confirmCardPayment on the FE with client secret returned from the intent.

teal meteor
#

Gotcha, still looking in to this. I think the difference here is that with req_YOFUdgH4vfAgjC the intent was confirmed server-side which mean the redirect had to happen still whereas with req_RZbH8Bcuebk54V it was confirmed client-side with a confirmation token and I think the token is created after the redirect happens. Double checking that

reef valve
#

got it. our flow is like this

If new card, or Apple/Google Pay -> FE calls Stripe with createPaymentMethod (for card payments) -> receives payment method id from Stripe
FE calls server to create intent with payment method id -> server returns payment intent id
FE calls server to confirm intent -> server makes validations and calls stripe to confirm
If server receives requires_action status -> server returns client secret to FE -> FE calls confirmCardPayment

#

I think specifically for Klarna, we are using confirmation token

teal meteor
#

Confirmation tokens work for cards as well, so you should be able to simplify things by moving to confirmation tokens for both. I actually didn't know you could get the ECE to make both PMs and CTs on the same page