#nate-subscription-link

1 messages ยท Page 1 of 1 (latest)

sour plazaBOT
final ruin
#

@wicked socket I'm sorry I'm not sure I really understand what that could mean.

#

nate-subscription-link

wicked socket
#

Hi @final ruin ! What can I clarify for you?

final ruin
#

I guess first off did you reproduce this end to end in Test mode and see the same behaviour?

wicked socket
#

Yes, I did

final ruin
#

Okay, can you provide all relevant information so that I can help you debug this?

wicked socket
#

Yep. What information do you need?

final ruin
#

@wicked socket Are you the developer fully owning the integration and writing the whole code? If so you should be able to share exact object ids (Subscription and Invoice ids, PaymentIntent, request ids, etc.)

wicked socket
#

Yep. A subscription that repro'd this in test mode is sub_1Nheq7CcKlYJxALVFFRn4bu0. The invoice that is failing is in_1NhewyCcKlYJxALVTrZK9sSK. The payment intent is pi_3NhexdCcKlYJxALV0IzOCF8J.

#

I can also provide live-mode object IDs if that would be helpful.

final ruin
#

looking, will take a while Discord is quite busy right now

#

That Invoice doesn't even have Link associated with it so I'm quite confused and based on those ids I see you're a pretty big account with lots of custom settings. I think we spoke about another obscure thing last week

wicked socket
#

Yes, we did speak last week. The Link payment method is attached to the subscription

#

it also shows up on the payment intent

final ruin
#

As far as I can tell this Invoice was retried, just the payment failed right? Which is quite different from what you said about being "stuck" no?

wicked socket
#

If I continue to advance the test clock, it should become failed. I'm happy to do that if it would help. I can also provide a live-mode payment intent ID that did fail, if that would be more helpful.

final ruin
#

Sorry right now I'm trying to understand your real report. You originally said they were stuck which to me means we never try to pay them at all. But they seem to be paid, just failing which is a different issue/behaviour
I'm trying to figure out what you meant

wicked socket
#

Ah, I understand now. Yes, you are right. They are failed, not stuck.

final ruin
#

okay so you're saying all your Link payments on off session Invoices are failing 100% in Live mode?

#

or you're saying something a bit different than that?

wicked socket
#

In live mode, we have 4,763 Link payments from off-session invoices in the requires_confirmation state, compared to only 439 succeeded

final ruin
#

Gotcha, thanks that helps

#

@wicked socket have you done Link before or is this the first time your company is using Link this way?
Looking at your logs we think something is wrong/broken with the way you integrated, you never collected mandate details for the subscription and seem to have done some manual attachment of a Link PaymentMethod which we don't really understand

wicked socket
#

We set up Link for the first time a few months ago and have not made any significant changes to the integration since. It's very possible that we did something wrong

final ruin
#

Can you give me a concrete example of a Subscription in Live mode with one Invoice that worked fine last month and now fails today without any change?

#

Sorry, it's really hard to say from just that random example as I don't get why your code would ever call the Attach PaymentMethod API for Link for example

wicked socket
#

Subscription in Live mode with one Invoice that worked fine last month and now fails today without any change?
I don't understand what you're asking for here. Wouldn't a subscription have to have multiple invoices, one that worked fine in one month, and one that failed in the next? Can you clarify what you're looking for?

final ruin
#

You said you have used Link for a few months now. So I'm thinking what you did in Test mode is not what you do in Live mode at all and I'm asking for a real example where the Subscription was paid say on June 1st and July 1st and August 1st but now is failing or something

wicked socket
#

I don't get why your code would ever call the Attach PaymentMethod API for Link for example
We're using the same codepath for Link as we do for cards, since we weren't aware of any different handling necessary for Link. Our general flow is 1) create payment method from client, 2) pass payment method ID to server, 3) server creates subscription with the payment method ID as default_payment_method, 4) server does online confirmation of the payment intent

final ruin
#

because the way you integrated Link in Test mode in that one example you gave me is really confusing to me and I'm not sure which doc(s) you are following that got you there and hoping it's not what you do in prod

wicked socket
#

It is what we do in prod ๐Ÿ˜ฌ

final ruin
#

Okay so you never collected any mandate information at all? I'm assuming you have never had a "subsequent payment" work and it's your first time noticing or hitting a renewal? ๐Ÿ˜…

wicked socket
#

Yeah, we just noticed that the vast majority of our subsequent payments using Link are failing

#

Because we confirm the first payment intent from an invoice on the server, we didn't notice when we set up the integration

final ruin
#

yeah unfortunately this is because you don't seem to have integrated most of this properly

#

even the guide you linked never says "attach the PaymentMethod yourself first" right?

#

That's likely some remnants of an old part of your integration your kept but that's not in our docs

wicked socket
#

Sounds likely. I'm pretty sure that's how we were doing it with Sources in the past.

#

We are calling confirmPaymentIntent from the server and passing mandate_data there

final ruin
#

yeah but Sources were just for cards and way before Mandate mattered

#

And that specific code is explicitly not calling the Attach PaymentMethod API right?

#

and that mandate_data is one-time use

#

I'm trying to repro, I haven't seen anyone do something like this with Link and I don't think is expected but will take me a while to get there

wicked socket
#

A different part of the same API handler does call Attach Payment Method. That happens before we create the subscription

#

It makes sense that that mandate_data is one-time use

#

What's the right way to set up a Link payment for recurring off-session usage?

final ruin
#

A different part of the same API handler does call Attach Payment Method. That happens before we create the subscription
you shouldn't really do that really, especially with Link

wicked socket
#

To clarify, not with any payment methods? What problems does that cause? Should we be passing the payment method ID as the default_payment_method param to Create/Update subscription? (we are now)

final ruin
#

I'm a bit worried this is going to take hours and hours on Discord and you have an integration that is many years old and full of legacy cruft/code that is not really in our recommended path

#

the way you built your integration is definitely not what we have recommended for quite a while now

wicked socket
#

Fair enough. I'll reach out to support or our account liaison for further help, unless you think there's a better path.

final ruin
#

I mean the problem is that there are many things here and I'm not really sure how to help you here.
But the real issue is your integration right now. I'm 99% sure of this and I also don't think there's any way to recover without getting those end customers to come back and pay with link again the right way

wicked socket
#

We can figure out what to do with those existing customers with our team

#

But as far as immediate actions, it sounds like we should 1) disable Link to contain the damage, and 2) stop calling Attach Payment Method?

final ruin
#

well it's more than this but yes

#

Like there's so many questions I want to ask like why would you even use that finalize on the server part too

#

But overall the problem seems to be that because you attached the Link PM upfront, the underlying first PaymentIntent has setup_future_usage: null and so because of it it leads to a state where the Mandate is single-use

#

But in the meantime I think the fix is to not attach that PaymentMethod

#

if you try in Test mode it should work for the future off session/renewal

#

I'm pairing with someone on my team to see if there's an easy work around, just taking a while to get into the exact state you're on as we've never seen anyone do that with Link before

wicked socket
#

Thanks @final ruin . I need to run, but one of my teammates will hop on to continue the conversation.

final ruin
#

At this point I think you should work straight with our support team again @wicked socket for next steps

wicked socket
#

Roger that

#

Thanks for your help @final ruin

final ruin
#

Sure thing, sorry about the trouble