#nicolas-paypal-mandates
1 messages ยท Page 1 of 1 (latest)
Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- nicolasbouteilleelephorm_93575, 23 hours ago, 6 messages
I don't have this problem with subscription renewal with a payment method of type credit_card. Only paypal
Hi can you share the request id where this happened?
ok
req_iRJQjZNfBAzKk0
could it be because I have already paid multiple times with this payment method (on session workflow with the parameter off_session true) so each time a mandate has been created, and now that I try an off session payment, I need to specify which mandate to use?
I will try to add a new Paypal payment method by making only one payment with it. And then try to renew subscription with it right away
Ok I did not have the error this time so I might be right about the reason why this error is showing...
Sorry
Looking now
Yeah that could be the issue
Can you share request id's where you used that pm multiple times?
Want to see exactly what you're doing
here is the id of the request that worked
req_V43Pu4ABB7FupL
That will be too difficult to find out the request of previous multiple payments
but I can try reproduce the error
I just need to see what your integration/code is doing
this is the request of the fisrt time I payed with this new Paypal PM : req_bK8hF6MXchhKp5
now trying to make a 2nd on session payment, that should create a new mandate
this is the 2nd on session payment : req_eRhMq7GV3Jd78R
now trying to renew the subscription in off session workflow, it should display the error this time...
yes I did get the error this time : req_jk4QQivf7FzSy5
Yeah I mean that makes sense. When you're paying on-session like that, mandate_data is passed: https://dashboard.stripe.com/test/logs/req_eRhMq7GV3Jd78R
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
So mandate's created
Should I avoid creating multiple mandates or better store the last mandate and try to pass it to the PaymentIntent when paying off session?
I would suppose it is better to generate a new mandate on each on-session payment so that it is fresh and more inclined to help us skip authentication?
but is seems from what you sent me that the mandate_data is pretty generic...
"mandate_data": {
"customer_acceptance": {
"type": "online",
"online": {
"infer_from_client": "true"
}
}
},
so if it is always the same each time, maybe I just need to provide this generic information ?
i will try to add this information to the PaymentIntent when renewing the subscription
it seems I need to provide the mandate secret key...
in the request you sent me, is it this parameter:
"key": "pk_test_1f****************************fvXH",
Ok hold up
If the initial payment/setup intent set up the payment method for future usage, then that's the mandate you should be using for each off sessinon payment
Is it my code that adds a mandate when paying with paypal in on-session and requiring future usage? Could I do it differently and not generate a mandate? or this I can't change...
I think I understand that the mandate comes from the intermediate page, after PaymentElement redirects me to Paypal acceptation page, where I accept... so the mandate creation cannot be skipped. Right?
There's a lot of it... I don't know what to send you...
can you confirm that the mandate creation is necessary and cannot be skipped?
Yeah if you need off session payments
can you tell me if on the return_url, I should be looking for a request parameter that holds the mandate's id and store it for later use?
I can confirm I don't have it in the return_url parameters
I only have payment_intent, payment_intent_client_secret and redirect_status
Yeah that's expected afaik
But also you shouldn't need to create a mandate for each on-session transaction
Only the initial one to set up the payment for future use
If they're going to keep paying on-session, no need to pass setup_future_usage for later payments
they can do both
I understand
they can use and reuse paypal in on session payment to buy individual trainings
But for future on-session payments, you already have set up the payment for future usage
So no need to pass that param and force mandate creation again
ok I understand
setup_future_usage: "off_session", don't pass this when creating payment intents later
You only need to do that once
That way you will only have 1 mandate
ok I understand
but don't you think it's best to have fresher mandates that are more inclined to succeed rather than eternaly keep an old mandate?
or is this not related with 3DS ?
No shouldn't matter
ok
I don't know yet how easy it'll be for me not to mention setup_future_usage: "off_session" every time...
So in case I can't, I'm still interested in knowing how I can retrieve the latest mandate ...
of the payment method
Well if you already have the payment method stored you shouldn't send the customer through the checkout flow to collect paypal details again
You should just confirm payment with the pm_ id
And not pass setup_future_usage when creating the payment intent
I can look for how to find the mandate for you, but you should know that your current flow isn't exactly correct
yep cristal clear
if you can find that info I would be glad to have it
however I understand I need to change stuff on my end
asking a colleague. we make finding mandate id's somewhat difficult
thank you for your time
on my end and I trying to update my code as suggested and see if it works that way
ok I have tried not to pass setup_future_usage but I got redirected to the Paypal acceptation page anyway and the request created a mandate
req_qew0lKVYbdVfvp
as you can see, setup_future_usage is null.
Hi ๐
I"m stepping in as my colleague needs to step away
however, I have tried to completely unset the attribute so I am surprised to even see it
You should do this instead: https://stripe.com/docs/payments/paypal/set-up-future-payments?platform=web&ui=checkout#charge-later
The setup_future_usage parameter is designed to configure the Payment Method you are saving for off-session usage
That way the customer doesn't need to go to paypal
โ๏ธ
Have to head out though. Snufkin will take further questions!
thank you for your time
have a good weekend ๐
I am not sure what's new in the doc you sent me... it seems to be already what I am doing?
except I am using PaymentElement JS form
No, no it isn't
except I am using PaymentElement JS form
That is a big part of the problem
and stripe.confirPayment when the pm already exists
The code snippet in that doc where you create a new off-session Payment Intent charges and confirms the PaymentIntent during creation
So when the payment method does not exist yet, I use PaymentElement form.
Then when it already exists, I create the PaymentIntent and pass it to stripe.confirmPayment
I understand that the problem is that the second time, when I create the PaymentIntent, i should not set setup_future_usage again so that a new mandate is not created
is this all correct?
Then when it already exists, I create the PaymentIntent and pass it to stripe.confirmPayment
NO you do not do this
You do not use the Payment Element and stripe.confirmPayment at all
You create/confirm the Payment Intent in a single API request on your back-end
ok I am talking about on-session payment
a second on-session payment later on... with the existing payment method
If the user is on-session you pass off_session=False, otherwise if they are off-session you pass off_session=True
a second on-session payment later on... with the existing payment method
Doesn't matter, if you are re-using a payment method
ok so I cannot confirm a PaymentIntent client-side if the payment method already exists and is Paypal type? I have no choice but confirm it server side?
Well, when I read the doc, I understood that trying server side can sometimes fail and require user action / authorization. Which means that we need to confirm client-side in that case. So I found it simpler to just try and confirm client-side all the time
this is also the way it was implemented, at least for credit cards, in the Drupal Commerce Stripe module I am using
I thought I had figured that stripe.confirmPayment was working with any kind of payment method and would save me from needing to call individual function such as stripe.confirmPaypal...
and so far it was working well with Paypal
You should confirm server-side, and if PayPal requests additional authentication then that is when you would confirm client-side and your customer would be redirected to the authentication screen
ok but then I will face the same problem of having multiple mandates
which is my only problem right now
I can successfully confirm existing paypal payment method client side with stripe.confirmPayment... this works...
ok but then I will face the same problem of having multiple mandates
No
You are incorrect
YOU are creating multiple mandates by passing setup_future_usage parameter even when using an existing payment method
can you take a look at this request ?
req_qew0lKVYbdVfvp
setup_future_usage is null
yet a mandate is created right?
ok despite what I just said, it seems the request I just gave you did not create a new mandate afterall
Right, the mandate associated with that payment method was created 4 minutes before this payment intent
so I was indeed able to reuse my existing paypal payment method and confirm it client side with stripe.confirmPayment however I successfully did set setup_future_usage to null so it did not create a new mandate
and I was able to just reuse this with an off-session PaymentIntent with having the error of multiple mandates
to renew a subscription
let me do two more tests with this PM : one more on-session payment and then one more off-session payment
I wanna make sure the error does not come up again
In the mean time, if you can give me a way to know how many mandates a PM has, and how to get its mandates ID's , I'm sure that could help me someday
so this is the on-session payment, confirmed client-side, with setup_future_usage null
req_Ne4fPMuSp30Pz5
What about it? It's in a state of requires_action, indicating you need to authenticate
ok sorry this is the succeeded one
req_kZDok93dlaGuGd
and now, this is the off-session payment that did not throw the error of multiple mandates
req_IsTGMeJ4Fwtmdp
Okay, does that resolve your issue?
if you can give me a way to know how many mandates a PM has, and how to get its mandates ID's , I'm sure that could help me someday
Unfortunately we do not expose that in the API from what I can tell
ok no pb
But if you follow our recommendations you should not run into this issue in the future ๐ค
yep it's the fingerscross part that scares me :p
I understand however that your collegue has been looking for it and did not find it so I guess I understand you will not have a better answer for me tonight about it
so I agree that the problem is solved for now ๐
if I may, though, it seems to me that you were not right when you said I should not confirm a PaymentIntent client side...
the only problem was about setup_future_usage in the end... not confirming server-side or client-side
english is not my mother tongue so I don't want you to take that the wrong way...
I am just saying this, so that, if indeed you were not correct, maybe you should just take some time to improve your knowledge on that part?
because you almost had me rewrite a lot of my code telling me I should not confirm client side...
nevermind... I am very happy that this worked out well for me in the end
I really appreciate the help you guys provide
I just think this is not an easy part of the doc since you made a mistake and it is worth spending some time on...
again thank you for your help, hoping you did not take that the wrong way