The SIBS Payment Gateway supports multiple payment methods and operational payment models that allow merchants to implement different online payment experiences, transaction lifecycles, and settlement flows.
Payment methods define how a payment is initiated, confirmed, and completed, while SPG ensures a consistent way to create transactions, track their lifecycle, and receive status updates across all supported methods.
The following diagram illustrates the generic operational lifecycle shared across SPG payment methods and transaction models, including asynchronous transaction updates through webhook notifications and Status Inquiry APIs.
Payment Models
Payment methods can be used under different payment models, depending on the business scenario.
These models define how and when funds are authorized, captured, settled, or operationally managed throughout the transaction lifecycle, independently of the payment method itself.
- One-off payments, where a single transaction is created and completed
- Recurring payments, where payments are executed over time based on prior authorization
- Two-step payments, where authorization and capture occur in separate steps
- Omnichannel operations, where merchants manage transactions originally initiated outside standard SIBS Payment Gateway checkout channels (such as xPOS, SmartPOS, or softPOS environments)
A single payment method may support one or more of these models depending on the operational scenario.
How to Navigate This Chapter
Integrators should first identify the payment model that matches their business operation, and then select the corresponding payment method and integration model.
For example:
- A standard e-commerce card payment should follow the One-Off Payments model
- A subscription or Merchant Initiated Transaction (MIT) collection should follow the Recurring Payments model
- A reservation, pre-authorization, or delayed settlement scenario should follow the Two-Step Payments model
- Operational actions over transactions initiated outside the standard SPG checkout flow should follow the Omnichannel Operations model
Each payment method section documents the complete operational lifecycle of the transaction, including checkout creation, authentication requirements where applicable, customer interaction, asynchronous processing behavior, status monitoring, webhook notifications, and post-payment operational actions.
Server-to-Server requests require application credentials to obtain Bearer Tokens used to authenticate API requests. For instructions on creating and managing these credentials, refer to G.1.7.3 – Credentials.
Several payment methods supported by SPG operate asynchronously and may transition through intermediate transaction states before reaching a final outcome.
Integrators should therefore implement proper transaction lifecycle monitoring using webhook notifications and, where needed, Status Inquiry APIs in order to support operational consistency and reliable transaction reconciliation.
The SPG transactionID should be treated as the authoritative transaction identifier for asynchronous lifecycle management, operational monitoring, webhook correlation, Status Inquiry operations, capture flows, refund operations, and reconciliation processes throughout the transaction lifecycle.
Available Payment Methods
The following payment methods are supported through the SIBS Payment Gateway across different operational payment models and transaction flows:
MB WAY
Mobile-based payments that require customer confirmation through the MB WAY application, supporting both immediate and authorized payment scenarios.
Cards
Card-based payments processed through SPG, supporting one-off, recurring, tokenized, and two-step authorization and capture payment flows depending on the operational scenario.
Multibanco Reference
Reference-based payments that allow customers to complete a payment outside the checkout flow, with confirmation occurring asynchronously.
| Payment Method | One-Off | Recurring | Two-Step | Form | Server-to-Server | Plugin |
|---|---|---|---|---|---|---|
| MB WAY | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Cards | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Multibanco Reference | ✔ | — | — | ✔ | ✔ | ✔ |
Each payment method has its own characteristics in terms of customer interaction, confirmation timing, and lifecycle behavior.
Depending on the payment method and operational scenario, SPG may support multiple integration approaches, including Form Integration, Server-to-Server Integration, and Plugin-based integrations.
Each supported integration model is documented independently in order to provide implementation-specific request flows, operational behavior, and integration requirements.
For a detailed overview of the available integration architectures and implementation approaches, refer to B. Integration Models.
Integration Sandbox Simulator
SIBS provides a browser-based payment simulator that allows integrators to validate supported payment methods, operational flows, transaction payloads, and checkout behavior in a controlled sandbox environment.
The simulator can be used to:
- Validate checkout and payment interaction flows
- Test supported payment methods and operational models
- Inspect generated request payloads and operational responses
- Observe transaction lifecycle behavior and status transitions
- Validate customer interaction flows and payment confirmation behavior
- Support troubleshooting, sandbox validation, and integration onboarding activities
The simulator complements the official Postman collections and technical integration examples available throughout this documentation.
Sandbox Payment Simulator: Access the sandbox simulator here.
Depending on the configured environment and available payment methods, simulator capabilities may vary.
Method-Specific Documentation
Each payment method and operational model is documented in dedicated sections covering supported payment flows, execution behavior, transaction lifecycle management, and method-specific operational considerations.
This includes standard checkout payment methods as well as Omnichannel operational flows for transactions initiated outside traditional SPG checkout channels.
Transaction lifecycle monitoring, asynchronous status updates, webhook processing, Status Inquiry usage, and operational reconciliation are documented in E. Notifications and Transaction Status.
All integrations involving asynchronous transaction behavior should implement webhook handling, with Status Inquiry used where needed for monitoring, recovery, and reconciliation.
Status Inquiry APIs should be treated as an operational mechanism for retrieving the current transaction state and supporting reconciliation when needed.
Practical request and response examples, Postman collections, cURL examples, sandbox testing scenarios, production readiness guidance, and common integration pitfalls are documented in F. Technical Examples and Best Practices.