Pre-Authorization vs. Manual Capture: They’re Related, But They’re Not the Same Thing

These two concepts are often used together in payment systems, which makes them easy to confuse.

The simplest way to think about them is:

Pre-authorization reserves the money. Manual capture takes the money.

Imagine a hotel stay.

You check in, and the hotel doesn’t yet know the final amount you’ll owe. There might be room service, minibar charges, parking, or other adjustments.

Instead of charging you immediately, the hotel performs a pre-authorization.

Cardholder
    │
    │ Pre-Auth €300
    ▼
Merchant / POS
    │
    ▼
Acquirer
    │
    ▼
Card Network
    │
    ▼
Issuer
    │
    └──► €300 reserved

The issuer approves the authorization and reserves the funds, but the merchant hasn’t completed the payment yet.

The transaction is essentially:

“Can I reserve up to €300 on this card?”

The answer comes back: Approved.

Then where does Manual Capture come in?

A few days later, you check out.

Your final bill is €250.

The merchant now wants to turn that authorization into an actual financial transaction. That’s where capture comes in.

PRE-AUTHORIZATION
€300
    │
    │ Funds reserved
    ▼
AUTHORIZED
€300
    │
    │ Manual Capture
    │ €250
    ▼
CAPTURED
€250
    │
    ▼
SETTLEMENT

The merchant explicitly requests the capture of €250.

Depending on the payment system, scheme rules, and implementation, the unused portion of the authorization can then be released or adjusted.

So what’s the actual difference?

Pre-authorization is a transaction/payment operation.

Its purpose is to obtain authorization from the issuer and reserve funds without immediately completing the payment.

Manual capture is a capture strategy.

It means that after authorization, the merchant explicitly decides when to capture the payment, rather than the system automatically capturing it.

That’s an important distinction.

Pre-Authorization
      ↓
Authorization approved
      ↓
Funds reserved
      ↓
Merchant waits...
      ↓
Manual Capture
      ↓
Financial completion
      ↓
Settlement

Why separate authorization from capture?

Because sometimes the final amount isn’t known when the customer presents the card.

Hotels are the classic example, but the same concept appears in:

Car rentals
Fuel stations
Restaurants
Deposits
Mobility services
Other businesses where the final amount may change

This separation gives the merchant flexibility while still obtaining assurance that funds are available.

One subtle but important point

You may see APIs that expose something conceptually similar to:

authorize(amount = €300, capture = false)

        ↓

payment = AUTHORIZED

        ↓

capture(amount = €250)

        ↓

payment = CAPTURED

That can make pre-authorization and manual capture look like two names for the same feature.

They’re not.

They describe different parts of the payment lifecycle:

Pre-authorization answers:

“Should we reserve these funds?”

Manual capture answers:

“When should we actually capture the authorized funds?”

Understanding that distinction becomes especially important when designing payment APIs, POS systems, retries, reversals, authorization expiry, incremental authorizations, and partial captures.

In payments, AUTHORIZED and CAPTURED are states worth treating very differently.

–

Why Your Favorite Hotel Doesn’t Actually Charge You at Check-in: The Subtle Art of Pre-Auth vs. Manual Capture

Introduction: The Invisible Hand of Modern Payments

When you check into a hotel or pick up a rental car, you are often asked for a credit card “to keep on file.” Minutes later, a notification pings your phone showing a “pending” transaction or a “hold” on your account. While it looks like a standard charge, the merchant hasn’t actually taken a cent. This common experience is driven by the invisible hand of two distinct but frequently conflated payment concepts: Pre-authorization and Manual Capture. While they often work in tandem, they serve radically different purposes in the payment lifecycle—one is about permission, while the other is about execution.

The €50 Gap: Why Reserving Isn’t Taking

To understand how this works, we have to look at the “Hotel” mental model. When you arrive at the front desk, the merchant doesn’t know your final bill. Between room service, the minibar, and potential extensions, the total is a moving target. To protect themselves, the hotel performs a pre-authorization.

The system essentially asks the card issuer: “Can I reserve €300 on this card?” The issuer says “Approved,” and those funds are set aside, but the transaction remains incomplete. The real magic happens at checkout. If your final bill is only €250, the merchant explicitly requests a capture for that specific amount. The payment system then settles the €250 and releases the remaining €50 back to your credit limit. This separation provides a safety net, ensuring funds are available without locking the merchant into an incorrect initial price.

“Pre-authorization reserves the money. Manual capture takes the money.”

Operation vs. Strategy: A Technical Cheat Sheet

For developers and systems architects, treating these as the same feature is a mistake. They represent two entirely different layers of payment logic:

Pre-authorization is a payment operation. It is the technical transaction used to obtain authorization from the issuer and reserve funds without immediately finalizing the payment.
Manual capture is a capture strategy. It is the merchant’s intentional decision to delay the settlement of an authorized transaction, explicitly choosing when to trigger the financial transfer.

Distinguishing between the operation and the strategy is vital for anyone designing APIs or POS systems. It allows for more complex workflows, such as incremental holds (adding more to the reservation) or partial captures, which are impossible in a “one-click” settlement world.

The Variable Total Problem: Why Fixed Charges Fail

In many industries, the final price is a mystery until the service is complete. Without the flexibility of separating authorization from capture, merchants would be trapped in a nightmare of constant refunds and multiple small, expensive transactions. This model is the lifeblood of several key sectors:

Hotels and Hospitality: Adjusting for incidental charges or extended stays.
Car Rentals: Managing fuel refills, damage, or extra mileage fees.
Fuel Stations: Securing a “hold” amount before the pump is even activated.
Restaurants: Allowing the merchant to add a tip to the total after the initial card swipe.
Mobility Services: Securing deposits for shared bikes, scooters, or equipment.

The capture=false Conceptual Trap

In many modern e-commerce APIs, this entire process is often reduced to a single flag, such as capture=false. While this simplifies integration, it creates a “conceptual trap” for developers. It makes pre-authorization and manual capture look like two names for the same feature, when in reality, they describe different worlds within the payment lifecycle.

To build a robust system, you must treat AUTHORIZED and CAPTURED as distinct states that answer different questions:

Pre-authorization: “Should we reserve these funds?”
Manual capture: “When should we actually capture the authorized funds?”

Treating these as unique states is the only way to effectively manage the “messy” parts of payments, such as authorization expiry (where a hold disappears after a few days) or reversals where a service is canceled and the funds must be released instantly.

Conclusion: Designing for the Lifecycle

Mastering the payment lifecycle is what separates a rigid checkout system from a professional-grade financial engine. While e-commerce has popularized the “instant charge,” the physical world of hospitality and transport requires a much more nuanced approach.

It is also critical to remember the role of infrastructure: in POS and SoftPOS environments, EMV and acquirer rules introduce further complexity. Card schemes like Visa and Mastercard often model authorizations and “completions” differently than a simple e-commerce API would, requiring strict adherence to timing and messaging rules. By recognizing that authorized funds are not yet captured funds, businesses can design smarter, more resilient workflows.

As you interact with payment systems today, look for the “invisible” hold: How would your own business or daily workflow change if you lost the ability to decide exactly when to take the money?