Fully Decoupled Payment Flow

A Fully Decoupled Payment Flow separates payment creation, update, confirmation, and capture into clearly independent API steps. Instead of treating checkout as a single atomic event, the merchant orchestrates the lifecycle progressively creating the intent first, enriching or modifying it over time, and confirming only when ready. This pattern is especially useful in complex checkout architectures, multi-step onboarding journeys, marketplaces, configurable pricing flows, or any scenario where payment details evolve before final authorization.

The flow begins with a simple intent creation call: POST /payments (Create Intent)

At this stage, the merchant typically sends minimal required fields (such as amount and currency) and receives back a payment_id and client_secret. The payment transitions from:

Start → RequiresPaymentMethod

Importantly, no authorization attempt is made yet. The intent simply represents the merchant’s expectation of a future payment.

Next, the merchant may update the intent:

POST /payments/{id} (Update customer, amount, metadata, etc.)

This step allows flexibility. The merchant can:

  • Modify the amount

  • Attach customer details

  • Add metadata

  • Adjust configuration parameters

The payment remains in a pre-confirmation state. This is where the “decoupled” nature becomes clear payment configuration and checkout progression are no longer tightly coupled to a single API call.

When the merchant is ready to proceed, they explicitly trigger: POST /payments/{id}/confirm

Only at this point does Hyperswitch attempt authorization with the processor. The payment transitions:

RequiresConfirmation → Processing → (Succeeded / RequiresCapture)

If capture_method was set to "automatic", the payment will move directly to Succeeded after authorization and capture. If capture_method was "manual", the payment will land in RequiresCapture, waiting for a subsequent capture call.

For manual capture scenarios, the final step is: POST /payments/{id}/capture

Which transitions:

RequiresCapture → Succeeded

The key characteristic of a Fully Decoupled Flow is lifecycle control. Each transition is intentionally triggered by a merchant API call rather than chained automatically. The merchant decides when to:

  • Create the payment

  • Attach or update details

  • Confirm the authorization

  • Capture the funds

State transitions remain identical to the standard lifecycle model, but ownership of timing shifts entirely to the merchant.

This pattern is particularly powerful for:

  • Complex checkout UIs

  • Multi-party or marketplace systems

  • Deferred confirmation scenarios

  • External fraud or risk decision workflows

  • Systems requiring asynchronous approval before confirmation

By decoupling lifecycle stages into discrete calls, merchants gain maximum flexibility while still operating within the same consistent Hyperswitch payment state machine.

Last updated