V3

Overview

• Minimum PHP raised to >= 8.1 (dropped PHP 7.3 and 7.4).
• Upgraded dependency to mollie/mollie-api-php V3 (typed request/response API).
• Removed Orders API integration; Payments API is now used exclusively.
• Queue-based transaction processing enabled by default.
• E2E tests migrated from Cypress to Playwright
• Payment Method configuration updated.
• Increased PHPStan and PHP Codesniffer levels
• Handle refunds from external sources (Mollie Dashboard)
• Optional invoices
• Cancel order on manual checkout return

Requirements

• PHP: >= 8.1
• mollie/mollie-api-php: ^3.3

Breaking Changes

• Update of mollie/mollie-api-php to ^3.3

• Orders API support removed

  • Removed Orders API client and wrappers: all classes under Model/Client/Orders/* and Service/Mollie/Wrapper/OrdersEndpointWrapper.php are deleted.
  • All transaction creation now goes through the Payments API (Model/Client/Payments).
  • Custom code relying on Orders API classes or response shapes must be refactored to use the Payments API flow.

• PHP 7.3/7.4 dropped; PHP 8.1+ required

• Removed deprecations

• Removal of Klarna Pay Later, Klarna Pay Now & Klarna Slice it

  • For old orders that need to be refunded, please use the Mollie Dashboard.

Pre-release testing

First of all: Please only test this on a local, test, or staging environment. Do not deploy this to production.

Make sure you have jq available on your system, and then run this command to update all packages to the latest version:

jq '
  # Always ensure replace section exists and has the hyva-themes entry
  .replace = (.replace // {}) + {"hyva-themes/magento2-mollie-theme-bundle": "*"} |

  # Update all existing mollie/* packages to 3.0.0-RC2
  if .require then
    .require |= with_entries(
      if .key | startswith("mollie/") then
        .value = "3.0.0-RC2"
      else
        .
      end
    )
  else
    .require = {}
  end |

  # Ensure mollie/magento2 is in require with correct version
  .require["mollie/magento2"] = "3.0.0-RC2" |

  # If hyva-themes/magento2-default-theme exists, add mollie hyva compatibility
  if .require["hyva-themes/magento2-default-theme"] then
    .require["mollie/magento2-hyva-compatibility"] = "3.0.0-RC2"
  else . end |

  # If hyva-themes/magento2-hyva-checkout exists, add mollie hyva checkout
  if .require["hyva-themes/magento2-hyva-checkout"] then
    .require["mollie/magento2-hyva-checkout"] = "3.0.0-RC2"
  else . end
' composer.json > composer.json.tmp && mv composer.json.tmp composer.json && composer update $(jq -r '.require | keys[] | select(startswith("mollie/"))' composer.json) -W

This does a few things:

• If you have the Hyvä theme installed, it will remove the hyva-themes/magento2-mollie-theme-bundle package as it has a hard requirement on the 2.x versions.
• I will update all installed Mollie packages to the v3.0.0-RC2 candidate.
• It will add the Hyvä Compatibility and Hyvä Checkout modules as they no longer get installed through the theme bundle.
• I will run composer update for all installed Mollie packages.

After this follow the normal procedure of clearing your cache, running setup:upgrade and setup:static-content:deploy.

Changes

Handle refunds from external sources (Mollie Dashboard)

In V2 and before, when an refund was created through an external system, for example the Mollie Dashboard, the refund was not processed by Magento. In this version we added this. When a refund is created through any external system, a creditmemo for this amount will be created.

Optional invoices

Got an external system for creating invoices? You can now disable the creation of invoices in Magento and handle them yourself.

You can find this setting under Stores -> Configuration -> Mollie -> Order Management -> Advanced -> Create invoice on successful payment

Cancel order on manual checkout return

Sometimes a customer uses the back button after placing the order to go back to the checkout. When working with low stock products, this may cause issues as the order has not been canceled yet. For this scenario, we added an option to cancel the order when the customer returns to the checkout. Please note that this may cause stock issues in some cases, for example when use user goes back to the payment page and finishes the order, while another customer also orders this product.

You can find this setting under Stores -> Configuration -> Mollie -> Order Management -> Triggers & Languages -> Cancel order on checkout return.

Orders API removal

Mollie has two ways of creating transactions on the platform: Using the Payments API or using the Orders API. The Orders API was introduced to handle more complex (Buy Now Pay Later) payment methods like Klarna and Riverty. These methods need to know each item that is ordered separatly, while the Payments API only required an amount.

A while ago, Mollie deprecated the Orders API, and added support for these order lines in the Payments API. The release of version 3.0 of the mollie/mollie-api-php library removed all support for the Orders API. As the Magento extension builds upon this library, it was a logical step to remove the support for the Orders API too.

Removal of old Klarna methods

Since the introduction of the Klarna method (mollie_methods_klarna), the other Klarna methods are deprecated (klarnapaylater, klarnapaynow, klarnasliceit). As we have removed support for the Orders API, it was a good moment to remove these methods too, as the Payments API doesn't have support for it. If you need to refund orders created using one of these legacy methods, please do that through the Mollie dashboard.

Drop support for PHP 7.4 and 7.3

These PHP versions reached their end of life about three years ago, but where still supported by this extension. As it's barely used anymore, we decided to remove support for it.

This opened the door for us to introduce more strict return types and type hints. That should improve overall reliability.

Enhanced Admin Configuration UI

The Mollie configuration got a big update. The payment method configuration has been restyled. Instead of a long list, each method now is shown as a tile. On top of that, you can directly see which methods are enabled by a color indication.

We also moved a few settings to a new "Order Management" group. We renamed "Advanced" to "Developer Settings".

Queueing is the default

When the webhook from Mollie comes in on a Magento shop, a lot of things happen in a short time. The confirmation email is sent, invoices get created, and this is also emailed to the client. Especially on busy webshops and webshops with a lot of extensions, this sometimes can take a bit too long, causing the update from Mollie's point of view to be "failed".

To mitigate this issue, we introduced well over a year ago a queueing option for order processing. This allowed webhooks to be handled faster when a status updated of the order came in. This option lived behind a feature flag.

After being battle tested by a lot of merchants, we decided to upgrade this to be the default. The option still exists, so you always switch back to synchronous processing.

If you have a consumer whitelist configured, make sure to add mollie.transaction.process. You can run the self test to validate if everything is configured correctly.

Move from Cypress to Playwright

We started using Cypress for End-2-End test a few years ago, and it was great. It catched quite a few bugs that all other tests failed to catch. So we were happy. But as time continued, we bumped into a lot of papercuts. Simple things that you need to install a plugins for (hovering over an element), a hard to understand javascript implementation, and the most annoying of all: hard to debug CI feedback.

That's why we converted the whole test suite to Playwright, and so far it's great. Nothing seems impossible using Playwright, and the trace collected in CI is great for debugging purposes. To top that off, Playwright supports sharding over multiple runners, recuding the End-2-End feedback loop from well over an hour to about 20 minutes.

Per-Method Capture Mode Configuration

New Feature:

Payment methods that support authorization/capture now have individual capture mode settings instead of a single global setting.

Affected Payment Methods:

• Billie
• Credit Card
• MobilePay
• Klarna
• Vipps

Notes

If you need help adapting a customization from Orders API to Payments API, share the relevant code and we’ll suggest a concrete refactor.