Instant Payment (Auto-Capture Flow)

An Instant Payment is the simplest and most straightforward payment pattern in Hyperswitch. In this flow, authorization and capture happen together in a single continuous transaction, with no intermediate merchant action required. It is typically used for digital goods, SaaS checkouts, and low-risk e-commerce scenarios where fulfillment happens immediately after payment. The defining behavior of this flow is controlled by two important request parameters in the POST /payments call: confirm: true and capture_method: "automatic". Setting confirm: true instructs Hyperswitch to immediately attempt confirmation of the payment after creation, instead of waiting for a separate confirm call. Setting capture_method: "automatic" ensures that once the processor authorizes the payment, the funds are captured instantly without transitioning into a manual capture state.

An Instant Payment can be implemented using either a single-call approach or a dual-call approach, depending on the merchant’s checkout architecture and operational requirements.

In the single-call approach, the merchant sends one POST /payments request with confirm: true and capture_method: "automatic" (along with the payment method details). Because confirmation is requested immediately, Hyperswitch creates the payment intent and proceeds through the lifecycle in one continuous run. Conceptually, the payment moves through the familiar sequence: RequiresPaymentMethod → RequiresConfirmation → Processing → Successful (or another terminal state depending on the connector response). Even though these states exist logically, they may occur so quickly that to the merchant it feels like a single “create-and-pay” operation.

In the two-step approach, the merchant first creates the intent using POST /payments with confirm: false and capture_method: "automatic". This keeps the payment in a waiting posture after intent creation typically landing in RequiresPaymentMethod until the payment method is attached and/or the merchant is ready to proceed. When the merchant explicitly triggers confirmation using POST /payments/:id/confirm, Hyperswitch then drives the payment forward through the remaining lifecycle: RequiresConfirmation → Processing → Successful (again, based on what the connector returns).

The key observation is that the state transitions are fundamentally the same in both patterns. What changes is the timing and ownership of the transition triggers: in the first pattern, everything is chained automatically as part of the initial create call, while in the second pattern, the merchant’s explicit confirm request is what moves the payment forward into processing and completion.

Refer to the API reference documentation for more information - https://api-reference.hyperswitch.io/