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.

Requirements

Incremental authorisation requires 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
	Mastercard	All cards
	Visa	All except Vpay
	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.

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 with authorisation_type: pre_authorisation and capture_mode: manual via the Merchant API.
2. Customer makes a payment via your chosen card payment integration.
3. Order reaches authorised state with funds reserved.
4. Additional charges occur during service delivery (minibar, fuel, etc.).
5. Your server increments the authorisation with the new total amount.
6. Order temporarily enters processing state while the increment is being processed.
7. 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
8. When service completes, capture the final amount.

Before you begin​

Ensure you have:

• Active Revolut Business account with Merchant capabilities
• API credentials for the Merchant API
• Understanding of 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 with the following parameters:

Request body

{
  "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: Offers an embedded checkout form with card payment options.
• Revolut Pay: Customers can use Revolut Pay to pay with their cards (account-to-account (A2A) payments not supported for pre-authorisation).
• Card payments: Our widget accepts most major credit and debit cards. This is a familiar and widely used payment method.
• Apple Pay or Google Pay: Provides a quick and convenient checkout experience, if the underlying card supports pre-authorisation.
• Hosted Checkout Page: 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 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.

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:

Configure a webhook URL to receive real-time notifications:

Webhook payload

{
  "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 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.

4. Increment the authorisation amount​

When additional charges occur (e.g., minibar usage), call the Increment authorisation endpoint:

Request body

{
  "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:

Response body

{
  "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:

Configure a webhook URL to receive real-time notifications:

Webhook payload

{
  "event": "ORDER_INCREMENTAL_AUTHORISATION_AUTHORISED",
  "order_id": "6920869a-8d8d-aefd-a3c3-8fe4690e4323"
}

When you receive an increment event, retrieve the full order details 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.

6. Handle multiple increments (if needed)​

You can increment multiple times, up to 5x the initial amount:

Request body

{
  "amount": 15000,  // Adding another £25 to £125 = £150 total
  "reference": "CHG-67891"
}

Increment limits

Two limits apply to incremental authorisation:

1. The sum of all increment amounts can be up to 5x the initially authorised amount
2. 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).

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:

Use the Capture an order endpoint 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.

Capture before expiry

You must capture before the clearing window expires. Check the capture_deadline parameter in your order details, or see: Clearing windows for scheme-specific details.

8. (Optional) Cancel the payment​

If the service is cancelled or not delivered, you can cancel the 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).

Note

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.

---

Success

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:

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.

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	-

Caution

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.

Note

Any test card 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:

amount = currently authorised amount + delta

Tip

Example - currently authorised amount: 10000

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

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 - Learn about pre-authorisation basics
• Clearing windows - Detailed card scheme and Merchant Category Code (MCC) clearing window rules
• Authorise a payment to capture later - Basic manual capture tutorial

API references:

• Increment authorisation
• Create an order
• Retrieve an order
• Capture an order

Related resources:

• Order and payment lifecycle
• Work with webhooks