#deadshot_api
1 messages ยท Page 1 of 1 (latest)
๐ 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/1245034633368961066
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
I don't understand how to display 3DS flow? Since my payments are off-session!
Hi there ๐ you will need to build a flow to bring your customer back on-session so they can complete the authentication challenge.
You also aren't passing the off_session parameter there, so that isn't an off-session payment.
I mean I am getting their payment method on setup checkout session and creating payment intent through API on webhook event. Doesn't that make it off-session?
Does a payment checkout session include the 3DS auth flow?
Is 3DS required for every transaction or just the first one?
Doesn't that make it off-session?
nope, passingoff_sessionon the PaymentIntent creation/confirm call does that
Does a payment checkout session include the 3DS auth flow?
yep!
Is 3DS required for every transaction or just the first one?
it's up to the customer's bank. In the happy path, the first payment requires 3DS, and subsequent off-session payments get exemptions. You can simulate that with the 3155 test card mentioned in the Stripe docs
I talked to the stripe support last week and they said that I can create payment in my current checkout flow. The customer will receive a 3DS notification on their device. Once they complete that. I can receive a 3ds complete event if the user completed the 3DS auth?
you would receive webhooks about successful payments yep, and the Promise from calling frontend functions resolves.
Like once I receive 3ds complete event, I can continue creating subscription and reservation workflow?
But that still leaves out the 3DS auth flow?
that's a bit vague so it's hard to answer. The normal way to do this is you create a Subscription, you process payment for the first Invoice, and that can involve doing 3D Secure, it's handled as part of that process.
I am using scheduled subscription, currently it can't be integrated in checkout flow
makes sense I suppose.
so can you describe how the payment flows works for you?
I'm a customer of yours and I want to use your product. When do I enter my card details, when do you charge them, when/if do you charge them subsequently?
First you go to my website, book an apartment and on checkout, you only enter your card details. Then, you will be charged for first week/night upfront, an auth hold payment for damage deposit and a weekly/nightly scheduled subscription will be created for you.
cool. So how do you implement that?
you only enter your card details. โ SetupIntent
Then, you will be charged for first week/night upfront โ PaymentIntent some days/weeks later
scheduled subscription will be created for you โ created after that PaymentIntent succeeds
is that accurate?
Enter card details - Setup Checkout Session
First week/night upfront - receiving session.completed event and creating payment intent and scheduled subscription
that is wrong I would say? why use a Setup session and then immediately charge the card?
you'd just use mode:payment or mode:subscription CheckoutSession.
That's because I have to create 3 types of payment
Normal payment, auth hold payment and scheduled subscription
that is ... a bit of a mess?
you charge me $100(normal payment), and also $100('auth' payment), at the same time?
why wouldn't you just charge me once, for the 'auth' payment?
Auth payment is just for damage deposit, only capture when there is a property damage on checkout
but you charge them both at the same time?
so on my bank statement I see that you charge me twice? (once payment that you capture, one that you don't). That is likely to lead to a lot of declines and chargebacks, it's confusing.
Yes, thats how it goes and its working
ok.
well anyway, are you unblocked?
if you want these off-session payments to be processed as off-session and be able to claim 3DS exemptions, passing off_session is how that's done, see https://docs.stripe.com/payments/save-during-payment?platform=web&ui=elements#charge-saved-payment-method . You can test this end to end by using the 3155 card from https://docs.stripe.com/testing#authentication-and-setup
if the payment does end up requiring 3DS, you'd catch that exception in the code and contact the customer to come back and do the payment on your site, as described in the doc. This is not automated by Stripe, that is only for recurring Subscription payments.
Well, thats the thing, I want to enable 3DS on all transactions. What is the best way to do that in my current checkout flow
hmm
well like what part are you missing? is it just "I got this PaymentIntent in status:"require_action" and I don't know what do with it"?
you'd take the PaymentIntent client_secret and confirm on the frontend , which will popup 3DS if it's requested https://docs.stripe.com/js/payment_intents/confirm_card_payment#stripe_confirm_card_payment-existing
But its a async event,
and why is that a problem?
have you tried this in test mode?
like you call it, it displays a popup while the Promise is waited, that promise resolves when the user completes the popup.You also get a payment_intent.payment_succeeded webhook event when it completes, on the backend.
I think I will have to change my checkout to payment mode for normal payment so it triggers 3DS and create auth and subscription because its a mess!
yep I think that would make sense, it would be best to simplify this as much as you can
Hello! I'm taking over and catching up...
Thanks. I will do that
I think the main point of confusion is that, when you confirm a Payment Intent off-session (where off_session is set to true), if 3D Secure is required you'll get an authentication_required decline. There's no option to proceed through 3D Secure at that point because the Customer isn't present to go through that flow. When you receive a decline like that (or any decline, really) you need to contact your Customer, bring them back on-session, then confirm the Payment Intent again while they're on-session so the 3D Secure flow can be triggered and handled by the Customer.
Exactly
I have to contact my customer to bring them back which isn't good thats why I have to change my checkout flow
I mean, you need to do this regardless. There's always a chance an off-session payment will be declined. It could be because 3D Secure is required, but it could be for another reason.
In those cases you need to get the Customer back on-session so they can pay.
I want to always enable 3DS
By "enable" do you mean "force"?
Yes
Why?
It's not practical or recommended to force 3D Secure for off-session payments.
If you force 3D Secure you effectively can't have off-session payments.
Only on-session payments would work.
For security
You can request 3D Secure for every on-session payment, but I don't understand how forcing it for off-session payments using saved Payment Methods that have already gone through 3D Secure will help with security, can you explain?
No 3D secure should only be required for first time, not when they have already done that
Hang on, let's back up. So you only want to request 3D Secure for on-session payments?
All my payments are off-session
And you explained that I need an on-session payment to request 3D Secure,
Maybe I'm misunderstanding your payment flow. If I'm your customer, and I want to transact with you, I'm going to go through Checkout and pay how much immediately, while I'm on-session?
At a high-level, the idea is that if you don't take any payment when the Customer is present (meaning you only charge them later, typically a long while later) then you set up their Payment Method for future use. During that set up process they may go through 3D Secure (you can request, but not force it, ultimately it's up to the card issuer if anyone goes through 3D Secure).
If you do take a payment when the Customer is present that payment should be made on-session and you can also, at the same time, set up the Payment Method for future use. You can also request 3D Secure at this point, but it's still up to the card issuer if they actually go through 3D Secure or not.
In either case, later off-session payments may or may not require 3D Secure, or may be declined for other reasons. In those cases you'll need to bring your Customer back on-session to try paying again.
Do they go through 3D Secure during their payment method setup? I thought they go through 3D Secure only on transactions.
They might, yes. 3D Secure is not only during payments.