Prerequisites (once per merchant/environment) You need the following credentials and configuration elements before calling the SIBS SPG APIs: Choose the appropriate API environment URL (<ROOT_URL>) for the target environment. Please refer to A.3 – API Requests for the complete list of environment-specific URLs. API Request Flow The following diagram summarizes the complete MB WAY Two-Step Server-to-Server flow, including authorization initiation, customer approval, authorization validation, capture execution, and final settlement validation. In a Two-step MB WAY (AUTH → CAPTURE) Server-to-Server Integration, the process is divided into: MB WAY is an asynchronous payment method. Authorization depends on the customer approving the transaction in the MB WAY mobile application. 1) Create the Checkout Session (server-to-server) Goal: Create a checkout session configured for Authorization only (paymentType = AUTH) and obtain the identifiers required for the subsequent server-to-server operations (authorization, status validation and capture). What you do 1.1 POST Checkout Payment to: Important Headers What you do in this step This call registers the payment and prepares the transaction for the subsequent server-to-server operations. 1.2. Store from the successful response: From the Checkout response, you must store: Also, the following values will have an important role after the authorization, namely: The SPG transactionID should be […]

Prerequisites (once per merchant/environment) You need the following credentials and configuration elements before calling the SIBS SPG APIs: Choose the appropriate environment URLs. The API base URL (<ROOT_URL>) and hosted widget URL (<WIDGET_URL>) must correspond to the same environment. Please refer to A.3 – API Requests for the complete list of environment-specific URLs. API Request Flow The following diagram summarizes the complete MB WAY Two-Step Form Integration flow, including checkout creation, hosted form rendering, customer authorization, authorization validation, capture execution, and final settlement validation. In a Two-step MB WAY (AUTH → CAPTURE) Form Integration, the process is divided into: 1) Create the Checkout Session (server-to-server) Goal: Create a checkout session configured for Authorization only (paymentType = AUTH) and obtain the parameters required to render the SPG form. What you do 1.1 POST Checkout Payment to: Important Headers What you do in this step This call registers the payment and prepares the transaction for the hosted form. 1.2. Store from the successful response: From the Checkout response, you must store: These values are required to: Also, the following values will have an important role after the authorization in the form, namely: The SPG transactionID should be treated as the authoritative identifier […]

MB WAY two-step payments allow a merchant to first obtain customer authorization and reserve the transaction amount, and later perform a separate capture operation to settle the funds. In a two-step scenario, the payment is not immediately captured upon customer confirmation. Instead, the transaction enters an authorized state, and the merchant decides when to finalize (capture) the payment within the allowed authorization validity period. This model is commonly used in scenarios where fulfillment, stock confirmation, or service validation occurs after checkout. How It Works In a typical MB WAY two-step payment flow: The customer interaction occurs only during the authorization phase. The capture phase is merchant-initiated. Workflow Characteristics The MB WAY two-step flow has the following characteristics: If the authorization is not captured within the defined validity window, the reserved funds are released automatically. The SPG transactionID should be treated as the authoritative identifier for transaction monitoring, webhook correlation, authorization tracking, capture operations, reconciliation, refund operations, and Status Inquiry requests throughout the transaction lifecycle. Transaction Lifecycle The following diagram illustrates the operational lifecycle of an MB WAY two-step payment within the SIBS Payment Gateway, including authorization, customer confirmation, capture execution, expiration handling, status validation, and merchant reconciliation. The lifecycle of […]

Overview Two-step payments represent a transaction model where payment authorization and payment capture occur as separate operations. In this model, the customer first authorizes the transaction, while final settlement occurs only after capture. The merchant later performs a second operation to capture (settle) the authorized amount. This approach is commonly used in scenarios where the final charge amount or fulfillment conditions are not fully confirmed at checkout time. What Is a Two-Step Payment A two-step payment is a transaction model where: From a technical perspective, a two-step payment involves: Until capture occurs, the transaction remains in an authorized state. Each authorization and capture operation executed through SPG generates its own transaction lifecycle events associated with the original authorization context. The SPG transactionID should be treated as the authoritative identifier for authorization monitoring, capture tracking, webhook correlation, reconciliation, refund operations, and Status Inquiry requests. When to Use Two-Step Payments Two-step payments are appropriate when there is uncertainty between checkout and fulfillment. Typical scenarios include: They are not required when immediate settlement is appropriate. Supported Payment Methods Within the SIBS ecosystem, two-step payments are supported through: Although the conceptual model is the same, execution characteristics may differ depending on the payment method. […]

Prerequisites (once per merchant/environment) You need the following credentials and configuration elements before calling the SIBS SPG APIs: Choose the appropriate API environment URL (<ROOT_URL>) for the target environment. Please refer to A.3 – API Requests for the complete list of environment-specific URLs. Prerequisites (Recurring Model Requirements) The merchant must have a successful Cardholder Initiated Transaction (CIT), including: Important: MIT transactions are only valid if derived from a compliant CIT (with SCA when required). Recurring Payment Model Recurring payments are performed using Merchant Initiated Transactions (MIT), executed server-to-server by the merchant. The recurring payment flow follows: Each step must be executed and validated independently. A MIT transaction is initiated by the merchant using a previously authorized card from a Cardholder Initiated Transaction (CIT). A MIT is not a customer-present authorization and does not perform Strong Customer Authentication (SCA). Requirements: Important: API Request Flow In a Recurring Credit Card Collection flow, the process is divided into: The recurring collection is considered completed after the capture is successful and the final result is received through webhook notification or, where needed, confirmed through the Status API. This page only covers the recurring collection phase. The initial recurring customer authorization flow is documented in: […]

Purpose This flow enables the merchant to perform the initial Cardholder Initiated Transaction (CIT) for a recurring payment agreement using the Merchant environment to securely collect the Customer’s credit card data. In this process: After this initial step: Prerequisites (once per merchant/environment) You need the following credentials and configuration elements before calling the SIBS SPG APIs: Choose the appropriate API environment URL (<ROOT_URL>) for the target environment. Please refer to A.3 – API Requests for the complete list of environment-specific URLs. In Server-to-Server integrations, the merchant must ensure: Failure to enforce these controls may result in compliance violations and security risks. Overview Recurring card payments are based on an initial Cardholder Initiated Transaction (CIT) followed by one or more Merchant Initiated Transactions (MIT). The CIT (Cardholder Initiated Transaction) can be performed with a zero or non-zero amount, depending on whether the first payment is collected during authorization or deferred to a later MIT. The CIT establishes the customer consent and recurring agreement. After a successful CIT, future recurring collections can be executed without customer interaction. It is used to: This step is mandatory before any Merchant Initiated Transaction (MIT) can be executed. A MIT is not a customer-present authorization and […]

Purpose This flow enables the merchant to perform the initial Cardholder Initiated Transaction (CIT) for a recurring payment agreement using the SIBS SPG hosted payment form. In this process: After this initial step: Prerequisites (once per merchant/environment) You need the following credentials and configuration elements before calling the SIBS SPG APIs: Choose the appropriate environment URLs. The API base URL (<ROOT_URL>) and hosted widget URL (<WIDGET_URL>) must correspond to the same environment. Please refer to A.3 – API Requests for the complete list of environment-specific URLs. Overview Recurring card payments are based on an initial Cardholder Initiated Transaction (CIT) followed by one or more Merchant Initiated Transactions (MIT). The CIT (Customer Initiated Transaction) can be performed with a zero or non-zero amount, depending on whether the first payment is collected during authorization or deferred to a later MIT. The CIT establishes the customer consent and recurring agreement. After a successful CIT, future recurring collections can be executed without customer interaction. It is used to: This step is mandatory before any Merchant Initiated Transaction (MIT) can be executed. Stored Credential Model This flow establishes the stored credential required for recurring payments. These identifiers are required to perform future recurring charges. Transaction […]

Credit Card recurring payments allow merchants to charge a customer’s card multiple times after an initial authorization and credential registration. In a recurring payment scenario, the first transaction establishes customer consent and securely registers the card credentials (tokenization). Subsequent transactions are initiated by the merchant without requiring the customer to re-enter card details for each charge. This model is commonly used for subscriptions, memberships, installment plans, and other ongoing billing relationships. How It Works In a typical Credit Card recurring payment flow: The initial customer interaction is mandatory. Subsequent recurring transactions are merchant-initiated. Workflow Characteristics The Credit Card recurring flow has the following characteristics: Recurring charges may require additional authentication depending on regulatory or issuer requirements. Transaction Lifecycle The lifecycle of a Credit Card recurring payment typically includes: If a recurring charge is declined, retry logic or customer re-authentication may be required. Use Cases Credit Card recurring payments are commonly used in: This payment model is particularly suited for environments where: Particularities in the SIBS Context When working with Credit Card recurring payments in SIBS SPG, merchants should consider: Integration Context Within the SIBS Payment Gateway, Credit Card recurring payments are implemented using: Each recurring charge is processed independently and […]

Prerequisites (once per merchant/environment) You need the following credentials and configuration elements before calling the SIBS SPG APIs: Additionally, you must have a previously active Authorized Payment (mandate): The mandateId used in this operation must be obtained from the Authorized Payment creation flow and validated as ACTV via the inquiry operation. Choose the appropriate API environment URL (<ROOT_URL>) for the target environment. Please refer to A.3 – API Requests for the complete list of environment-specific URLs. Overview MB WAY Authorized Payments Collection allows the merchant to charge a customer using an existing Authorized Payment (mandate). The process consists of: This process is server-to-server and does not require customer interaction, provided that: Although the collection is initiated using the MB WAY channel, transactions executed using an Authorized Payment are identified with paymentMethod = "MANDATE" in API responses. API Request Flow The Authorized Payment Collection flow consists of: 1) Create payment (checkout) using mandate (Server-to-Server) Goal: Create a payment transaction referencing an existing Authorized Payment. 1.1 POST Payment creation to: Headers Processing Behavior The SPG transactionID should be treated as the primary and authoritative identifier for collection monitoring, webhook correlation, reconciliation, transaction monitoring, and operational lifecycle tracking. 2) Execute purchase using mandate […]

Prerequisites (once per merchant/environment) You need the following credentials and configuration elements before calling the SIBS SPG APIs: Choose the appropriate API environment URL (<ROOT_URL>) for the target environment. Please refer to A.3 – API Requests for the complete list of environment-specific URLs. Overview MB WAY Authorized Payments allow the creation of a mandate (Authorized Payment) that enables subsequent transactions initiated by the merchant. The process includes: During authorization, the customer: The process is asynchronous. API Request Flow The Authorized Payment flow consists of: 1) Create the Authorized Payment (Mandate) 1.1 POST Mandate creation to: Processing Behavior The mbwayPhoneNumber field should be collected in the Merchant environment. The format of the phone number is <country code>#<phone number>. Example: 2) Customer Authorization Goal: Allow the customer to approve the Authorized Payment. Characteristics 3) Check Mandate Authorization Status until it is finalized (Back-End) Goal: Confirm the final authorization status after the authorization process is completed. 3.1 When to check status You must verify the transaction status, right after receiving the authorization creation response, up until 10 minutes after (the user has 10 minutes maximum to accept or reject the operation. After that time, the transaction will timeout) 3.2 Status endpoints you can […]