#nitin_api

1 messages · Page 1 of 1 (latest)

sleek sirenBOT
#

👋 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/1379003095505178656

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

warm prism
#

Um I see req_Do4lVwYZsdG4Y0 is a PaymentIntent, while req_PXTOo2ww9GDvLS is a SetupIntent

graceful thistle
#

Yes, that is expected

#

When I tried this test card - 4000002500003155

It triggered 3ds for both payment intent and setup intent

warm prism
#

Yes the test card behavior could be different. 3155 is a widely used 3DS test card, while 0123 is specific for India Recurring

graceful thistle
#

So, is this expected for that indian card?

Ideally, when people make payments for the recurring payment via indian cards they will be triggered 3ds right?

warm prism
#

Yep

graceful thistle
#

Got it, thanks

sleek sirenBOT
graceful thistle
#

@warm prism In real payments, if 3ds is not validated during the checkout session how will the customer do 3ds in the upcoming recurring payments?

Or, in a real checkout session if that card mandates a 3ds will it happen in the checkout session itself?

We are mainly checking this for Indian cards

graceful thistle
#

@glossy valley Can you please help with this

glossy valley
#

Hey! Taking over for my colleague.

#

3DS is managed by the card issuer, they will request 3DS when required

graceful thistle
#

So, the customer will receive a email to complete 3ds is what you mean?

glossy valley
#

It depends on the bank issuer how they implement 3DS, is it per email, sms or bank app...

graceful thistle
#

Got it, just for my confirmation check this

We used this card - 0123 for testing payment, it did not trigger a 3ds while setting up an intent, and later when simulated it to the next payment, the payment failed saying that the customer has to complete 3ds. What is expected with this card? If so, how do we test payments with this card since we are testing for Indian card scenarios

chrome wigeon
#

hello i have question,, why after integration API radar, and open radar free trial,, my account have charge and payout issue?

glossy valley
#

@chrome wigeon you should open your own thread please via #help

graceful thistle
#

So, @glossy valley these 3ds cards will also include testing the mandate setup that indian cards require?

glossy valley
graceful thistle
#

But this again loops back to the same question. While using the indian recurring payment cards we were not able to continue with the simulate payment since setup intent was created initially without any 3ds. The simulated future payment fails with error that 3ds has to be completed by the customer

#

How do we test indian mandate with 3ds in that case?

sleek sirenBOT
solid karma
#

I think that's answered in the link my colleague just shared? Overall I'm not understanding the exact issue

graceful thistle
#

Hi @solid karma , we are trying to simulate indian mandate with the card ending in 0123. We initially create a setup intent and later after 1 hour the invoice gets charged automatically. When triggering setup intent in the checkout everthing looks good, the card gets processed successfully for the setup intent, but when we try to simulate it to 1 hour to complete the payment of the invoice, it fails stating that 3ds has to be completed by the customer. So, how do we test future payments with the card ending on 0123 since it is failing due to 3ds failure

solid karma
#

Can you share the ID of that payment that requires 3DS?

graceful thistle
#

Sure, this is the req id - req_Do4lVwYZsdG4Y0

solid karma
#

I'm confused as to what is unexpected here? You're confirming payment with new card details, not the existing PM that was previously saved/setup

Stripe Login | Sign in to the Stripe Dashboard

Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.

#

Auth must be completed in that scenario so we can generate the e-mandate

graceful thistle
#

That's right, we are setting up new card details. What do you mean by auth? If you mean 3ds we do not get any 3ds popup to complete the auth for this card - 0123

solid karma
#

There should be assuming you're using the confirmPayment function in Payment Element

#

What happens when you call confirmPayment?

graceful thistle
#

Yes, we are using confirmPayment. We call confirmPayment with the setup intent's client secret. It confirms the card without any auth

This is the req id of the confirm payment call that happened without auth - req_Do4lVwYZsdG4Y0

solid karma
#

I'm confused. confirmPayment with a Setup Intent secret shouldn't work

#

It sounds to me like something is blocking the 3DS/auth challenge UI

graceful thistle
#

Sorry, the req id that I shared earlier was wrong. This is the correct req id - req_PXTOo2ww9GDvLS

This was triggering the setup intent client secret only and it worked

solid karma
graceful thistle
#

Please check this request as shared above - req_PXTOo2ww9GDvLS

This does not respond with requires_source_action

We are confirming a setup intent here, will setup intent confirmation not trigger 3ds?

solid karma
#

It can do yep

#

I'm talking about the one that does transition to requires_source_action as ultimately that is the problem here

#

The Setup Intent is irrelevant

graceful thistle
#

No, that's not the problem here. For the one that translates to requires_source_action, we did receive the 3ds popup and everything was fine

The real problem is what I just shared above. For req - req_PXTOo2ww9GDvLS. That 3ds popup is not getting triggered during setup intent confirmation

solid karma
#

Why would you expect a 3DS popup when it immediately suceeded?

#

I don't understand what the actual issue is. I think you're overthinking things

graceful thistle
#

Ok, tell me what's expected here?

We create susbcription with pay_immediately: false . We are confirming the setup intent that got created with new card (0123), and the invoice goes from draft to open in 1 hour, we try to simulate the payment in stripe dashboard by 1hr. But now the payment fails saying that 3ds is not perfrmed by the customer.

So, how do we test this scenario with card - 0123. Did you get it?

solid karma
#

You haven't sent me a payment that fails yet

#

How is the Setup Intent even relevant here? You didn't use the pm_xxx generated by the Setup Intent when you tried to pay the invoice

#

This is where I think your issue lies

graceful thistle
#

Subscription - sub_1RVUj8FpU9DlKp7RG34DFKeN
Invoice - in_1RVUj8FpU9DlKp7RM40KeLHw
Payment - pi_3RVUjYFpU9DlKp7R0rqvONC3

solid karma
#

Yeah I think this is just expected

#

Why do you use a Setup Intent and then immediately charge the resulting PM? If you goal is to reduce friction, then you don't need to create the Setup Intent first

graceful thistle
#

We are creating subscription with pay_immediately: false. That creates a setup intent and not a payment_intent. Hence we were confirming the setup intent

solid karma
#

Then I imagine this is just an edge case of that flow I'm afraid

#

Why do you use pay_immediately: false?

graceful thistle
#

We have taxes to be applied by third party integrations. Hence we use pay_immediately: false

solid karma
#

What does that allow you to do? Update the invoice?

graceful thistle
#

Yes, it updates the invoices with the updated automatic taxes

solid karma
#

OK, but that doesn't mean you need to use/confirm the Setup Intent that is generated. You can discard it and just use the Payment Intent that is generated when you finalize the invoice

graceful thistle
#

We want to confirm if the card details entered by the customer is correct. So, we confirm the setup intent with the card details

And the invoice payment does not happen from our end, since we simulated it this happens at stripe's end itself I believe

solid karma
#

Right, just offering a potential solution to reduce the additional confirmation

#

I imagine this is just a edge case with pay_immediately which we kind of deprecated. It probably doesn't generate a RBI e-mandate correctly or something, which is rleatively new

#

So you'll either have to live with this, or refactor your flow

graceful thistle
#

By refactor, what do you mean?

solid karma
#

We want to confirm if the card details entered by the customer is correct. So, we confirm the setup intent with the card details
Like the Payment Intent will facilitate that too

#

Doing both a Payment and Setup Intent in such a short space of time really redundant

#

And the invoice payment does not happen from our end, since we simulated it this happens at stripe's end itself I believe
Sure, we can automate it. Or you can just confirm the Payment Intent in the front-end with the Payment Element like you do now for the Setup Intent

#

But your customers will need to complete a 3DS/auth challenge flow at the start of the subscription. That's necessary so we can can charge their card off-session for the recurring payments

graceful thistle
#

Or you can just confirm the Payment Intent in the front-end with the Payment Element like you do now for the Setup Intent

How do you confirm the payment intent? We still dont have the payment intent right? We will only have the setup intent in the checkout session since we pass pass_immediately: false.

solid karma
#

You'd get a Payment Intent when you finalize the invoice after making the updates to add tax, etc

#

Right now, that is happen automatically after an hour