Merchant API version `2026-04-20` is now available. It introduces an updated 3DS device fingerprinting flow for direct API integrations and extends the `cancel_authorised_after` window to 30 days for pre-authorisation orders.

## What's new in `2026-04-20`

### Updated 3DS fingerprint flow

The 3DS device fingerprinting step now returns `fingerprint_html` - a base64-encoded, fully constructed HTML page that you decode and render in your frontend. Revolut builds the HTML; your integration just renders it.

Previously, the `Three-Ds-Fingerprint` challenge type returned `fingerprint_url` and `fingerprint_data` fields intended for internal use only. The new `fingerprint_html` field replaces both with a single, render-ready payload:

```json
{
  "type": "three_ds_fingerprint",
  "fingerprint_html": "PCFET0NUWVBFIGh0bWw+..."
}
```

:::warning [Breaking change]
`fingerprint_url` and `fingerprint_data` are not present in version `2026-04-20`. If your integration processes the `three_ds_fingerprint` challenge type, migrate to `fingerprint_html` when adopting this version. Earlier versions continue to work unchanged.
:::

### Extended `cancel_authorised_after` for pre-authorisation

The `cancel_authorised_after` parameter now supports up to **30 days** (`P30D`) for pre-authorisation orders, matching the maximum clearing window available for those orders. The 7-day (`P7D`) maximum for final authorisation orders is unchanged.

| Order type | Maximum `cancel_authorised_after` |
|------------|----------------------------------|
| `pre_authorisation` | 30 days (`P30D`) |
| `final` | 7 days (`P7D`) |

This applies both when creating an order and when updating it in `authorised` state.

### Pre-authorisation payment method restriction now enforced at the API level

Pre-authorisation orders now explicitly reject unsupported payment methods at the API level. Card, Apple Pay, and Google Pay are supported. Revolut Pay account-to-account (A2A), Pay by Bank, and SEPA Direct Debit are not supported for pre-authorisation - this was already the case, but is now enforced server-side and reflected in the API schema.

## How to adopt the new version

Set the `Revolut-Api-Version` request header to `2026-04-20`:

```http
Revolut-Api-Version: 2026-04-20
```

If your integration does not handle the `three_ds_fingerprint` challenge type, you can adopt the new version without any code changes. If you do handle it, update your challenge handling to use `fingerprint_html` before switching versions.

## Get started

- [API versions reference](/docs/guides/merchant/reference/versioning/api-versions) - full list of versions and their supported endpoints
- [Create an order](/docs/api/merchant#create-order) - updated schema for version `2026-04-20`
- [Pre-authorisation guide](/docs/guides/merchant/operations/capture-and-settlement/advanced-authorisation/pre-authorisation) - using `cancel_authorised_after` with pre-authorisation orders