Overview

This chapter defines the core security principles and controls required for a secure integration with SIBS Payment Gateway (SPG).

It focuses on the controls that must be enforced across the integration lifecycle, while detailed behaviors such as transaction validation, webhook processing, and error handling are defined in their respective sections of this documentation.

Scope and Positioning

Security in SPG integrations is achieved through a combination of controls applied across:

• Communication channels
• Data handling practices
• External input validation
• Transaction lifecycle management
• Operational behavior

These controls collectively protect against:

• Unauthorized access
• Data tampering
• Duplicate or inconsistent transactions
• Information leakage

Security Model Overview

A secure SPG integration enforces security across the following layers:

• Communication Security
  Ensures that all interactions with SIBS are authenticated, integrity-protected, and encrypted
• Data Protection
  Prevents exposure or misuse of sensitive payment information
  Security responsibilities vary depending on the selected integration model. Server-to-Server integrations may require the merchant to handle PCI-sensitive data directly, while Form Integration reduces exposure of sensitive payment information within merchant systems.
• Trust Boundaries
  Ensures that all external inputs, including asynchronous notifications, are validated before being accepted
• Transaction Integrity
  Prevents duplicate, inconsistent, or invalid operations
• Operational Security
  Ensures safe handling of errors, retries, and observability

For asynchronous lifecycle handling, consistency behavior, and operational edge cases, refer to F.3.4 – Asynchronous and Consistency Scenarios and F.3.5 – Edge Cases and Operational Pitfalls.

Illustrative Examples

The following examples highlight common security pitfalls and the expected control:

Example 1 – Unvalidated Asynchronous Notification

A notification indicates paymentStatus = Success, and the system immediately updates the order status.

Risk:
A forged, delayed, or duplicated notification may lead to incorrect fulfillment.

Control:
Asynchronous notifications must be decrypted, validated, correlated with a known transaction, and processed according to the expected transaction lifecycle before any business action is triggered.

For detailed webhook validation, delivery behavior, integrity verification, and security recommendations, refer to E.1 – Webhooks (Notifications).

Example 2 – Unsafe Retry Behavior

A payment request fails due to invalid parameters, and the system retries automatically.

Risk:
Repeated invalid requests or unintended duplicate operations.

Control:
Retry mechanisms must be controlled and must not introduce duplicate or inconsistent operations.

Example 3 – Missing Integrity Validation

A response is processed without verifying its authenticity and integrity.

Risk:
Tampered or replayed responses may be accepted as valid.

Control:
All messages must be verified for authenticity and integrity before being accepted or processed.

Key Principle

Security must be enforced as a system-wide responsibility, not as a feature of individual API calls.

All components of the integration must assume that:

• External inputs are untrusted until validated
• Data integrity must be explicitly verified
• Final transaction state must be determined from a validated final webhook paymentStatus, or through Status Inquiry when confirmation, recovery, reconciliation, or inconsistency resolution is required.

Failure to enforce these principles may result in operational, financial, or security risk, inconsistent transaction states, or exposure of sensitive information.