# Increase authorised amounts during service delivery

Incremental authorisation allows you to increase the authorised amount on a pre-authorised payment after the initial authorisation has been processed.

This guide shows you how to implement incremental authorisation when charges increase during service.

:::warning[Requirements]
Incremental authorisation requires [pre-authorisation](/docs/guides/merchant/operations/capture-and-settlement/advanced-authorisation/pre-authorisation) with card payments.

Advanced authorisations are only supported for Card Not Present (CNP) transactions.

Support depends on the card brand:

|                  | Card brand | Support level     |
| ---------------- | ---------- | ----------------: |
| :LogoMc\|image:  | Mastercard | All cards         |
| :LogoVisaColour: | Visa       | All except _Vpay_ |
| :LogoMa\|image:  | Maestro    | Limited support   |

**Card scheme clearing window behaviour:**

- **Mastercard**: Each increment extends clearing window by 30 days
- **Visa**: Clearing window does NOT extend with increments

For more details on clearing windows see: [Clearing windows](/docs/guides/merchant/operations/capture-and-settlement/advanced-authorisation/clearing-windows).
:::

## What is incremental authorisation

Incremental authorisation (also called "incremental auth" or "auth increment") is the process of **increasing the total authorised amount** on an existing pre-authorised payment. This allows you to add charges as they occur during service delivery, maintaining a single payment flow with your customer.

### How it differs from standard authorisation

|                        | Standard authorisation   | Incremental authorisation                |
| ---------------------- | ------------------------ | ---------------------------------------- |
| **Amount flexibility** | Fixed at initial auth    | Can be increased up to 5x initial amount |
| **Requires**           | Any order                | Pre-authorisation only                   |
| **Use case**           | Known final amounts      | Variable amounts during service          |
| **Multiple charges**   | Separate payments needed | Single payment with increments           |
| **Clearing window**    | 7 days (typical)         | Inherits from pre-auth (up to 30 days)   |
| **Capture mode**       | Automatic or manual      | Manual only                              |

### Key characteristics

|                     | Details                                                                  |
| ------------------- | ------------------------------------------------------------------------ |
| **Prerequisite**    | Pre-authorisation only (`authorisation_type: pre_authorisation`)         |
| **Amount changes**  | Each increment adds to the currently authorised total                    |
| **Clearing window** | **Mastercard**: extends by 30 days per increment; **Visa**: no extension |
| **Maximum limit**   | Up to 5x the initial authorised amount                                   |

### Use cases

Incremental authorisation is designed for industries where additional charges occur during service delivery:

- **Hotels and lodging** - Authorise room deposit, increment for minibar and services, capture total charges at checkout
- **Car and vehicle rentals** - Authorise rental deposit, increment for fuel and damages, capture total cost at return
- **Equipment rentals** - Authorise estimated cost, increment for extensions and additional equipment, capture based on actual usage
- **Cruise lines and travel** - Authorise cruise deposit, increment for onboard purchases and excursions, capture total when voyage completes
- **Service providers** - Authorise estimated cost, increment for additional materials and labour, capture actual total upon completion

## How it works

Incremental authorisation is a server-to-server integration between the Merchant API and your backend server. Your frontend (website or app) implementation is up to you—this guide focuses on the server-side API interactions.

Incremental authorisation builds on pre-authorisation by allowing you to increase the total authorised amount after the initial payment has been authorised. This lets you add charges as they occur during service delivery.

### Incremental authorisation flow

Here's the step-by-step process:

1. Your server [creates a pre-authorised order](/docs/api/merchant#create-order) with `authorisation_type: pre_authorisation` and `capture_mode: manual` via the Merchant API.
1. Customer makes a payment via your chosen card payment integration.
1. Order reaches `authorised` state with funds reserved.
1. Additional charges occur during service delivery (minibar, fuel, etc.).
1. Your server [increments the authorisation](/docs/api/merchant#increment-authorisation) with the new total amount.
1. Order temporarily enters `processing` state while the increment is being processed.
1. You receive a webhook notification about the increment result, and order returns to `authorised` state:
   - **Success**: Order amount updated to new total
   - **Declined**: Order amount remains at original value
1. When service completes, [capture the final amount](/docs/api/merchant#capture-order).

### Before you begin

Ensure you have:

- [ ] [Active Revolut Business account with Merchant capabilities](/docs/guides/merchant/get-started)
- [ ] [API credentials for the Merchant API](/docs/guides/merchant/get-started)
- [ ] Understanding of [pre-authorisation](/docs/guides/merchant/operations/capture-and-settlement/advanced-authorisation/pre-authorisation)
- [ ] Pre-authorised order in `authorised` state with card payment
- [ ] Server-side integration capability (server-to-server API flow)

## Increment a pre-authorised order

Follow these steps to increment a pre-authorised order and capture the final amount.

### 1. Create an order with pre-authorisation

Call the [Create an order endpoint](/docs/api/merchant#create-order) with the following parameters:

```json [Request body] {4-5}
{
  "amount": 10000,
  "currency": "GBP",
  "capture_mode": "manual",
  "authorisation_type": "pre_authorisation",
  "description": "Hotel booking deposit - Room 101"
}
```

**Required parameters:**

| Parameter            | Description                                                                                               |
| -------------------- | --------------------------------------------------------------------------------------------------------- |
| `capture_mode`       | Set to `"manual"` to separate authorisation from capture, giving you control over when funds are settled  |
| `authorisation_type` | Set to `"pre_authorisation"` to enable extended clearing windows and incremental authorisation capability |
| `amount`             | Initial authorisation amount in minor units (e.g., `10000` = £100.00)                                     |
| `currency`           | Three-letter currency code (e.g., `"GBP"`, `"EUR"`, `"USD"`)                                              |

**Optional but recommended:**

| Parameter                       | Description                            |
| ------------------------------- | -------------------------------------- |
| `description`                   | Helps to identify the transaction      |
| `customer.email`                | For sending receipts and notifications |
| `merchant_order_data.reference` | Your internal order reference          |

### 2. Collect payment from customer

Take a payment from your customer with your preferred payment solution. Incremental authorisation requires card payments, so choose an integration that accepts cards:

- [**Revolut Checkout:**](/docs/guides/merchant/accept-payments/online-payments/revolut-checkout/introduction) Offers an embedded checkout form with card payment options.
- [**Revolut Pay:**](/docs/guides/merchant/accept-payments/online-payments/revolut-pay/introduction) Customers can use Revolut Pay to pay with their cards _(account-to-account (A2A) payments not supported for pre-authorisation)_.
- [**Card payments:**](/docs/guides/merchant/accept-payments/online-payments/card-payments/introduction) Our widget accepts most major credit and debit cards. This is a familiar and widely used payment method.
- [**Apple Pay or Google Pay:**](/docs/guides/merchant/accept-payments/online-payments/apple-pay-google-pay/introduction) Provides a quick and convenient checkout experience, if the underlying card supports pre-authorisation.
- [**Hosted Checkout Page:**](/docs/guides/merchant/accept-payments/online-payments/hosted-checkout-page/introduction) Use payment links to redirect your customers to our self-hosted checkout page with card payment option.

:::tip
You can also authorise payments using a customer's saved payment method via the [Pay for an order](/docs/api/merchant#pay-order) endpoint. The saved payment method must be a card (_Mastercard_ or _Visa_) - Revolut Pay A2A payments are not supported for pre-authorisation.

For more information see: [Charge a customer's saved payment method](/docs/guides/merchant/optimise-checkout/save-payment-methods/charge-saved-payment-method).
:::

:::tip[When the customer completes the payment]

- Funds are reserved (held) on the customer's card
- Order reaches `authorised` state
- Funds remain on hold for up to 30 days (depending on card scheme) - check the `capture_deadline` parameter for the exact deadline
- You control when to increment, settle, or cancel the payment

:::

### 3. Monitor order state

After the customer completes payment, monitor the order state to confirm successful authorisation:

- ![Webhooks (recommended)]

  [Configure a webhook URL](/docs/api/merchant#create-webhook) to receive real-time notifications:

  ```json [Webhook payload] {2}
  {
    "event": "ORDER_AUTHORISED",
    "order_id": "6920869a-8d8d-aefd-a3c3-8fe4690e4323",
    "merchant_order_ext_ref": "Hotel booking #12345"
  }
  ```

  When you receive the `ORDER_AUTHORISED` event, [retrieve the full order details](/docs/api/merchant#retrieve-order) using the `order_id` to confirm the authorisation and check the `capture_deadline`.

  **Handling events:**

  | Event                    | When it fires                       | Recommended action                               |
  | ------------------------ | ----------------------------------- | ------------------------------------------------ |
  | `ORDER_AUTHORISED`       | Payment authorised successfully     | Deliver service, increment charges as they occur |
  | `ORDER_PAYMENT_DECLINED` | Payment declined by issuer/bank     | Notify customer to retry with different card     |
  | `ORDER_PAYMENT_FAILED`   | Technical failure during processing | Customer can retry same payment method           |
  | `ORDER_CANCELLED`        | Order manually cancelled            | No action needed                                 |
  | `ORDER_FAILED`           | Order expired (timeout)             | Create new order if customer returns             |

  When a payment is declined or fails, the order returns to `pending` state and customers can make another payment attempt.

  :::info
  For details on the complete lifecycle, see: [Order and payment lifecycle](/docs/guides/merchant/reference/order-lifecycle).
  :::

- ![Polling]

  Call the [Retrieve an order](/docs/api/merchant#retrieve-order) endpoint at regular intervals.

  ```json [Response body] {5,10-11,23}
  {
    "id": "69726c30-1358-a043-a099-da9a0ef7f931",
    "token": "4749c99d-b744-44aa-88ed-36070470162d",
    "type": "payment",
    "state": "authorised",
    "created_at": "2026-01-22T18:28:00.983427Z",
    "updated_at": "2026-01-22T20:29:17.321172Z",
    "amount": 10000,
    "currency": "GBP",
    "capture_mode": "manual",
    "authorisation_type": "pre_authorisation",
    ...
    "payments": [
      {
        "id": "69728898-34fc-a4bd-8b92-d4f4ea018581",
        "state": "authorised",
        "amount": 10000,
        "authorised_amount": 10000,
        "payment_method": {
          "type": "card",
          "card_brand": "visa",
          ...
          "capture_deadline": "2026-02-21T20:29:16.057Z"
        }
      }
    ],
    ...
  }
  ```

  When the order reaches `authorised` state, funds are successfully reserved on the customer's card. Check the `capture_deadline` to see when you must capture by.

  **Possible order states:**

  | Order state  | Description                              | Next steps                                         |
  | ------------ | ---------------------------------------- | -------------------------------------------------- |
  | `authorised` | Payment authorised, funds reserved       | Proceed with service delivery, increment as needed |
  | `pending`    | Waiting for payment or payment failed    | Customer needs to pay or retry payment             |
  | `processing` | Payment attempt in progress              | Continue polling                                   |
  | `failed`     | Order expired without successful payment | Create new order if needed                         |
  | `cancelled`  | Order cancelled or authorisation expired | Create new order if needed                         |

  :::info
  For details on the complete order lifecycle, see: [Order and payment lifecycle](/docs/guides/merchant/reference/order-lifecycle).
  :::

  :::tip[Payment-level details]
  For advanced use cases, you can also retrieve individual payment attempt details using the [Retrieve payment details](/docs/api/merchant#retrieve-payment-details) endpoint.

  This provides granular information about each payment attempt, which can be useful for detailed analytics or debugging specific payment failures.
  :::

### 4. Increment the authorisation amount

When additional charges occur (e.g., minibar usage), call the [Increment authorisation endpoint](/docs/api/merchant#increment-authorisation):

```json [Request body] {2}
{
  "amount": 12500,
  "reference": "CHG-67890",
  "line_items": [
    {
      "name": "Minibar",
      "type": "service",
      "quantity": {
        "value": 1
      },
      "unit_price_amount": 1500,
      "total_amount": 1500
    },
    {
      "name": "Room service",
      "type": "service",
      "quantity": {
        "value": 1
      },
      "unit_price_amount": 1000,
      "total_amount": 1000
    }
  ]
}
```

**Required parameters:**

| Parameter | Description                                                                                                                                                                             |
| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `amount`  | **The new total amount to authorise** (not the increment value). If current authorised amount is £100.00 (`10000` minor units) and you want to add £25.00, pass `12500` (£125.00 total) |

**Optional but recommended:**

| Parameter    | Description                                                                     |
| ------------ | ------------------------------------------------------------------------------- |
| `reference`  | Your internal charge or invoice ID (e.g., `CHG-67890`, `INV-12345`)             |
| `line_items` | Array of line items for this increment, providing itemised breakdown of charges |

**Immediate response:**

```json [Response body] {4-5,9,14}
{
  "id": "6972e44b-560b-a316-8ce7-1336b23448dd",
  "type": "payment",
  "state": "authorised",
  "amount": 10000,  // Order amount remains at old value until increment completes
  "currency": "GBP",
  "capture_mode": "manual",
  "authorisation_type": "pre_authorisation",
  "incremental_authorisations": [
    {
      "old_amount": 10000,
      "new_amount": 12500,
      "state": "processing",
      "reference": "CHG-67890",
      "line_items": [
        {
          "name": "Minibar",
          "unit_price_amount": 1500,
          "quantity": { "value": 1 },
          "type": "service",
          "total_amount": 1500
        },
        {
          "name": "Room service",
          "unit_price_amount": 1000,
          "quantity": { "value": 1 },
          "type": "service",
          "total_amount": 1000
        }
      ]
    }
  ],
  "payments": [ ... ],
  ...
}
```

The `incremental_authorisations` array appears immediately, tracking your increment request. The order `amount` updates to the new value once the increment is authorised. Monitor the increment progress as described in the next step.

### 5. Monitor increment result

After requesting an increment, monitor the result to confirm whether it was authorised or declined:

- ![Webhooks (recommended)]

  [Configure a webhook URL](/docs/api/merchant#create-webhook) to receive real-time notifications:

  ```json [Webhook payload] {2}
  {
    "event": "ORDER_INCREMENTAL_AUTHORISATION_AUTHORISED",
    "order_id": "6920869a-8d8d-aefd-a3c3-8fe4690e4323"
  }
  ```

  When you receive an increment event, [retrieve the full order details](/docs/api/merchant#retrieve-order) using the `order_id` to check the final authorised amount and increment status.

  **Handling events:**

  | Event                                        | When it fires                                 | Recommended action                                                              |
  | -------------------------------------------- | --------------------------------------------- | ------------------------------------------------------------------------------- |
  | `ORDER_INCREMENTAL_AUTHORISATION_AUTHORISED` | Increment authorised successfully             | Update your system with new authorised amount, continue service                 |
  | `ORDER_INCREMENTAL_AUTHORISATION_DECLINED`   | Increment declined by issuer/bank             | Alert staff, request alternative payment from customer                          |
  | `ORDER_INCREMENTAL_AUTHORISATION_FAILED`     | Technical failure during increment processing | Original authorisation remains valid, retry increment or capture current amount |

  When an increment is declined or fails, the order remains in `authorised` state with the previous amount. You can capture the current amount or request another payment for additional charges.

  :::info
  For details on the complete order lifecycle, see: [Order and payment lifecycle](/docs/guides/merchant/reference/order-lifecycle).
  :::

- ![Polling]

  Call the [Retrieve an order](/docs/api/merchant#retrieve-order) endpoint at regular intervals to monitor the increment status.

  **Response during processing:**

  ```json [Response body] {4-5,13-14,23,27}
  {
    "id": "6972e44b-560b-a316-8ce7-1336b23448dd",
    "type": "payment",
    "state": "processing",  // Order in processing while increment is being authorised
    "amount": 10000,  // Order amount stays at old value during processing
    "currency": "GBP",
    "capture_mode": "manual",
    "authorisation_type": "pre_authorisation",
    "payments": [
      {
        "id": "6972e462-a2cf-a79c-a09e-633d71e63ae4",
        "state": "authorisation_started",
        "amount": 12500,  // Payment amount shows new value during processing
        "authorised_amount": 10000,  // Authorised amount stays at old value
        "payment_method": {
          "type": "card",
          "card_brand": "visa",
          "capture_deadline": "2026-01-30T03:00:55.508Z",
          ...
        }
      }
    ],
    "incremental_authorisations": [
      {
        "old_amount": 10000,
        "new_amount": 12500,
        "state": "processing",  // Increment in progress
        "reference": "CHG-67890",
        "line_items": [ ... ]
      }
    ],
    ...
  }
  ```

  **Response after completion (success):**

  ```json [Response body] {4-5,14,27}
  {
    "id": "6972e44b-560b-a316-8ce7-1336b23448dd",
    "type": "payment",
    "state": "authorised",  // Order returns to authorised state
    "amount": 12500,  // Order amount now updated to new total
    "currency": "GBP",
    "capture_mode": "manual",
    "authorisation_type": "pre_authorisation",
    "payments": [
      {
        "id": "6972e462-a2cf-a79c-a09e-633d71e63ae4",
        "state": "authorised",
        "amount": 12500,
        "authorised_amount": 12500,  // Authorised amount now updated
        "payment_method": {
          "type": "card",
          "card_brand": "visa",
          "capture_deadline": "2026-01-30T03:00:55.508Z",
          ...
        }
      }
    ],
    "incremental_authorisations": [
      {
        "old_amount": 10000,
        "new_amount": 12500,
        "state": "authorised",  // Increment succeeded
        "reference": "CHG-67890",
        "line_items": [ ... ]
      }
    ],
    ...
  }
  ```

  During an increment, several fields change to reflect the processing state:

  | Field                                | Initial state             | During processing             | After completion                            |
  | ------------------------------------ | ------------------------- | ----------------------------- | ------------------------------------------- |
  | `order.state`                        | `"authorised"`            | `"processing"`                | `"authorised"`                              |
  | `order.amount`                       | Old value (e.g., `10000`) | Old value (`10000`)           | New value (`12500`) if succeeded            |
  | `payment.amount`                     | Old value (`10000`)       | New value (`12500`)           | New value (`12500`) if succeeded            |
  | `payment.authorised_amount`          | Old value (`10000`)       | Old value (`10000`)           | New value (`12500`) if succeeded            |
  | `incremental_authorisations[].state` | —                         | `"pending"` or `"processing"` | `"authorised"`, `"declined"`, or `"failed"` |

  <br />

  :::tip[Monitoring tips]
  - Check `order.state`: Poll until it returns to `"authorised"` from `"processing"`
  - Check `incremental_authorisations[].state`: Look for `"authorised"` (success), `"declined"` (issuer rejected), or `"failed"` (technical error)
  - The `incremental_authorisations` array contains the complete history of all attempts (successful and declined)
  - Most recent increment is the last entry in the array
  - If declined, check the `reason` field for details
    :::

  **Increment states:**

  | Increment state | Description                                        | Impact                                                       |
  | --------------- | -------------------------------------------------- | ------------------------------------------------------------ |
  | `"pending"`     | Increment registered, not yet sent to card network | Wait for processing to start                                 |
  | `"processing"`  | Increment being authorised by card network         | Wait for final result                                        |
  | `"authorised"`  | Increment succeeded                                | Order amount updated to new total                            |
  | `"declined"`    | Increment declined by card issuer                  | Order amount remains at previous total, check `reason` field |
  | `"failed"`      | Technical failure (not issuer decline)             | Order amount remains at previous total, retry increment      |

  :::info
  For details on the complete order lifecycle, see: [Order and payment lifecycle](/docs/guides/merchant/reference/order-lifecycle).
  :::

  :::tip[Increment-level details]
  The `incremental_authorisations` array is useful for itemised receipts, audit trails, and analysing decline patterns across multiple increment attempts.
  :::

### 6. Handle multiple increments (if needed)

You can [increment](/docs/api/merchant#increment-authorisation) multiple times, up to 5x the initial amount:

```json [Request body]
{
  "amount": 15000, // Adding another £25 to £125 = £150 total
  "reference": "CHG-67891"
}
```

:::info[Increment limits]
Two limits apply to incremental authorisation:

1. The sum of all increment amounts can be up to 5x the initially authorised amount
1. You can increment maximum 10x per order

**Example with initial £100 authorisation:**

- You can increment by £100 five times (total £500 in increments, max £600 final amount)
- Or increment by £50 ten times (total £500 in increments, max £600 final amount)
- Or any combination respecting both limits

You can also increment with the same amount to extend the capture deadline without adding charges (Mastercard only).
:::

:::tip[Process sequentially]
Process increments one at a time. Wait for each increment to complete (return to `authorised` state) before initiating the next increment. This reduces the risk of declines.
:::

### 7. Capture the final amount

When you're ready to finalise the transaction (e.g., when guests are checking out), capture the authorised order:

- ![Merchant API]

  Use the [Capture an order endpoint](/docs/api/merchant#capture-order) in the Merchant API to capture the payment. You can choose from two approaches:
  - **Full capture:** Send the request without a body to capture the full incremented amount.
  - **Partial capture:** Send the request with a specific amount in the body to capture a partial amount of what was authorised after all increments. The remaining amount will be automatically released back to the customer's card. For more information see: [Partial capture](/docs/guides/merchant/operations/capture-and-settlement/capture-later#partial-capture).

  :::warning[Capture before expiry]
  You must capture before the clearing window expires. Check the `capture_deadline` parameter in your order details, or see: [Clearing windows](/docs/guides/merchant/operations/capture-and-settlement/advanced-authorisation/clearing-windows) for scheme-specific details.
  :::

- ![Revolut Business]

  :::info
  On the Revolut Business dashboard, you can only capture the **full amount**.
  :::

  To capture the authorised amount using Revolut Business, follow these steps:
  1. Log in to [Revolut Business](https://business.revolut.com).
  1. Navigate to the :Cart: **Merchant** menu on the sidebar.
  1. Select an authorised payment, and click :Check: **Capture** on the overview panel.
  1. Click **Capture order** in the pop-up to confirm the capture.
  1. Once the capture is successful, the order will proceed to the processing stage.

### 8. (Optional) Cancel the payment

If the service is cancelled or not delivered, you can [cancel the order](/docs/api/merchant#cancel-order). The amount will be immediately voided and returned to your customer's card, providing a much faster experience than standard refunds (which typically take 5-7 days).

:::info
Once a payment has been captured, you can no longer cancel it. Captured payments can only be refunded using the standard refund process.

For more information see: [Refund payments](/docs/guides/merchant/operations/refunds).
:::

---

:::tip
You've completed the incremental authorisation tutorial!

You now know how to increase authorised amounts during service delivery, allowing you to add charges as they occur while maintaining a single payment flow with your customer.
:::

## Scheme-specific behaviour

Card scheme rules significantly impact how incremental authorisation works, particularly regarding clearing window extension:

:::info[Clearing window differences]

- **Mastercard:** Each successful increment extends clearing window by **30 days**
- **Visa:** Clearing window does **NOT extend** with increments (fixed from initial authorisation)

For MCC-specific rules and best practices see: [Clearing windows](/docs/guides/merchant/operations/capture-and-settlement/advanced-authorisation/clearing-windows).
:::

### Mastercard example

**Initial 30-day window with extension:**

|                   | Event                     | Authorised amount | Clearing window expires    |
| ----------------- | ------------------------- | ----------------- | -------------------------- |
| **Day 0**         | Initial pre-authorisation | £100              | Day 30                     |
| **Day 15**        | First increment           | £150              | Day 45 (extended +30 days) |
| **Day 35**        | Second increment          | £200              | Day 65 (extended +30 days) |
| **Before day 65** | Capture                   | £200              | —                          |

### Visa example

**Fixed 30-day window (Lodging MCC) without extension:**

|                   | Event                     | Authorised amount | Clearing window expires |
| ----------------- | ------------------------- | ----------------- | ----------------------- |
| **Day 0**         | Initial pre-authorisation | £100              | Day 30 (fixed)          |
| **Day 15**        | First increment           | £150              | Day 30 (no extension)   |
| **Day 25**        | Second increment          | £200              | Day 30 (no extension)   |
| **Before day 30** | **Must capture**          | £200              | —                       |

:::warning
Visa clearing windows **do NOT extend** with increments:

- Note the `capture_deadline` from the initial authorisation - this remains fixed throughout all increments
- Plan all increment timing within the original window
- Ensure final capture occurs before this fixed deadline
- For comparison: Mastercard extends the clearing window by 30 days with each increment, but Visa does not

:::

---

## Test in the Sandbox environment

Incremental authorisation is supported in the Sandbox environment. The test outcome of each increment depends on the **delta** - the difference between the `amount` you pass in the increment request and the **currently authorised amount** (`authorised_amount` on the payment at call time). The currently authorised amount may differ from the initial pre-authorised amount if any previous increments have already succeeded.

:::info
Any [test card](/docs/guides/merchant/test-and-go-live/testing/test-cards) can be used for the initial payment. In the Sandbox environment, using all test cards (including error test cards) result in `authorised` state when completing a pre-authorised payment.
:::

:::tip
The standard incremental authorisation limits apply in the Sandbox environment: up to **5× the initial authorised amount** across all increments, and a maximum of **10 increments** per order.

Use a large enough initial order amount to avoid hitting the 5× limit with the test deltas - for example, an initial amount of `10000` gives ample headroom for the test amounts below.
:::

### Increment outcomes

The outcome depends on the **delta** you create:

| Delta           | Increment state |
| --------------- | --------------- |
| `34543`         | `failed`        |
| `23432`         | `declined`      |
| Any other value | `authorised`    |

Use this formula, to calculate the `amount` to pass in the increment request:

```math
amount = \text{currently authorised amount} + \text{delta}
```

:::tip
**Example - currently authorised amount: `10000`**

| Target increment state | Delta   | Request `amount` |
| ---------------------- | ------- | ---------------- |
| `failed`               | `34543` | `44543`          |
| `declined`             | `23432` | `33432`          |
| `authorised`           | `5000`  | `15000`          |

:::

:::info[Sequential increments]
The delta is always calculated against the **currently authorised amount** at the time of each request:

- After a **`failed` or `declined`** increment, the currently authorised amount is unchanged - the same `amount` value will re-trigger the same outcome on the next attempt.
- After an **`authorised`** increment, the currently authorised amount updates to the new total - you must recalculate the `amount` to pass in your increment request before your next test.

The example below starts with an initial pre-authorised amount of `10000` and shows how the base shifts:

| Step | Current `authorised_amount` | Target increment state | Delta   | Request `amount` | New `authorised_amount` |
| ---- | --------------------------- | ---------------------- | ------- | ---------------- | ----------------------- |
| 1    | `10000`                     | `failed`               | `34543` | `44543`          | `10000`                 |
| 2    | `10000`                     | `failed`               | `34543` | `44543`          | `10000`                 |
| 3    | `10000`                     | `authorised`           | `5000`  | `15000`          | `15000`                 |
| 4    | `15000`                     | `failed`               | `34543` | `49543`          | `15000`                 |

- **Steps 1 and 2**: The increment results in `failed` both times. The currently authorised amount stays at `10000`, so the same `amount` (`44543`) re-triggers the failure.
- **Step 3**: The increment to `15000` succeeds (delta `5000`). The currently authorised amount updates to `15000`.
- **Step 4**: To trigger another failure, the `amount` must be recalculated: `15000 + 34543 = 49543`. Reusing `44543` from steps 1-2 would produce a delta of `29543` instead - a different value - and would result in a successful increment.
:::

---

## What's next

**Explore related topics:**

- [Pre-authorisation](/docs/guides/merchant/operations/capture-and-settlement/advanced-authorisation/pre-authorisation) - Learn about pre-authorisation basics
- [Clearing windows](/docs/guides/merchant/operations/capture-and-settlement/advanced-authorisation/clearing-windows) - Detailed card scheme and Merchant Category Code (MCC) clearing window rules
- [Authorise a payment to capture later](/docs/guides/merchant/operations/capture-and-settlement/capture-later) - Basic manual capture tutorial

**API references:**

- [Increment authorisation](/docs/api/merchant#increment-authorisation)
- [Create an order](/docs/api/merchant#create-order)
- [Retrieve an order](/docs/api/merchant#retrieve-order)
- [Capture an order](/docs/api/merchant#capture-order)

**Related resources:**

- [Order and payment lifecycle](/docs/guides/merchant/reference/order-lifecycle)
- [Work with webhooks](/docs/guides/merchant/monitor-and-observe/webhooks/using-webhooks)