Webhooks – the Winning Recipe to Get Them Right
7 MIN READ
|
Updated on January 2, 2018
In the nineties, Amazon came up with an innovation, and named it “One-Click Buying”. Their sales kept escalating, and this particular “innovation” was a significant contributor to that – so significant, that Amazon even got it patented, and has since been fighting to prevent others from using it.
The reason behind this innovation? Their not-so-secret business model – “Make online shopping so easy and convenient that customers won’t think twice.”
Fast forward to 2009, Behavior Scientist B. J. Fogg, deep-dived into that concept, and came up with A Behaviour Model for Persuasive Design.
His observation: Human adults are naturally wired to be fundamentally lazy.
His solution: The makers of a product/service must acknowledge that fact and make the user experience as easy as possible.
…persuasive design relies heavily on the power of simplicity. A common example is the 1-click shopping at Amazon. Because it’s easy to buy things, people buy more. Simplicity changes behaviors.
And a webhook is one such component of “Persuasive Design”. And we’re going to see how. (Psst! If you are new to the concept of Webhooks, and you want to know how they benefit you, give this a quick read before you go further.)
You probably know how webhooks make your job easier, already.
Swapping the perception. Picture this: You provide “useful” webhooks to your customers. Their job gets easier. They get happier. Your customer satisfaction quotient thanks you. Professor B. J. Fogg pats your back!
Concocting the best possible API is a good first step in perfecting your product and making it fit your customers’ needs. But it doesn’t end there, does it? How do you further widen that curve on their faces with webhooks?
We started out with a similar question in our minds, and here’s how we pulled it off – an awesomesauce webhook recipe!
Step 1: Spot the right ingredients.
We noticed a genuine need of webhooks for subscription related events (subscription created, trial ending, subscription cancelled, etc.). These were mission-critical functions – they have a direct impact on the fundamental numbers of our customers’ businesses – all the more reason to get them more streamlined.
Step 2: Ensure that your dish can withstand the heat of the oven, without getting burnt.
The basic logic of webhooks is this: when a specific event occurs, the corresponding webhook with the necessary details will get triggered. This webhook will then be received by the listener, which will then perform the pre-defined actions. So how do we ensure that this process is as graceful as possible?
The bulbs went off – “Fail-over mechanism”.
Once a webhook is fired, Chargebee waits for twenty seconds to establish a connection with the listener, and another twenty seconds to get a response (a 200 status code) from it.
If any of this doesn’t happen within the prescribed time, then the webhook gets cancelled and the process is repeated automatically, at exponential time intervals for about 48 hours. And when all of those attempts don’t get a response, the webhook is then deemed to have “failed”.
This event will push out an email to the owner and the admin of the Chargebee account, notifying them about the failure and the reason for the same. (Here we got hit with another question – what if more than one webhook fails and the customer keeps getting emails from us? Last time we checked, that’s what we called “Inbox Spamming”. Hence, we make sure that Chargebee sends just one email per day.)
Step 3: Don’t forget the burnt crumbs – they’re equally essential.
Assuming that the customer looks through our email, fixes the listener and the subsequent webhooks are received properly. The day is saved.
Oh, but wait. What about those unsuccessful ones? (Reminder: We’re dealing with important data here. Important, unmissable data.)
The bulbs went off yet again – “Manual Webhooks”.
With this, the customer can now filter out the failed webhooks, and then manually resend them.
That’s about it. We had dished out our very own set of sumptuous webhooks!
A seamless fail-over mechanism is one of the key ingredients to get your webhooks right. And for that, you’ll have to think from all possible angles, figure out all possible glitches/scenarios, and make sure that your webhooks can elegantly tackle every single one of them!
Ours isn’t the only winning recipe under the sun, and yes, we have gained considerable inspiration from many other SaaSy webhook connoisseurs around the world.
And from that list, we’ve picked out 3 pretty neat webhook implementations that we make use of, to serve you today, in no particular order:
Three groups of our use cases. Three swell webhooks. Take a bow, guys!
Nice-to-Have Use Case:
Whenever a user raises a support ticket, a Freshdesk webhook (carrying details such as the email id of the user and the kind of question posed by them) gets delivered to our user analysis tool.
The user analysis tool takes this data and uses it to generate daily reports for us – which shed light on which customers have signed up for a trial, and on what questions they have in their minds about Chargebee.
This will in turn tell our sales mates how to handle each one of them differently (when a specific prospect has a question, making a sales pitch to them before that question is solved – not a good move).
In short, this webhook helps us in compiling a single report of those who have signed up and if they have sought our support yet. No polling whatsoever.
A webhook that just adds a bit of sunshine to your everyday routine work – a webhook that’s just really nice to have!
Must-Have Use Case:
In this case, the sales team actually initiates the webhooks, quite contrary to the previous example.
A “Lead” gets created in Salesforce, as and when someone signs up with Chargebee. Our sales comrades then evaluate them, and qualify them as an “Opportunity”, if their score is high enough.
And this marks the beginning of yet another webhook’s journey. This webhook carries information about the opportunity, their sales score, whether or not they have contacted support, whether they’ve claimed/verified their account, and whether or not the sales team has contacted them.
So all of these data are stored at one place – in our Business Intelligence (BI) system, making business decision-making easier and more informed.
With this webhook lending us a helping hand in this must-have-a-webhook scenario, we steer clear of costly sales mistakes.
Mission-Critical Use Case:
(Prelude: A small clarification – for the following few paragraphs, just keep in mind that the “Business” is Chargebee’s customer. B2B and its fascinating complexities!)
PayPal basically connects a Customer Account and a Business Account to facilitate transactions between them, via Chargebee – most of us are aware of this.
What we might not be aware of is, when a business signs up with Chargebee and chooses PayPal as a payment option, PayPal gives Chargebee API credentials, referring to the Business Account (think of it as a key for a specific door).
Let’s say that during checkout, one of their customers opts to pay by PayPal. Chargebee will then receive a Billing Agreement ID, pointing to the Customer Account (yes, another key, for another door).
Now that we have the basic concept sorted out, let’s jump to the webhooks part of the plot.
PayPal offers a slick message service called the PayPal Instant Payment Notification (PayPal IPN) that sends webhooks to a pre-mentioned URL. So when a business signs up with Chargebee and wants it to join hands with PayPal, we give them a notification URL to be configured in the corresponding account’s PayPal IPN.
How does this serve a “Mission-Critical” function?
Say a customer lost their credit card and has applied for a fresh one, and has decided to pay via PayPal Express Checkout in the meantime. After a couple of weeks, the new credit card arrives, and it’s time to switch back.
The customer cancels the Billing Agreement in their PayPal Account. Chargebee immediately gets to know about this through a webhook from PayPal IPN, and automatically removes PayPal from that customer’s Payment Method details. The customer will now have to update their payment method to continue their subscription. Mission-critical enough?
This webhook saves so much of our energy as opposed to certain other payment gateways, where we have to poll once every few hours to track transactions. The implications of doing that – more load on their server, and more time and effort spent from our side.
A RESTful API is excellent and would never go out of style, but by itself isn’t sufficient to make your product perfectly fit somebody else’s workflow. Webhooks complement your existing good APIs, and help you take those APIs to the next level.
There, however, is a catch: you can’t implement webhooks just for the sake of doing it. No. That’s not going to get you anywhere.
Pick out those events and/or functions that would actually benefit from having a webhook, churn out webhooks for those functions, and garnish them with an efficient fail-over mechanism.
Voila! Piping hot, kick-ass webhooks that’re sure to satisfy your customers’ tech-appetites!
