Skip to content

Backport

What?

We continuously improve our API's whilst supporting as many integrations as possible.

To achieve this, we've made it possible to use the latest features—particularly for payments—allowing you to build integrations with our newest improvements without forcing customers to upgrade their entire checkout.

Why?

This brings significant benefits to PSPs, agencies, and merchants alike, ensuring they can always remain up-to-date with security improvements without needing to invest in an immediate upgrade.

We keep upgrades to a minimum and maintain backwards compatibility wherever possible.

How?

Every customer with a Hyvä Checkout licence can now require hyva-themes/magento2-hyva-checkout-frontend-api.

We aim to release a new version of this backport module whenever a new release of the main Hyvä Checkout package is published.

This may not always happen on the same day, but we recommend keeping an eye out for new releases, as they are safe to install.

We only release a new version when we've actually changed files related to the backport.

Installation

  1. Configure the Hyvä packagist.com repository as a composer source 

    # This command adds your key to your projects auth.json file
# Replace yourLicenseAuthenticationKey with your own key
composer config --auth http-basic.hyva-themes.repo.packagist.com token yourLicenseAuthenticationKey
# Replace yourProjectName with your project name
composer config repositories.private-packagist composer https://hyva-themes.repo.packagist.com/yourProjectName/

  2. Require the hyva-themes/magento2-hyva-checkout-frontend-api package using composer: 

    composer require 'hyva-themes/magento2-hyva-checkout-frontend-api'

Future

The module's initial intent was to support only payment and security improvements. We are now exploring the possibility of including more JavaScript-specific upgrades in the backport module. At the time of writing, there is no clear roadmap for this yet.

Insights

The backport itself is quite straightforward, and we strive to keep things simple.

Admittedly, it does require some effort by us to match each version with the latest code, but the benefits gained are undeniable.

Structure

Starting with the view folder and layouts, we've only overwritten those templates that belong to the Frontend API and have a clear connection with, for example, payments.

These blocks have been referenced and given new templates. Therefore, if your customisation does overwrite any of these files—even those we've marked as internal—we encourage you to review them closely.

Secondly, we have a Preference folder that contains only PHP objects which we were certain also existed in the supported version. A preference is only needed if certain methods have been added in between versions to restore compatibility.

Then, we've added an Origin folder, following a nested folder structure that mirrors the Hyvä Checkout package folder structure. This keeps things organised and easy to maintain. Only those classes that were completely missing have been added here, immediately marked as deprecated to ensure you don't use them on an older version.

At some point, the package will no longer be needed once the merchant decides to upgrade their checkout.

Some other classes are added here and there purely to maintain forwards-compatibility for missing elements, such as providing configuration to the frontend on page loads and Magewire subsequent upgrade requests.

FAQ

Can this module be installed when running the latest version?

Yes, but bear in mind that this module takes priority over the core files, meaning that if you've made any overwrites to the core, you'll need to adjust them.

In theory, this should never be the case, as most overwritten files are marked as @internal and should not be altered.

When and why do I need this module?

This module aims to make API features that don't yet exist in older versions of the checkout available. Not every feature is included, but rather those most common to PSP and shipping integrators.

Note that early versions of the module are primarily aimed at payment-related areas, and we will expand further based on demand.

If you have multiple modules that require this backport, always try to use the latest version. Therefore, vendors that require this module should use * or come up with a requirement strategy that ensures the latest version is installed.