#Tony-paymentlink
humble heath
hi there! i'm afraid not, it's not possible to generate a payment link from a PaymentIntent
stiff flax
okey, maybe the way is to put it on a checkout page ?
Like, our customer support wants something to send to our customers when they kind of fail with 3DS and so
humble heath
would you be able to share more context e.g. How does your payment flow currently work?
stiff flax
So we have a case where the client sends a request for something and later in the future - this request is accepted and the backend tries to charge the customers card. Since its off-site, a lot of 3DS cases arises.
We have a way in the app for customers to retry payments with changing the paymentMethod for the same paymentIntent.
Sometimes, we see that its just easier to simply sent them a link which they can use any card to complete, and the paymenIntent is fullfilled
I think I can render the simple payment form at https://stripe.com/docs/payments/quickstart with the paymentIntentID ?
sounds like an easy plan
humble heath
when you try to charge the user off session, did you pass in off_session=true when creating the PaymentIntent?
stiff flax
I do not, actually
hmm. That could save us a lot of trouble, I guess ?
or wait, I do
I do this.
additional_args = {
"setup_future_usage": "off_session",
"payment_method_options": {"card": {"request_three_d_secure": "any"}},
}
is that what we are talking about ? Sorry for the wrong formatting here
humble heath
i was actually referring to this parameter : https://stripe.com/docs/api/payment_intents/create#create_payment_intent-off_session
if you're passing in request_three_d_secure": "any" - this means you're requesting for 3DS for the payment : https://stripe.com/docs/api/payment_intents/create#create_payment_intent-payment_method_options-card-request_three_d_secure
is that what you intended?
stiff flax
Aha, I think this was setup back in the days to fight fraud. Probably time to take them all down
humble heath
if you're using an existing PaymentMethod id, you should omit this also : setup_future_usage
stiff flax
Alright. I will kill that whole thingy
humble heath
waitwaitwait, you shouldn't necc. "kill" the whole thing
stiff flax
Ah, I meant - kill the additional_params
humble heath
if you're collecting a payment method from your frontend using the PaymentIntent, then you would need that parameter
stiff flax
Nope, we are not doing that. And that is the funny part
we have a separate place where we have a list of all paymentMethods (like a wallet)
humble heath
Can you share your account id so that I can take a closer look at how your integration works too? You can find your account id by logging in to https://dashboard.stripe.com/settings/account. It'll be in the upper right hand corner and looks like acct_123
stiff flax
acct_15IhAcJLmO8KP9l1
humble heath
since you're using PaymentIntents, you can adjust the rules which request for 3DS here : https://dashboard.stripe.com/settings/radar/rules
Example :
stiff flax
aha. okey
humble heath
so remove request_three_d_secure": "any" in your code. But you can adjust the rules in Radar so that it requests 3DS for more PaymentIntents
stiff flax
True.
humble heath
if you include off_session=true, the Radar rules shouldn't request for 3DS
stiff flax
From a customer point of view, we dont want that friction either. I think when SCA was introduced we were thinking this was required. But apparently migration to paymentIntents was just enough