Every payment in the Bitcoin Lightning Network is asynchronous.

Therefore, every payment inside of ZBD API is asynchronous.

Payment Lifecycle

Although it may be that 99% of the time you use the ZBD API to send a payment it settles immediately, this is NOT a certainty. All payments are asynchronous so there’s still chances they will not succeed.

The Lightning Network is a decentralized organism / network and therefore there are many factors and circumstances that are outside of ZBD’s control. Whether it is another provider going offline, or improper management of Bitcoin liquidity on the network, payments in Lightning can fail and you as a developer must understand how to react to these failures.

Receiving Bitcoin

To receive payments, you normally create Charges (or Static Charges). These are created and remain in a pending status until someone successfully scans and pays the Charge, at which point it becomes completed. If enough time is elapsed, the Charge can also expire making it impossible to be paid.

Sending Bitcoin

On the other hand, to send Bitcoin you must use one of the many Payment APIs. Payments through the Lightning Network can always fail, due to a myriad of reasons (e.g. network connectivity, size of payment, destination or receipient, etc). Because of that, every payment starts in a processing state, and only when it’s settled or failed does it receive the completed or failed status’ respectively.

As you can understand now, it is important that you subscribe to updates on all your Charges and Payments when using the ZBD API.

ZBD API retains a 97% payment success rate for all time payments in the Lightning Network.

Callback URL

In order to properly receive updates to any Payments, Charges, and Withdrawals created through the ZBD API, you should always pass along the callbackUrl property.

This callbackUrl should point to an HTTP server that you control/manage and should expose a POST HTTP call on this endpoint. It could look like this:


Callback URLs MUST be HTTPS. HTTP calls are ignored. The server must be reachable to the public internet and not require any additional means of authentication.

We are in the process of adding retry functionality for these callback payloads, in case your server happens to be offline when a payment settles.


Below is a set of example payloads for the main APIs available:


Coming soon.


Coming soon.


Coming soon.

Lightning Address

Coming soon.

Security / Integrity

It is important that developers are able to validate the integrity of all API calls performed to their callbackUrl endpoints.

To ensure that calls are coming from trusted ZBD API servers, please use the ZBD IP Address API Endpoint.

By checking the originating IP address of the request received to your callback servers, with the approved IP address returned from this API endpoint, you are able to verify the authenticity of the requests.

We have plans to expose features to further harden this security by providing data-encryption capabilities. The idea here is to allow developers to enter a secret key in their ZBD Project’s Settings and then require this key to decode the encrypted data payload.

Testing Locally

When developing with the ZBD API, it is imperative that developers can test full end-to-end functionality of payment flows, including the async updates received through the callbackUrls.

In order to receive updates locally, we recommend using a proxy server such as ngrok.

  • Follow the installation steps
  • Run command to start ngrok tunnel ngrok http 8000
  • ngrok URL (e.g. https://84c5dfxx39d74.ngrok.io) is provided
    • This URL is accessible to the world —> expose an API endpoint here and use it as the callbackUrl (e.g. https://84c5dfxx39d74.ngrok.io/api/zbd-callback).

You will now be able to receive async updates about your ZBD API transactions directly to your local environment.