Webhook

Xendit will send your web application HTTPS requests asynchronously after certain events occur. Example of an event is a VA payment event when it indicates that Xendit has successfully processed incoming VA payment, so you can proceed to process your customer’s order, but these events differ for each Xendit product.

These asynchronous requests are known as webhooks. Typically, the reason that your web application would get an HTTP webhook would be that something a user did should probably be handled by your web application.

Xendit uses webhooks to let your application know when events happen. When the event occurs, Xendit makes an HTTP request (usually a POST request) to the URL you configured for the webhook. Xendit's request will include details of the event such as the transaction details or any data related to the Xendit product you’re using.

This is a comparison of API vs Webhook flow using Xendit Invoice flow as an example:

To handle a webhook you only need to build a small web application that can accept the HTTP requests. If you already have a web application set up, handling a webhook is usually as easy as adding a new URL to your application.

If you don't already have a web application, almost all server-side programming languages offer frameworks to help you build one. Examples include:

Webhooks can also be handled by serverless frameworks like AWS Lambda and Azure Functions. Really anything that can receive and reply to an HTTP request will do.

Whichever framework and language you choose, webhooks function the same for every Xendit application. An HTTP request will be made to a URI that you provide to Xendit. Your application must acknowledge the event immediately and perform whatever logic you feel necessary afterwards - read/write from a database, integrate with another API, or perform some computation.

Last Updated on 2023-09-04