#oranges13_code

1 messages · Page 1 of 1 (latest)

swift frigateBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1251188005763551253

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

waxen portalBOT
#

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.

vale blade
#

Hey there! We finally got this flow working 🎉 but my problem now is that if there's a failed payment I get multiple subscriptions for the customer ☠️

#

Due to where the subscription is created in the flow.. is there a best practice here? Is it ok if the subscriptions are just left ot expire or should I actively be removing them or attempting to pass that value back to retry?

sour jacinth
#

Hi there 👋 if a payment fails your recovery flow should try to reuse the same client secret it did before, rather than creating a new Subscription.

#

It's fine to leave them to expire if that fits your flows.

vale blade
#

OK so in error state, pass back the secret to retry?

sour jacinth
#

Ah, sorry, overlooked that you're doing server-side confirmation

vale blade
#

I sort of got it working with createPaymentMethod to simulate the way we currently do it, but apparently that can cause renewal issues, and I believe we are definitely seeing that when our customers renew the next year

#

Yeah 🫠 We don't necessarily have to do server side but I'm tyring to modify the code as little as possible.

#

There's a lot of other logic going on around the subscription creation

sour jacinth
#

Gotcha, and totally get that, just needed to reorient myself a bit 😅

So this is the step that normally creates a Subscription when a Customer goes through your flow.
https://docs.stripe.com/payments/finalize-payments-on-the-server?platform=web&type=subscription#create-and-submit-payment

When trying to process a payment again because the initial payment failed, you can use that same flow to create a new Subscription, but you can also reuse the existing Subscription's first Invoice's Payment Intent to try another confirmation.

You would need to either track the ID of the Subscription, or the ID of it's first Payment Intent, but then you can make another request to confirm that existing payment intent.

Finalize payments on the server

Build an integration where you render the Payment Element before you create a PaymentIntent or SetupIntent, then confirm the Intent from your server.

vale blade
#

OK, thank you. I just wanted to get some confirmation on best practices.