Overview

This chapter defines the integration models supported by the SIBS Payment Gateway (SPG) and establishes the functional, technical, and operational scope associated with each model.

It enables integrators to:

• Understand the structural differences between integration approaches
• Evaluate the technical, security, and operational implications of each model
• Identify the required components to implement, operate, and maintain each integration
• Select the most appropriate model based on system architecture, compliance requirements, and business constraints

This chapter also defines the expected documentation scope for each integration model, ensuring consistency, completeness, and alignment across all implementation guides.

Scope of Each Integration Model

Each integration model is not limited to a different way of initiating payments. It defines a complete interaction model between the merchant system and SPG, including:

• How payment requests are created and submitted
• How customer interaction is handled (if applicable)
• How transaction states evolve throughout the lifecycle
• How asynchronous events (callbacks/webhooks) are processed
• How operational actions (capture, refund, cancellation, MIT) are performed
• How errors, retries, and idempotency are handled
• How monitoring, logging, and troubleshooting are implemented

For this reason, each integration model is documented with a consistent structure covering:

• Functional description and positioning
• Typical use cases and applicability
• Technical flow (sequence of interactions)
• Authentication and security requirements
• Transaction lifecycle and state management
• API structure, endpoints, and payloads
• Asynchronous communication (callbacks/webhooks)
• Idempotency and retry behaviour
• Common pitfalls and error scenarios
• Practical integration examples (Postman, cURL, or equivalent)

This ensures that all models are described with the same level of depth and can be evaluated consistently.

Choosing an Integration Model

When selecting an integration model, consider the following aspects:

• Level of control over the payment lifecycle
• Responsibility for handling sensitive payment data
• Integration complexity and operational maintenance effort
• Time to market
• Existing platforms or technologies in use

SPG provides multiple integration models to accommodate these requirements, ranging from fully backend-driven integrations to hosted and plugin-based approaches.

All integration models are built on the same SPG platform capabilities. However, they differ significantly in how those capabilities are exposed, controlled, and operated by the merchant.

Depending on the model, the merchant may have full control over API interactions and transaction lifecycle management, or may delegate part of the payment interaction to SPG-managed components. Regardless of the model used for payment initiation, backend responsibilities such as transaction status handling, reconciliation, refunds, capture, and error management remain required.

In most cases, merchants adopt a primary integration model aligned with their architecture, while additional models may be used selectively to address specific business or technical scenarios.

The choice of integration model must also account for post-payment responsibilities. Payment processing in SPG may involve synchronous or asynchronous outcomes, depending on the payment method and execution flow. Final transaction outcomes may be communicated through webhooks and may also be retrieved through Status Inquiry when explicit status retrieval or recovery is required. As such, all integration models require proper handling of transaction-status mechanisms, as well as support for operational actions such as capture, refund, and reconciliation.

This diagram illustrates the progression between Plugin Integration, Form Integration, and Server-to-Server Integration in terms of merchant control, implementation complexity, exposure to sensitive data, and operational responsibility.

Responsibility and control increase from Plugin Integration to Server-to-Server Integration.

Available Integration Models

Server-to-Server Integration

In a Server-to-Server integration, merchant systems communicate directly with SPG using APIs.

This model provides the highest level of control over payment execution and transaction lifecycle management, including:

• Payment creation and execution
• Post-payment operations (capture, refund, MIT, etc.)

It is typically used when merchants require:

• Custom checkout experiences
• Advanced payment logic
• Full ownership of transaction handling

This approach is best suited for merchants with strong backend capabilities and more complex payment requirements.

For payment methods involving sensitive data (such as card payments), this model may increase the merchant’s PCI DSS scope, as payment data may be collected, transmitted, or processed within the merchant environment. This requires appropriate security controls, strict data handling policies, and compliance readiness.

Form Integration

Form Integration uses SIBS-hosted payment pages or embedded payment components to collect payment information.

In this model:

• The customer interacts with a payment interface managed by SIBS
• The merchant initiates and tracks the transaction via SPG

Key characteristics:

• Reduced integration complexity
• Limited exposure to sensitive payment data
• Built-in handling of payment UI and security

This approach is commonly chosen when:

• Faster implementation is required
• PCI DSS scope must be minimized
• Standardized checkout experience is acceptable

Despite delegating the payment interface to SPG, the merchant remains responsible for backend integration tasks, including checkout creation, transaction correlation using transactionID, handling redirects, processing transaction-status notifications, and retrieving transaction status through Status Inquiry when explicit verification, reconciliation, or recovery is required as part of the transaction lifecycle.

Plugin Integration

Plugin Integration relies on pre-built plugins available for supported e-commerce platforms.

These plugins encapsulate the integration logic and configuration, enabling merchants to start accepting payments with minimal development effort.

In this model:

• Payment flows and communication with SPG are managed by the plugin
• Integration follows predefined patterns aligned with the platform
• Depending on the plugin implementation, this model typically relies internally on Form Integration or API-based models.

This approach is typically used when:

• Merchants operate on supported platforms (e.g., WooCommerce, Magento, PrestaShop, Shopify)
• Rapid deployment is a priority
• Customization requirements are limited

Although plugins abstract most of the integration complexity, merchants remain responsible for correct configuration, operational monitoring, reconciliation processes, and alignment with their business workflows. Plugin behaviour may vary depending on the platform and specific implementation, and should be validated during integration and testing phases.

Relationship with Integration Model Subchapters

Each integration model described in this chapter is expanded in its corresponding subchapter:

• B.1 Integration Models – Server-to-Server Integration
• B.2 Integration Models – Form Integration
• B.3 Integration Models – Plugin Integrations
• B.4 Integration Models – Comparison and Criteria to Choose

These subchapters follow the scope defined above and provide the detailed implementation, configuration, and operational guidance required for each approach.

Moving Forward

Each integration model is described in detail in its own dedicated section, including:

• Supported use cases
• Technical flows
• Implementation guidelines

A comparison and decision guide is also provided to help merchants select the most appropriate integration model based on their technical and business requirements.

By understanding the characteristics of each integration model, you can choose the approach that best fits your systems and business needs.

Related Documentation

For implementation and operational details, refer to:

• E.1 Webhooks (Notifications) – for transaction-status notifications and event handling
• E.2 Status Inquiry / Get Status – for transaction status retrieval and reconciliation
• F.4 Security Best Practices – for security, compliance, and data protection considerations
• F.6 Production Readiness Guidelines – for go-live requirements and operational readiness