#matt11-paymentintent
quiet glade
Ok thanks anyway. I'm facing an issue with this testing customer: cus_Lyjr3rE8msdCbd
I did what your colleagues told me in the previous thread.
The first payment created with
confirm: true, setup_future_usage: 'off_session'
and the next payments with confirm:true and off_session:true
as you can see the first 897€ payment was completed with 3ds page but the 2nd one (with confirm:true and off_session:true) is in 'requires_payment_method' status and I don't understand why
oblique warren
That's test mode right? Which Test card are you using?
quiet glade
yes, test mode, i used this 4000000000003220
oblique warren
that card requires 3DS2 all the time
quiet glade
yep but why is the PI in required_payment_method status instead of requires_actions?
oblique warren
ah
let me check
that's because of off_session: true
in that world the customer is not on session so we default to a decline not to escalate to the 3DS flow
at that point you would email the customer and get them back on session. In that world they would enter a new card (though you could use the already saved one)
I agree we could move to next_action but it'd be no different, you'd still have to re-confirm client-side anyways
quiet glade
this is worst than before 😄 at least now I have a lot of PI in requires_actions
I thought that off_session: true helped me avoiding lot of unnecessary 3ds but I see that this is not the case
oblique warren
not really
off_session: true means that the customer is not on session. You are charging them "out of band"
In that world they can't do 3DS, so we claim an exemption with the bank from a previous set up you did (your first PaymentIntent)
If the customer is on session, never pass off_session: true
quiet glade
I don't understand why stripe tells me that the 897 payment setup the card. for future usage
since now I cannot do another payment off-session
oblique warren
you can
quiet glade
how?
oblique warren
you are just using a test card that is specifically built to not work that way
quiet glade
oh ok
oblique warren
Use 4000002500003155 that will work
that test card you use is IMO horrible :p
it's here to always require 3DS. That helps developers always see 3DS no matter what they did with that card before
but then it confuses them when they want the real behaviour they would get in production
quiet glade
there're so many doc pages that is very difficult to find everything 😂
oblique warren
I know
quiet glade
so, let's assume we are in production mode and I have a card setup fo future off-session payment by customer first payment.
If I create a PI from a recurring job with off_session: true and confirm: true will I get a requires_actions status or succeeded?
lethal pine
Hi Matt! In production, that would depend on the card issuer. The issuer may always choose to decline for a variety of reasons, or decide to require 3DS. If they decline or decide to require 3DS, you'll get a requires_payment_method status like you saw with the first test card.
quiet glade
yep but if the card is setup for future off_session payment does it means that the card issuer won't ask for 3ds?
lethal pine
Usually, yes. But some issuers may still ask for 3DS. This is uncommon, though.
quiet glade
okok but I think that statistically the 3ds requests will be less
lethal pine
Yes, exactly
quiet glade
okok perfect! thanks @lethal pine @oblique warren
oblique warren
@quiet glade fun fact, @lethal pine is the engineer who helped design and build the PaymentIntents API in the first place
quiet glade
nice!! I tell you my fun fact too 😄
my client asked me to replicate stripe's subscriptions logic into the application by recurring jobs and setup_intents/payment_intents
so I really struggling to understand everything
but it is really hard to replicate something like Stripe logic by my own 😅
I think that at the end of this, If I will be able to do it, I can apply for a position in Stripe too 😂