#leedurrant-off-session-sca

1 messages · Page 1 of 1 (latest)

fathom hazel
#

Hey, can you share a specific PI example?

#

Unfortunately banks can still request auth for 3DS/auth for payment even if previously setup/saved. You need to account for this in your integration

desert barn
#

pi_3LGeNhA1ET92r2sw0SdICArx

fathom hazel
#

Yeah, the card_xxx you're passing has no mandate for payments like this (it hasn't been authenticated via a Setup Intent)

#

The bank requested 3DS, so it requires confirmation in your front-end application. But it isn't an off-session payment so surely your customer is available to do that

desert barn
#

It should be an off_session payment

fathom hazel
#

There's no off_session: true parameter

desert barn
#

Ah okay. I was sure that was there. So if I add off_session=true, what would happen to these payments in future? Would they fail because the card requires 3DS and the customer is not in the checkout flow?

fathom hazel
#

There's no guarantee either way. You should just use the APIs and SDKs we provide to ensure that your integration can handle both success/failure

desert barn
#

Previously you mentioned "the card_xxx you're passing has no mandate for payments like this (it hasn't been authenticated via a Setup Intent)". I believe the card was added via a setup_intent and is flagged as setup for future use, so why is there "no mandate for payments like this"? Is it just that the payment_intent wasn't flagged as off_session, and if it had been then you wouldn't have made that reply?

fathom hazel
#

via Tokens endpoint which doesn't support 3DS/s_f_u

desert barn
#

Ah, the merchant that is using my app is also using the Stripe dashboard to add cards, and I believe the stripe dashboard uses the deprecated tokens method.

fathom hazel
#

Yep, it does (because we can't do 3DS/auth in the Dashboard as the customer/cardholder isn't present)

desert barn
#

So if a card is added via the dashboard that requires 3DS then at some point when being used for an off_session payment intent it will want to start the 3DS process. Is there a way of seeing if a card will require 3DS prior to using it?

fathom hazel
#

You should just assume that all UK/European cards will likely required 3DS as SCA enforcement is now in effect across Europe

#

UK was actually last country to enforce it

desert barn
#

In my app, the merchant sends a link to the customer that uses stripe.js to attach a card. This, I believe will then be compliant with 3DS. Is that correct? However, to avoid additional user licensing costs (not mine, a 3rd party) the merchant is using the Stripe Dashboard to create the cards, which are not compliant with 3DS.

fathom hazel
#

In my app, the merchant sends a link to the customer that uses stripe.js to attach a card. This, I believe will then be compliant with 3DS. Is that correct?
Depends on which APIs you're using

desert barn
#

it uses either a setup_intent or a payment_intent

fathom hazel
#

However, to avoid additional user licensing costs (not mine, a 3rd party) the merchant is using the Stripe Dashboard to create the cards, which are not compliant with 3DS.
Correct, we're just tokenising the card data for usage with the APIs. There's no request form us to the issuer to say 'we want to authenticate this card', because the cardholder isn't present in the flow to authenticate it.

fathom hazel
desert barn
#

So the code that I added works fine, but as the merchant is using the dashboard it has put a spanner in the works. Recently I have noticed merchants (when I buy over the phone) have requested the code that has been texted to me as part of the 3DS process. So the Stripe Dashboard isnt really built for a merchant that wants to add a card to the customer while they are on the phone?

fathom hazel
#

That's a MOTO payment, which are SCA exempt. But that doesn't cover just adding/saving the card: https://support.stripe.com/questions/mail-order-telephone-order-(moto)-transactions-when-to-categorize-transactions-as-moto

Mail Order Telephone Order (MOTO) transactions: when to categorize ...

Find help and support for Stripe. Our support center provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.

desert barn
#

Yes, my app also covers adding cards via MOTO as well and also MOTO payments.

#

This is really useful. Thank you. I am getting towards the end...

#

So I believe what you are saying is that... yes you can 3DS it via a setup_intent or payment_intent, but at some point the bank may require a further 3DS process, so looking at a setting on a card to see if it has been 3DS is irrelevant. I have to expect that at some point a payment_intent that uses a saved card will require an additional 3DS procedure to be performed?

fathom hazel
#

but at some point the bank may require a further 3DS process, so looking at a setting on a card to see if it has been 3DS is irrelevant
Correct, there's no way of knowing prior to payment if bank/issuer will request 3DS/auth. It's assessed on a per payment basis. We provide the APIs/SDKs to help mitigate and prevent a lot of that for off-session payment, but the bank can still request auth even if the card was previously authenticated. So you need to factor that into your integration, to potentially bring them back on-session to complete.

desert barn
#

Is there a simple checkout page from Stripe that I can tap in to? My app is for the merchant, and not for the customer. I do provide a small amount of html that uses stripe.js allowing the merchant to send a link, but it is very lightweight. Ideally, it would be great to pick up a url from the payment_intent that I can simply email to the customer to complete the 3DS process. Although the customer may well not have a valid email address anyway!

fathom hazel
#

Depends what exactly you want to do?

desert barn
#

I just want to be able to provide the merchant with a tool that will allow them to get the payments finalised. At the moment they have 7 payment that are just sitting there awaiting 3DS. I thought (maybe hoped) that perhaps Stripe took care of this process by sending emails to the customer.

fathom hazel
#

Both Checkout and Payment Links will do that

desert barn
#

I have a feeling that I decided to avoid stripe payment links as they required quantities prices and items etc. So perhaps checkout is the best approach. So at the moment my app creates a payment intent based on the customers open invoices, sends it to Stripe, but it comes back as "requires action". So am I correct that I need to somehow email the customer with a unique link that when clicked, will initialize the stripe checkout with the payment intent id and stripe checkout will take care of the rest?

fathom hazel
#

No, you can't initiate a Checkout Session from an existing Payment Intent

#

You'd basically not create the PI yourself, and instead just email them a link to the Checkout Session

desert barn
#

So where would I get the link from?

#

Not sure I understand. My app creates the pi, submits it, and some go though and some dont. The ones that dont are a pi with "requires action". So are you saying that using checkout I cannot uses the pi at all?

jaunty steppe
#

Hi! I'm taking over this thread.

#

Do you want to use Checkout Session to handle 3DS for you?

#

If so, you create a Checkout Session with: https://stripe.com/docs/api/checkout/sessions/create
Then you will get an URL that you send to a customer to pay. And that's it. There's no need to create a PaymentIntent or handle 3DS, everything is handled by Stripe.

desert barn
#

I am not sure what I need to do. My app is built around recurring billing and using saved cards for off session payments. To do the off_session payment, I create a payment_intent, submit it to Stripe and normally it goes through. But there are now a few payment intents with a status of requires action, and I am trying to figure out the easiest method to have the customer complete the 3DS process.

#

The ideal for me would be that the status comes back with "requires action" and I grab an "action link" from Stripe that I can email to the customer, but that is not how it works. I am trying to find the easiest method to allow the 3DS process to be completed for an offsession payment intent.

jaunty steppe
#

So these are invoice payments that fail because the PaymentIntent has status:requires_action, and you want to know how to handle this?

desert barn
#

yes. although they aren't "stripe invoices" as the invoice is in the system that I am extending. My app just figures out how much is to be collected and creates a payment intent. It gets to status:requires_action and nothing seems to happen from there on.

jaunty steppe
desert barn
#

The customer doesn't really have access to the system, it it the merchant who is triggering a payment from a saved card.

jaunty steppe
#

If the PaymentIntent is in status:requires_action, then the customer has to go thought the 3DS flow for the payment to succeed. T

desert barn
#

so is it just simply that I hadnt added offsession=true to the payment intent, and had I done so it would never have gotten to a status::requires_actiojn status?

jaunty steppe
#

so is it just simply that I hadnt added offsession=true to the payment intent
If the PaymentIntent is off session, then yes it's better to set this
and had I done so it would never have gotten to a status::requires_actiojn status?
That's not guaranteed. It's completely up to the bank to require or not the 3DS flow. If the bank does require it, then you have to handle it.

desert barn
#

I have now gone around full circle on this thread..... So the answer to completing a PI that requires_action is to not use a pi at all, and the answer to satisfying 3DS for an offsession payment is to bring the customer online to an app that they never had or will have access to! Is there really no simple method to complete the 3DS process for an offsession pi?

jaunty steppe
#

So the answer to completing a PI that requires_action is to not use a pi at all,
Of course you can use the PI, that's what I suggested before.
and the answer to satisfying 3DS for an offsession payment is to bring the customer online
Yes, that's correct.
s there really no simple method to complete the 3DS process for an offsession pi?
There is: bring the customer back to your website/application to do the 3DS.

desert barn
#

It was ynnoj that said about not using a payment intent. The customer does not have access to the application, as it is the merchants

#

oops. presswed enter by mistake

#

The customer does not have access to the application, as it is the merchant's internal accounting system. The merchant is using a saved card to collect payment, and it creates the PI. I cannot get the customer to complete 3DS on the merchants system.

jaunty steppe
#

If you can't redirect the customer to the website/app to complete the 3DS of the existing PaymentIntent, and if you can't create a new PaymentLink/Checkout Session to send your customer by email, then it's not possible to make the payment.

desert barn
#

It seems to me that there is a huge flaw here. I need a tool to allow the merchant to complete the 3DS on the customers behalf. So when the PI has "requires_action" the merchant can call the customer and request a 3DS code from them, and enter it in to a screen that I can provide. So I would have thought that all I need is the PI reference, and an api to call to state pi=pi_12345; 3DSCode=123456

#

Sorry, not being rude, just concerned at the potential changes that I need to make!

jaunty steppe
#

No worries, but yes I think I already shared two options to solve this (complete the 3DS of the existing PaymentIntent by bringing the customer back, or create a new PaymentLink/Checkout Session to send your customer by email). If none work for you, then I'm not sure how I can help.

desert barn
#

To bring the customer back, I suppose that this can be a screen that the merchant can use while on the phone to the customer? If so, what api would I call? Or would it be Stripe.js?

golden sandal
#

It would need to be stripe.js if your next action is use_stripe_sdk

fathom hazel
#

👋 jumping back in here. I think there's a lot of wires crossed! Can you explain how you current integration issues with Stripe?

desert barn
#

Bingo! Got it. So just provide a page with stripe.is on it using handle_card_action and provide the payment_intent_secret and the merchant can call the customer to complete the process. Or provide a lightweight piece mod html elsewhere that teh customer could potentially use also.

fathom hazel
#

merchant can call the customer to complete the process
But if these are MOTO transaction, then they should be exempt for SCA and all of this is void. You shouldn't really be doing 3DS over the phone, that's why its exempt.

#

So in the case of your invoices, that are by all means MOTO payments, process them via the Dashboard with the user on the phone. No need for PI creation

desert barn
#

There are MOTO transactions, but they are okay. The app sits in an accounting system for use by the merchant only. The merchant can use MOTO to take a payment, or save a card. It can email out a link to the customer to make a payment or save a card. This is a lightweight webpage outside of the accounting system that the customer can reach. Once a card has been saved, the merchant can use a batch process to take multiple payments for all open invoices where the customer has madden a card for future use.

fathom hazel
#

Right, and that will work fine as it's the Setup Intent process we spoke of earlier. But the issue of the Dashboard saved cards requiring 3DS is what we're trying to solve, no?

#

Maybe all of our wires are crossed and you're actually unblocked now. But your process for MOTO payments sound overly convoluted if the 'merchant can call the customer to complete the process'

desert barn
#

The dashboard saved cards yes, but as you mentioned, it is wider than that because any non-MOTO payment in the future may require 3DS.

fathom hazel
#

Right, so perhaps you need to adjust your integration to only use pm_xxx objects (which we know will have been authenticated via a Setup Intent) for the off-session payments, as opposed to the card_xxx objects (from the Dashboard and aren't authenticated)

#

You really shouldn't be doing 3DS over the phone like that

desert barn
#

I like that but its easier said than done. To use our app the user requires a licence for the host application, and the issue is that this particular merchant has lots of salespeople signing new customers. So they have opted to provide free access to the dashboard to save the card rather than buy an expensive user licence for the host application. My app is free, paid for by the app_fee, and so it is in my interests not to limit which cards can be used. Also, as you said previously, there is no way of knowing if a transaction will actually trigger 3DS, so it does need to be catered for. I think for 3DS it can be a link that is emailed, but I know that the salesperson will probably just open the link and call the customer. In my experience Salespeople are inherently uncontrollable!

fathom hazel
#

Fair! Are you unblocked here and know how to proceed now?

desert barn
#

Yes, I think so. I just need the payment_intent_secret, stripe.js and a small webpage and I think that will allow for the 3DS action to be completed. Do you agree?

fathom hazel
#

Yep that's how it works