Skip to content
Menu

PAYMENT GATEWAY

[THK] D.3 Two-step payment

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, reserving the funds. 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
  • Funds are reserved 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 referencing the original authorization

Until capture occurs, the transaction remains in an authorized state.

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 reserves funds on the card
  • Capture is performed later by the merchant
  • Partial captures may be supported (depending on configuration)
  • 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 initiated server-to-server
  • Authorization expiration handling required

Transaction Lifecycle

Two-step payments follow a multi-phase lifecycle:

  1. Authorization request
  2. Customer approval
  3. Authorization successful (funds reserved)
  4. Capture request (merchant initiated)
  5. Final settlement
  6. Possible expiration (if capture not executed in time)

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

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 identifiers must be stored securely
  • 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

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:

ModelDescription
One-OffAuthorization and capture occur in a single step
RecurringMerchant-initiated repeated charges
Two-StepAuthorization first, capture later
Pre-Authorization (variant)Temporary reservation without immediate settlement

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

Integration Context

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

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

Two-step payments are typically implemented via:

  • API integration
  • Server-to-server flows
  • Some plugin configurations (where supported)

They are not purely form-based, as capture requires backend interaction.

Detailed integration guidance is provided in the Integration Flows section.

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.

Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.

Strictly Necessary Cookies

Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.