#commento

1 messages · Page 1 of 1 (latest)

urban lilyBOT
subtle wedge
#

Can you share a request id where the decline is happening?

lusty python
#

Yes, here it is req_i52p5GdMSGIQLs

subtle wedge
#

Ah ok. So with the 3063 test card, 3DS must always be completed for payment to succeed

#

So the customer actually needs to be on-session to pay with that card

lusty python
#

it is on-session in this case: the frontend performs a cretePaymentMethod and the backend atttach the payment method to the customer and perform an invoice pay

subtle wedge
#

No by on session I mean the customer is in the Invoice UI submitting payment

#

You called /pay server-side

lusty python
#

ok, but is it possible to do an on-session invoice payment attaching the payment method to the customer or the only option is to use the paymentIntent api?

subtle wedge
#

Not really no

#

So the other problem is you're creating the payment method not setting it up for future usage

#

Payment methods need to be created via SetupIntents or PaymentIntents with setup_future_usage if you want to reduce the chance future payments will be declined or require 3ds auth

lusty python
#

ok, still not clear why the 3Dsecure2 test-card 4000000000003220 works without problems. If I need to generate an invoice for each payment then, how should I have to proceed? the paymentIntent does not allow for invoice items and such kinds of things

subtle wedge
#

Hm can you send a request id where the 3220 card was successful?

#

As long as the payment method was created properly and set up for future usage you can use it with invoices

#

Issue is right now you're creating the payment method directly instead of creating it through a setupintent, for example

lusty python
#

this is the 3D secure confirmation request with card 3220: req_3tc5HHKOcoy1kf

#

yes I tried that approach but it was asking me two times (once for the setup intent and one for the invoice pay)the 3D secure authentication with such cards

subtle wedge
#

Yeah that's because of the test card

#

So you could use 4000002500003155

#

That one will only require 3ds for the setup

#

And mimics a real world scenario

#

Looking at the 3220 one now

#

Oh that one doesn't work without problems

#

You can see in the response of the request id you shared that the card requires authentication

lusty python
#

yes and after the confirmCardSetup (if I remeber it correctly) in the FE the payment is authorized

#

I mean the "invoice_payment_intent_requires_action" error is handled by the BE to start the 3Dsecure authorization flow

#

is this approach wrong? btw I will introduce the setupIntent as suggested

subtle wedge
#

That would work

#

Just confused why you don't accept payment method info directly on the Invoice's Payment Intent

urban lilyBOT