#nate-subscription-link
1 messages ยท Page 1 of 1 (latest)
@wicked socket I'm sorry I'm not sure I really understand what that could mean.
nate-subscription-link
Hi @final ruin ! What can I clarify for you?
I guess first off did you reproduce this end to end in Test mode and see the same behaviour?
Yes, I did
Okay, can you provide all relevant information so that I can help you debug this?
Yep. What information do you need?
@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.)
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.
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
Yes, we did speak last week. The Link payment method is attached to the subscription
it also shows up on the payment intent
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?
https://dashboard.stripe.com/test/events/evt_1NhexsCcKlYJxALVzgfEcoWl is a failed payment attempt for example
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.
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
Ah, I understand now. Yes, you are right. They are failed, not stuck.
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?
In live mode, we have 4,763 Link payments from off-session invoices in the requires_confirmation state, compared to only 439 succeeded
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
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
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
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?
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
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 asdefault_payment_method, 4) server does online confirmation of the payment intent
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
The docs we followed are https://stripe.com/docs/payments/finalize-payments-on-the-server?type=subscription
It is what we do in prod ๐ฌ
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? ๐
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
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
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
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
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?
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
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)
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
Fair enough. I'll reach out to support or our account liaison for further help, unless you think there's a better path.
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
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?
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
Thanks @final ruin . I need to run, but one of my teammates will hop on to continue the conversation.
At this point I think you should work straight with our support team again @wicked socket for next steps
Sure thing, sorry about the trouble