I'm in a bit of a pickle
I want to create a webhook listener to Stripe's customer.subscription.trial_will_end event to send a customer an email letting them know billing will start and giving them cancellation info, but I can't work out how to test it works without waiting a day between each test, i.e. setting the trial period for 4 days, and the event being fired when there's 3 days left.
The Stripe docs give a method for testing trials, but this doesn't fit my use case as the only thing that doesn't work using that method is the trial_will_end event. The CLI can send webhook events, but again the trial_will_end event is not implemented.
How can I test this functionality without having to wait a full day between tests?
There are not currently great ways to manage time-dependent events like this. You will need to seed some test data to generate such events. For a given day of testing through, you can re-use a recent trial_will_end event (say evt_123) using the CLI resend function (doc):
stripe events resend evt_123 --webhook-endpoint we_321
This will let you re-test your endpoint to handle the event & send the email multiple times, ingesting the same event.
Related
I'm new to webhooks and am not really getting the hang of some points of it. KISS; the current problem is, think about:
a platform
that provides a service X
to book a service X, customer Y has to pay in advance
every payment is authorized first only
every payment is captured after the service has been received
From the booking of a service to the capture of the related payment, only the authorization is handled involving the client-side. All the rest is handled on the server-side.
For every possible case of a booking of a service on my platform, payment authorizations is requested as the first action on the server-side. Adaptations of the DB of the platform are only executed after a successful authorization of the payment from the frontend.
The only fallback webhook I implement is for the case where a customer books a service, authenticates, and then loses connection. Because in this case, the customer would have booked the service, but the platform server could not make the related updates. So the customer will have paid, but not receive his / her service via the platform.
My strategy is thus to implement a webhook to listen for the event of a transaction authorization "completed", and, if no transaction data is found internally, execute what needs to be done.
BUT, two questions popped up:
A) How can I control that a webhook gets executed AFTER the regular server-side script should have been executed? Delay the execution of the webhook script? What are the best pracs here?
B) If A) is possible, isn't it smarter to just cancel the authorized payment in the webhook, instead of coding the completion of every possible transaction via webhook? Already the thing that you lose the entire payload in case of a client who lost connection (the payload that you need to execute the server-side tasks after a payment authorization), and the consequent need of passing the according payload back-and-fourth to your payment API, while ensuring that CID is encrypted etc.; this just sounds like overkill to me.. Was anyone in the same situation, and also decided to just immediately cancel the just-authorized payment in lost connections via webhooks? Or must webhooks generally execute the exact same server-side script that the related server-validation would do? Meaning I have to find a way to pass the payload to my webhook function?
The webhook is your notification that the event has happened - you're under no obligation to perform any processing right that moment, or ever.
If you're using webhooks as a backup to a primary synchronous flow (a good design!), then you can record the event and enqueue for later.
Stick a record somewhere indicating "got this authorization. Check this again in an hour to make sure the customer did the thing."
And to your comment above: you probably don't want your sync and async flows to be the same. Your async backup might involve contacting the customer eg via email, while that's not necessary for the sync flow since the customer is still on session.
I have implemented Recurring Event with google api and I want to integrate office 365 calendar recurring as well, I can read the event from office 365 calendar api, but when I want to take only changed instances I can not find any api endpoint that return only changes like google does.
I'm using endpoints like:
GET https://graph.microsoft.com/me/calendars/{calendarId}/calendarview
GET https://graph.microsoft.com/me/calendars/{calendarId}/events
Endpoint 'events' return main recurring event, this is what I'm using to read the main event, and works fine.
Endpoint 'calendarView' returns all events calculated for recurring event, if is daily without end, it will return 365 events for whole year if you query that way.
The problem is I can't read updated or deleted instances for this recurring event. I tried delta/feed endpoint but returns everything without any status or information for updated or deleted instances/occurrences.
Does anyone have found any solution for this?
Thank you.
AFAIK, this is not supported currently. Being said that, consider filing user voice for your specific ask so that it could be considered for future implementation.
I am using Stripe to test how my code would react to recurring subscription renewal payment attempts for a product we are working on (need to test success, failure ...etc.). And it seems that most answers on StackOverflow suggest creating a subscription with a recurring payment of 1 day (which is the minimum recurring payment available at Stripe), and waiting until next day to see how my code would react to the webhook notifications. (By the way, I could not find much documentation on Stripe to suggest testing methodologies for recurring payment).
I do not agree much with this approach, because it stretches the testing of my code to more than a week, maybe even two, but in normal conditions I might finish that testing within a couple of hours.
I think one of the following two approaches would be sufficient to do my coding/testing.
Find a way to make recurring subscription interval happen on shorter custom periods, such as every 15 minutes, or every 10 minutes.
A better solution is to make recurring subscriptions trigger on demand. That is, I create a subscription, and then I would update the date for the next renewal manually to a custom value, such as "1 minute in the future" or "30 seconds in the future" which would trigger the payment attempt.
Is there a way of doing any of those two options in Stripe? If neither is a viable option, how do I test recurring payments efficiently.
Thanks.
Our solution was to reset the billing cycle of the subscription.
open the subscription in Stripe
click "Actions" in the upper right
select "Update Subscription"
be sure to switch off "Prorate changes"
scroll down and open "Advanced Options"
check "Reset billing cycle"
and finally... Update Subscription
This will trigger a new subscription payment and all the associated webhooks.
Simple method
Definitely #Marc found the great option for arbitrarily subscription renewal. The same action he described in this answer can be done programmatically or with the Stripe CLI:
stripe subscriptions update sub_id \
--proration-behavior=none \
--billing-cycle-anchor=now
This command generates the following sequence of events:
charge.succeeded
invoice.finalized
invoice.created
invoice.paid
invoice.payment_succeeded
customer.subscription.updated
payment_intent.succeeded
payment_intent.created
Advanced method
The use of test clock gives more opportunities to verify your system's behavior. It is possible to attach test clock not only to the Subscription object.
So I would start with their testing documentation It walks you through the process.
it seems that you can trigger events on the fly with CLI commands.
Also look at the Webhook Monitor
I read laravel documentations about Events and Notifications, it seems we can fire an event and from that event (using ShouldBroadcast interface) broadcast it to laravel echo which i understand, in the other hand we can use Notifications viaBroadcast to do the same, so what's the difference?
What the provided answer lacks imo is that they are in most cases used both instead of 1 or the other, which seems to be the tone of the provided answer/question.
An event is something significant in your application. Let's assume your application is a Webshop.
A significant action in your webshop can be Product Purchased . When a product is purchased you need to do a lot of different steps. Putting this all inside a controller and potentially in several different places can get very messy and not clear.
So a good approach would be to use a Event called ProductPurchased . This event can have Listeners, those listeners are in this case all the steps you need to perform when a user purchases a product.
e.g.:
ProductPurchased (event)
BillClient (eventlistener)
GenerateInvoice (eventlistener)
notifyClient (eventlistener)
...
Let's say we want to notify our client with a text-message and an email when they purchased a product.
So on the notifyClient event-listener we can create a Notification . This notification is responsible for sending a message to the client. This can be a SMS/Slack-message/Email/...
And like you mentioned both Events and Notifications can be put on the Queue or can be broadcasted. Broadcasting is mainly used in combination with Laravel Echo and the use of Websockets.
You choose notifications when you want to send something to different channels. Mail/SMS/Slack..
If you only need broadcasting you can just use ShouldBroadcast. Just like when you only want to send an e-mail use Mail:: without the need for a notification.
Notifications are a nice way to group the same 'message' to different destinations.
After thinking a lot, i found out that they are made for different things, here's what i understood:
Notifications:
Consider facebook, everytime you login you see bunch of notifications about things that happened while you where away, also if you are present you see live notifications..
meanwhile you're getting emails about notifications that you want..
this is exactly what Laravel Notifications is doing.
you can use notify method on your eloquent models such as App\User about something like OrderApproved which will do whatever you planned it to do for you like sending sms to that user. and also you can save one instant of that notification on database so when user comes back he or she can see that you have approved their order..
Events:
it's when something happens, like when a new user is created and you want to do different things like sending verification email, sending verification sms and.. this is why you create an event so that you could handle different logics of that event using listeners.
when it comes to broadcasting, you can use ShouldBroadcast interface on your event and from there you can sync data with your admin panel that a new user is registered. this will be useful when admin is watching list of users and without reloading the page you could user Laravel Echo to receive that event on admin panel and append new registered user to the list.
Conclusion:
it really depends on what you need, if you just want to update something in your interface, maybe events are what you need. but if you need to do more you can use notifications.
in the end events are used when you need to do things when something happens while notifications are report of what just happened.
hope it help others..
I have a question
I have a simple system where a User creates a Booking
After a user has created a booking, an email and a SMS will be sent to the user.
I have though of multiple ways to approach this
After the booking was made, send the email and the SMS(blocking)
After the booking was made, Fire an event that is queueable and has two listeners. One sends the email. The second one sends the SMS.
After the booking was made, Fire and event, that will queue 2 jobs, one that sends the email, the second one sends the sms.
Option 1 is a no-go since it is blocking and doesn't have a retry to my Transactional Email provider or SMS provider.
Option 2 is do-able
Option 3 is do-able
In the future I want to be able to send the same email/sms without the BookingConfirmation event, so I will eventually need jobs that can be queue'd without the event.
Or is the event part just overhead and can I queue the jobs directly from the Controller instead of firing the event?
I am basically asking if I should use the Events at all or just use Jobs?
Thanks!
Events are useful because you can fire one event and have multiple action independently.
That means if in the future you want to have a third action, if you use events you can just add another event callback, meanwhile if you skip the events and directly put the jobs into the queue, you have to modify the controller to put the third action.
Convenience lies in the fact you don't have to alter any method in order to add new functionality.
In the end of the day, it's up to the developer. Events provide better code between each action. But performance wise, I think it is the same.
I would put all the tasks as Jobs in a queue, you then fire events (last line of job) when the Job is done, so you can do any follow up actions or things you want to do to inform the use.
So then you can have a job for each task and keep them simple, and also less exceptions or errors to track on each one.
The system I am using at the moment for example uses the event to trigger the next job, but other tasks I fire multiple jobs at once.
Eg.
user clicks booked.
dispatch job email
job email is queued
Job email is processed
Job email sends event
Event picked up by listener
Listener dispatch Job SMS
job SMS is queued
Job SMS is processed
Job SMS sends event
Event picked up by listener
anything else you want to do...
might sound a lot of steps but all are short and then simple to follow and update.