#geimsdin-3ds

1 messages ยท Page 1 of 1 (latest)

tacit wren
#

do you have more context on how exactly you present the 3D Secure window? That PaymentIntent is associated with an Invoice that you called the manual invoice.pay endpoint on(which doesn't support 3D Secure)

#

I just tested that same card in my normal PaymentIntent integration and it authenticates and succeeds as expected

glad maple
#

Which endpoint is supported by 3Ds to collect the payment without waiting 1 hour?

tacit wren
#

or after finalizing the invoice, redirecting the user to the hosted_invoice_url for a hosted page where the customer can pay

glad maple
#

hmmm... I give you more context

#

I'm developing a plugin on Woocommerce that allows to buy online courses, As soon as the order is placed I finalize the invoice and trigger the charge on the card (as you got already). The operation should be "invisible" by the user then I handle everything server side in PHP.
Is it possible to do so with a 3Ds or I am forced to show something in frontend and ask for more interaction?

tacit wren
#

I mean 3DS is inherently a frontend concept (showing the customer their bank's authentication page in their browser while they're making a payment)

glad maple
#

The modal is already loading correctly in the Elements Payment method

tacit wren
#

if you attempt a payment and it requires 3D Secure that has to be handled on the frontend. That's why our default integrations are all about confirming PaymentIntents in the frontend and not backend scripts like in legacy integrations

tacit wren
glad maple
#

I am creating a Scheduled subscription that creates a setup intent

#

After I click complete the payment fails

tacit wren
glad maple
#

The one written on first message or if you want another one: pi_3Ld8zQLmxBucQd151qBNtMl8

tacit wren
#

yeah but that PaymentIntent 100% did not present 3D Secure that way.

#

are you doing something like using a SetupIntent to save the card with the PaymentElement and then trying to create your Invoice?
I'm right here, correct?

glad maple
#

"I am creating a Scheduled subscription that creates a setup intent"

tacit wren
tacit wren
glad maple
#

wait

tacit wren
#

so am I correct in saying that you create a SetupIntent, confirm that in the frontend, and your screenshot is from confirming that SetupIntent? and then later you try to create and pay an invoice and that's what's failing.

glad maple
#

You are right, sorry, I create the setup intent and I attach a payment element to it

tacit wren
#

yep

#

so that's completely wrong and will never work

glad maple
#

It works for normal cards but not for 3Ds ๐Ÿ˜ฆ

tacit wren
#

the correct way to build this (for an immediate subscription or invoice creation) is

  • create Invoice
  • finalize Invoice
  • send the invoice.payment_intent.client_secret to the frontend
  • use that PaymentIntent with the PaymentElement
  • that completes the payment , does 3DS and should save the card to the customer too
#

now in your case you want to schedule the payment for later which I suppose complicates it

glad maple
#

Seems too much not user friendly and leading to lose many sales

#

I should create the order (then the invoice and finalize it) then on the confirm order page ask to pay?

#

"to pay" = to insert payment data

tacit wren
#

yes that's how the Stripe integration works

#

you create the "intent to pay" on the backend and then confirm the payment on the frontend, and use webhooks to activate/fulfill the order

glad maple
#

Another way is to create the invoice everytime the user opens the checkout and then create there the payment intent as you said. That will lead to lot of trash data on Stripe but compress everything in one step for me

tacit wren
#

can you explain why there is a subscription schedule in your flow? I'm not following that part.

tacit wren
glad maple
tacit wren
glad maple
#

Nope, I use the subscription schedule, would be crazy not to use it as Stripe team code is already written and working.
I just handle events with webhook, today I thought the integration was already ended when I tried 3Ds and see that doesn't complete the payment.
Btw I followed your colleague suggestions on how to make this happen...
I will modify my frontend to comply with your suggestions and I hope it works this time.

#

For example I have a cart of 300 euro and I split the payment in 3 times (once per month) so it is:
1 - 100 euro now
2 - 100 euro in 1 month
3 - 100 euro in 2 months
Then the subscription will be deleted

tacit wren
#

fair, but is your client aware they'd be charged for using Billing? If that's their concern

#

those are recurring invoices so they use our pricing for that, if that was the concern

#

anyway I would say if you're going to use schedules this way

  • just let the invoice finalise and pay normally in an hour, don't try and force it
  • if you do want to force it, call https://stripe.com/docs/api/payment_intents/confirm#confirm_payment_intent-off_session )with true) instead of the invoice.pay endpoint or confirming on the frontend. That has less chance of requiring 3DS if the card was set up previously.
  • either way, any recurring or subscription payment can require 3DS and you need to be able to catch that and handle on the frontend
#

I have to run but my colleagues can jump in

glad maple
#

I think something will not work with your solution

#

Why I cannot use subscription with setupintent?

dire wigeon
#

Hi! I'm taking over this thread.

#

Can you try to summarize your question?

glad maple
#

Hi Soma, I don't understand why I can charge a standard credit card with a setup intent in a subscription schedule but I cannot charge a 3Ds card

#

Standard card complete the payment, 3Ds seems like failing in test mode

dire wigeon
#

Which test card are you using?

glad maple
#

"4000000000003238" this for example

dire wigeon
#

This card will trigger 3DS on ALL transactions. So when a subscription renews, it will ask for 3DS, which will fail. You probably want to use 4000002500003155 instead

This card requires authentication for every payment unless you set it up for future payments. After you set it up, it no longer requires authentication.
So it will requires 3DS only for the first payment, when the customer can go though the 3DS flow.

glad maple
#

How should I set it up for future payments? Is not the scheduled subscription already doing that?

glad maple
#

My webhook will then react to the received events and finalize the invoice and try to pay it

#

But the payment fails (while with a standard card it works)

#

This is a failed payment id: pi_3Ld8zQLmxBucQd151qBNtMl8

#

This is a succesful one: pi_3Ld8QnLmxBucQd150Ry1mTXL

dire wigeon
#

Can you try with this test card: 4000002500003155

glad maple
#

I try now

#

Worked great

#

pi_3LdAdDLmxBucQd150uIbOp8v

#

Then how to handle the failed payments with cards like "OTP"?

#

Also this: "4000000000003063" doesn't work

#

Also this fails: "4000000000003253"

#

Is it safe to say that if I receive the event "payment_intent.requires_action" followed by "payment_intent.payment_failed" I can handle it sending an email to the user asking to complete the payment in Stripe?

What will happen then in the future payments? Will they require again user action or they will be automatic?

dire wigeon
#

You are trying to pay for an invoice off session using a payment method that require 3DS. It's expected that it will fail, so that's something that you'll need to handle in your flow.
But overall I would recommend doing what karllekko suggested:

anyway I would say if you're going to use schedules this way

  • just let the invoice finalise and pay normally in an hour, don't try and force it
  • if you do want to force it, call https://stripe.com/docs/api/payment_intents/confirm#confirm_payment_intent-off_session )with true) instead of the invoice.pay endpoint or confirming on the frontend. That has less chance of requiring 3DS if the card was set up previously.
  • either way, any recurring or subscription payment can require 3DS and you need to be able to catch that and handle on the frontend
glad maple
#

I should contact the endpoint:

$stripe = new \Stripe\StripeClient( 'sk_test_ysGRD8v35CKKJSGqZt1BQWfH' ); $stripe->paymentIntents->confirm( 'pi_1EUq4543klKuxW9fVKimzjFV', ['payment_method' => 'pm_card_visa'] );

#

And specify the payment method?

#

Or just specifying that is an offline payment?

#

After I set the off_session to true how can I trigger the payment?

#

While creating the Setupintent I specify that usage is "off_session" already

high merlin
#

๐Ÿ‘‹ taking over for my colleague. Let me catch up.

tacit wren
#
  'pi_1EUq4543klKuxW9fVKimzjFV',
  ['payment_method' => 'pm_xxx',
    'off_session'=>true
]
);
``` . Along those lines.
glad maple
#

That is enough to trigger the charge

#

?

tacit wren
#

yes, 'confirming' a PaymentIntent is what attempts to charge any attached payment method

#

actually my example is wrong,(edited) you don't need confirm:true, that's only for creating a PI

#

if you're calling ->confirm, that is explicitly attempting a charge.

glad maple
#

Ok thanks a lot, I'm afraid I will bother support again later ๐Ÿ™‚

tacit wren
#

sure, just try it really in test mode and it makes sense

glad maple
#

Yes sure, I'm 1 month in test mode already

#

๐Ÿ™‚

#

Have a nice day