Creating a Webhook

To create a webhook :

1. Navigate to Merchants → Webhooks
2. Click on "+ Create" button
3. Enter the webhook name
4. Enter the target URL
5. Select at least one trigger
6. Configure headers if needed
7. Configure payload fields if needed
8. Click on "Create" button

During creation, the user defines the main configuration of the endpoint.

Required configuration

The following fields are required :

Optional configuration

The following configuration can also be completed during creation:

Once the webhook is created, the user is redirected to the webhook detail page.

Trigger event families

Webhook triggers are grouped by event family.

The current version supports three event families:

• Transaction: Track payment execution and lifecycle changes.
• Checkout: Track checkout sessions and payment progression.
• Batch: Track transaction batch processing and batch-level outcomes.

A webhook does not have a separate Webhook Type field.

The event families covered by a webhook are determined automatically by the selected triggers.

Example :

• If only Transaction triggers are selected, the webhook receives Transaction events.
• If Transaction and Checkout triggers are selected, the webhook receives Transaction and Checkout events.
• If triggers are selected across all families, the webhook can receive Transaction, Checkout, and Batch events.

Editing a Webhook

Click Edit to enter edit mode. In edit mode, users with the required permissions can update the webhook configuration. The edit page is organized into sections:

Editable elements may include:

• webhook name
• target URL
• custom headers
• selected triggers
• payload configuration by event family

Changes are staged locally.

No modification is applied until Save is clicked.

Saving changes

Click Save to apply pending modifications.

Once saved, the updated configuration becomes the reference configuration for future webhook deliveries.

Resetting changes

Click Reset to discard unsaved modifications.

Reset restores the webhook configuration to its last saved state.

Unsaved changes

If a user attempts to leave the page with unsaved changes, the Console displays a confirmation modal.

Message: Are you sure you want to close this page? Your updates will not be saved.

Available actions:

• No, go back: Returns to the page so the user can Save or Reset.
• Yes, I’m sure: Leaves the page and discards pending changes.

Configuring headers

Headers can be configured directly from the webhook edit page.

Headers are additional HTTP values sent with each webhook request.

They are often required by receiving systems to identify the source of the request, route it internally, or apply integration-specific processing rules.

Each header is defined by:

Adding a header

To add a header:

1. Go to the webhook edit page.
2. Open the Custom headers section.
3. Enter a header key.
4. Enter the corresponding header value.
5. Click Add header if another header is required.
6. Click Save to apply the configuration.

Header changes are staged locally.

They are not applied until Save is clicked.

Removing a header

To remove a header, click the delete icon next to the header row.

The header is removed from the local configuration.

The change is only applied after clicking Save.

Header usage

Headers should match the requirements of the receiving system.

Examples of common usage include:

• identifying the webhook source
• routing the request inside an internal system
• applying environment-specific processing
• supporting integration-specific rules

Before activating a webhook, make sure that required headers are correctly configured.

Incorrect or missing headers may prevent the receiving system from processing webhook requests correctly.

Configuring Triggers

The Trigger configuration section lets users select which events generate webhook deliveries.

Triggers are grouped by event family:

• Transactions
• Checkout
• Batch

Users can select individual triggers, all triggers in a category, all triggers in an event family, or all triggers across all event families.

At least one trigger must be selected before saving.

Selecting triggers determines which event families the webhook receives.

Configuring Payloads

Webhook payloads can be configured from the webhook edit page.

The payload configuration defines which fields are included in webhook deliveries.

Available fields depend on the selected Payload configurator tab. Mandatory fields are locked and cannot be removed.

Optional fields can be selected or unselected depending on what the receiving system needs. The Payload configurator may also include internal tabs for:

• Transaction
• Checkout
• Batch

These tabs exist only inside the Payload configurator. They do not represent separate webhook pages or separate webhook types.

Use these tabs to configure the payload fields for each event family when relevant.

Field selector

The Field selector lists the fields available for the selected event family.

Fields can have different behaviors:

Use the checkboxes to select or unselect optional fields.

Mandatory fields remain visible and locked so users understand what will always be sent.

Preview payload

The Preview payload shows an example JSON payload based on the selected fields.

When several event families are relevant, the preview can be reviewed through Transaction, Checkout, and Batch tabs inside the Sample payload component.

Use these tabs to check the expected structure for each event family before saving the configuration. The preview updates when fields are selected or removed.

Use the preview to check:

• which fields will be sent
• how the payload is structured
• whether the receiving system can process the selected data
• whether unnecessary fields can be removed

Reset

The Reset action restores the payload configuration to the last saved version.

Use Reset when you want to discard unsaved payload changes.

Save as a preset

The Save as a preset action allows the current payload field selection to be saved for reuse.

Presets help teams apply the same payload structure to the same event type configuration.

Payload presets are event-type-specific.

A Transaction preset can only be reused in the Transaction payload configurator. A Checkout preset can only be reused in the Checkout payload configurator. A Batch preset can only be reused in the Batch payload configurator.

Saving payload changes

Payload changes are staged locally.

They are not applied until Save is clicked on the webhook edit page.

Once saved, the updated payload configuration applies to future webhook deliveries.

Webhook Lifecycle

Webhook endpoints follow a lifecycle.

The main statuses are:

Available actions depend on the webhook status and user permissions.

Activating a Webhook

Activate makes a webhook live.

Activation is available from the webhook edit page when the webhook is in a state that allows activation.

Before activating a webhook, review:

• target URL
• selected triggers
• headers
• payload configuration

If the configuration has unsaved changes, Save must be completed before changing the webhook status. This prevents status changes from being applied to an outdated or partially edited configuration.

Activation requires a successful test. During activation, the user selects one trigger or event to test. A successful HTTP 2xx response is enough to validate that the receiving endpoint accepts webhook requests. The activation test does not validate every selected trigger individually.

Deactivating a Webhook

Deactivate stops future deliveries for the webhook endpoint.

The webhook remains visible in the Console and can be reviewed or edited.

Deactivation is useful when:

• the receiving system is temporarily unavailable
• the endpoint needs to be replaced
• the configuration must be reviewed before being used again

Deactivation requires explicit confirmation.

Deleting a Webhook

Delete removes a webhook from operational use.

Delete is a controlled destructive action.

The delete action is available only when the webhook status allows deletion.

Active webhooks must be deactivated before they can be deleted.

The confirmation modal explains the impact of the action and requires explicit confirmation before deletion.

Deleted webhooks are no longer used for future deliveries

Confirmation dialogs

Sensitive lifecycle actions use confirmation dialogs to prevent accidental changes.

This applies to actions such as:

• Activate
• Deactivate
• Delete

Confirmation dialogs explain the expected impact before the user confirms the action.

For destructive actions, the user may be required to type a confirmation value before the action button becomes available.

Best practises

Use clear webhook names

Use names that describe the purpose of the endpoint.

Examples:

• Order status updates
• Checkout notifications
• Reconciliation webhook
• OMS transaction updates

Avoid generic names such as:

• Test
• Webjook 1
• New endpoint

Clear names make webhooks easier to identify in tables, logs and support investigations.

Use one endpoint per integration purpose

A single endpoint can receive events from several trigger families, but it is still best to keep endpoints organized by integration purpose.

Avoid sending unrelated events to the same endpoint when different systems process different workflows.

Example :

• one webhook for order management
• one webhook for reconciliation
• one webhook for monitoring

This makes troubleshooting easier and reduces the risk of breaking multiple workflows at once.

Keep payloads focused

Select only the payload fields required by the receiving system.

Focused payloads are easier to process and reduce unnecessary data exposure.

Review headers before activation

Make sure required headers are correctly configured before activating the webhook.

Incorrect or missing headers may prevent the receiving system from processing notifications correctly.

Deactivate before replacing an endpoint

If a target URL changes, review the configuration carefully.

When replacing an endpoint, deactivate the old webhook if it should no longer receive notifications.

Review configuration before saving

Before clicking Save, review:

• target URL
• selected triggers
• custom headers
• payload fields
• additional settings such as Notify last transaction only

Saved changes affect future webhook deliveries.