A webhook in web development is a method of augmenting or altering the behavior of a web page or web application with custom callbacks. These callbacks may be maintained, modified, and managed by third-party users and developers who may not necessarily be affiliated with the originating website or application.

Access the Webhooks Interface

In the navigation on the left hand side, click on Configurations > Integrations and tools > Webhooks.

Webhook Configuration

Click on Configuration in the top right corner.
In the Webhook urls add a URL and click on Add.
Select one or more Event types, you have the choice between
- Invoice events
- Subscription events
- Customer events
Add an email address to the Alert emails box and click on Add.
Enter a Username and a Password in the Credentials box.
You can copy the Secret key by clicking on .
Activate the webhook using the Status switch.
Click on Save.

Explanation for pending Webhooks

Sometimes webhooks stay on pending and it seems they are not even sent to your server.

First in, first out

All webhooks are sent in FIFO (first in, first out) order grouped for each customer.

That means that you can expect to get events for each customer in the right order.

Example: You do not get CUSTOMER_UPDATED before CUSTOMER_CREATED.

Note
If your service does not return an HTTP code between 200 and 299:
we consider the webhook as failed
we will block the next webhooks for that specific customer

Considerations for webhooks

Your endpoint must respond within 30 seconds.
A response with HTTP code 2XX is considered successful. All other responses are considered as failures.
The content of a webhook notifies of an event in the Frisbii Payment system, the affected resources, and the event type, but does not in itself carry any state. It is recommended to subsequently use the API to get the updated state of a resource.
Your endpoint must be idempotent, allowing multiple invocations of the same webhook with the same result as one invocation.
This is due to the fact that communication errors can result in a scenario where Frisbii Payments considers an invocation as failed even though it has been received. We will retry failed invocations. See below.
In failure scenarios, webhooks can be delivered out of order. Therefore always use the API to get the actual state of a resource.
An example is a subscription cancellation followed by an uncancel. The cancel webhook could be received after the uncancel.

Best practice

Frisbii Payment will send max. 10 webhook requests to your server at a time.

A good practice is to offload events to a local queue on your side and return 200 OK on each.

That means you will respond quickly and have no events blocking each other. You can then process each event from your queue and update your assets without any problems.

May Release - 06.05.2019