There is no fixed time period between our plugin releases. We release if we have an urgent fix, or when we have accumulated a certain amount of changes to release. We recommend upgrading your plugin when we release to benefit from new features and bug fixes.
Follow the steps in the migration guide when upgrading to this version.
New
Installments for tokenized payment methods.
For Klarna payments, the plugin now supports multi-shipping.
We added type declarations to the interfaces in the Api/Data directory.
For payments with card tokens stored in Adobe Commerce Vault, the plugin now mounts the Adyen component on the checkout page, and shoppers need to enter their CVC to complete a payment.
Unit tests for the GiftcardPayment and AuthorisationWebhookHandler classes.
End-to-end test pipeline for the new version.
Changed
The Adyen webhook notification endpoint is changed. See the migration guide to update your webhook URL configuration.
The payment result redirect URL is changed to https://THE_URL_OF_YOUR_STORE/adyen/return.
We renamed AdyenHppConfigProvider to AdyenPmConfigProvider and refactored the code.
Improved
All payment methods are now registered independently on the Adobe Commerce platform. Previously, payment methods were grouped into cards and alternative payment methods, this limited the ability to apply changes to the order of payment methods. With the separation of payment methods to their own files, payment methods will be sorted based on the order you set in your Customer Area.
For integrations set up in Automated mode, it is now possible to choose between creating a new webhook or using an existing webhook when configuring the plugin. Previously, a new webhook was created in the Customer Area each time.
If you use manual capture, the order state will now be set to pending_payment after receiving an AUTHORISATION webhook.
We refactored the interfaces, classes, and .js files related to the /payments/details endpoint.
You no longer need an access token to complete your integration. Previously, the plugin used the Access Control List function of Adobe Commerce which required to set up an integration token and store that token in a front end headless application. This dependency is now removed and you can complete your integration with only customer tokens and guest endpoints.
By default, the payment methods shown to shoppers during checkout are based on their billing address country/region. You can now override this with the ISO Country Code setting.
We refactored our code to use one HTTP client for all transactions. Previously, MOTO transactions used a different HTTP client.
For partial payments with gift cards, the Payment Information block in the admin panel and the Payment method summary shown to shoppers now display the amount paid with the gift card.
For in-person payments, we removed redundant back-end elements and changed the way the plugin handles timeouts to improve implementation.
We refactored the interfaces, classes, and .js files related to the payments-detail endpoint.
Shoppers can now view and remove their tokens for all recurring methods when they are logged in.
For payment requests of guest shoppers, the payment-status endpoint now requires the cardId parameter.
Breaking Changes
The plugin configuration page in Adobe Commerce is restructured to make configuration simpler. The main changes are:
The plugin now stores all token references in the Adobe Commerce Vault. If you previously used Adyen tokenization, we added a script that migrates the tokens to the vault automatically when you upgrade.
When a partial payment with a gift card is placed, you now receive an ORDER_OPENED webhook from Adyen.
Removed
You can no longer configure max_order_total and min_order_total values for payment methods. This reverts the new feature introduced in v8.17.0.
Magento_Paypal dependency.
The notification that pops up when the plugin does not find an API key no longer appears.
Fixed
The country code is now fetched correctly when a logged-in shopper changes the billing address country/region during checkout. Previously, the country code was fetched from the default billing address of the shopper.
Fixed an issue where refunds for partial payments failed because the merchantAccount was missing from the refund request.
When a shopper cancels a credit card payment and changes the payment method to a gift card, the cc_type is now unset. Previously, the cc_type value was not updated correctly to reflect the payment method change.
When the merchantReference field in the webhook body was empty, the webhook stayed at a processing state. The helper now checks if this field is set before executing the webhook processing logic.
For manual capture, orders can now be voided if the shopper does not pay by canceling the invoice before canceling the order. Previously, the plugin created a pending invoice and the order could not be canceled when linked to an invoice.
The Pay button for gift cards now correctly shows the shipping costs if the balance of the gift card covers the full amount.
For shoppers who are logged in, the getDefaultBillingAddress() method is no longer called on the incorrect class.
