Webhooks
Introduction
Generally, when you make a request to an API endpoint, you expect to get a near-immediate response. However, some requests may take a long time to process, leading to timeout errors. To prevent a timeout error, a pending response is returned. Since your records need to be updated with the final state of the request, you need either of the following:
Poll
Use webhooks to receive events
Webhooks vs Polling
Polling requires making a GET
request at regular intervals to get the final status of a request. For example, when a customer makes a payment for a transaction, you keep making a request for the transaction status until you get a successful transaction status.
With webhooks, the resource server, Juice in this case, sends updates to your server when the status of your request changes. The change in status of a request is known as an event. You’ll typically listen to these events on a POST
endpoint called your webhook URL.
We recommend that you use webhook to provide value to your customers over using polling. We recommend you use the polling endpoints on occasions where you need to verify a payment or if your system has been down for an extended duration. With webhooks, ensure your webhook endpoint processes events in an idempotent fashion to avoid duplicate processing.
Creating a Webhook URL
A webhook URL is simply a POST
endpoint that a resource server sends updates to. The URL needs to parse a JSON request and return a 200 OK
:
When your webhook URL receives an event from us, it needs to parse and acknowledge the event. Acknowledging an event means returning a 200 OK
response in the HTTP header. Without a 200 OK
in the response header, we’ll keep sending events for the next 48 hours at specific intervals:
Adding webhook URLs
Sample Request
Sample Response
Verify event origin
Since your webhook URL is publicly available, you need to verify that events originate from Juice and not a bad actor. The two ways to ensure events to your webhook URL are from Juice are:
Checksum validation
IP whitelisting
Checksum validation
We have added a checksum attribute to every webhook payload.
Example payload below
To calculate the checksum we've used the following algorithm
event|json_encoded_data
The encoded data should exclude the checksum
attribute and should be in alphabetical order.
The checksum validation will fail if the encoded data is rendered in the wrong order. See example:
{"currency": "USD", "amount":1000, "card_id": "81817411-9ffd-42ba-8bc8-f407b5cef9d9", "reference": "b070b0d2-e394-4783-a6f0-f10ccb3cae89"}
Notice: The encoded data is the same, but the order in which the string is generated is not alphabetical. This checksum validation will fail.
create an HMAC SHA-256 hex-encoded hash, using the
id
of the business receiving the request as the hash key
In order to validate the checksum, you will need to repeat the operation on your system, using your id
as the hash key. If your checksum matches ours, you can be certain that the request originated from Juice.
IP whitelisting
Using this method, you can accept requests from specific IP addresses to access your webhook URL, effectively blocking others.
Juice will send webhooks exclusively from the following IP address:
68.183.219.141 167.71.50.238 167.71.57.22 164.92.131.158 167.172.191.189 134.209.237.227
You should whitelist this IP address and consider requests from other IP addresses a counterfeit.
Go live checklist
After creating your webhook URLs successfully, you need to check this list for an optimal experience
Ensure your webhook URL is publicly available online (localhost URLs cannot receive events)
If using
.htaccess
kindly remember to add the trailing/
to the URLTest your webhook to ensure you’re getting the JSON body and returning a
200 OK
HTTP responseIf your webhook function has long-running tasks, you should first acknowledge receiving the webhook by returning a
200 OK
before proceeding with the long-running tasksIf we don’t get a
200 OK
HTTP response from your webhooks, we flag it as a failed attempt.Ensure your webhook URL endpoints are idempotent.
Supported events
Here are the events we currently raise. We would add more to this list as we hook into more actions in the future.
In the sandbox environment, successful transactions will remain pending. Only failed transaction events will be propagated.
payment.session.created
payment.session.succeeded
payment.session.failed
Sample Response [Seccessful Desposit]
Last updated