#linqisnice_best-practices
mental spireBOT
đ 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/1288775878385467404
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
warm willow
hi!
nothing specific
yes : https://docs.stripe.com/api/payment-link/update.
not sure what you mean by "an order [being] updated" and how that connects to a PaymentLink which is just a static/anonymous link for the most part
no limit on creation
wouldn't you use something like CheckoutSessions directly instead? But again I don't follow what you mean by updating an order and how that would work
to be clear I kind of expect that you create + redirect to a PaymentLink/CheckoutSession after the customer has gone through your cart and order process and is now ready to pay the final amount
desert inlet
I'm talking about updating the checkout session data, i.e. the products and amount. Not the actual URL, btw. Sorry for not making that clear. When an order i nour system si modified (products reemoved/added, we'd like that to be reflected in the payment link created for that order)
We're a property management system and it should be possible for our customers (property owners, hoteliers), to send order mails which contain a payment link. Their customer, in turn, can choose to use it or not
I hope that makes it clearer
the optimal flow for our system would be
- every order created ahs a payment link attached
- every time an order in our system is modified, the checkout session attached to the payment link should reflect that
is that possible?
warm willow
I struggle to understand how that would integrate though. You can't really change the details while the customer is visiting the Stripe Checkout page, and to me it's more that you would create the order in your database, and you email links to your site and the site checks the current state of your database, auths the user, and creates a CheckoutSession for the final details and redirects the user to that.
But yes, you can send the customer a PaymentLink and then later call the Update PaymentLink API to change things. But it's messy because you don't know what the customer is actually going to pay; if they click the link 'before' you update it then they are redirected to a CheckoutSession that gets created with the current state of the Link object and can pay that CheckoutSession for 24 hours after opening it.
I really wouldn't do it that way, I would send links to my own site, the customer visits the site, the site does backend logic to create a CheckoutSession from your order details, and redirects to that for payment.
desert inlet
Ok so what about... inactivating the previous link and just replacing it with a new?
Wouldnt that solve that issue?
warm willow
how would the user get the new link?
desert inlet
The user can only get the link if sent the link, either via mail or personally by the property owner/host/hotelier
since an order can change quite significantly and frequently, depending on the host, it'd be good if the payment link was also updated (as you would suggest, by creating a new link every time)(
warm willow
so I can be sent a link, then later you inactivate it(https://docs.stripe.com/payment-links/api#deactivate-link), I click the link in my email and I'm redirected to a "this link is expired" page.
desert inlet
Yes but that would be on the host, it's his fault for changing the order but not re-sending the email
with the new link
warm willow
that seems unoptimal? that's why I would not use Stripe PaymentLinks for this, I would use my own site and my own "links" that map to my database and then create a CheckoutSession for the current database state, and that way I can have persistent links.
desert inlet
right i see what u mean
direct them to a link which triggers an endpoint that creates the link then and there
that indeed is better
i feel stupid for not considering that lol
warm willow
yes you can have an endpoint that just checks details like user auth/database state, and then 3xx redirects to a CheckoutSession .url immediately
desert inlet
so then what ios the purpose of these payment links?
We also dont want to build our own UI so maybe we ca nstill redirect ot the payment liknk
jsut with that intermediary step
warm willow
sending links in emaiks for less complex cases than yours, or just putting an easy "pay now" link on your website when you have static pricing, less complex/no code things like that