Skip to content
Menu

PAYMENT GATEWAY

[THK] F.3.5 Edge Cases and Operational Pitfalls

Overview

This section highlights critical edge cases and operational pitfalls observed in real-world SIBS Payment Gateway (SPG) integrations.

It focuses on non-obvious scenarios that can lead to:

  • Incorrect transaction states
  • Duplicate processing
  • Inconsistent business actions

The goal is to ensure integrations remain robust under imperfect conditions, without duplicating patterns already covered in previous sections.

Delayed or Missing Webhooks

Scenario

  • A transaction remains in Pending
  • No webhook is received within the expected timeframe

Risk

  • Transactions remain unresolved
  • Business processes stall

Handling

  • Do not rely exclusively on webhooks
  • Use the Status API (GET <ROOT_URL>/api/v2/payments/{transactionID}/status) as fallback
  • Include all non-final transactions in reconciliation routines

Out-of-Order State Updates

Scenario

  • A Success state is processed
  • A delayed webhook or internal process later reintroduces a Pending state

Risk

  • Final states are overwritten
  • Incorrect rollback of business actions

Handling

  • Enforce forward-only state transitions
  • Prevent overwriting of final states (Success, Declined)
  • Maintain an explicit state hierarchy in the persistence layer

Duplicate Event Processing

Scenario

  • The same webhook is delivered multiple times
  • Status checks return identical states repeatedly

Risk

  • Duplicate business actions (e.g., double fulfillment)
  • Data inconsistencies

Handling

  • Implement idempotent processing
  • Track processed events using:
    • transactionID
    • Event identifiers (e.g., notification ID)
  • Ensure downstream operations are safe to re-execute

Premature Business Actions

Scenario

  • Business logic is triggered on:
    • Initial response
    • Pending state

Risk

  • Orders fulfilled without confirmed payment
  • Financial inconsistencies

Handling

  • Trigger business actions only when paymentStatus = "Success"
  • Treat Pending as a non-final state
  • Explicitly separate:
    • Transaction creation
    • Transaction confirmation

Timeout Misinterpretation

Scenario

  • A transaction reaches Timeout

Risk

  • Treated as final failure
  • Duplicate retry attempts

Handling

  • Treat Timeout as an uncertain state, not a final failure
  • Always confirm via Status API (GET <ROOT_URL>/api/v2/payments/{transactionID}/status)
  • Include in reconciliation workflows

Duplicate Transaction Submission

Scenario

  • Same logical transaction is submitted multiple times
  • Network retries or client-side duplication

Risk

  • Multiple transactions for the same intent
  • Financial duplication

Handling

  • Enforce uniqueness of merchantTransactionId
  • Implement idempotent request logic
  • Use Status API to retrieve existing transaction instead of recreating

Partial Completion in Multi-Step Flows

Scenario

  • AUTH succeeds
  • CAPTURE is delayed, retried, or fails

Risk

  • Funds reserved but not collected
  • Inconsistent financial state

Handling

  • Track each phase independently
  • Reconcile outstanding authorizations
  • Implement clear lifecycle management for:
    • AUTH
    • CAPTURE

Long-Lived Pending Transactions

Scenario

  • Transactions remain in Pending for extended periods (e.g., reference-based payments)

Risk

  • Accumulation of unresolved transactions
  • Operational blind spots

Handling

  • Implement expiration or review policies
  • Periodically reconcile all pending transactions
  • Ensure business processes tolerate delayed completion

Inconsistent State Across Systems

Scenario

  • Internal system state diverges from SPG state

Risk

  • Incorrect reporting
  • Reconciliation failures

Handling

  • Treat SPG (via Status API GET <ROOT_URL>/api/v2/payments/{transactionID}/status) as source of truth
  • Periodically reconcile internal data
  • Log all state transitions for traceability

Summary

Edge cases in SPG integrations are primarily driven by:

  • Asynchronous behavior
  • Event delivery uncertainty
  • Distributed system characteristics

Robust integrations must:

  • Assume non-deterministic timing
  • Enforce idempotency and state consistency
  • Continuously reconcile and validate transaction state

Handling these scenarios correctly ensures:

  • Reliable financial operations
  • Consistent business outcomes
  • Resilience under real-world conditions
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.