#Filip Rogić-webhooks
1 messages · Page 1 of 1 (latest)
Yes, Getting 405 not allowed message when it goes off
in test environment
It's set-up to change user "premium" property in the database 0 > 1 when it detects "invoice paid" event -- not sure if that's the correct event to hook it up on even
Just to make sure I'm understanding correctly, you're saying when the event is sent to your server that your server is responding with a 405?
That's the message I'm seeing in Stripe dashboard at webhook logs
Do you have the ID of an event where you saw this behavior that you can share?
Thank you for that. Okay, yes, when we attempt to send this event to your server, your server is responding with a 405.
When I was testing on localhost before deploying on the server, they were going through
Also, is it even possible to affect my current logged in user using webhooks? I'm using Sanctum validating in Laravel and collect the bearer token in Vue on the frontend. My concern is if the handle function for the webhook can even recognize the Auth::user() in Laravel, because of the redirections
Using the https://buy.stripe.com/test_00g02PaaL29I7K0eUU link
because it does redirect away from the app to handle payment
Do I need to consider a different integration approach? Building the payment page myself instead of using the no-code link you provide
In summary - I need to change the current user value in DB when the Premium package is purchased, what is the best approach to this?
I'm not sure whether you can have webhooks take action based on the currently authenticated user, that would be dependent on the frameworks you're using and their capabilities.
My suspicion is that you can't, because how would that work in scenarios where you have a single webhook endpoint but multiple customers that are currently authenticated?
If you're wanting to be notified whenever a customer completes a checkout session, then you'll probably want to listen for checkout.session.completed events.
We won't have much insight into how you need to write your event handler code though, as that will fluctuate greatly depending on the various components that your system is leveraging.
So using the no-code link and webhooks is not the approach I should be taking.
I should build the page myself and send API requests in the controller with user data?
A low code approach may still be viable, can you help me understand the flow that you're hoping to achieve?
The flow would be the user navigating to the Buy Premium page in my app, filling payment information and firing a function in my controller that updates the user row for the user that sent the request so user.premium (0 => 1) and after my app handles the permissions that the user enabled by purchasing the premium package
Hm, so I think the biggest challenge there is what you're describing, finding a way to map the purchase back to one of your records so you know which DB entry to update.
Payment Links collect email address, so you could try relying on that, but I think that could lead to problems if a user mistypes their email or something along those lines.
I think what may work better is to leverage Checkout Sessions (they also route your users to a hosted checkout experience the way Payment Links do). When creating the session you can leverage the metadata parameter to store a value identifying the user, so you can map the event back to the user who created/completed the session.
https://stripe.com/docs/payments/checkout
https://stripe.com/docs/api/metadata
So I can place my user IDs in the request payload for the stripe checkout and in the response of the request I can get it back in my handler?
Yes, the value will be echo in the response, but it will also be included in the event data when the associated webhook event is sent to your server.
What happens if an error occurs? Do payments still go through if a mistake in the system happens? Obviously I don't want to charge customers if all of my handler actions haven't been successfully completed
Yes, checkout.session.completed events are sent after a checkout session has been completed (meaning the payment has also been completed). Returning an error back to us will not have any action (other than us reading that as your system couldn't receive the event we sent and we'll queue it to be retried).
If your handling code is unable to handle the event, then your error logic will need a way to act accordingly depending on what your goals are. For example, you could have your error handling logic refund the associated payment if you aren't able to update the entry in your DB.
Okay thank you, I'll go forward with the integration and contact if any other issues occur. Thanks again!