Skip to content
Menu

PAYMENT GATEWAY

[THK] F.6.7 Production Observability Prerequisites

Production-ready integrations must provide full visibility into transaction processing, enabling reliable monitoring, troubleshooting, and operational control.

In SIBS Payment Gateway (SPG) integrations, observability is essential to ensure that transactions can be tracked, correlated, and diagnosed across their full lifecycle, including asynchronous updates, retries, and failure scenarios.

A system that lacks observability cannot be safely or reliably operated in production, as issues cannot be detected, understood, or resolved in a timely manner.

Observability as a Production Requirement

Observability is not an optional enhancement – it is a mandatory prerequisite for production operation.

A production-ready system must allow:

  • End-to-end tracking of each transaction
  • Correlation between API requests, webhook notifications, and internal processing
  • Identification of failures, inconsistencies, and anomalies

Without these capabilities:

  • Transaction issues cannot be diagnosed
  • Reconciliation problems cannot be resolved
  • Operational reliability cannot be guaranteed

See F.5 Logging, Monitoring, and Observability for implementation guidance.

Transaction Traceability and Correlation

Each transaction must be traceable across all system interactions.

This requires consistent use and logging of:

  • transactionID (SPG identifier)
  • merchantTransactionId (merchant-side identifier)
  • notificationID (webhook identifier)

These identifiers must be:

  • Persisted across all processing stages
  • Used to correlate events, API calls, and internal operations
  • Available for debugging and operational analysis

Traceability must enable reconstruction of the full transaction lifecycle from initiation to final state.

See F.5.2 Correlation and Traceability.

Visibility Across the Transaction Lifecycle

Observability must cover all stages of transaction processing, including:

  • Initial API requests and responses
  • Intermediate states (e.g., Pending, InProcessing)
  • Webhook-driven updates
  • Status API validation
  • Final transaction outcome

This ensures that:

  • State evolution is visible and understandable
  • Delays or inconsistencies can be identified
  • Final outcomes can be verified against authoritative sources

See F.6.3 Asynchronous Flow Readiness.

Monitoring of Operational Signals

Production systems must actively monitor key operational indicators.

This includes:

  • Transaction success and failure rates
  • Frequency of pending or delayed transactions
  • Webhook delivery and processing behavior
  • Retry and recovery activity

Monitoring must allow:

  • Early detection of abnormal patterns
  • Identification of systemic issues
  • Rapid response to operational incidents

Without monitoring, issues may remain undetected until they impact business operations.

See F.5.3 Monitoring and Alerting.

Detection of Failures and Inconsistencies

Observability must enable detection of:

  • Failed or incomplete transactions
  • Transactions in unknown or indeterminate states
  • Inconsistencies between SPG and internal system state
  • Missing or delayed webhook notifications

The system must support:

  • Identification of affected transactions
  • Diagnosis of root causes
  • Initiation of recovery or reconciliation processes

See F.6.6 Operational Resilience and Failure Strategy.

Support for Debugging and Root Cause Analysis

Operational issues must be diagnosable through available observability data.

This requires:

  • Sufficient logging of transaction processing steps
  • Correlation of events across system boundaries
  • Visibility into retry and recovery actions

The system must enable:

  • Reconstruction of transaction history
  • Identification of failure points
  • Verification of system behavior under error conditions

Consistency with Asynchronous and Idempotent Processing

Observability must be aligned with the system’s asynchronous and idempotent behavior.

This includes:

  • Tracking multiple events related to the same transaction
  • Distinguishing between initial processing and retries
  • Identifying duplicate or out-of-order notifications

Observability must reflect the true and authoritative state of the system without introducing ambiguity.

See F.6.2 Transaction Idempotency and Duplicate Protection and F.6.4 Webhook Reliability and Processing Guarantees.

Operational Readiness Criteria

An integration is observability-ready for production when:

  • All transactions can be traced end-to-end
  • All processing stages are visible and correlated
  • Failures and anomalies can be detected in real time
  • Transaction state can be verified and reconciled
  • Debugging and root cause analysis are supported

Failure to meet these criteria results in operational risk and reduced system reliability.

Final Consideration

Observability is a foundational requirement for operating SPG integrations in production.

A production-ready system ensures that:

  • Every transaction can be tracked and understood
  • Operational issues can be detected and resolved
  • System behavior remains transparent under all conditions

Without observability, even a technically correct integration becomes operationally unmanageable.

Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.

Strictly Necessary Cookies

Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.