#munjay_api

1 messages · Page 1 of 1 (latest)

cold pivotBOT
#

👋 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/1374748714291433504

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

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.

stray turtle
#

Hi 👋 Link payments aren't mandate-sensitive, you shouldn't need to worry about or handle mandates expiring.

By default, Link runs as an abstracted payment method, where you don't see details of the underlying funding source. You can take a look at this guide to get a feel for how to force Link to behave like card payment methods:
https://docs.stripe.com/payments/link/link-payment-integrations?link-integrations=link-card-integrations
That guide also explains what card details you'll see when Link is used to wrap a funding source other than a card, such as a bank account, so there are no underlying card details to be exposed to you.

sour flare
#

We've had a surge in setup_intents being link, and when we try to confirm a payment intent using a payment method that has type link, it says we need a mandate? is that not true

stray turtle
#

I don't think so, can you share an example of a request/intent where you saw that error?

sour flare
#

ahhh im just realising now, is it potentially because i had this line?

PaymentIntentCreateParams.builder() .setSetupFutureUsage(PaymentIntentCreateParams.SetupFutureUsage.OFF_SESSION)

#

req_CeKJQGNKpqCPQS

#

yes i think i misread this error then

cold pivotBOT
stray turtle
#

Hm, I am a little surprised you're getting an error there.

sour flare
#

the thing is we collect payment details first separately from charging them, so i think the call to setSetupFutureUsage was redundant in the first place

#

I've just tried it without supplying the mandate, and it works so i think its solved

#

So it means i dont have to handle/worry about mandate_ids on my backend right?

stray turtle
#

Awesome, I'm glad to hear that resolved the issue from your side!

I'm still convinced that you shouldn't have seen that error in the first place, and will be digging into that with my teams.

I'm pretty sure you don't need to worry about handling mandates for Link payments, but you encountering that error is making me nervous that I'm wrong about that.

sour flare
#

Thanks for the help!

stray turtle
#

Okay, I've confirmed that Link isn't expecting mandate details. The error is being thrown by our Payment Intent flow, and the team that owns that and Link are collaborating on how to solve this. I'm not sure when a fix will be shipped to avoid the occurrence of that error related to needing mandate_data, but I don't anticipate you running into any problems regarding the lifecycle of a mandate for Link payments.