Overview

SIBS Payment Gateway (SPG) provides multiple integration models to
accommodate different merchant architectures, technical capabilities, and
business requirements.

This section provides a structured comparison of the available integration models,
including Server-to-Server, Form Integration, and Plugin Integration, and highlights
their impact on technical responsibility, user experience, implementation complexity,
and operational ownership.

The available integration models are:

• Server-to-Server Integration (see B.1 Server-to-Server Integration)
• Form Integration (see B.2 Form Integration)
• Plugin Integration (see B.3 Plugin Integration)

Each model offers a different balance between:

• Control over the payment lifecycle
• Implementation complexity
• Security and compliance responsibilities
• Time-to-market

Integration Models at a Glance

Dimension	Server-to-Server	Form Integration	Plugin Integration
Integration Type	Direct API	Hosted + Backend (Hybrid)	Platform Plugin (Abstracted)
Control	Full control (merchant-managed)	Shared control	Limited control (platform-managed)
Implementation Complexity	High	Medium	Very Low
Time-to-Market	Longer	Moderate	Fast
PCI DSS Scope & Card Data Exposure	Full scope (merchant handles sensitive data)	Reduced scope (SIBS handles sensitive data)	Reduced scope (handled by plugin/platform)
UI Control	Full	Limited	Platform-defined
Backend Involvement	Full	Mandatory (Hybrid)	Indirect (via platform/plugin)
Customization	High	Moderate	Low
Advanced Flows (MIT, complex logic)	Fully supported	Partially supported	Limited / Not supported
Operational Ownership	Merchant	Shared	Platform / Plugin
Error Handling Responsibility	Merchant-managed	Shared (merchant + SIBS)	Platform/plugin-managed
Retry / Idempotency Responsibility	Merchant-managed	Merchant-managed	Platform/plugin-managed
Asynchronous Flow Handling	Full responsibility	Partial responsibility	Abstracted by platform
Operational Monitoring Effort	High	Medium	Low
Dependency on External Components	Low	Medium (SIBS widget)	High (platform/plugin)

Integration Models Spectrum

Figure: Integration models spectrum showing the trade-off between control and implementation complexity (Left: Plugin – Low control/complexity, Right: Server-to-Server – High control/complexity)

All integration models rely on the same underlying SPG APIs, but differ in how responsibilities and interactions are distributed.

Key Differences

Level of Control

• Server-to-Server
  Full control over payment flow, UI, and transaction lifecycle.
• Form Integration
  Control over backend orchestration, but payment UI is managed by SIBS.
• Plugin Integration
  Control is delegated to the plugin and platform.

Integration Complexity

• Server-to-Server
  Requires full API integration and backend orchestration.
• Form Integration
  Requires backend integration plus frontend widget integration.
• Plugin Integration
  Requires installation and configuration only.

Security and Compliance

• Server-to-Server
  Merchant is responsible for handling sensitive data and PCI DSS compliance.
• Form Integration
  Sensitive data handled by SIBS; PCI scope significantly reduced.
• Plugin Integration
  Security is largely abstracted by plugin and platform, but not eliminated.

Impact on End-User Experience

Server-to-Server Integration:

• Fully customizable user experience
• Seamless integration within the merchant application
• Maximum flexibility in UI/UX design
• Requires additional effort to ensure consistency and usability

Form Integration:

• Standardized payment experience provided by SIBS
• Reduced implementation complexity
• Limited UI customization
• Ensures compliance and consistency across payment methods

Plugin Integration:

• User experience is defined by the platform/plugin
• Minimal customization options
• Fast deployment but limited control over UX
• Suitable for standard e-commerce scenarios

Technical Responsibilities

Each integration model implies a different distribution of responsibilities between
the merchant and SIBS.

Server-to-Server Integration:

The merchant is fully responsible for the entire payment lifecycle, including:

• Checkout creation
• Payment execution and API orchestration
• Asynchronous flow handling and status validation
• Error handling, retries, and idempotency
• Secure handling of sensitive data (PCI DSS scope)

Form Integration:

Responsibilities are shared between the merchant and SIBS:

• The merchant handles backend orchestration and transaction lifecycle
• SIBS manages the payment form and sensitive data collection
• The merchant remains responsible for validating transaction status and business logic

Plugin Integration:

Most responsibilities are delegated to the plugin/platform:

• The plugin handles communication with SIBS and payment execution
• The merchant is primarily responsible for configuration and monitoring
• Customization and control are limited

Practical Recommendations for Choosing an Integration Model

The choice of integration model should be based on the merchant’s technical
capabilities, business requirements, compliance constraints, and desired level
of control over the payment experience.

Choose Server-to-Server Integration when:

• Full control over checkout and payment flow is required
• Advanced payment scenarios are needed:
  • Recurring payments (MIT)
  • Tokenization
  • Two-step payments (AUTH → CAPTURE)
• The merchant has backend development capability
• PCI DSS requirements can be managed

(see B.1 Server-to-Server Integration)

Choose Form Integration when:

• PCI DSS scope must be minimized
• A secure, SIBS-hosted payment UI is acceptable
• Moderate customization is sufficient
• Backend integration is available for orchestration

(see B.2 Form Integration)

Choose Plugin Integration when:

• The merchant uses a supported e-commerce platform
• Rapid deployment is required
• Development resources are limited
• Standard payment flows are sufficient
• Customization requirements are minimal

(see B.3 Plugin Integration)

Decision Criteria

When selecting an integration model, consider the following dimensions:

1. Technical Capability

• Do you have backend development expertise?
• Can you manage API integrations and transaction lifecycle logic?

If not → Plugin or Form

2. Desired Level of Control

• Do you need full control over UI and payment flow?

If yes → Server-to-Server

3. Time-to-Market

• How quickly must the solution be deployed?

Fast → Plugin
Balanced → Form
Flexible timeline → Server-to-Server

4. Compliance Requirements

• Do you want to minimize PCI DSS scope?

Yes → Form or Plugin
No / manageable → Server-to-Server

5. Complexity of Payment Flows

• Do you need:
  • Recurring payments
  • Advanced orchestration
  • Custom business logic

Yes → Server-to-Server

6. Platform Constraints

• Are you using an e-commerce platform?

Yes → Plugin Integration is the natural choice

Sequence Diagrams per Integration Model

The following sequence diagrams illustrate the interaction flows between the customer, merchant systems, and SIBS Payment Gateway (SPG) for each integration model.

They highlight the distribution of responsibilities and the main integration steps, including checkout creation, payment execution, and status validation.

Server-to-Server Integration Flow

Figure: Server-to-Server Integration flow illustrating the interaction between merchant backend and SIBS SPG API.

Form Integration Flow

Figure: Form Integration flow illustrating the hybrid interaction between merchant backend and SIBS-hosted payment form.

Plugin Integration Flow

Figure: Plugin Integration flow showing the abstraction of payment handling through the platform and plugin.

Typical Architecture Patterns

Simple E-commerce Setup

• Platform: WooCommerce / Shopify
• Integration: Plugin

Fast deployment, minimal customization

Standard Merchant Website

• Custom frontend
• Backend available

Integration: Form Integration

Advanced Payment Platform / Enterprise

• Custom checkout
• Complex payment orchestration
• Multiple payment scenarios

Integration: Server-to-Server

Important Considerations

• All integration models rely on the same underlying SPG APIs and infrastructure
• Plugin and Form integrations do not eliminate backend responsibilities, only abstract or reduce them
• The choice of model impacts long-term scalability and flexibility
• Migration between models is possible but may require re-architecture

Summary

Each integration model serves a distinct purpose:

• Server-to-Server → Maximum control and flexibility
• Form Integration → Balanced approach (security + simplicity)
• Plugin Integration → Fastest and simplest implementation

Selecting the correct model depends on:

• Technical capability
• Business requirements
• Compliance constraints
• Desired level of customization

A well-informed decision at this stage ensures a scalable, secure, and maintainable payment integration.