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:

• The customer authorizes a payment
• The payment is authorized but not immediately settled
• The merchant later confirms (captures) the charge
• Authorization may expire if not captured within the allowed timeframe

From a technical perspective, a two-step payment involves:

1. An Authorization request
2. A Capture request associated with the original authorization transaction

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:

• Hospitality (hotels, short stays)
• Car rentals
• Travel bookings
• E-commerce with delayed shipment
• Inventory confirmation workflows
• Services with variable final amounts

They are not required when immediate settlement is appropriate.

Supported Payment Methods

Within the SIBS ecosystem, two-step payments are supported through:

• Credit Cards
• MB WAY

Although the conceptual model is the same, execution characteristics may differ depending on the payment method.

Execution Models

Credit Card Two-Step (Authorization + Capture)

The customer authorizes the payment during checkout.

Characteristics:

• Authorization confirms the payment intent while settlement remains pending until capture
• Capture is performed later by the merchant
• Partial captures may be supported (depending on configuration)
• Operational reconciliation should correctly account for partially captured authorizations and remaining authorized balances
• Authorization has a validity period
• Uncaptured authorizations expire automatically

This is the most common two-step implementation.

MB WAY Two-Step

MB WAY supports an authorization-first model where:

• The customer authorizes the payment in the MB WAY app
• The merchant later captures the authorized amount
• Authorization validity period applies

Characteristics:

• Mobile-based authorization flow
• Customer interaction required only during authorization
• Capture operations executed through server-to-server interactions
• Authorization expiration handling required

Transaction Lifecycle

The following diagram illustrates the generic operational lifecycle commonly followed by Two-Step payment transactions in SPG.

Two-step payments follow a multi-phase lifecycle:

1. Authorization request initiation
2. Customer authorization or approval
3. Authorization processing and successful authorization state
4. Merchant-initiated capture request
5. Capture processing and settlement
6. Final transaction confirmation through synchronous response, webhook notification, and/or Status Inquiry validation
7. Authorization expiration handling if capture is not executed within the allowed timeframe

If capture is not performed within the allowed authorization window, the authorization is automatically released.

For transaction lifecycle monitoring and capture 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, capture flow scenarios, and authorization lifecycle examples are documented in F. Technical Examples and Best Practices.

Advantages of the Two-Step Model

From a merchant perspective, two-step payments provide:

• Flexibility in fulfillment timing
• Protection against stock or service uncertainty
• Ability to adjust final charge before settlement
• Reduced refund scenarios compared to immediate capture

This model is particularly valuable in industries with delayed delivery or service confirmation.

Particularities in the SIBS Context

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

• Authorization and capture are separate API operations
• Authorization transaction references and operational identifiers must be stored securely for subsequent capture and reconciliation operations
• Capture must reference the original transaction
• Authorization validity periods apply
• Partial capture rules depend on configuration
• If capture fails or expires, a new authorization may be required
• Operational monitoring of authorization expiration windows is required to avoid failed settlements and revenue loss

Proper lifecycle management is critical to avoid lost revenue due to expired authorizations.

Two-Step vs Other Payment Models

To position two-step payments within the broader ecosystem:

Model	Description
One-Off	Authorization and capture occur in a single step
Recurring	Merchant-initiated repeated charges
Two-Step	Authorization first, capture later
Pre-Authorization	Operational authorization variant where settlement occurs only after explicit capture

This section focuses exclusively on the two-step authorization + capture model.

For standalone payment flows where authorization and settlement occur together, refer to D.1 – One-Off Payments.

For recurring payment flows and Merchant Initiated Transactions (MIT), refer to D.2 – Recurring Payments.

Integration Context

In the SIBS Payment Gateway, two-step payments require:

• An initial authorization request
• Storage of authorization transaction references
• A subsequent capture request
• Server-to-server logic for capture execution

Two-step payments are typically implemented via:

• API integration
• Server-to-server flows
• Supported plugin-based integration models (where available)

Although the initial authorization step may be performed through Form Integration or hosted checkout flows, capture operations are always executed through server-to-server interactions initiated by the merchant backend.

Detailed implementation examples are available in the dedicated Credit Card and MB WAY two-step integration pages.

Summary

Two-step payments separate customer authorization from final settlement, providing merchants with operational flexibility and control over fulfillment timing.

They are particularly suitable for industries where immediate capture is not appropriate.

Understanding the two-phase lifecycle and authorization validity rules is essential before implementing the technical integration.