> Documentation index: [Saleor](/llms.txt) · [This section](/developer/llms.txt)
> Source: https://docs.saleor.io/developer/app-store/apps/adyen/migration-guides

# Migration guides

This page contains notable functional changes introduced in the Adyen App.

note

We do our best to avoid breaking changes. However, some changes are required. Depending on how the system is configured, some functional changes may be breaking.

Below is the list of changes introduced in Adyen App releases

<a id="v150"></a>

## v.1.5.0

<a id="new-features"></a>

### New features

-   The app now includes client logs for enhanced observability in the following webhooks:
    -   `transaction-process-session`
    -   `transaction-refund-requested`
    -   `transaction-charge-requested`
    -   `transaction-cancel-requested`
    -   Adyen webhook

<a id="cancelation-webhook-improvements"></a>

### CANCELATION webhook improvements

<a id="before-this-release"></a>

#### Before this release

Previously when handling [`CANCELLATION`](https://docs.adyen.com/api-explorer/Webhooks/1/post/CANCELLATION) webhook events from Adyen that didn't have `amount` value, app sent `amount: 0 to` Saleor, which caused Transactions that were cancelled in Adyen to still have `authorizedAmount`, when they should have had:

-   `authorizedAmount`: `0`
-   `cancelledAmount`: previous authorized amount

<a id="after-this-release"></a>

#### After this release

Now app when handling such events, will fetch last known `CANCEL_` event from Saleor and use it's amount or will use `authorizedAmount` or `authorizePendingAmount` on related `TransactionItem` from Saleor.

<a id="incorrect-handling-of-negative-amounts"></a>

### Incorrect handling of negative amounts

<a id="before-this-release-1"></a>

#### Before this release

Previously the app could use a `TransactionEvent` with `amount` that was lower than zero, due to incorrect comparison. This would cause events to be reported incorrectly and potentially break Saleor calculations.

<a id="after-this-release-1"></a>

#### After this release

The app now properly validates amount values, ensuring all transaction events use correct positive amounts in calculations.

<a id="improved-apple-pay-timeout-handling"></a>

### Improved Apple Pay timeout handling

<a id="before-this-release-2"></a>

#### Before this release

Previously Apple Pay related requests had **20s timeout**. This caused sync webhooks to timeout and because of that Saleor ignored app's response.

<a id="after-this-release-2"></a>

#### After this release

After this change app will use 18s timeout, so that it has an error margin for sending the actual response to Saleor.

<a id="v143"></a>

## v.1.4.3

In this release a new feature was added: when making payments app will send [ESD (Enhanced Scheme Details) Level 2 data](https://docs.adyen.com/payment-methods/cards/enhanced-scheme-data/l2-l3/#include-level-2-3-esd-in-your-request) to Adyen. ESD are used in US domestic payments for providing details when purchases are made using corporate, fleet, or purchasing cards.

<a id="before-this-release-3"></a>

### Before this release

No ESD data was sent to Adyen

<a id="after-this-release-3"></a>

### After this release

App will now send following ESD Level 2 fields to Adyen:

-   `enhancedSchemeData.customerReference`: `user.id` will be used, if none is provided app will send string `anonymous`
-   `enhancedSchemeData.totalTaxAmount`: `total.tax.amount` will be sent from the source object (either `Checkout` or `Order` wherever payment is being made)

<a id="v140"></a>

## v.1.4.0

In this release, a functional change was introduced in order to improve handling of `ORDER_CLOSED` notifications from Adyen for Transactions that had failed.

<a id="before-this-release-4"></a>

### Before this release

Previously app didn't handle properly `ORDER_CLOSED` notifications from Adyen with Transactions that had already been rejected (e.g. due to fraud). This resulted in a `chargedAmount` being negative for TransactionItem, which in turn made `totalBalance` on Order and Checkout in Saleor negative. This prevented users from completing checkouts even after successful payment.

<a id="after-this-release-4"></a>

### After this release

Now when Adyen app will handle events related to this case we will:

-   For user order cancellations (`orderCancel` action on `paymentGatewayInitializeSession`): before reporting `REFUND_REQUEST` or `CANCEL_REQUEST` event to Saleor, check if Transaction was already rejected, if so then report `INFO` event instead
-   For `ORDER_CLOSED` Adyen notification item: before reporting `REFUND_REQUEST` or `CANCEL_REQUEST` event to Saleor, check if Transaction was already rejected, if so then report `INFO` event instead
-   For `AUTHORIZATION` with `success: false` Adyen notification item: before reporting `CHARGE_FAILURE` or `AUTHORIZATION_FAILURE` event to Saleor, check if Transaction was already refunded / cancelled, if so then also report `REFUND_FAILURE` or `CANCEL_FAILURE` to revert that previous refund (you can't have both refund and failed payment at the same time).

<a id="v122"></a>

## v.1.2.2

In this release, a function change was introduced to consume an improved Transactions API in Saleor

<a id="before-this-release-5"></a>

### Before this release

If Adyen webhook hasn't received transaction amount, the app fetched transaction history to find it, so it can be returned to Saleor as API contract demands it.

<a id="in-this-release"></a>

### In this release:

Saleor core implemented change in [3.20.32](https://github.com/saleor/saleor/releases/tag/3.20.32) that make amount optional. App will now return null as amount if there is none present in Adyen webhook, and it's allowed for [TransactionEvent.type](/api-reference/payments/enums/transaction-event-type-enum.md) that will be reported by app to Saleor:

-   `CANCEL_FAILURE`
-   `CHARGE_FAILURE`
-   `AUTHORIZATION_FAILURE`
-   `REFUND_FAILURE`
-   `REFUND_REVERSE`
-   `CHARGE_BACK`
-   `INFO`

<a id="v110"></a>

## v1.1.0

In this release we introduced a _client logs_. Now, some of the operations that are performed by the app (webhooks) will be stored and available to access via the Dashboard.

In the future, more events will be stored.

<a id="v0240-september-2024"></a>

## v0.24.0 (September 2024)

This release changes when Transaction metadata will be set, based on Adyen response.

<a id="before-this-release-6"></a>

### Before this release:

Transaction metadata was updated in `transaction-initialize-session`, `transaction-process-session` webhooks and Adyen webhook handler.

In first two webhooks (sync) metadata was set eagerly, but not complete. It was possible that race condition occurred, causing incomplete metadata overwriting the complete one. In the final Adyen webhook, metadata was delayed, but was complete.

<a id="in-this-release-1"></a>

### In this release:

Metadata will not be updated in `transaction-initialize-session` and `transaction-process-session` webhooks. Adyen webhook behavior will stay the same.

Metadata will be set only once, and it will be set lazy. Metadata will be complete.

<a id="migration-guide"></a>

### Migration guide

Prior to this release, you may have been listening to `ORDER_UPDATED`, `ORDER_CREATED`, `CHECKOUT_FULLY_PAID` events to access the Transaction's metadata. After this change the `TransactionItem` object will not have any `metadata` until it is updated by Adyen webhook

To ensure you listen to proper events, subscribe to `TRANSACTION_ITEM_METADATA_UPDATED`. This webhook will execute exactly when metadata is set by Adyen.