Webhooks are amazing, use them!
How to use webhooks to build your subscription-based platform
Context
When I was working on phpReel I needed a way of implementing payments in a recurring manner. I wanted something very simple to set up and most importantly, something that will help me move most of the payment process away from my application because it was hard enough to stream videos, I didn’t want to try building a payment processing open-source software too and fail miserably.
All my research eventually brought me to webhooks and once I understood what is a webhook and what it does I was hooked. This is my goal with this article, to get you from not knowing a thing about webhook to being amazed by how useful they can turn out to be.
What is a webhook?
Although the term might seem strange, the actual concept is really easy to understand. A webhook is nothing more than a way of communicating between apps. It pretty much works as a notification system, where one app sends a notification and another app receives it and acts accordingly to a set of predefined rules.
Real-life example, please!
First of all, I am 100% sure that you have encountered webhooks by now dozens of times without you actually realizing it. Have you ever went shopping, paid with your credit card, and immediately got a text or an app notification telling you someone has made a purchase? Well if that happened to you then you already know what a webhook does. The bank waits for someone to make a charge on your bank account, once someone does it, it fires an event that sends you a text.
How does it work?
As I previously stated, this is a way of communicating between two apps, but how do they actually do that?
Everything is done by registering an endpoint on your application. This acts as a bridge between the two apps. To better demonstrate how this works I will use the subscription-based application as an example.
The basic use case is something like this:
- A customer goes to your website and purchases a subscription. The purchase is actually done 100% by a payment service provider (Stripe, Paypal, or any other vendor of similar services). phpReel uses Stripe, so in this case, the user goes to Stripe’s website, fills out all the required fields, and Stripe attempts to charge the customer.
- At this point, Stripe will do its magic (store the credit card info, charge the customer, and so on) and at the end of this process will actually send you the results. These results can vary upon a lot of factors like: was the credit card declined or not, did the customer had enough cash in the bank for that charge, was the payment successful?
- The result is sent to you via the webhook which is nothing fancy actually. Is just an API route (might be something like domain.com/stripe/webhook) that must receive a POST request containing the result of the payment process. Inside that route, you have to define what happens to your application in various situations (what happens if the user doesn’t have enough funds, in this case, you might want to send the user a message to try again, or if the received message tells you that the payment was successful you have to start that user’s subscription).
This is the actual magic of webhooks. By using them you can completely separate two systems that rely on each other to work but don’t actually need each other’s implementations. As you saw, our app doesn't have to keep track of any payment information and the third party doesn't care if your app is a subscription-based application or a donation website.
How to do it without webhooks?
The same concept presented above can be actually implemented without webhooks, by simply using API calls but you will see really fast why this approach must be avoided.
Let’s say that we are creating the same application, in order to check out the subscription status we would have to call Stripe’s API to check if there are any new users that subscribed or renewed their subscription. But how do you know when to make those calls?
You might call once every 5 minutes but if you do this, someone that subscribes now might have access to the platform in 5 minutes from now which might be confusing for the user.
You might call it non stop but this is not just inefficient, it will actually make Stripe ban you temporarily because you spam the API with your calls.
This is why we can say that a webhook is a reverse API. In the case of an API, we actually call a third party, with webhooks, the third party calls us.
How does the third party know what to call?
You have to check out the third-party documentation for more information about this but generally speaking, they should have a form where you enter your endpoint.
How do I know what events will I receive?
Again, please check out the third party’s documentation, every provider is different, they send different events via the webhook so you must build your app in a way that accommodates those events.
This is a very down-to-earth approach to webhooks. It was not created to give you extensive knowledge on the topic but to introduce you to the concept in an easy-to-understand manner.
The article was made possible by phpReel, my open-source subscription-based video streaming application. If you want to support me please consider checking it out, giving it a star, contributing, using it, or spreading the word.
