Overview

Webhook delivery in the SIBS Payment Gateway is designed to operate within an asynchronous, event-driven architecture.

To support reliable operation and troubleshooting, the platform provides visibility into webhook delivery behavior, including success rates, failures, retries, and operational alerts.

This section describes the operational observability model for webhook delivery and the mechanisms available to monitor and manage webhook execution.

Webhook Delivery Observability

Webhook delivery is asynchronous and may involve multiple delivery attempts for the same event.

The platform provides visibility into:

• Delivery attempts
• Successful deliveries
• Failed deliveries
• Retry behavior

This allows integrators to monitor webhook reliability and identify potential delivery issues affecting transaction processing.

Delivery Status and Retry Behavior

When a webhook delivery attempt fails (e.g. non-200 HTTP response or connectivity issues), the platform may retry delivery according to internal retry policies.

Important characteristics:

• Multiple delivery attempts may occur for the same webhook
• Retry timing is not guaranteed to be deterministic
• Duplicate webhook deliveries are expected and must be handled

Detailed webhook delivery semantics, acknowledgement requirements, and idempotent processing strategies are described in E.1.3 – Webhook Delivery, Retries and Idempotency.

Integrators must ensure:

• Idempotent webhook processing
• Safe reprocessing of repeated events
• No assumption of single delivery

Retry behavior is internal to the platform and not externally configurable. Integrators must not rely on retry timing or frequency and must ensure that webhook processing remains idempotent and resilient to repeated delivery attempts.

For webhook processing requirements, refer to E.1 – Webhooks (Notifications) and E.2.6 – Consistency Model: Query vs Webhook.

Failure Visibility

The platform provides mechanisms to identify failed webhook deliveries.

Typical failure scenarios include:

• Endpoint unavailability
• Timeout during delivery
• Invalid or non-200 HTTP responses
• Network or infrastructure issues

Failure visibility enables:

• Detection of delivery issues
• Operational troubleshooting and root cause analysis
• Operational response and recovery

Transient failures and intermittent delivery disruptions should be expected in distributed systems and handled through resilient retry-aware processing architectures.

Operational Alerts and Notifications

To support proactive monitoring, the platform may generate operational alerts related to webhook delivery issues.

These may include:

• Email notifications for repeated failures
• Alerts triggered by delivery anomalies
• Notifications of persistent endpoint issues

These mechanisms allow integrators to react quickly to disruptions in webhook delivery.

Webhook operational monitoring provides visibility into delivery behavior only and does not expose transaction state, payment outcome, or business-level status.

Monitoring and Operational Practices

To ensure reliable webhook processing, integrators should implement:

• Monitoring of webhook endpoint availability
• Logging of all webhook deliveries and responses
• Alerting for repeated delivery failures
• Reconciliation using the Status Inquiry APIs when inconsistencies are detected

Webhook delivery must always be considered part of a broader observability and reliability strategy.

Operational monitoring strategies should define alert thresholds, escalation paths, and response procedures appropriate to the criticality of the payment environment.

Detailed operational logging, correlation, observability, and monitoring practices are described in E.1.6 – Logging and Monitoring.

Operational visibility of webhook delivery (including statistics, failures, and alerts) is typically accessed through the Backoffice interface. For details on operational tooling and navigation, refer to G. Backoffice SPG.

Relationship with Transaction State Management

Webhook delivery observability does not replace transaction state validation.

Monitoring webhook delivery ensures reliability of event reception, but final transaction outcomes should be confirmed via Status Inquiry when no final webhook is available or when additional confirmation, recovery, reconciliation, or inconsistency resolution is required.

Summary

Webhook operational statistics and monitoring provide visibility into the reliability and behavior of webhook delivery.

By combining:

• Delivery observability
• Failure detection
• Retry awareness
• Operational alerting

Integrators can ensure robust, resilient, and auditable webhook processing.

This capability is essential for maintaining reliable transaction state propagation in asynchronous payment flows.