Overview

Plugin Integration is a payment integration model based on pre-built plugins provided for supported e-commerce platforms and content management systems.

In this model, the integration logic between the merchant platform and the SIBS Payment Gateway (SPG) is encapsulated within a plugin, allowing merchants to enable payments with minimal development effort.

The merchant system interacts with SPG indirectly through the plugin abstraction layer, while the customer interacts with the payment interface exposed by the platform and/or SIBS components, depending on the plugin implementation.

The merchant is responsible for:

• Configuring the plugin according to business and operational requirements
• Managing platform-level settings and payment options
• Monitoring transaction outcomes and reconciliation

The plugin is responsible for:

• Managing communication with SPG
• Payment execution and transaction flow orchestration
• Abstracting integration complexity from the merchant

This approach significantly reduces implementation effort and accelerates time-to-market. However, this abstraction also limits direct control over payment behavior and integration logic.

Depending on the plugin implementation, Plugin Integration typically relies internally on Form Integration or Server-to-Server interactions, without exposing this complexity to the merchant.

Key Characteristics

• Very low integration complexity
• Minimal or no custom development required
• Fast time-to-market
• Integration managed through platform plugins
• Limited control over payment flow and behavior
• Standardized integration patterns defined by the platform
• Dependency on plugin capabilities and updates

When to Use

Plugin Integration is recommended when:

• The merchant operates on a supported e-commerce platform
• Rapid deployment is a priority
• Internal development resources are limited
• Standard payment flows are sufficient
• Customization requirements are minimal

This model is commonly used for:

• WooCommerce-based websites
• Magento stores
• PrestaShop installations
• Shopify environments

SIBS currently provides plugins for the following platforms:

• WooCommerce
• Magento
• Shopify
• PrestaShop

Each plugin integrates natively with the platform’s checkout and order lifecycle.

Prerequisites

Before implementing Plugin Integration, ensure the following are available:

• Access to a supported e-commerce platform
• Availability of the official SIBS plugin for that platform
• Merchant credentials provided by SIBS:
  • AuthToken: Used for API authentication (Authorization: Bearer <AuthToken>)
  • X-IBM-Client-Id: Application identifier provided by SIBS
  • TerminalId: Assigned by SIBS during onboarding
• Configured environment (Test / Production)
• Basic understanding of the platform’s plugin installation and configuration process

Refer to the platform-specific plugin documentation for detailed setup instructions.

High-Level Flow

A typical Plugin Integration follows these steps:

1. Install and Configure Plugin
   The merchant installs the SIBS plugin and configures it with the required credentials and payment settings.
2. Customer Initiates Payment
   The customer selects a payment method during checkout on the merchant platform.
3. Payment Processing
   The plugin handles the interaction with SPG and executes the payment flow on behalf of the merchant.
   Depending on the implementation, this may involve:
   • Hosted payment forms (Form Integration)
   • Direct API interactions (Server-to-Server)
4. Process Payment Result
   SPG processes the transaction and returns the result via the plugin.
5. Handle Result
   The platform updates the order status based on the transaction outcome.
   Additional confirmation may be performed via backend validation or platform-level mechanisms.
6. Post-Payment Operations (optional)
   Depending on plugin capabilities, operations such as:
   • Capture
   • Refund
   may be available through the platform interface or backend processes.

Synchronous vs Asynchronous Payments

Plugin Integration supports both execution models:

Synchronous Payments

Immediate final status is returned after payment processing.

Example:

• Credit Card (depending on flow)

Asynchronous Payments

Require external user action or delayed processing.
Final status is not immediately available.

Examples:

• MB WAY (user approval in mobile application)
• Multibanco Reference (payment via ATM or home banking)

For asynchronous methods:

• Platform and plugin handle status updates
• Webhooks and backend mechanisms may be used internally
• Status polling may be implemented depending on the plugin

Payment Methods Support

Plugin Integration supports SPG payment methods depending on:

• Plugin capabilities
• Platform limitations
• Merchant configuration

Typical supported payment methods include:

• Credit Card
• MB WAY
• Multibanco Reference

Available methods are configured through the plugin settings and depend on merchant enablement.

Security and Compliance

PCI DSS Responsibility

In Plugin Integration, sensitive payment data is typically handled by SIBS-hosted components or secure mechanisms embedded within the plugin.

This significantly reduces the merchant’s PCI DSS scope.

However:

• The exact scope depends on the plugin implementation and configuration
• Merchants remain responsible for ensuring their platform and environment are secure
• Compliance obligations are reduced but not eliminated

Security Responsibilities (Plugin-Managed)

Most security-related mechanisms are handled internally by the plugin, including:

• Secure communication with SPG
• Authentication and request handling
• Validation of transaction responses

These responsibilities are abstracted from the merchant and implemented according to SIBS integration standards.

HMAC Validation (When Applicable)

HMAC-based message validation may be supported and handled internally by the plugin.

When available:

• It ensures message integrity and authenticity
• It is configured through the plugin or platform settings

No direct implementation is typically required by the merchant.

Transport Security

All communication between the platform, plugin, and SPG must use HTTPS.

Transport security is generally enforced by:

• The plugin implementation
• The underlying platform infrastructure

Merchants must ensure their hosting environment maintains proper TLS configuration and certificate validity.

Error Handling and Idempotency

Error handling and retry mechanisms are typically managed by:

• The plugin
• The e-commerce platform

However, merchants should:

• Monitor transaction outcomes through the platform
• Ensure proper order state reconciliation
• Validate that retry or duplicate processing does not impact business logic

Advantages and Trade-offs

Advantages

• Very fast implementation
• Minimal development effort
• Simplified integration process
• Reduced PCI DSS scope
• Tight integration with platform ecosystem

Trade-offs

• Limited control over payment flows
• Dependency on plugin capabilities and updates
• Reduced flexibility for advanced use cases
• Potential limitations in customization and extensibility
• Reliance on platform-specific behavior

Related Topics

• B. Integration Models (overview)
• B.1 Server-to-Server Integration
• B.2 Form Integration
• Payment Methods (CARD, MB WAY, REFERENCE, MANDATE)
• API Requests and Authentication

Conclusion

Plugin Integration provides the fastest and simplest way to integrate with the SIBS Payment Gateway, leveraging pre-built components tailored for popular e-commerce platforms.

It is best suited for merchants who prioritize rapid deployment and minimal development effort, while accepting reduced flexibility and control.

Although abstracted from the merchant, plugin-based integrations still rely on the same SPG infrastructure and may internally use Form Integration or Server-to-Server interactions to execute payment operations.

Understanding these underlying mechanisms is important to ensure correct expectations regarding capabilities, limitations, and extensibility.