Webhooks are an important part of your payment integration. They allow Just Wallet notify you about events that happen on your account, such as a charge or payment transaction. A webhook URL is an endpoint on your server where you can receive notifications about such events. When an event occurs, we'll make a POST request to that endpoint, with a JSON body containing the details about the event, including the type of event and the data associated with it.

Enabling webhooks

Here's how to set up a webhook on your Just Wallet account:

  1. Log in to your dashboard and click on Settings
  2. Navigate to Webhooks to add your webhook URL
  3. Check all the boxes and save your settings

Verifying webhook signatures

When enabling webhooks, you have to set a webhook secret. Since webhook URLs are publicly accessible, the webhook secret allows you to verify that incoming requests are from Just Wallet. You can specify any value as your secret hash, but we recommend something random. You should also store it as an environment variable on your server. You must specify a webhook secret, as we'll include it in our request to your webhook URL, in a header called Signature. In the webhook endpoint, check if the Signature header is present and that it matches the secret hash you set. If the header is missing, or the value doesn't match, you can discard the request, as it isn't from Just Wallet.

Responding to webhook requests

To acknowledge receipt of a webhook, your endpoint must return a 200 HTTP status code. Any other response codes, including 3xx codes, will be treated as a failure. We don't care about the response body or headers

You may need to disable CSRF protection

Some web frameworks like Rails or Django, automatically check that every POST request contains a CSRF token. This is a useful security feature that protects you and your users from cross-site request forgery.


Here are a few examples of implementing a webhook endpoint in php

              // In a Laravel-like app:
              Route::post('webhook', function (\Illuminate\Http\Request $request) {
                  //check for the signature
                  $secret = 'your-secret';
                  $signature = $request->header('webhook-secret');
                  $sign_secret = hash_hmac('sha256', json_encode($request->all()), $secret);
                  if (!$signature || ($signature !== $sign_secret)) {
                      // This request isn't from Just Wallet; discard
                  $payload = $request->all();
                  // It's a good idea to log all received events.
                  // Do something (that doesn't take too long) with the payload
                  return response(200);

Retries & Failure

In a case where Just Wallet was unable to reach the URL, all the webhooks will be retried. Webhook URLs must respond with a status 200 OK or the request will be considered unsuccessful and retried.

Sample webhook format

The JSON payload below is a sample response of a webhook event that gets sent to your webhook URL. You should know that all webhook events across Just Wallet, payout, funding, payouts all follow the same payload format as shown below.

Fields Descriptions
event The name or type of webhook event that gets sent eg; charge.
data The payload of the webhook event object that gets sent.

Webhook events

Event Descriptions
charge Payment event.
payout Payout event.
funding Account funding event.

Best practices

Don't rely solely on webhooks

Have a backup strategy in place, in case your webhook endpoint fails. For instance, if your webhook endpoint is throwing server errors, you won't know about any new customer payments because webhook requests will fail.

Respond quickly

Your webhook endpoint needs to respond within a certain time limit, or we'll consider it a failure and try again. Avoid doing long-running tasks or network calls in your webhook endpoint so you don't hit the timeout. If your framework supports it, you can have your webhook endpoint immediately return a 200 status code, and then perform the rest of its duties; otherwise, you should dispatch any long-running tasks to a job queue, and then respond.