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:

1. The merchant initiates an authorization request through the SIBS Payment Gateway.
2. The customer provides their mobile phone number associated with MB WAY.
3. An authorization request is sent to the customer’s MB WAY app.
4. The customer confirms the transaction in the app.
5. Upon confirmation, the payment is authorized and the amount is reserved.
6. The merchant receives the authorization result.
7. At a later moment, the merchant initiates a capture request referencing the original authorization.
8. The transaction is finalized and settled.

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:

• Customer-initiated authorization
• Real-time confirmation within the MB WAY app
• Funds reservation (not immediate settlement)
• Separate capture operation
• Authorization validity period
• Automatic expiration if capture is not performed in time
• Authorization and capture lifecycle monitoring through Merchant Notifications and Status Inquiry

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 an MB WAY two-step payment typically includes:

• Payment creation (authorization request)
• Pending customer confirmation
• Authorized (funds reserved)
• Captured (successful settlement)
• Expired (if not captured in time)
• Failed (if authorization is declined)

Only after capture is executed is the transaction considered fully settled.

Use Cases

MB WAY two-step payments are commonly used in:

• Hospitality bookings
• Service reservations
• E-commerce with delayed shipment
• Orders requiring manual approval
• Scenarios where final amount confirmation is required

This payment model is particularly suited for environments where:

• The final charge should only occur after validation
• Stock or service availability must be confirmed
• Immediate settlement is not appropriate
• A mobile-first payment experience is desired

For transaction lifecycle monitoring and final transaction state validation, refer to E.2 – Status Inquiry / Get Status.

For webhook delivery and asynchronous transaction notifications, refer to E.1 – Webhooks (Notifications).

Practical implementation examples, Postman collections, MB WAY authorization and capture scenarios, and integration examples are documented in F. Technical Examples and Best Practices.

Particularities in the SIBS Context

When working with MB WAY two-step payments in SIBS SPG, several platform-specific aspects should be considered:

• Customer interaction through the MB WAY mobile application is mandatory during the authorization phase.
• Authorization and capture are separate operations and must be managed independently.
• Authorized transactions remain valid only during the configured authorization validity period.
• If capture is not executed within the allowed timeframe, the authorization expires and the reserved funds are released automatically.
• Webhook notifications and Status Inquiry validation should be implemented for reliable authorization and capture lifecycle monitoring.
• Mobile phone number validation and formatting should be handled consistently.
• Proper authorization tracking, capture execution, and transaction lifecycle monitoring are critical to guarantee operational consistency and accurate reconciliation.

Capture request examples and authorization-to-capture transaction flows are documented in F. Technical Examples and Best Practices.

Integration Context

Within the SIBS Payment Gateway, MB WAY two-step payments require:

• An initial authorization request
• Storage of the authorization transaction identifiers required for capture
• A separate server-to-server capture request

The capture operation must reference the original authorized transaction.

Merchants must implement logic to:

• Monitor authorization validity
• Execute capture within the allowed timeframe
• Handle expired or uncaptured authorizations
• Avoid duplicate capture attempts

The following sections describe the technical integration flow, required parameters, authorization handling, and capture execution for MB WAY two-step payments.