# 1.6.3
- PHP 8.3 to 8.5 compatibility verified on Shopware 6.6 and 6.7; minimum PHP version raised to 8.3.
- Full acceptance run (install from ZIP, configuration, widgets, instalment payment, refund) replayed under PHP 8.5 on Shopware 6.6.10 and 6.7.13. The plugin's code emits no deprecation. Only the bundled Alma SDK still calls `curl_close()`, deprecated and without effect in PHP 8.5: one log line, no functional impact.
- Fixed truncated texts in the administration on Shopware 6.7.
- Alma amount limits under each plan ("Alma limits: € - €"), the details of plan loading errors, and the refund, connection test and key deletion messages lost their values because Shopware 6.7 switched to a newer Vue I18n. They display again on both 6.6 and 6.7.
# 1.6.2
- Fixed the "Class \"Alma\API\Client\" not found" error.
- The Alma SDK is bundled with the plugin, but Shopware never loads the `vendor/` autoloader of an extension installed from the Store: it only registers the plugin's own namespace. The plugin now loads it itself on boot.
- Without it, the error appeared on the first use of the SDK — typically the connection test, right after entering the API key — and made the plugin unusable. Affected Shopware 6.6 and 6.7 alike.
# 1.6.1
- Fixed the administration being invisible on Shopware 6.7.
- The plugin only shipped the legacy administration asset format. Shopware 6.7 resolves those assets through Vite entry points only, so the plugin's entire administration bundle was missing (API key management, key selection, payment plan configuration, refund card).
- Worst consequence: the API key selection field rendered no control at all, and saving the configuration page wiped the selected key, disabling Alma on the shop. The plugin now ships both formats and works on 6.6 as well as 6.7.
# 1.6.0
- Fixed a 500 error when activating the plugin on Shopware 6.6.
- The Alma payment method filter called `str_starts_with()` on the payment method technical name without handling `null`. On Shopware 6.6 the `payment_method.technical_name` column may be null: it only became mandatory in 6.7.
- Because that filter decorates the store-api payment method route, it runs on every cart and checkout page: a single third-party payment method without a technical name brought the whole shop down with a 500 error as soon as the plugin was activated.
- The merchant reference is now sent to Alma when the payment is created, instead of after the order is validated.
- The order number is reserved from the Shopware number range as the payment is created, then reused by the order: payments that are created but never completed now carry their reference in the Alma dashboard too.
- Please note: an abandoned payment consumes an order number, so the order numbering may show gaps.
- Merchant reference made more reliable.
- A new hourly scheduled task replays the reference upload when it failed, instead of leaving it permanently lost.
- The reference actually sent is stored in the database, so it can be checked afterwards.
- Shopware 6.7 compatibility: two fixes required to run on 6.7 (no 6.6 regression).
- Plugin install/update: replaced `Connection::PARAM_STR_ARRAY` (removed in Doctrine DBAL 4 / Shopware 6.7) with `ArrayParameterType::STRING`, which works on DBAL 3 and 4. Without this, installing the plugin failed on a 6.7 instance.
- Checkout widget/InPage rendering: the `payment-method.html.twig` override now hooks the `component_payment_method_field` block (present in both 6.6 and 6.7) instead of `component_payment_fieldset_template` (deprecated in 6.6, removed in 6.7). Without this, neither the instalment widget nor the InPage anchor rendered on 6.7.
- InPage payment: fixed a payment failure on custom themes.
- The InPage anchor (the `data-alma-checkout` config div + the Alma SDK loader) is now rendered from the payment-method component (`component/payment/payment-method.html.twig`) instead of the confirm page (`page/checkout/confirm/index.html.twig`).
- Previously, a merchant theme overriding the `page_checkout_confirm` block without calling `parent()` dropped that anchor: the SDK and config were not loaded, the JS plugin had no element to bind to, the form submit was not intercepted, and the order was placed without an Alma payment ("Missing Alma payment ID" failure).
- The anchor is rendered exactly once (on the first eligible Alma payment method), making the InPage flow independent of the theme's page layout.
- IPN webhook: fixed the callback URL on multi-domain shops using a language path prefix.
- The IPN URL sent to Alma (`ipn_callback_url`) is now built from the sales channel domain origin only (`scheme://host[:port]`), dropping any language/path prefix (e.g. `/et`, `/ch`).
- Previously, on a domain such as `https://example.com/et`, the generated URL `https://example.com/et/api/alma/webhook` was intercepted by the Storefront RequestTransformer and resolved outside the `api` scope, causing an HTTP 500 error; the webhook never reached the controller.
- Reconciliation: the Shopware order number is now sent to Alma.
- On payment finalization (`pay()`), the order number is attached to the Alma payment via `order.merchant_reference`, allowing the order to be located from the Alma dashboard.
- Best-effort operation: a failure never interrupts the payment (warning log only).
- Payment flow: the locale is no longer sent to Alma.
- Removed the `locale` field (`fr`) from the payment creation payload sent to the Alma API (`payments.create`).
- The InPage payment iframe no longer forces a locale (`Alma.InPage.initialize`); the `locale` field of the storefront configuration has been dropped.
- As a result, Alma now relies on the customer's browser language (error messages included) instead of forcing French.
- The display widgets (instalment badges on product / cart pages) stay localised in the merchant site language.
- Tests: migrated the `AlmaPaymentHandlerTest` and `OrderAmountFeeExclusionTest` suites to the Shopware 6.6 `AbstractPaymentHandler` API (they still targeted the old 6.5 API). Full backend suite green (255 tests, 0 errors; previously 27 pre-existing errors).
- Added Shopware 6.7 compatibility (the plugin already passed Store review on 6.6):
- Broadened the `shopware/core` and `shopware/storefront` composer constraints to `~6.6.0 || ~6.7.0`.
- Validated end-to-end with `shopware-cli extension validate --check-against highest --store-compliance --full` against Shopware 6.7.10.2 (latest 6.7): 0 errors.
- Confirmed that the migrations done in 1.1.0 (extension of `AbstractPaymentHandler`, `technicalName` on every payment method, Vue 3 strict bindings, attribute-based routing) and in 1.1.2 (removal of `Context::createDefaultContext()` / `SystemSource`, Symfony HTTP client in the commission report) already cover what 6.7 enforces.
- Confirmed that the `ScheduledTaskHandler` constructor already forwards a non-null logger to the parent, matching the new 6.7 requirement.
- Cleaned residual `eslint(@typescript-eslint/no-unused-vars)` warnings in `catch` blocks and one test file.
- Silenced stylelint validation on the third-party Alma SDK CSS bundled under `scss/vendor/_alma-widgets.scss` (no source change to vendor styling).
- Aligned with the Shopware Store automated review feedback (Round #8):
- Removed `!important` declarations from the administration SCSS override (specificity is now carried by a doubled meaningful class).
- Removed two `console.error` calls in the API key detail page; the toast notification flow is now the only error surface.
- Migrated the daily commission report cURL call to the Symfony HTTP client (`http_client`) for proper transport-error handling and testability.
- Removed inline `style=` attributes from the storefront Twig templates (footer banner, PDP widget, checkout data container) and moved the styling to dedicated SCSS classes (`.alma-plugin-info`, `.alma-checkout-data`).
- Added `parent()` calls on every overridden Twig block of the checkout summary total template so the Alma fee row remains additive over the core layout.
- Stopped instantiating `new Context(new SystemSource())` outside CLI / scheduled-task code: `ConfigService::getApiKey()` now takes a `Context` from its caller, threaded through `AlmaClient` and every public method that needs an API client (`getClient`, `getMerchantId`, `fetchPayment`, `partialRefund`, `fullRefund`); the IPN webhook controller receives the `Context` injected by Shopware's `ApiRequestContextResolver`.
- The daily commission report scheduled task handler now uses `Context::createCLIContext()` (the documented CLI / scheduled-task pattern).
- Fixed administration crash on the configuration page when no API key is selected (`sw-entity-multi-id-select` no longer receives a null value).
- Fixed Vue 3 strict event propagation on plan selection and amount fields so the API key dropdown selection and the per-plan min/max amounts are persisted on save.
- Fixed authorization on the Alma fee-plans admin endpoint so the configuration page loads the available plans without a 401 retry.
- Fixed the storefront eligibility widgets so the "Click to find out more" message and the entire widget zone open the Alma details modal as a fullscreen overlay (the Alma SDK CSS was missing from the storefront bundle).
# 1.0.3
- Renamed plugin namespace from AlmaShopwarePayment to SASALMA to match the Shopware Store technical name.
- Changed license from MIT to proprietary to match Shopware Account configuration.
Shopware 
Shopware