Migration guides
This page contains notable functional changes introduced in the Adyen App.
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
v.1.x.x
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
CANCELATION webhook improvements
Before this release
Previously when handling 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
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.
Incorrect handling of negative amounts
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.
After this release
The app now properly validates amount values, ensuring all transaction events use correct positive amounts in calculations.
Improved Apple Pay timeout handling
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.
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.
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 to Adyen. ESD are used in US domestic payments for providing details when purchases are made using corporate, fleet, or purchasing cards.
Before this release
No ESD data was sent to Adyen
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 stringanonymous
enhancedSchemeData.totalTaxAmount
:total.tax.amount
will be sent from the source object (eitherCheckout
orOrder
wherever payment is being made)
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.
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.
After this release
Now when Adyen app will handle events related to this case we will:
- For user order cancellations (
orderCancel
action onpaymentGatewayInitializeSession
): before reportingREFUND_REQUEST
orCANCEL_REQUEST
event to Saleor, check if Transaction was already rejected, if so then reportINFO
event instead - For
ORDER_CLOSED
Adyen notification item: before reportingREFUND_REQUEST
orCANCEL_REQUEST
event to Saleor, check if Transaction was already rejected, if so then reportINFO
event instead - For
AUTHORIZATION
withsuccess: false
Adyen notification item: before reportingCHARGE_FAILURE
orAUTHORIZATION_FAILURE
event to Saleor, check if Transaction was already refunded / cancelled, if so then also reportREFUND_FAILURE
orCANCEL_FAILURE
to revert that previous refund (you can't have both refund and failed payment at the same time).
v.1.2.2
In this release, a function change was introduced to consume an improved Transactions API in Saleor
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.
In this release:
Saleor core implemented change in 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 that will be reported by app to Saleor:
CANCEL_FAILURE
CHARGE_FAILURE
AUTHORIZATION_FAILURE
REFUND_FAILURE
REFUND_REVERSE
CHARGE_BACK
INFO
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.
v0.24.0 (September 2024)
This release changes when Transaction metadata will be set, based on Adyen response.
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.
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.
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.