#vishesh-purohit_api

1 messages · Page 1 of 1 (latest)

slender quiverBOT
#

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

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

hoary marten
#

hi there!

#

indeed, paymening multiple invoices can result in multiple 3DS flow, which is not ideal. so combining all payments into one PaymentIntent, and then marking the Invoices as paid out of bands makes sense.

hearty delta
#

Hey @hoary marten We no longer want to consider the solution paid_out_of band for marking the invoices true, There should be direct mapping of the payment components with the invoices.

hoary marten
#

I'm not sure I follow. can you clarify your question?

hearty delta
#

We want to enforce 3DS authentication for paying all invoices, while still keeping the user experience smooth. Even when a user is paying multiple invoices at once, they should be required to complete at most one 3DS challenge. So we're thinking of creating a large paymentIntent of total outstanding balance (total invoices balance) and do 3DS on it. if it's successfull we then attach a portion of the paymentIntent to each of the outstanding invoices. it looks we can't do that.

hoary marten
#

it looks we can't do that.
which part you can't do? you mean "attach a portion of the paymentIntent to each of the outstanding invoices"?

acoustic flint
#

Yes

slender quiverBOT
acoustic flint
#

Is there a way to perform a single 3DS authentication and apply it across all the PaymentIntents being charged in the same session? And if that's possible, does the liability shift from that single 3DS authentication carry over to all the other PaymentIntents, or does each one need its own independent 3DS for liability shift to apply?

junior dock
#

How are you actually collecting payment informartion from customers and paying the invoices? What APIs/UIs are you using?

You seem to be overcomplicating this to be honest. Theoretically you should be able to 'setup' a card (e.g. do 3DS) on an initial invoice payment, and then re-use the same card on further invoice payments without triggering auth/3DS again

acoustic flint
#

We're using Stripe Elements on the frontend to collect the card, and on the backend we create a SetupIntent with usage: 'off_session' to save the card and do the initial 3DS during setup. Then when the customer hits "Pay Outstanding Balance", we loop through all their open invoices and charge each one off-session using the saved PaymentMethod.
The issue we're running into is that even though 3DS was completed during the SetupIntent, some banks are still requiring re-authentication on the actual charge — so when we have say 3 open invoices, we end up with 3 separate requires_action responses, each needing its own 3DS challenge.
We want to enforce 3DS on the actual charge rather than just at setup time, which is why we started looking at creating a single on-session PaymentIntent for the combined total. But you're right that we may be overcomplicating this — is the correct approach to just confirm each invoice's PaymentIntent on-session one by one, so that the first one triggers 3DS and the subsequent ones benefit from the existing authentication without re-challenging the customer? And would liability shift apply across all of them in that case?

junior dock
#

I'm looking at the example request you shared: req_Yae9gxTQm6ilJq

In that request is a Payment Intent (pi_3TR7k1RvnJQt6Z8t18OJtBxy) which was paid here, using this Payment Method: pm_1TR7lBRvnJQt6Z8tATIxYLSA

But that PM is the 4242 test card which won't ever trigger 3DS/authentication, so overall I don't understand the flow. Can you provide an actual example where the invoice payment required 3DS?

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.

hearty delta
#

Hey @junior dock This above example was just to test if we can attach a single paymentIntent to multiple invoices or not. For ex: There 3 open invoices with $100 each, We want to create one single payment intent of $300, enforce 3DS on it. if the payment go through, we try to attach a portion of paymentIntent to the invoices to settle them.

junior dock
#

Can we take a step back here, looks like I'm talking to two different people with different messages

#

One of you says you want 3 separate Payment Intents without 3DS for them all, the other says you want to do partial payment/attachment. Which is it? We're talking about two different problems

#

The beta header (invoice_partial_payments_beta v2) you're setting is deprecated/removed since the feature is out of beta

hearty delta
#

@junior dock We currently have the feature like, When customers enters a new card and clicks on pay all my outstanding balance.
We setup the card enforcing 3DS (setupintent) and then attempt payment on each of the outstanding invoices (paymentIntent).

But we now, we want to move the 3ds from card setup to actual transactions (PaymentIntent).

Porblem with this is since there can many outstanding invoices. and we create seperate paymentIntent for each invoices, so we enforce 3DS on each paymentIntents, customer will be asked to complete 3DS challenge for multiple times, which is a Bad UI experience.

Instead, We thought of creatting just one single paymentIntent with total amount, enforce 3ds on it so customer gets to complete just one 3ds challenge, and once paymentintent is successfull. and we utalize this paymentintent to settle all oustadining invoices. but stripe says, we can't attach a paymentIntent to multiple invoices.

I'm talking about multiple applications (portions) of the same payment Intent not partial payment.

junior dock
#

Instead, We thought of creatting just one single paymentIntent with total amount, enforce 3ds on it so customer gets to complete just one 3ds challenge, and once paymentintent is successfull. and we utalize this paymentintent to settle all oustadining invoices. but stripe says, we can't attach a paymentIntent to multiple invoices.
Yes, that won't work. The relationship is 1:n (invoice:payments), but 1:1 (payment:invoice) – you can't have a single payment that pays multiple invoices

So you're likely going to need to use the other approach and have a payment per invoice, ensuring that the card is correctly saved/setup during the initial payment. Can you share an example Setup Intent with me that you're using to authenticate the card before payment?

#

Also, some example pi_xxx IDs where 3DS was requested with the same card multiple times

#

(it's a lot easier for us to help you with some examples of what isn't working)

slender quiverBOT
acoustic flint
#

here are some invoices : in_1TRXaJRvnJQt6Z8tlWbqoPyr, in_1TRXZURvnJQt6Z8tqtCl240D, in_1TRXYoRvnJQt6Z8tw0DOqyBX

#

related pi: pi_3TRXaaRvnJQt6Z8t0i9Jqmol, pi_3TRXZnRvnJQt6Z8t0x1Rz3gT, pi_3TRXZGRvnJQt6Z8t09Yadqxm

junior dock
#

Thanks, let me take a look

#

OK, looks like payment was attempted on all those invoices/payment with this token (example): pm_1TRXe2RvnJQt6Z8tIQl9nH0W

This token was created via the Payment Element (here), using this test card: ``4000000000003220`

Crucially, that test card always requires 3DS/authentication for every payment. As noted here:

3D Secure authentication must be completed for the payment to be successful. By default, your Radar rules request 3D Secure authentication for this card.

So the behaviour you're seeing is expected – you're using the wrong test card

acoustic flint
#

But I believe that's what we'd face with real cards in production. Say a customer has 5 unpaid invoices — we'd have to put them through 3DS 5 times in a single session, which is a terrible experience. What we're trying to achieve is a workaround where the customer approves 3DS only once, and all the remaining payments go through smoothly under that same authentication without any additional challenges

junior dock
#

That's not necessarily true, no. If you correctly set up a card, either via a Setup Intent or s_f_u on a Payment Intent, then we will request exemptions for subsequent payments made with that card. The test card you're usign does NOT simulate that flow

#

Now there isn't really a perfect test card for you to use in this scenario unfortunately. You could use 4000002500003155 but that only ensures that future off-session payments don't need 3DS and you're technically not doing 3DS

hearty delta
#

Hey @junior dock We always want to force 3ds on the payment ( previously which we're doing it at card setup), meaning if the card support 3ds, it will promt for 3ds , ex: 4000000000003055. purpose of moving enforcing 3DS from setupintent to paymentIntents is liability shift. If we do 3DS on the first invoice payment and the customer uses the same card for the next 10 invoices payments, we will not get liability shift. we want to make sure liability shift applies to all the invoices that are being paid on a single action Pay balance by customer.

junior dock
#

OK, and that's fine? I'm not sure what you're asking me. Yes, you an force 3DS on the initial payment and use it to save/setup the card rather than using a separate Setup Intent. Then you can initiate MIT payments (via off_session: true) for the subsequent invoice payments

acoustic flint
#

Whether a single on-session 3DS authentication on the first PaymentIntent in a session can extend liability shift to subsequent off-session PaymentIntents in the same session. Thats what we are trying to know.

junior dock
acoustic flint
#

If no is there a way that we can achieve it without forcing 3DS for all the subsequent payments.

junior dock
#

We don't know anything about liability shift here, you'd need to speak with support about that

acoustic flint
#

Liability shift means if a fraudulent transaction is disputed, the bank pays — not you.
Normally as a merchant you're liable for fraud chargebacks. But when 3DS authentication is completed on a charge, that liability shifts from you to the card issuing bank.

junior dock
#

I know what it is, but we don't know how exatly it works here. We can help with API and integration questions

slender quiverBOT