What can be shaped in a webhook endpoint?

An endpoint carries a name, a target URL and at least one trigger. Triggers are grouped by event family, so your merchants subscribe to exactly the events their systems need.

The three event families

• Transaction events, for payment execution such as an authorization or a refund.
• Checkout events, for conversion monitoring, such as an abandoned checkout.
• Batch events, for matching and reconciliation.

A merchant can select individual triggers, a full family or everything at once. One endpoint can cover all three families, or the merchant can split them across several endpoints, for example sending transaction events to an order system and batch events to finance.

Custom headers and payload configuration are available as optional steps at creation. The selection of triggers determines which fields are available in the payload configurator, so what arrives is what the merchant configured, with no generic payload to parse and no missing fields to chase.

As an operator, you can define webhook templates at Program Manager level, with pre-configured endpoint structures, triggers and payload fields. Your merchants then start from a working configuration and adjust it. Webhooks subscribe to the payment events the platform produces, which keeps event generation and event delivery as separate concerns and makes each delivery traceable.