#murat-acar_api
quartz arrowBOT
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.
- murat-acar_api, 1 day ago, 26 messages
strange wyvernBOT
đ 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/1243147394196176937
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
formal meteor
hi there!
compact pine
hi
formal meteor
how are you accepting payments? Checkout Session, Payment Element, something else?
compact pine
checkout session
formal meteor
then yes you have to use webhook events to fillfill the order. otherwise what would happen if the user pays, the immediately close their browser windows before being redirected to your website?
compact pine
Whether the user closes the window after making the payment or not is not important to me. As long as the necessary information (order id, payment status) is sent to my designated API in the background, I can later show the relevant information to the user. In my previous system, I was using a payment method called Param. While making a request during payment there, it was enough for me to specify which API it should callback to, which is why I asked
formal meteor
As long as the necessary information (order id, payment status) is sent to my designated API in the background
sure, that exactly what webhooks are for: to send the information to your backend.
compact pine
I was actually expecting you to trigger this webhook in your servers, so that the payment information would automatically be sent to the API I specified during the payment process
I might write this in the feedback section; I just wanted to know if we must trigger the webhook ourselves
then should i renew the webhook each 90 day in my server
formal meteor
I'm sorry I don't understand your question. the way this works:
- you create the Checkout Session
- user enter their payment information and submits the form
- Stripe sends you a
checkout.session.completedevent with all the information you need so you can fulfill the order
compact pine
I found it unnecessary to run a script in my terminal in the background for Stripe to send me the payment result with the checkout.session.completed event. I was expecting to provide the callback URL in the checkout.sessions.create step and have you automatically post to my callback URL
formal meteor
got it, but that's not how Stripe works.
formal meteor
what do you mean by "renew"? once the webhook is working, there's nothing to change.
compact pine
The stripe login command gives me a 90-day limit to webhook work
Please note: this key will expire after 90 days, at which point you'll need to re-authenticate.
sorry is this key test key?
formal meteor
the Stripe CLI is for testing only. for productions you should use a real webhook endpoint in the dashboard
compact pine
Alright, I see. So, when I go live, just specifying my callback URL in the Hosted endpoints section in this url will be enough, as far as I understand. Is that correct?
the cli scriprts for local testing
formal meteor
pretty much yes. you'll also need to udpate your webhook secret in your code
compact pine
got it thx bro you are great